Resetting queue when someone doesn't join is simply mind-boggling.

[Suellen]

It isn't a bug; it's a design choice. When you lose a member (because they failed to accept queue or because they withdraw), your group is considered a new group and is placed at the back of the queue. This isn't something done "by accident".

How exactly do you know it's a design choice and not a bug? There's lots of bugs in games where coders implemented something it works in the sense that it functions and doesn't crash. But the devils in the details and it's possible no one noticed this anomaly.

I'm still leveling I've only seen the reserving instance after I got a full group once. I've seen people fail to click the button when a group forms and I'm definately not being placed in the back of the queue. I don't see how that's possible when my Sastasha queue pops for the first time after a 40 minute wait then pops 3 times in 3 mins due to members not clicking their button. Hard to believe that would be an example of me being placed in the back of the queue.

It sounds like the queue system has two behaviors with the one your stuck in only happening in dungeons where there is a wait list to get an available instance. At least that's how I understand it from this thread. Same system with 2 behaviors depending on various conditions sounds like a bug to me.

[MusouMugen]

I agree OP, one of most stupides systems ever (or bug, who cares, intentional or not, it's retarded). Yesterday, what with the reset and all, I managed whole 2 AKs in 5 hours...2nd AK had me waiting around 90+ minutes in the queue...

Ah how I wish I wasn't slacking when speedruns were around.

[skiwi]

It isn't a bug; it's a design choice. When you lose a member (because they failed to accept queue or because they withdraw), your group is considered a new group and is placed at the back of the queue. This isn't something done "by accident".

How would this be a design choice?
In the simplified use case of the Duty Finder the observed and wanted behaviour is that when the condition holds that one player has failed to accept the queue, that then you are put in front of the queue.

Now take a look at the extended use case, namely that there is an instance to reserve. Why would you now suddenly be put back at the end of the queue? If the simplified version puts you always* in front of the queue.
*Except when you are a premade group and someone does not accept. But that special case makes sense, as you are with a premade, and you do not want one person to not end up in the instance.

This seems like a bug to me.

[Alavastre]

Had multiple people drop out of CM last night, the bloody thing popped back up in about 20-45 seconds. I would have to see a dev tell us how this operates, because to me, it doesn't appear to function as the OP has stated.

Must DF's, and it appears this one follows that trend,put a higher priority on whomever is at the top of the list. So if it pops, and guy D drops out, you're still the highest priority. Likewise, you should also then be in the highest priority for an instance.

But with all of these changes, it may have been an over sight, or just something that wasn't important to SE at the time. The fix was more important than this one situation. Would like to hear a response from SE, and let them tell us if the OP is correct.

[Furious]

How exactly do you know it's a design choice and not a bug? There's lots of bugs in games where coders implemented something it works in the sense that it functions and doesn't crash. But the devils in the details and it's possible no one noticed this anomaly.


I'm still leveling I've only seen the reserving instance after I got a full group once. I've seen people fail to click the button when a group forms and I'm definately not being placed in the back of the queue. I don't see how that's possible when my Sastasha queue pops for the first time after a 40 minute wait then pops 3 times in 3 mins due to members not clicking their button. Hard to believe that would be an example of me being placed in the back of the queue.

It sounds like the queue system has two behaviors with the one your stuck in only happening in dungeons where there is a wait list to get an available instance. At least that's how I understand it from this thread. Same system with 2 behaviors depending on various conditions sounds like a bug to me.

The behaviour is very clear. The process is two part. The duty finder creates a group, then puts you in the instance queue. If there is no-one in the instance queue, the instance pops as soon as your group is formed. The former part, creating the group, works how it should. Individuals are at the front of the queue until they get into the dungeon; if their group fails to come together, they get reassigned. Hence, when you queued for 40 minutes before a pop, you were waiting to get to the front of the queue for a healer.

Then, once the GROUP is formed, that group becomes a single entity and is placed in the instance queue. If this group, as a whole, fails to join, the group is broken and the individuals wait for another member to form a new group, which is placed at the back of the instance queue. The existance of the two step process is, I assume, the reason that the problem exists (groups based on individual queues, then instance based on group queue). It is not the same system twice, it is two mechanics within the same system.

[Medivan25]

You're running AK, that's all. Myth stones reset on Monday's, everyone in my FC had issues with AK running on Monday's and everywhere else was fine. It's because everyone wants to start on their daily limit ASAP and not wait throughout the week so the server that handles AK dungeons is loaded and people "get in line" with everyone else.

[Tombles]

Players A, B, C and D queue for a dungeon.
Player D falls asleep.
The queue pops, players A, B and C click accept, and player D does not.
The queue fails. The dungeon finder takes the next-in-priority DPS from whatever group they are in, places them in the group, and re-pops the instance. Players A, B and C get their "average" queue time pop, plus a little bit extra for the failed player D, instead of potentially 4 to 5 times the "average" queue timer depending on their luck.

This is a fairly decent solution but it has a problem. If you are pulling people out of the group prior to yours then theres a possibility that you pull people out of a pre-made group. The obvious solution is to make it ignore people that are grouped together, but that causes people to essentially jump the queue ahead of a pre-made group.

I dont think theres an obvious way to make it fair for all however, I feel the way the duty finder servers arent being utilized properly. At the moment most other dungeons dont have this problem with reserving instances from what i can tell, this brings me to the conclusion that the way the duty finder server clusters are setup is so that each dungeon has a set amount of total usage they can use. This is pretty inefficient. If say dungeons can use a maximum of 10% of the server cluster each, then when one dungeon reaches that threshold it becomes "full". The problem is that other dungeons may only be using 1-4% or so, namely the lower level dungeons which probably arent being used as much now. This means that its possible that even though one dungeon is completely full the server cluster itself is only about 50% utilized.

I think they should allow dungeons that reach their maximum usage threshold to "borrow" lesser used dungeons space. This would allow busier dungeons to have shorter queues because their max capacity could possibly even triple or more. In instances where this could cause lesser used dungeons to become full you grant them highest priority for their server space and make the "full" dungeon borrow server space from a different dungeon.

Overall i think the bigger problem is that the duty finder servers arent being used to their full potential. However the people dropping out of the queue problem is still an issue and i dont really know of a 100% fair way to solve it really.