Guild Wars 2

So at reset tonight, there was an immediate queue as expected. People in guild were yelling out their position and about 7 people all yelled that they were position 17.

Seems like a bug.

Another two examples: Someone announced they were leaving and signed off.

1. The person who was #1 in queue did not get in.
2. My personal queue spot did not improve

The queue is definitely NOT working.

style.6173:

Another two examples: Someone announced they were leaving and signed off.

1. The person who was #1 in queue did not get in.
2. My personal queue spot did not improve

The queue is definitely NOT working.

Not necessarily, it depends on how that person left. If they just closed the game without logging out or exiting WvW, it probably still treats them as in there for a few more seconds until the server realises the player has actually “DC’d” and isn’t responding.

style.6173:

Another two examples: Someone announced they were leaving and signed off.

1. The person who was #1 in queue did not get in.
2. My personal queue spot did not improve

The queue is definitely NOT working.

The queue is not broken. As you said earlier, your guild mates were all at position 17. So using this logic, it is clear that when your guild mate was at position 1, so were 500 other players. He didn’t get in because his #1 position was a large #1. Someone with a small #1 will get in ahead of him.

The queue approximates your position. Queues rarely go up after you join them. That would kitten people off if they are at #10 and after 30 minutes are at #50 because the queue approximated wrong. So to solve this issue, they just keep you at #10 for 30 minutes and hope you think nothing of it.

The issue is, the queue is not broken. If they add 540 players at position #1, that makes everyone feel cool.

Allie Murdock.8152:

The queue is not broken

Stop calling it a “queue” because it is obviously not a queue..

I liked how I watched my queue position go from #34 down to #7 then shot up to #58.

10 people queue up at the same time, it sends back that all of you are #7 in line. Now all 10 of you can’t be #7 now can you?

Have to let it update to show where you really are.

That kind of explains I guess why I stayed at 24 while everyone else in my party went from mid twenties to 5, 6, 7 in the queue

Allie Murdock.8152:

The queue is not broken. It shows approximate positions, and at times like the reset it won’t be as accurate as the number of people logging in simultaneously can cause it to update incorrectly. Once you move through the queue, the positions tend to be corrected.

Thanks for the report!

If its updating incorrectly…….wouldnt we call that broken?

So even over 15 minutes or so it could have one person (myself in this case), drop very slowly from 27 to 24, and everyone else go from the mid twenties to 5-6 in line? The game just did not like me today. Kept kicking me out of EotM as well, so I gave up on the queue as well when everyone else who clicked the queue at the same time got in way ahead of me

DevonCarver.5370:

Black Scoutsman.5830:

Allie Murdock.8152:

The queue is not broken. It shows approximate positions, and at times like the reset it won’t be as accurate as the number of people logging in simultaneously can cause it to update incorrectly. Once you move through the queue, the positions tend to be corrected.

Thanks for the report!

If its updating incorrectly…….wouldnt we call that broken?

The queue itself is not broken, the display is an approximation. The queue is completely FIFO and while the display can be misleading on occasion, the underlying system is functioning exactly as you would expect.

I guess what people are trying to say is that whether its the queue itself or the display of the number of your position, SOMETHING isnt working right. Call it updating incorrectly or misleading if you want but the simple fact is that its not correct. When your position in queue number goes UP after spending some time in queue, or some stay the same while others move after a group queuing at the same time, I would say that something was wrong in there somewhere. That’s all we’re saying. I would assume that people are quicker to blame the actual queue because of the well documented past history of queue issues. Anyways, Cheers and thanks for the responses.

Yea, I saw it go from 20 to 21 to 20 for me in a few seconds while looking at it.

I queued, my husband queued, then two more guildies queued. Since I was booted out of EotM, I was in another zone, they were still in EotM.

I was at 25, husband was at 24, other two said “cool, 26 and 28 here”

I finished a heart. I was at 24, husband said “Oh 15!”, the other two said “14 & 16.”

I finished off another section with an event, “24 still”
Husband: 12
other two “11” , “10” (one jumped ahead of her husband)

I finished off another heart, 23.
“5, 4, 6”

Two left to watch the olympics, I was at 20, jumped to 21, then down to 20, husband was at 4, so we left the queue.

