Guild Wars 2

So today someone brought up in TS:

If entering WvW while guesting on another server you taking that servers wvw spot as “count” goes however you are playing on your server.

Can Arena net confirm or deny this?

Mikitten058:

So today someone brought up in TS:

If entering WvW while guesting on another server you taking that servers wvw spot as “count” goes however you are playing on your server.

Can Arena net confirm or deny this?

I highly doubt this as the queue is per battleground. You would have to be able to join the guested server’s battlegrounds to count towards the total. Were this the case you could completely avoid all queues and put thousands of people in a given battleground by queuing from overflow servers.

GottFaust.5297:

Back to my initial point. You aren’t seeing them because the new culling system aggressively culls allied players in favor of enemy players.

You seem, however, to be forgetting the minimap display, which as far as I know does not cull out allied green dots and is by far the easiest way to determine numbers of friendlies in an area.

GottFaust.5297:

Mikitten058:

So today someone brought up in TS:

If entering WvW while guesting on another server you taking that servers wvw spot as “count” goes however you are playing on your server.

Can Arena net confirm or deny this?

I highly doubt this as the queue is per battleground. You would have to be able to join the guested server’s battlegrounds to count towards the total. Were this the case you could completely avoid all queues and put thousands of people in a given battleground by queuing from overflow servers.

Only if you assume that the system is working correctly. I could easily imagine a bug that adds you to your guest server’s queue but puts you in your home server’s battleground. This does not, however, address the observed issue where of a group of people entering a BG at the same time, some get in and some are queued. Your second point is irrelevant because overflow servers do not have battlegrounds of their own.

GottFaust.5297:

Mikitten058:

So today someone brought up in TS:

If entering WvW while guesting on another server you taking that servers wvw spot as “count” goes however you are playing on your server.

Can Arena net confirm or deny this?

I highly doubt this as the queue is per battleground. You would have to be able to join the guested server’s battlegrounds to count towards the total. Were this the case you could completely avoid all queues and put thousands of people in a given battleground by queuing from overflow servers.

Thing is assuming the system is working correctly.

Hince asking for a confirm or deny from Arena net.

Ordibble.3092:

GottFaust.5297:

Back to my initial point. You aren’t seeing them because the new culling system aggressively culls allied players in favor of enemy players.

You seem, however, to be forgetting the minimap display, which as far as I know does not cull out allied green dots and is by far the easiest way to determine numbers of friendlies in an area.

Details, details, details.

We have a theory and we’re gonna run with it despite all evidence that we’re wrong.

Porky.5021:

Ordibble.3092:

GottFaust.5297:

Back to my initial point. You aren’t seeing them because the new culling system aggressively culls allied players in favor of enemy players.

You seem, however, to be forgetting the minimap display, which as far as I know does not cull out allied green dots and is by far the easiest way to determine numbers of friendlies in an area.

Details, details, details.

We have a theory and we’re gonna run with it despite all evidence that we’re wrong.

You know what, thinking about this a bit more I do wonder, are the green dots culled as well? If the green dots are compiled client side using info from the server, then I’d imagine they could be, but if the minimap is compiled server side and sent in toto, perhaps not.

So I was in a BL last night, it was starting to get late and we were losing players, this is normal. At one point about half of us got the outmanned buff and the other half did not? I had the outmanned buff and had to log for the night. As a test after I left the BL I tried to get back in, I WAS IN THE QUEUE for 20 mins while when I left the BL I had the outmanned buff.

2 things:

Why did only a few of us have the outmanned buff and not everyone? Are only some of us outmanned?

Why was I in the queue when we had the outmanned buff?

I’m sorry but this was not culling. There is something wrong. Being that only some of us had the outmanned buff tells me something is wrong. It was painfully obvious we were outmanned, I have no question there.

I need to learn2fraps, so I can get this stuff and post it as proof. Maybe then we would get some answers.

I would quote myself to try and drive the point home that I made to you earlier Gott, but I am guessing you will ignore it again. I am curious why you are clinging so tenaciously to this and refusing to even consider other possibilities. Is it blatant stubbornness. That is a dangerous flaw for anyone, let alone someone who claims to be a software engineer for a defense contractor.

