Auto-Join instance perks should not count towards instance cap
_Silent
I understand the need and perk of being able to jump the queue of events. I understand that it is necessary to be able to hop in to provide moderation and troubleshooting help and skip the queue. But when there are so many people who have this ability who also participate in the community and attend large events, it makes trying to go to these events as a regular vrchat user frustrating. High profile events are already hard to get into requiring long waits for people to leave those parties. So it's even more frustrating when events reach well above 80 attendees requiring the number to drop below 80 to allow people from queue in.
I think this perk has a use case and is okay to exist, I just think it should either bump the instance cap or not apply to it at all.
Log In
CodeLaurel
I think an okish solution would be to have 16 staff slots
- host (always gets assigned to it)
- 3 staff (should be enough for a 80 instance moderation)
- 6 DJ/VJ
- 6 extra slots for support or other needs, like vrcdn people trying to fix stream or more DJ/VJ
For any other staff people trying to join, they get asked if they are acting as staff or not
- if they aren't they behave like normal users
- if they are, they get added at the 1st position in queue
- - If a normal slot becomes free they go in as normal user
- - if a staff slot becomes free they go in as staff
(this doesn't change their staff privileges, just what slot group they occupy)
For normal users (with or without prio queue)
- if a normal slot becomes free they go in as normal
- if a staff slot becomes free nothing happens and is left free for other staff members to join
Worst case scenario you have some staff that really needs to get in, you are supposed to have communication with your staff to tell them to get out of the instance to let the one that really needs to get in... in, and should be fine cause they'll get prio in queue to get back in as soon as possible.
I also think 16 extra spots shouldn't be a great problem, as i believe vrchat has taken into consideration the limits and given us conservative instance capacities just in case.
This system would still be abusable, like making a lot of people be staff so they get absolute priority... but that's a problem we already have not an added one, meanwhile i think this would solve most of the problem for those venues that don't abuse it.
Toothbrush
These defeats the entire purpose of instance caps and would be immediately abused. Forcibly allowing instances to exceed 80 would negatively affect the entire instance which is likely already having issues due to 80 people being there. I know no one wants to hear it, but not everyone is meant to make every party.
_Silent
Toothbrush I'm more trying to address the fact that there are people who do already have the power to jump queue and instantly get into an instance making events exceed 80 where there's cases where we see parties get to 87/80 leaving those who don't have that ability waiting in queue. It's already a thing taking place, where if you don't have this ability you are left waiting far longer than if this ability did not exists. Now the pool of people who have this ability is small, but it's disruptive enough to make it hard for regular users to attend high profile events. I'm not saying people who throw events should have the power to push anyone they want into the instance. Just in the case when people who do have these abilities use them, I don't think it should effect the regular VRchat user.
Toothbrush
_Silent mismanagement of an event is on the people who run it. It is not justification for vrchat to make a change that would be heavily abused and put stress on the system. Any changes made have to be done with the expectation of the worst intentions because that is how the playerbase will inevitably use it.
Vesturo
Toothbrush you know it's only people with a special staff tag that can ignore queue and caps right? it's quite literally an issue on VRChats end if that happens because their staff uses their permissions to skip queue and instance limits
D
Docteh
One thing that's important for VRChat to do is consider how features can be abused. So if you allow staff to join and have over 80, how many over 80 do you allow? Well if you assign things right it's easy to consistently have more than 80.
Last year I heard about some large capacity instances with a limit of 200. I'm hoping they try it again, I want to see how badly my pc handles it.
ZenithVal
Docteh Betting we'll see it again during US new years hours.
DarkSwordsman
I understand where this feature is coming from, but I guess I'm not understanding what the solution here would be.
If we were to allow priority users to bypass the instance limit, where do we draw the next threshold? 10? 20? 30+? How do we determine the limit that should be allowed before the instance collapses from performance issues or bugs?
I guess I just don't understand how to mitigate the issue this feature will cause, which is unstable instances from too many people joining, and drawing a line beyond that to allow priority users in feels arbitrary.
Shouldn't the priority feature already work with soft and hard caps? A world creator can set their soft threshold to, say, 60 or 70 users, and the hard cap to 80, which leaves some room. But it then makes it harder for people to join the instance.
I understand the core desire is "it'd be nice if we could have hundreds or thousands of people in an instance", but we will just keep running into this issue all the time as VRChat grows.
We need a fundamental change to how instances work if we truly want to solve this problem. It'd probably include a culture shift in how we understand and use instances.
ellaris
DarkSwordsman this isnt a priority queue though, that already exists. this is if staff or mods join an instance, they dont affect the queue in place. so if an 80/80 instance has a staffer join it goes to 81/81, but the 1st person in queue doesnt have to now wait for 2 people to leave to get it below 80. they sit in queue as if it was still 80/80.