GW2… where a queue is not a queue, and warriors / thieves are fine.

In summary, l2q imo.

DevonCarver.5370:

The queue itself is not broken, the display is an approximation. The queue is completely FIFO and while the display can be misleading on occasion, the underlying system is functioning exactly as you would expect.

I’m boggled as to why something so simple like a queue can be turned into a complex system with approximations and the possibility of misleading displays. This sounds like obfuscation for the sake of obfuscation.

I realize you may not want to push an update out to all our clients every second or every time someone leaves, and I’m perfectly fine with that, but that shouldn’t cause confusion. Is it really too much to ask that if the display says that I’m #1, I’ll be the next one in? Is it really too much to ask that if it says I’m #53 that I was 53rd in line at a moment in the not very distant past, and that number will never go higher?

The reason we don’t trust that things are working correctly is historical. The queues have always operated quite bizarrely for something that should be simple.

Tamasan.6457:

I’m boggled as to why something so simple like a queue can be turned into a complex system with approximations and the possibility of misleading displays.

This is actually quite standard. Especially in highly dynamic scenarios computing the precise position in the queue may require too much computation for such a relatively irrelevant statistical information. Approximate positions however may be more easily to obtain, and they suffice for the informational purpose they fulfill. (Or do you really, really care whether you are nr. 42 or nr. 43 in line?)

Also, for all your observations with the queue position, you should have in mind that there is most likely an asynchronous update interval for each player’s client. So if you and your guildie seem to share the same position in the queue at one point, then this might be just because of the asynchronous information you got.

“Thanks” to a fair number of disconnects during our reset WvW raid yesterday I also had the chance to have a close look at the numbers (with some guildies in parallel) and I’d say that the queue is actually working quite nicely. There is no doubt that this feature should have been in place at release, but better now than never.

~MRA

Anen.1742:

Stop calling it a “queue” because it is obviously not a queue..

You wanna pick nits? Ok.

I’d say you should differentiate between the abstract FIFO collection data type (often commonly referred to as “queue” like that thing we know from our supermarket or post office) the WvW queuing system aims for, and the actual implementation of the concrete data structure. As you are most likely aware of, the vanilla FIFO collection contract only demands for an ‘enqueue’ and ‘dequeue’ (and maybe also a ‘peek’) operation, and not for a “position of element x” operation. So it is fair to assume that ANet is not using your usual textbook implementation of a FIFO collection, but a special implementation that also allows for efficient “approximate position of element x” queries. It may even be possible that the implementation may not always fulfill the usual enqueue and dequeue contract by the book but is also just an approximation for the sake of a faster implementation.

Having said that, we don’t have the slightest clue what implementation is actually at work here. But assuming that “a queue is exactly that thing on the picture on this website” is very very shortsighted.

Also, I’d say the Wikipedia lemma you linked is very superficial on its topic.

~MRA

DevonCarver.5370:

Black Scoutsman.5830:

Allie Murdock.8152:

The queue is not broken. It shows approximate positions, and at times like the reset it won’t be as accurate as the number of people logging in simultaneously can cause it to update incorrectly. Once you move through the queue, the positions tend to be corrected.

Thanks for the report!

If its updating incorrectly…….wouldnt we call that broken?

The queue itself is not broken, the display is an approximation. The queue is completely FIFO and while the display can be misleading on occasion, the underlying system is functioning exactly as you would expect.

So if its not updating as it should, people do not know if that number 7 in the queue is really number 70, as its not updating correct, so technically we are back to what we had before where there was no indicator of how long it would take…..if its not updating as it should its then technically thus broken.

Since queue cannons work, clearly queue is a bad word for Anet’s system, as others have described their experiences in this thread.

The missing factor is priority. This may be represented by something else, but clearly each position has a priority. That is, someone with a high priority moves through the queue faster.

Anet doesn’t want to keep on asking the server/db what a clients position is, so they coded a formula that estimates a position based on priority and position reported when they entered the queue.

When Devon says it is FIFO (first in, first out), he is telling a half-truth, if not lying completely. It is clear people who group together prior to queue can move more quickly through the queue than party members in different zones. I think this is because they are using their overflow queue system which prioritizes parties in order to get them into the same overflow / main map. It also looks like people in wvw / eotm gain a higher priority.