Stubbornness and problem solving skills generally are mutually exclusive.

The outmanned buff crap is present for as long as I remember. And I’m playing the game since the 1st headstart day. Very often my guildies had the “buff” and I didn’t. Other times it was the other way around.

There are many bugs, I dont care for the outmanned “buff” I care for the bugs that affect the already bad WvW. I don’t really think that anything is gonna be fixed. No, not even in March. There were enough times ANet proved that WvW is nowhere near being a priority. Ever.

Ruprect.7260:

So I was in a BL last night, it was starting to get late and we were losing players, this is normal. At one point about half of us got the outmanned buff and the other half did not? I had the outmanned buff and had to log for the night. As a test after I left the BL I tried to get back in, I WAS IN THE QUEUE for 20 mins while when I left the BL I had the outmanned buff.

2 things:

Why did only a few of us have the outmanned buff and not everyone? Are only some of us outmanned?

Why was I in the queue when we had the outmanned buff?

I’m sorry but this was not culling. There is something wrong. Being that only some of us had the outmanned buff tells me something is wrong. It was painfully obvious we were outmanned, I have no question there.

I need to learn2fraps, so I can get this stuff and post it as proof. Maybe then we would get some answers.

Things like this are why I don’t understand the Anet not answering.

Makes no sense to have an outmanned buff, along with a Queue.

I’ve decided to test some of the claims made in this thread. I’ll give you both my test results, and the test procedures that I undertook to get these results so that you can replicate them yourself. If you come up with different, legitimate, results by all means post them here.

First Claim: Tarnished Coast has both a queue and the outmanned buff.

Test procedures:
TC Players:

• Simply queue up for a battleground and see if you have the outmanned buff when you get in.
  Non-TC Players:
• Guest on TC.
• Ask a few individuals to queue up for a battleground of their choosing and then have them report back to you if they have the outmanned buff when they get in.

Results: None of the 20 indidivuals I contacted in TC’s lion’s arch had the outmanned buff when they entered the battleground of their choice, but they all had a queue.

Conclusion: There is no Outmanned Buff on Tarnished Coast while also having a queue outside of buggs with the outmanned buff itself.

Other Notes: The queue experienced by my volunteers was actually significantly shorter than most of the recent claims at only around 20-30 minutes.

Second Claim: Queueing from a different server than your home server will subject you to the queues associated with the guested server and use a slot for that server’s battleground rather than your home server.

Test procedures:

• Queue for a battleground on your home server. Note the queue time.
• Guest on a different server.
• Queue for the same battleground as you did on your home server. Note the queue time.
• Compare the noted queue times.
• For an additional test, get into an overflow server (Lion’s Arch is the easiest to do so) and then queue again. Note and compare the queue times again.

Results:

• Queue time to enter the eternal battleground while on Gates of Madness: 0 seconds.
• Queue time to enter the eternal battleground while guested on Tarnished Coast: 0 seconds.
• Queue time to enter the eternal battleground from an overflow while guested on Tarnished Coast: 0 seconds.
• Queue time to enter the eternal battleground from an overflow while on Gates of Madness: 0 seconds.

Conclusions: The server you are guested on has no affect on the queue time or which battleground you enter. This is direcly in line with the parameters listed by A-Net in both the guesting announcement and patch notes.

Third Claim: The green dots representing allied players on the minimap in Wv3 are not culled.

Test procedures:

• Gather a party, ideally this would be a full 5 players who are capable of communicating well.
• Turn off “show allied names” so that only the names of allied players in your party will be visible. This makes for easier tracking of the test players.
• Enter the Wv3 battleground of your choice.
• Find a large zerg.
• Wait for the zerg to enter combat with an enemy zerg.
• Sit at the back of the zerg and have your party members run around the outside of the zerg (this makes them easier to track).
• Identify the blue dots representing your party members as they run around the zerg.
• Watch as the allied party members are subjected to culling as they move away from you (Their names will vanish as well as their models).
• Observe if the number of green dots representing allied players near the blue dots representing party members.
• When party member is culled, compare the number of green dots you see near their blue dot with the number of allied players that the party member reports visible to them.
• Repeat the last step multiple times with each party member.

Results:

• Party members consistently reported a larger number of green dots close to themselves than was observed near their blue dot after culling took effect.
• Green dots representing allied players constantly pop in and out of existance on the minimap relative to the proximity to the observing player.

Conclusion: Green dots are indeed culled in large zerg situations.

Other Notes:

• The green dots do not appear to update at the same rate as actual player movement. Green dots closer to the observer seem to move more accurately.
• The culling of green dots seems to be entirely independant from player model culling.
• Green dot culling seems to be far less aggressive than actual player model culling.
• Green dot culling seems to be far more proximity based than actual player model culling.
• The green dots representing allied players are very, very hard to keep track of and estimate numbers of. It took hours to compile enough data to have a good idea of what was happening. Unless you are a bot, a casual observation will not provide any accurate data of any sort.

GottFaust.5297:

Bunch of “stuff”.

There is so much wrong with your “testing” or whatever you want to call it and you make so many assumptions that I’m not even going to go into it with you. We will all just have to agree to disagree on this one with you.

covenn.7165:

Stubbornness and problem solving skills generally are mutually exclusive.

This is entirely incorrect.

• Stubbornly refusing to let a problem continue to exist is the very essence of problem solving.
• Trial and error, the essence and mode of most scientific discovery, is stubbornly trying different things over and over in the attempt to understand or achieve something.
• Nikola Testla and Albert Einstein, two of the greatest problem solvers in history, were often described as extremely stubborn.

Burl.9567:

GottFaust.5297:

Bunch of “stuff”.

There is so much wrong with your “testing” or whatever you want to call it and you make so many assumptions that I’m not even going to go into it with you. We will all just have to agree to disagree on this one with you.

• Petitio Principii
• Onus Probandi

GottFaust.5297:

This is entirely incorrect.

• Stubbornly refusing to let a problem continue to exist is the very essence of problem solving.

Actually I am quite correct as that is not the type of ‘stubbornness’ I was referring to. It should be quite obvious what I was referring to and I shouldn’t need to explain it to someone with your self proclaimed expertise and intelligence.

You don’t know the source code first of all. This means that the probability of your theory being 100% correct is extremely small. You also do not have the expertise with their network, hardware, and reporting tools to even begin to make any conjecture about other contributing factors.

Despite this gross lack of information available to you, you are clinging to your theory and refusing to accept other possibilities. Despite the fact that you are using anecdote yourself, you refuse to consider other anecdotal evidence that is contrary to your ‘theory’. Despite the fact that reasonable, rational, and plausible holes have been punched in your theory, you refuse to even acknowledge other possibility.

No my friend, I am not wrong about you being stubborn about this. I am also not wrong about this kind of stubbornness hampering problem solving skills. I am sure you are a competent software engineer and developer, but you would not last a month on my team here at <edited because where I work is none of your business> with that kind of close mindedness.

covenn.7165:

GottFaust.5297:

This is entirely incorrect.

• Stubbornly refusing to let a problem continue to exist is the very essence of problem solving.

Actually I am quite correct as that is not the type of ‘stubbornness’ I was referring to. It should be quite obvious what I was referring to and I shouldn’t need to explain it to someone with your self proclaimed expertise and intelligence.

You don’t know the source code first of all. This means that the probability of your theory being 100% correct is extremely small. You also do not have the expertise with their network, hardware, and reporting tools to even begin to make any conjecture about other contributing factors.

Despite this gross lack of information available to you, you are clinging to your theory and refusing to accept other possibilities. Despite the fact that you are using anecdote yourself, you refuse to consider other anecdotal evidence that is contrary to your ‘theory’. Despite the fact that reasonable, rational, and plausible holes have been punched in your theory, you refuse to even acknowledge other possibility.

No my friend, I am not wrong about you being stubborn about this. I am also not wrong about this kind of stubbornness hampering problem solving skills. I am sure you are a competent software engineer and developer, but you would not last a month on my team here at <edited because where I work is none of your business> with that kind of close mindedness.

^this for truth^

Did he just compare himself to Einstein and tesla lol.

Sunspots.9861:

Did he just compare himself to Einstein and tesla lol.

I get the distinct feeling we are talking to Sheldon Cooper. Explains a lot really…

Don’t know if it has been raised yet but this observation came from the Gandaran community forum;

