Tiered priority queue for large events.
Rantis
The queue system is very handy for large events and venues that get full quickly, however larger venues are starting to offer fastpasses via the ingame currency to guests that want to support the venue and "skip the line" while I think this is a great avenue to give the community something more tangible in exchange for supporting the hard work that goes into putting together these large shows the current queue system isent really designed for tiered entry.
At large venues typically hosts, technicians, performers, and other staff get priority as they NEED to be able to traverse multiple instances and be able to get into the main instance quickly to do their tasks. The current system has no way to distinguish key guests and staff that NEED access from paid ticket holders.
An issue I ran into as a performer at C&DFest is the organizers advertised vip tickets to skip the line and encouraged free guests to queue up for the main instance and hang out in an overflow, it led to a situation where as a performer I still had to wait 40 or so minutes behind paid guests to get into the instance to preform, we had to switch instances on several occasions to keep on schedule due to performers or staff on the recording team not being able to get in.
I propose that the queue system be expanded to specify different priority tiers, venues could, for example: prioritize staff, then performers, then paid ticket holders, then general admission.
I didn't see a canny post for this since paid "VIP" access using the queue system is a relatively recent idea that's starting to make the rounds between event organizers and is already seeing implementation at larger events like TubeVR and Nurtured 3.
Log In
Zono Ken
Got more votes for the same thing here: https://feedback.vrchat.com/feature-requests/p/set-group-roles-with-forced-entry-rights-to-group-instances
Fax
Merged in a post:
Waiting Queue Permission Tiers
Corbelle
I'll explain this as simple as possible, the ability to make people who already have queue skipping permissions be a higher priority than others who also have skipping perms. For those of you familiar with what I do, we often come across the unfortunate occurrence where Fast-Pass owners, Staff, and Performers bottleneck in the waiting queue and just can't get in, with our highest and most annoying queue being 180. That was a 7-hour wait for regular attendees and 30-mins to an hour for people who NEEDED to be in the main instance. In a perfect world(Only for our operation), we would have Performers ranked as the most important, followed by Fast-Pass owners and then Staff. I've been discussing this with other event hosts who also have their busy events as streamlined to attend as we do and yes, the queue skipping permission tiers are one of the most important features to make things easier for us to host. Preferably as customizable as possible.
EngineerIsaac
I mean with ques like that you could easily boot a second instance to funnel all those people into. Why not offer to users to join a new instance or join a second instance?
Corbelle
EngineerIsaac Oh no, we already have those. We have from two-to-seven overflow instances normally. This feature is primarily for the main instance.
DeliciousSalad
Got more votes for the same thing here: https://feedback.vrchat.com/feature-requests/p/tiered-priority-queue-for-large-events
Shay
Agreed! This will be so useful for large scale events to get staff, performers in and then allow other VIP roles beneath them (perhaps purchased passes with VRChat Credits). I've seen big events try to coordinate getting people in first by making gathering point instances, but in active event sessions it can be tricky to get necessary people back in if there's a VIP queue all ready (Such as a crashed DJ/host)
n a k u
I honestly thought a type of importance order for prio que was already in place cause you can organize the order of roles in the role settings. Upvoted for sure- this will be very helpful for large scale event managers!
owlboy
I think a hierarchy of queue priority makes a lot of sense, as you explained it.
Giving straight up bypass roles (like world authors, instance owners, and VRChat employees have) seems like it might be going a bit too far.
Instead of bypass roles, I would create world affiliation associations so performers and collaborators can be marked as "co-world author" or "contributor" Then those would confer the same rights as world author or instance owner.
These world affiliation/association rights are a system that would enable a bunch of other features too.
Rantis
owlboy if you limit it to something like 10 or maybe even 20 bypass slots it MIGHT work out actually, then it falls back to priority queue if those slots are full. It would absolutely have to be given out sparingly though. 100 person instances might be too much but its a nice even number XD.
owlboy
Rantis I see that as a UI/Design problem, if you mean the slots are assigned to people. And hard to fit into the current Group permissions system. But maybe I'm doubting VRChat's ambition there. -- Think about a discord server as an analogy. There are not any permissions or roles that you can only assign to a limited number of people. AFAIK…
And the current way bypass works is not that there are "bypass slots" free above the cap. There are just certain, and very limited, contexts where someone can bypass.
Rantis
owlboy Not really assigned slots per se or hidden slots, more like once enough people are in the world theres a hard cap where it starts turning people away, just like how dev and world creator bypasses lead to instances saying 86/80 maybe certain group roles will allow for that but once the instance hits 100/80 it will fall back to the queue system regardless of role. Vrchat has toyed with 100 person instances before for certain events and occasions. I do agree that under the current system the ability to give the world creator bypass perks to others would be pretty cool.
owlboy
Rantis That sounds like it would fit into the systems. But I suspect they would see that as just a way for people to create 100 person instances intentionally. And that's not really the goal here, and networking appears to currently have some issues when you get that high. But they are actively working on it. -- Around St. Patrick's day they were testing 100 person instances at Shelter and elsewhere, and we even did it at St. Patrick's at The Pug in one instance. It contributed to unexpected network instability in all cases I think. (That's not to say this can't be fixed)
I'm just attempting to anticipate their design decisions and goals here.