Person A is position 3, priority 1 (best)
Person B is position 2, priority 2 (normal)
Person C is position 1, priority 3 (worst)

A spot opens up, the system looks for the next best priority and skips B and C selecting A. When a new spot opens, it skips C and selects B.

This is simplified. I would hope anet isn’t stupid enough to program it like this. They would have a counter that progresses as high priority people are added, and every x priority 1 people added, a priority 2 and priority 3 person is added (to keep the queue moving for everyone).

IMO, the queue is an effort by Anet to please people complaining about the queue, but just like the GvG arena, culling, wvw map max player size going down, etc. It blows.

Lol yeah, queue is not broken at all.
I was just pushed back from position 3 to 59 and you are telling me it’s completely working, FIFO, etc.
I have a serious question – has any of your devs graduated with CS?
Thanks for wasting my time.

would you all prefer to go back to having no clue how many people are in the “queue” ahead of you? I don’t use the numbers presented to me as anything other than a general idea of which Borderland I should queue up for that will have the shortest wait and just that simplest of thing is a huge improvement over knowing nothing so I am pretty happy with any sort of “approximation” ANET chooses to give me. I love the new UI and all the empowerment it gives me.

To those who find the queue position going up over time I have to wonder if you are changing maps at all while waiting or if this experience is happening while EotM? Would be helpful to know more details of those issues first. These days who is standing around watching their position in queue anyways? So much other stuff you could be doing.

If they had displayed: “Approximate queue position: 23,” upon release of this update, that’d probably prevented all these threads.

Instead they tried to pass off the number as your actual precise queue position hoping no one would notice. Well, people noticed.

There’s another way to bypass the problem of queues.

Transfer down.

Basically the queue position is a completely useless feature since the only time it will be accurate is when your turn is up. I just want to know if the queue is per server per map or just per map. In the past I have often seen friends queued on a map while we are severely outnumbered.

Black Scoutsman.5830:

DevonCarver.5370:

Black Scoutsman.5830:

Allie Murdock.8152:

The queue is not broken. It shows approximate positions, and at times like the reset it won’t be as accurate as the number of people logging in simultaneously can cause it to update incorrectly. Once you move through the queue, the positions tend to be corrected.

Thanks for the report!

If its updating incorrectly…….wouldnt we call that broken?

The queue itself is not broken, the display is an approximation. The queue is completely FIFO and while the display can be misleading on occasion, the underlying system is functioning exactly as you would expect.

I guess what people are trying to say is that whether its the queue itself or the display of the number of your position, SOMETHING isnt working right. Call it updating incorrectly or misleading if you want but the simple fact is that its not correct. When your position in queue number goes UP after spending some time in queue, or some stay the same while others move after a group queuing at the same time, I would say that something was wrong in there somewhere. That’s all we’re saying. I would assume that people are quicker to blame the actual queue because of the well documented past history of queue issues. Anyways, Cheers and thanks for the responses.

I think the developers are just trying to differentiate between the queue itself and the queue display system. Thus why they are saying the queue isn’t busted – because it itself isn’t. Just like when my washer told me 20 minutes ago I had 15 minutes left, I know it’s not because the washer is busted that it’s still going, just that the estimate is off.

I agree they should add a line to the queue display along the lines “this is an estimate of your position.”

Part 1:

CS student over here, and though I’m pretty sure ANet has some capable guys, I’d really like to mention a few possibilities I would think about when implementing such a queue. Because you know, sometimes, as we would say in German, one simply can’t see the tree because of the forest.

Since it was already mentioned that the queue is (or should be) completly FIFO, I simply neglect stuff like higher/lower priority etc.

First of all, which datastructure? At first glance, it makes sense to simply use a linked list, since you’re basically interested in easy insertion (queuing) and remove (dequeuing). However, the lookup of the position is quite expensive; one has to go trough the whole list to get the position, which is O(n). If a lot of players want to know their position at the same time, things can get pretty expensive.

My suggestion: Use a linked list for the queue itself, but use a hashtable for position-lookup. You can also use the hashtable for dequeuing-information (still in queue/left the queue).