- When exiting the game, the GW2 process keeps running in task manager (unlike earlier patch)
- When exiting the game from WvW zone, player still ‘appears’ online in party window/guild screen
- When exiting the game from WvW zone, mini-map dot still appears at a random location in zone

Could it be that players that exit the game in WvW aren’t registered as such and still registered as online? This would create a long queue as more people are indicated in a zone than are actually there.

Humanpony.4921:

Don’t know if it has been raised yet but this observation came from the Gandaran community forum;

- When exiting the game, the GW2 process keeps running in task manager (unlike earlier patch)
- When exiting the game from WvW zone, player still ‘appears’ online in party window/guild screen
- When exiting the game from WvW zone, mini-map dot still appears at a random location in zone

Could it be that players that exit the game in WvW aren’t registered as such and still registered as online? This would create a long queue as more people are indicated in a zone than are actually there.

I think that you are quite possibly correct. Many of us here (at least if not named GottFaust) have noticed those same things and arrived at that same hypothesized conclusion. I’m not even sure that the problem is limited to WvW, though, since I often find myself in an overflow server when exiting to Lion’s Arch even at 1 AM server time.

It would seem to be a trivial thing for ANet to check but so far we have had zero feedback from them on it.

Your first point about the GW2 process still running in Task manager is especially interesting. I wonder if it would be possible for someone with programming skills to track incoming data packets from ANet’s server to see if the usual warning about getting booted for inactivity is still being sent to the local client even though it is no longer being displayed on the monitor. Wouldn’t that be a hoot if so? Wouldn’t it be even more amazing if ANet hadn’t thought to try that from their end?

Humanpony.4921:

Don’t know if it has been raised yet but this observation came from the Gandaran community forum;

- When exiting the game, the GW2 process keeps running in task manager (unlike earlier patch)
- When exiting the game from WvW zone, player still ‘appears’ online in party window/guild screen
- When exiting the game from WvW zone, mini-map dot still appears at a random location in zone

Could it be that players that exit the game in WvW aren’t registered as such and still registered as online? This would create a long queue as more people are indicated in a zone than are actually there.

If this is indeed happening, and happening on a large scale, it could very well be a contributing factor. Does anyone have any more data on this phenomenon? I’ll see if I can replicate it when I get off work.

GottFaust.5297:

covenn.7165:

Stubbornness and problem solving skills generally are mutually exclusive.

This is entirely incorrect.

• Stubbornly refusing to let a problem continue to exist is the very essence of problem solving.
• Trial and error, the essence and mode of most scientific discovery, is stubbornly trying different things over and over in the attempt to understand or achieve something.
• Nikola Testla and Albert Einstein, two of the greatest problem solvers in history, were often described as extremely stubborn.

Burl.9567:

GottFaust.5297:

Bunch of “stuff”.

There is so much wrong with your “testing” or whatever you want to call it and you make so many assumptions that I’m not even going to go into it with you. We will all just have to agree to disagree on this one with you.

• Petitio Principii
• Onus Probandi

You are not stubbornly refusing to let a problem exist…you are stubbornly clinging to some theory which doesn’t hold water. I am surprised you don’t know the difference.

People who are stubbornly refusing to let a problem exist will be more than happy to abandon a theory on the cause of the problem should it seem that theory is not correct or the cause of the problem is most likely something else.

Donkeys will cling to their theory no matter what, eventually doing things like comparing themselves to Einstein to attempt to give their stance some credibility.

All this speculation s fine but ANet could fix it all with a statement post their latest patch and moreover provide empirical evidence of queue waiting times and volumes.

Cactus.2710:

Your first point about the GW2 process still running in Task manager is especially interesting. I wonder if it would be possible for someone with programming skills to track incoming data packets from ANet’s server to see if the usual warning about getting booted for inactivity is still being sent to the local client even though it is no longer being displayed on the monitor. Wouldn’t that be a hoot if so? Wouldn’t it be even more amazing if ANet hadn’t thought to try that from their end?

Some simple wire shark use can easily show if the hung process is still communicating with the A-Net servers.

Ireniicus.2167:

All this speculation s fine but ANet could fix it all with a statement post their latest patch and moreover provide empirical evidence of queue waiting times and volumes.

