Would it be feasible to add a Pause Queue feature?

[Rongway]

No, it isn't. Queue position refers to the party that you are in, not individual player.

This is not a relevant point to the mechanics I've described. #2 player in queue v player in #2 party makes no difference; just don't let anyone who is paused advance to #1.

[Silverquick]

I would love something like that...

BUT its not for the same reasons other people are talking about. I queue for like a Dungeon or Raid... and then go do something else like, play the MSQ or replay it, or like now doing Shadowbringer Fates... and there are SOME cutscenes it will not allow you to click the accept button so you have your choice... either let the queue expire or skip the cutscene, and its annoying as hell.

Or I'll be right at the end of a Fate and I'll be going... Oh you dick... you would pop right now.

[Tohe-Spidhire]

This is not a relevant point to the mechanics I've described. #2 player in queue v player in #2 party makes no difference; just don't let anyone who is paused advance to #1.

Long story short, you've oversimplified the party matching that takes place.

If queue-party#1 has everyone except a healer, and queue-party#2 has everyone except a tank, and then a tank shows up, which party do you suppose is going to start *immediately* ?

Regardless, an afk-dps on either of those teams gets shunted onto queue-party#3, which is shorthand for "end of the line." No point having fancy coding when the person should have dropped from the queue.

[Shurrikhan]

Long story short, you've oversimplified the party matching that takes place.

If queue-party#1 has everyone except a healer, and queue-party#2 has everyone except a tank, and then a tank shows up, which party do you suppose is going to start *immediately* ?

Regardless, an afk-dps on either of those teams gets shunted onto queue-party#3, which is shorthand for "end of the line." No point having fancy coding when the person should have dropped from the queue.

All queues numbers visible to a player are already role-specific. If I queue for a trial, healer RQ #1-2 are first party, 3 and 4 the second, etc., etc.

If I pause at position #3, #1 and #2 go in, #4 and #4 become the new #1 and #2, and I'm left waiting for a further party, just as I would have been before pausing.

If I'm healer #3 for a raid and pause, 1, 2, 4, 5, 6, and 7 enter; I remain at queue position 3. I will still join the next raid to pop from the time I unpause (or maximum pause duration expires, etc.). Depending on bottle-necks among other roles, that may be a good 15 minutes later than had I remained at my seat until it popped and I could enter, but if returning to my desk within 45 seconds were possible, I wouldn't have hit pause and taken that risk over the chance of losing my queue entirely. I have substituted a risk of being pushed back to position #21 or so, the true end of the line, with the risk of the queue popping (while I'm unable to respond) to it, thus skipping an entry I could (not) have otherwise taken.

Bottlenecks within a particular role can push the others to maximum effective queue positions well beyond just the next-next entry. I would guess that if we only ever had nearly ideal proportions (i.e. only a run's worth of the least relatively populous role short of the most populous role's runs'-worth of players) queuing for a duty, you would be right, since the difference between position # (In for next entry) and # (In for the entry after next) would be the difference between the front of the line and the end of the line. But that's often not the case, so I'm not sure it's quite so clear-cut.

That said, it may indeed not be worth the trouble to code for a doubly niche benefit. That's largely why my original question was phrased as such, to discuss whether it'd first even be feasible, secondly--worthwhile, and only finally--attractive.

NOTE: I may still be misunderstanding what you've said here. Or, more particularly, I'm not sure I believe that, say, a solo-queued individual player is bound automatically to a particular party until the time that there are sufficient numbers of each role for a party to be matched, as that goes against what I've heard from people who've analyzed this in the past. Any further links or data would be appreciated.

[deadman1204]

Abuse issues aside, this would make the queue SUPER complicated and WAY more system heavy. It would become impossible to give legitimate time estimates with players at all levels locking and unlocking in the queue. I see WAY to many downsides for SE to do this compared to the small upsides.

[Shurrikhan]

Abuse issues aside, this would make the queue SUPER complicated and WAY more system heavy. It would become impossible to give legitimate time estimates with players at all levels locking and unlocking in the queue. I see WAY to many downsides for SE to do this compared to the small upsides.

If I recall correctly, the time estimates are already made based on recent party entries rather than any real estimate of how quickly the bottleneck role will enter the queue, and actual entry times can swing pretty wildly from their estimates; after all it's a matter of, say, a tank joining or not joining, potentially for hours. Even if one previously joined every 10 minutes or so, at any time there could be many more in the typical interval or none for several such intervals. Many of the swings towards the short end are further varied by non-bottleneck roles dropping out.

Again, if anyone has seen GDC explanations, etc., of queues or worked on any themselves, I'd love some insight on how heavy the code would actually be, but so far I'm not sure why the number of user complications through added factors of complexity so outweighing those we already see (e.g. sudden upward movement already seen in long-estimate queues when non-bottleneck roles drop queue due to inactivity).

[Tlamila]

I'm all for it, if technically doable.
Both for quickly afkling and for, like mentioned, watching cutscenes. Hell, sometimes I even risk dropping off the queue because it pops at the start of a long loading screen.
It's easy to say "if you're busy don't queue" but queues can take up to hours and anything can happen in the meantime, including a common pot break.
As long as it's made so that it's not abused (ex: can only pause for 5 mins or so max) I see no negatives with it.

[Tohe-Spidhire]

It's easy to say "if you're busy don't queue" but queues can take up to hours and anything can happen in the meantime, including a common pot break.

Sorry, if the PF takes hours, then that can't possibly be described as using it correctly. At best, the PF is a tool for assembling quick matches, with AT MOST waiting 15 minutes, otherwise you should be manually recruiting people to play at a scheduled time.

[Tlamila]

Sorry, if the PF takes hours, then that can't possibly be described as using it correctly. At best, the PF is a tool for assembling quick matches, with AT MOST waiting 15 minutes, otherwise you should be manually recruiting people to play at a scheduled time.

1- we're talking about DF, not PF, and there's no "using it correctly"
2- not everybody can play at prime time, and even when you queue at reset time as dps yes, you can easily wait half an hour or longer, as DPS. And this for roulettes, single dungeons is much worse.
You're probably lucky with your datacenter, but how that leads you to believe it's a rule is beyind me.

[Tohe-Spidhire]

1- we're talking about DF, not PF, and there's no "using it correctly"
2- not everybody can play at prime time, and even when you queue at reset time as dps yes, you can easily wait half an hour or longer, as DPS. And this for roulettes, single dungeons is much worse.
You're probably lucky with your datacenter, but how that leads you to believe it's a rule is beyind me.

Sorry, I meant to say DF, and you're still crazy if you normally expect to be sitting there for hours. However, I've already advised you to manually recruit, so if you choose not to do that, then that is your choice. Defend that choice, my friend, as it is your freedom to do so.