Ok, and now how the basic things should be handled:

• A player enters queue:
  He is added at the end of the queue. Cost: O(1). An entry for this player is added in the hashtable, O(1). There is some kind of counter for the size of the queue, he’s adjusted accordingly, O(1). According to the counter, the player’s hashtable entry contains the position in the queue.

• A player leaves the queue:
  His entry in the hashtable is adjusted accordingly (player has left the queue). Cost: O(1).

• “Queue update”:
  This is probably the hardest part or at least the part where things can get difficult depending on the requirements of the queue. If a player leaves WvW and makes space for someone in the queue, should this player be able to enter WvW immediatly? Or is it OK if there is some kind of time inbetween?
  My personal suggestion: Make a queue-update like every 15 seconds or something like this (15 is out of the blue and would be my personal first choice; depending on how much CPU-time and bandwith you want to throw on this topic you can in-/decrease this time).
  What needs to be done: First of all, remove all dequeued players. Go through the list, look in the hashtable if the player is still queued, if yes, adjust his position-information in the hashtable (most likely, you use another counter for this which says at which position in the list you are right now), if no, delete his list-node, remove his hashtable entry and adjust the list-size-counter accordingly. Cost for deletion and hashtable-lookup: O(1). Cost for doing this for the whole list: O(n). Total cost: O(n). What we have now is a linked list and a hashtable that contains only players that are still queued; the position of the player is stored in the hashtable.
  Now new players can (maybe) enter WvW. Compare the list-size-counter to your maximum number of players allowed on one map. Comparison-cost: O(1). Let’s say, p players are allowed now to enter WvW. Go trough the first p entries of the list and let these players play WvW. Adjust the list-size-counter accordingly and adjust the hashtable entries of the players to ‘dequeued’. Cost: O(p) (neglecting the effort to inform those players which is most likely O(p) too).

• A player wants to know his queue-position:
  Hashtable-lookup of the position; cost: O(1) (neglecting effort to inform the player which is most likely O(1) too but costs some bandwith). You need to inform the player only once every 15 second (see “Queue Update”). The player knows that the position is updated only once every 15 seconds (i.e., add a ‘Update-timer’ to the WvW-window).

Part 2:

My personal oppinion upon this datastructure:
The big benefit is that the player knows his ‘true’ position every 15 seconds, so that the player is able to estimate how much time it takes. A queue-position that goes up and down isn’t really helpful in this topic, to be honest – or at least that’s my oppinion. The big cost of it is the queue-update every 15 seconds (or whatever time you put in this place) which is O(n), where n is about the amount of queued players (and players which dequeued in the last 15sec). To be honest, I do not know how many players are queueing at the same time, but since you can have one such queue per server (i.e., not all queues must be handled by the same hardware at once), but I estimate it to be less than 3000 players per server. Going through a linked list with ~3000 entries and adjusting a hashtable accordingly every 15 seconds is something that really should be feasible. To be honest, I don’t know how it looks like upon bandwith usage; that’s a topic where I’m missing some knowledge/experience. To inform 3000 players every 15 seconds at the same time could maybe be a bottleneck; but I’m pretty sure there are solutions to this too (e.g., each player has an own 15-sec cooldown with a start chosen uniformly at random somewhere in this 15sec-timespace).

If I made any mistakes in my suggestion or if I’m missing something obvious which makes things far worse complicate than I’m thinking, please let me know I love this datastructure-thingie, so if anyone sees an opportunity to improve something please let me know, I’d highly appreciate it
Sorry for any English mistakes, it’s unfortunately not my mother tongue.

Has the thing been fixed where you can Taxi in party members?

People can appreciate a hard coding issue. People don’t appreciate being mislead.

If they had been honest in the first place and put the words “approximate queue position,” this whole thing would be a much smaller issue. It’s not as if we wouldn’t have noticed this.

DevonCarver.5370:

Black Scoutsman.5830:

Allie Murdock.8152:

The queue is not broken. It shows approximate positions, and at times like the reset it won’t be as accurate as the number of people logging in simultaneously can cause it to update incorrectly. Once you move through the queue, the positions tend to be corrected.

Thanks for the report!

If its updating incorrectly…….wouldnt we call that broken?