To be fully descriptive, what we actually need are three things:

-1. number of people in the queue at a specific time

-2. the average number of minutes that players have been in the queue at that same point in time

-3. most importantly > the total number of players verified to actually be in the map at that specific point in time

ANet seemingly has only been looking at queues while not actually investigating whether those who are supposedly in the map are really there. At least the only comments we’ve seen from them have dealt only with queue numbers, and that won’t tell the whole story.

I applaud this attempt to get better information, but the testing methodology is insufficient to be able to come to any kind of conclusion. the evidence collected so far can’t be considered more than “anecdotal”. At best, it gives us better ideas about what tests to perform next.

Personally, I suspect that the queue bug is due to people who think they are queued when they actually aren’t. That is, they get a message saying they are queued, they see the hourglass overlay on the WvW icon, but on the back end they are not actually placed in the queue and therefore never get in. The people who queued after and got in before are the people who actually made it into the queue on the back-end, instead of getting dropped.

When you think you are queued, you naturally infer that the map you’re queued for is full. This then leads you to do all sorts of things (like trying to count how many people are in the map). But if you were never actually queued to begin with, then all your previous inferences and assumptions are called into question.

Of course, I have no way of knowing if my suspicion is correct. We have lots of reports of people being queued for a long time, while others get in before them, but do we know if any of them eventually made it in, or did they give up and log off or queue for something else instead?

-ken

Porky.5021:

You are not stubbornly refusing to let a problem exist…you are stubbornly clinging to some theory which doesn’t hold water. I am surprised you don’t know the difference.

People who are stubbornly refusing to let a problem exist will be more than happy to abandon a theory on the cause of the problem should it seem that theory is not correct or the cause of the problem is most likely something else.

Donkeys will cling to their theory no matter what, eventually doing things like comparing themselves to Einstein to attempt to give their stance some credibility.

You are reading WAY too far into what I said if you think I was comparing myself to Einstein. That or this was a sad attempt at a straw man.

The fact is that until Humanpony’s post there has been absolutely 0 verifiable evidence contrary to my thoery. Even his addition doesn’t contadict mine or A-Net’s statements as it is an outlying factor and doesn’t cause a bug with the queues themselves, rather a bug with the number of players reported to be in a given battleground. To top it off, the frequency of this happening would be directly tied with Wv3 population to begin with and this mass transfers are still a contributing factor.

Before you continue claiming that I’m ignoring all statements to the contrary you should note that I dedicated hours of my time to testing the three major claims that have been made to the contrary, prior to Humanpony’s post of course which I will be testing this evening.

If this claim proves to be true, I will adjust the theory to account for it.

I just jumped into WvW and then quit the game from there. I see no extra processes lingering around on my system. Granted, I am running the Mac client. I can check Windows later today.

“All men make mistakes, but a good man yields when he knows his course is wrong, and repairs the evil. The only crime is pride.”

Sophocles, Antigone

nalenb.1425:

I just jumped into WvW and then quit the game from there. I see no extra processes lingering around on my system. Granted, I am running the Mac client. I can check Windows later today.

I doubt that it’s an every-time occurance as that would never have made it past a decent QA session, and I haven’t personally seen it happen as of yet. My guess is that there are other contributing factors that would cause this to happen, if it is indeed happening.

The trick will be to first replicate it, then identify the steps required. At that point the problem can then be passed off to A-Net and the word can be spread on how to avoid it while A-Net works on an actual solution.

nalenb.1425:

I just jumped into WvW and then quit the game from there. I see no extra processes lingering around on my system. Granted, I am running the Mac client. I can check Windows later today.

It may require that you be in a party when you quit the game from WvW, since that’s what also seems to cause the lingering dots on the mini-map. I plan to test that out some more this evening, as well as trying GottFaust’s suggestion to use Wireshark (free open source application) to track packet activity.

Cactus.2710:

Ireniicus.2167:

All this speculation s fine but ANet could fix it all with a statement post their latest patch and moreover provide empirical evidence of queue waiting times and volumes.

To be fully descriptive, what we actually need are three things:

-1. number of people in the queue at a specific time

-2. the average number of minutes that players have been in the queue at that same point in time