The queue itself is not broken, the display is an approximation. The queue is completely FIFO and while the display can be misleading on occasion, the underlying system is functioning exactly as you would expect.

Then if it IS FIFO, why not display the ACTUAL number instead of an approximation ? It’s actually easier and takes less computer processing power to show up the real number than calculate an approximation…wth ?

Fenrir.6183:

Then if it IS FIFO, why not display the ACTUAL number instead of an approximation ? It’s actually easier and takes less computer processing power to show up the real number than calculate an approximation…wth ?

If you build a static queue it would be eaysier to show the real position. But If you have a dynamic queue it is not. Normaly you don’t use static systems for a highly dynamic process like a queue.

for example:

Static: You have an Array with 4 Entrys (player waiting)
1. A
2. B
3. C
4. D
Player A joins, now the programm has to write every Entry to his new static position makes 3 Operations, which increase with the numbers of players in Queue.

Dynamic:
You have a Pointerlist where each pointer shows the next Person in the row.
A->B
B->C
C->D
The Programm only needs to know which player is first in the row and get the Information of Player B when Player A enters the game. Only 1 Operation has to be done no matter how long the queue is. However the disadvantage is to calculate the exakt number of people in the queue or their Position takes huge ammount of resources. Thats why you use approximations instead of exact calculations as counterintuitive this may seem.

greetz

Rajani Isa.6294:

Black Scoutsman.5830:

DevonCarver.5370:

Black Scoutsman.5830:

Allie Murdock.8152:

The queue is not broken. It shows approximate positions, and at times like the reset it won’t be as accurate as the number of people logging in simultaneously can cause it to update incorrectly. Once you move through the queue, the positions tend to be corrected.

Thanks for the report!

If its updating incorrectly…….wouldnt we call that broken?

The queue itself is not broken, the display is an approximation. The queue is completely FIFO and while the display can be misleading on occasion, the underlying system is functioning exactly as you would expect.

I guess what people are trying to say is that whether its the queue itself or the display of the number of your position, SOMETHING isnt working right. Call it updating incorrectly or misleading if you want but the simple fact is that its not correct. When your position in queue number goes UP after spending some time in queue, or some stay the same while others move after a group queuing at the same time, I would say that something was wrong in there somewhere. That’s all we’re saying. I would assume that people are quicker to blame the actual queue because of the well documented past history of queue issues. Anyways, Cheers and thanks for the responses.

I think the developers are just trying to differentiate between the queue itself and the queue display system. Thus why they are saying the queue isn’t busted – because it itself isn’t. Just like when my washer told me 20 minutes ago I had 15 minutes left, I know it’s not because the washer is busted that it’s still going, just that the estimate is off.

I agree they should add a line to the queue display along the lines “this is an estimate of your position.”

I know what they are trying to say. We’re trying to show them that they are admitting it’s broken. If you want to say the queue works, Fine. So does ur washing machine apparently. The display, is wrong. As is the display on your washing machine apparently. I just think the fact that we are arguing over semantics and choices of words is asanine when we could just say, Hey guys something isnt working here, lets see if we cant make it better. Which is what, I think, everyone who has posted in this thread (devs included) would like to see.

If things were working properly, how is there ANY approximation involved?? Using the above example of a dynamic queue, why wouldn’t the system be programmed to tell the person in A position that they are first? No need to calculate and re-calculate positions and then display them on the client. When the person falls into position A (1st in line) their client displays them as 1st in the queue.

So basically the queue displays a random number that may or may not correspond to your position?

So it is just a random number generator? How is this an improvement over what we had before and why were resources spent on it? If it isn’t going to display my actual position then I am no better off than before and it was a waste of development time.

Cantur Soulfyre.5409:

If things were working properly, how is there ANY approximation involved?? Using the above example of a dynamic queue, why wouldn’t the system be programmed to tell the person in A position that they are first? No need to calculate and re-calculate positions and then display them on the client. When the person falls into position A (1st in line) their client displays them as 1st in the queue.

At this point, it is just as plausible to believe that the queue is functioning exactly as before, however we now have the benefit of seeing a random number that is remotely close to the queue pool; as it is to believe that the queue is functioning properly and the number is faulty…..