-3. most importantly > the total number of players verified to actually be in the map at that specific point in time

ANet seemingly has only been looking at queues while not actually investigating whether those who are supposedly in the map are really there. At least the only comments we’ve seen from them have dealt only with queue numbers, and that won’t tell the whole story.

1. is vastly important to this.

Part of good development is not reinventing the wheel. In other words, you don’t write new code to perform the same function as existing code (in most cases, there are exceptions obviously). If ANETs reporting tool is using the same underlying objects as the queue system to get map numbers, it will affect both equally if there is a coding bug.

Also, we already know that there is a long outstanding bug in the queue system. Chances are that it is a completely separate issue because it existed months ago and greatly predated the current issue. Unfortunately, even if not directly related, it certainly is confounding the issue. (I am referring to why I like to call the ‘queue lotto’ where someone gets in after 5 minutes when others have been waiting for an hour).

From my perspective as a subject matter expert in the field both as a team member (code monkey) and lead engineer on various projects both large and small, it wouldn’t surprise me to find several issues related to developmental mistakes in the same place. Resources (developers) typically get assigned to complete tasks within the project. If you have a developer that makes stupid mistakes often, has bad habits, or is simply a bad programmer….. chances are you are going to find them in everything he/she worked on.

Is there a name for the process that gets kept around? Could write a little tool to check for it all the time and then try different methods of quitting.

GottFaust.5297:

I doubt that it’s an every-time occurance as that would never have made it past a decent QA session

In all fairness though, there have been numerous things that have already made it into production that shouldn’t have if there had been decent testing / QA taking place. Not only that, some of these issues have been in existence since release and still not resolved.

Cactus.2710:

nalenb.1425:

I just jumped into WvW and then quit the game from there. I see no extra processes lingering around on my system. Granted, I am running the Mac client. I can check Windows later today.

It may require that you be in a party when you quit the game from WvW, since that’s what also seems to cause the lingering dots on the mini-map. I plan to test that out some more this evening, as well as trying GottFaust’s suggestion to use Wireshark (free open source application) to track packet activity.

Just keep in mind that even if your client is completely disconnected from the game server, it doesn’t automatically means that game server realizes it. Further more, it doesn’t mean that the code is handling it correctly across the board.

Unfortunately any amount of testing we do won’t prove that. That all has to be done on their end.

covenn.7165:

Just keep in mind that even if your client is completely disconnected from the game server, it doesn’t automatically means that game server realizes it. Further more, it doesn’t mean that the code is handling it correctly across the board.

Unfortunately any amount of testing we do won’t prove that. That all has to be done on their end.

Yeah, actually, as much fun as tracking down possible issues is I have other real work to do.

Oh, to add more anecdote into the mix…..

We had major queue issue since the last major release on my server, just like all the other servers with a WvW population have. Ignoring reset night as it is always going to be crazy, Saturday through Tuesday we had over an hour queue on every map. Oddly, last night we had almost no queue during prime time on most maps. Did everyone stop playing all of a sudden?

covenn.7165:

Cactus.2710:

nalenb.1425:

I just jumped into WvW and then quit the game from there. I see no extra processes lingering around on my system. Granted, I am running the Mac client. I can check Windows later today.

It may require that you be in a party when you quit the game from WvW, since that’s what also seems to cause the lingering dots on the mini-map. I plan to test that out some more this evening, as well as trying GottFaust’s suggestion to use Wireshark (free open source application) to track packet activity.

Just keep in mind that even if your client is completely disconnected from the game server, it doesn’t automatically means that game server realizes it. Further more, it doesn’t mean that the code is handling it correctly across the board.

Unfortunately any amount of testing we do won’t prove that. That all has to be done on their end.

Very true, but since we can’t seem to get any action (or at least any feedback on what they might be doing, if anything) from ANet the only things we can look at are from the client side. However, if we DO see evidence of ongoing packet activity from the client side even after disconnecting from the game it would certainly point to it being a problem. Just because I don’t catch a fish doesn’t mean that there aren’t any in the lake, but if I do catch one at least I have good reason to believe that some exist.

nalenb.1425:

covenn.7165:

Just keep in mind that even if your client is completely disconnected from the game server, it doesn’t automatically means that game server realizes it. Further more, it doesn’t mean that the code is handling it correctly across the board.

Unfortunately any amount of testing we do won’t prove that. That all has to be done on their end.

I am doing my best to avoid that today. In a holding pattern the last couple of days with not much to do here gets kind of boring.
Yeah, actually, as much fun as tracking down possible issues is I have other real work to do.

covenn.7165:

In all fairness though, there have been numerous things that have already made it into production that shouldn’t have if there had been decent testing / QA taking place. Not only that, some of these issues have been in existence since release and still not resolved.

This is a good point. The state of the Necromancer class at launch was a good example of this.

covenn.7165:

Just keep in mind that even if your client is completely disconnected from the game server, it doesn’t automatically means that game server realizes it. Further more, it doesn’t mean that the code is handling it correctly across the board.

Unfortunately any amount of testing we do won’t prove that. That all has to be done on their end.

Also a good point. We can, however, verify that the client does indeed disconnect and shut down properly on our end. If it does not, as Humanpony suggests, then we can report this issue, and hopefully steps to replicate it, to A-Net to expedite a fix.

Humanpony.4921:

Don’t know if it has been raised yet but this observation came from the Gandaran community forum;

- When exiting the game, the GW2 process keeps running in task manager (unlike earlier patch)
- When exiting the game from WvW zone, player still ‘appears’ online in party window/guild screen
- When exiting the game from WvW zone, mini-map dot still appears at a random location in zone

Could it be that players that exit the game in WvW aren’t registered as such and still registered as online? This would create a long queue as more people are indicated in a zone than are actually there.

i indeed believe it is something along these lines. On my server i have noticed people in map chat for the last week informing others of the possible bug and asking them to zone to LA before logging out. Or if they do log out(so they don’t have to port back to the zone they want to be in) then log back in real quick so their character will be registered in the zone they Qed from.

the Q times have gone down a bit from what i have noticed 5 to 10 min max for myself. Also i haven’t noticed missing people as much.

these are just observations from my end and not meant to be listed as facts.

Snowreap.5174:

I applaud this attempt to get better information, but the testing methodology is insufficient to be able to come to any kind of conclusion. the evidence collected so far can’t be considered more than “anecdotal”. At best, it gives us better ideas about what tests to perform next.

Personally, I suspect that the queue bug is due to people who think they are queued when they actually aren’t. That is, they get a message saying they are queued, they see the hourglass overlay on the WvW icon, but on the back end they are not actually placed in the queue and therefore never get in. The people who queued after and got in before are the people who actually made it into the queue on the back-end, instead of getting dropped.

When you think you are queued, you naturally infer that the map you’re queued for is full. This then leads you to do all sorts of things (like trying to count how many people are in the map). But if you were never actually queued to begin with, then all your previous inferences and assumptions are called into question.

Of course, I have no way of knowing if my suspicion is correct. We have lots of reports of people being queued for a long time, while others get in before them, but do we know if any of them eventually made it in, or did they give up and log off or queue for something else instead?

-ken

On reset nights we have had ppl get in after hours of waiting, they will just stay queued while they go do othere things and they do eventually get in.

Some of what you say makes sense. What has been happening lately is ppl will start to requeue up every 5 mins and some will get in right away after requeuing and some will requeue for hours and finally get in.

covenn.7165:

Oh, to add more anecdote into the mix…..

We had major queue issue since the last major release on my server, just like all the other servers with a WvW population have. Ignoring reset night as it is always going to be crazy, Saturday through Tuesday we had over an hour queue on every map. Oddly, last night we had almost no queue during prime time on most maps. Did everyone stop playing all of a sudden?

This was also my experience. There was very little to no queue when a lot of us first got on. After about 20 of us got into the bl the others started getting a short queue. I would guess there was about 50 total of us on the map, and that is just what I saw so I am sure there were more.

As the night progressed ppl started leaving for the night, it got to a point where we were very undermanned. Then some of us got the outmanned buff, I didn’t think much of it until I noticed not all of us had it. That was strange and I had never seen that before. It was getting late for me and I had the buff so I was logging for the night, I went to LA through the portal and just for kittens and giggles I thought I would try to get back into the bl to see if there was a queue, there was.

I think ANet should just do 2 things that many games have done before: Put an infographic telling you how many players are on the map out of a maximum, e.g. 140/166 and if you are waiting in queue, tell you what your spot is, e.g. #50. Is it really so hard to tell players how many people you have on a map? And, if that is too much info, is it so hard to have a literal line and each person in queue takes a number? This sort of queue system already exists, it isn’t like they’d have to do a ton of coding to let you know where you are in line anyway.

Esoteric.5490:

I think ANet should just do 2 things that many games have done before: Put an infographic telling you how many players are on the map out of a maximum, e.g. 140/166 and if you are waiting in queue, tell you what your spot is, e.g. #50. Is it really so hard to tell players how many people you have on a map? And, if that is too much info, is it so hard to have a literal line and each person in queue takes a number? This sort of queue system already exists, it isn’t like they’d have to do a ton of coding to let you know where you are in line anyway.

ANet said very early on that the queues were pretty much a first-in/random-out kind of situation and that they were working to fix that. To my knowledge they have never announced any kind of fix for it, though, so the logical assumption would seem to be that queue times are still random by default. That doesn’t alter the fact that having a queue in the first place doesn’t seem to match the current map populations, though, and for that I still lean toward the fail-to-release hypothesis.

Esoteric.5490:

I think ANet should just do 2 things that many games have done before: Put an infographic telling you how many players are on the map out of a maximum, e.g. 140/166 and if you are waiting in queue, tell you what your spot is, e.g. #50. Is it really so hard to tell players how many people you have on a map?

I would totally agree except that requires that:

-1. ANet knows those figures, and I honestly don’t think they do. There seems to be at least some circumstantial evidence that because of various bugs ANet doesn’t actually know how many people are in the map.

-2. the queue be first-in/first-out, and ANet has already admitted that it is not.

After some heavy testing I managed to replicate Humanpony’s claim of the hung process. The sad part is that it was only once and I couldn’t get it to happen again. I did sniff around a bit with wireshark and it appears to be pinging what I guess is the login server, but not the ip of my server (Gates of Madness) or the eternal battlegrounds. I can’t draw any concrete conclusions from this info. Did anyone else manage to test it and have more luck?

GottFaust.5297:

After some heavy testing I managed to replicate Humanpony’s claim of the hung process. The sad part is that it was only once and I couldn’t get it to happen again. I did sniff around a bit with wireshark and it appears to be pinging what I guess is the login server, but not the ip of my server (Gates of Madness) or the eternal battlegrounds. I can’t draw any concrete conclusions from this info. Did anyone else manage to test it and have more luck?

When I logged in last night my client did not come up. I checked the processes running on my computer and found there was 2 GW2.exe processes running. It had to have been running since I logged out the night before and it was using about half the resources that the new process was using. I stopped the process and my client came right up.

This has happened a few times to me since the patch. In the past I had just restarted my computer to get the client to come up when it seemed to hang. It’s hard to say because I did not Wireshark it but I wonder if as long as the GW2.exe process is running in tha background even after I logged out if the server still thinks I am online.

If this were the case then if I had logged out while still in the BL, it may consider me still in the BL even though I am logged out and that would make for strange queues. This could really answer everything if this is the case. Unfortunatly when I logged off last night I was tired and forgot to check if that process continued to run. I will check when I get home and if it is I will run a Wireshark and see what or if it is sending data.

This is an interesting find.

GottFaust.5297:

After some heavy testing I managed to replicate Humanpony’s claim of the hung process. The sad part is that it was only once and I couldn’t get it to happen again. I did sniff around a bit with wireshark and it appears to be pinging what I guess is the login server, but not the ip of my server (Gates of Madness) or the eternal battlegrounds. I can’t draw any concrete conclusions from this info. Did anyone else manage to test it and have more luck?

GW2.exe does seem to stay in my Task manager after I ‘Exit to Desktop’ from WvW on occasions, but I’m not tech-savy enough to get any other meaty data for you i’m afraid.

Yet another observation. No or short queues last night during NA prime time on a T1 server. Personal anecdote: I have seen significantly more people in zone in the past two days than I did in the days prior by far. I wonder if the maintenance a few days ago has anything to do with this……