Disclaimer: This is meant to be a thread about how latency affects end-game raiding in general. We have currently only done research into a limited scope, shield block while tanking a boss mob. This was the most important to us because the main tank is a single point of failure whereas healing and dps are spread over more players/connections. I believe this is worthy of a separate thread, but if the moderators feel differently, please feel free to move it into the tanking theorycraft thread.

Background:
A couple of RL friends and I all raid together. One of us is the main tank for the guild, Prayes, and we also make up the two main healers, myself and Gian, and two top dpsers, Antlers and Eppendorf. Anyhow, we use the mod Recap to tell us a lot of information about raid performance during encounters and we noticed a crushing percentage on the Prince fight of much higher than was predicted by the one roll system giving our tank's gear (he pushes crushes off the table when shield block is up). So we decided to do some testing.

Testing:
As a side note, we found testing on Anachronus to be useless. We do not believe he behaves like a boss mob. Specifically, he didn't crush the tank at all even without shield block ever up and did not resist Antlers (a destro fire lock). So we headed to Onyxia.

Onyxia yielded better data. We had the MT keep a combat log and looked at only phase one. We used one round where the tank never used SB to calibrate the percentages and then at the end of two rounds of testing with shield block we had enough data for the statistics to yield fairly meaningful results. It was surprising what we found.

Results:
During the fight we identified that the roll system in place appeared to be a one roll system to a high degree of certainty, but this is nothing new. Gian wrote a parser to pick out the times Prayes was crushed and what buffs he had on during that time. He was never crushed when shield block was up. Out of the 11 times our tank was crushed, 2 of them were due to user error (ie Prayes had used his rage on something else and failed to activate shield block). The other 9 were due to Prayes's latency. The combat log allowed us to see when he could not initiate a move due to latency (an error message is reported in the log ... several times). He would do a move on the global cooldown and then immediately spam shield block. His latency was rather high at the time (~200 ms). So instead of activating shield block it simply returned an error message for not 200ms but 400 ms! So even if the tank were to react immediately to shield block coming off cooldown there is almost a half second window where he can be crushed. This is rather significant when tank death nowadays is usually due to spike damage (or healer incompetence {not me or Gian}) and not healers going oom (at least it seems this way in our guild).

Theory:
Our theory is that Blizzard has implemented a system in which the client is forced to check if it is "ok" to allow a move when a global cooldown is in place. Specifically, when not under the global cooldown, shield block is synchronized instantaneously, but when there is a global cooldown in effect it has a 2*latency lag before even sending the command to shield block.

Solutions (lol):
Needless to say we have banned him from using iTunes, AIM, or Vent on his desktop while tanking and he now uses a laptop to run peripheral programs while only running WoW on his desktop. We are also looking into writing macros that reprioritize the order in which his moves are activated so that shield block has priority over moves on the GCD and thus reduce the time without shield block up.

Further Implications:
We believe that all players generally experience this type of issue. This is important to any type of player that uses spells and abilities both on and off the GCD. Especially when those spells have timing issues associated with them.

Latency plays a bigger roll in the game than I originally thought. I think the current coding in the game relies too much on low latency. There are examples of problems from other classes (e.g. Arcane Missiles) that I remember Blizzard saying they cannot replicate due to their low latency-testing environment.

I'm sure Gian would be more than willing to give his parser to anyone who would like to do their own testing. I think he will be posting in this thread a little more on the technical side of the testing procedures, but I wanted to get this to the community ASAP.

I hope you've found this to be at least a little insightful and I look forward to discussing this with the EJ community.

Not sure if this is relevent to the discussion but I've had problems not getting all 5 arcane missile firings even on < 30 ms latency so I'm not really sure if it's necessary that type of problem.

This has ever been a problem for raiding casters, particularly those playing on US servers from overseas. My old raiding guild had many folks that played regularly with latency of 500ms or more.

I was a mage at the time, so I'm only really familiar with that aspect of it, but our raid leader's (also a mage) damage jumped about 20% when he installed FastCast for the first time. He regularly played with a 350ms lag and was, at the time, a frost mage with untalented frostbolt (3 sec cast), so the 20% damage increase corresponded exactly to the (2*latency) lag that your tank experienced.

I can't find the post right now, but a blue post that the reason not all 5 arcane missiles fire is because of a mapping process back and forth from client to server that is related to any latency that is not near 0 and the reason Blizzard cannot reproduce it is because it is costly to introduce latency into their testing process. Sorry I can't back this up with a link, but it was awhile ago and I didn't bookmark it.

As a student at a major research institution I understand both the costs and benefits of introducing latency into computer system, so I can't really blame them too much since being able to replicate latency in controlled amounts is somewhat cost prohibitive.

Sidenote: The Blizzard search algorithm for the forums is not great and the search algorithm at BlueTracker, while better, could not find it either. :-(

You can achieve similar result to fastcast with /stopcasting macros. Can't solve GCD problems with /stopcast though.

There is similar weirdness surrounding shortening of the GCD with haste effects. It's a shame there isn't some kind of one action queue you could enable. I think it would clear up a lot of this stuff...

I'm unfamiliar with FastCast, what is the theory behind what it does? Does it work on all classes or is it mage specific? I think that 20% more damage is great for a dps class, but as I mentioned earlier, tanks are a single point failure in a raid and thus having tanks with this type of mod would benefit the raid even more.

FastCast was a mod (still around, maybe?) that worked for any caster that typically chain-cast a single spell for a long duration.

It worked by using the /stopspellcasting command to step spell casting client send, so that the client could send additional commands before waiting for the spell to actually finish casting.

We hypothesized that the typical sequence went like this:
(say cast time is 3 seconds and lag is 300ms)

time 0: Caster hits Cast
time 3: Caster hits Cast again. Client says, "I'm done now, can I cast another spell?."
time 3.3: Server gets request to cast another spell
time 3.6: Client gets OK from server, starts casting again

With FastCase, it was more like:
time 0: Cast hits Cast
time 2.7: Caster hits Cast again; FastCast sends StopCasting. Client believes casting has stopped.
time 3.0: Server receives StopCasting message and new cast request; Grants request because caster is done casting. Caster doesn't actually stop casting because he's already done -- his 3 second cast time is done. Caster starts casting again right now, because his client has already stopped casting.

Something like that, anyway.

FastCast was an old mod (functionality removed in 2.0, sadly, though it can be approximated with /stopcasting macros) to help casters with high latency cast, well, faster. It did this by using the in-game stopcasting command to tell the client to stop a cast once your cast bar had gone green. The net result of this was that your cast goes off (the bar went green, after all, signifying a complete spellcast) but you do not have to wait for server confirmation of a successful spellcast before beginning your next cast.

You can see a sort of variation of this effect if you have high latency and try to cancel a spell in the last .5 seconds or less. Your bar will go away (you could start a new cast if you so choose) but the spell will likely as not still cast, due to latency (the server calculated that your spellcast completed before it received the information that you interrupted it, and thus cast the spell - however, since you interrupted the spell client-side, you could have already started a new spell cast).

I can't imagine any of this would help your GCD issues, though you could potentially use a macro with Shield Block and xxx other ability, with a /stopcasting in between, which ensures that Shield Block always casts first (the macro will cast both spells simultaneously, but the Shield Block goes off before the GCD starts).

On the contrary, it's quite simple.
Install a socks server somewhere on a remote computer and use a program like SocksCap or similar to connect WoW over the socks proxy to the actual server.

We've done that to bypass a bottleneck that occurred between the WoW server hosting company and the largest German internet provider (in fact we had been relaying the data from Germany to Austria and then back again to Germany...).

This method even was allowed by a German blue poster in the official EU forums (the link is somewhere hidden in this forum).

Although this may have some other issues that I am currently not aware of, it is a certain way to increase your ping from near 0 to near 200 (or more if you choose your destination wisely ).

The issue is not creating latency, but being able to test it as a controlled variable. It's definitely doable. There are experiments that use latency to measure the speed of light and such, so it's definitely scientifically feasible, but not trivial.

This has been an issue for a stupidly long time. A one-deep spell queue would do wonders for the variations in casting speed latency and the like. I had no idea the GSC was affected in this way, actually. Fairly lame. What's further lameness is that I have to make a stopcasting macro and play beatmania with my casting bar to do my maximum damage. Not having to put up with that is definitely what I miss about being a rogue - limited by energy so you don't have any macro bullshit to get your dps up.

Yeah, rogue is a great class to play for people (such as myself) with high latency. As long as my energy bar doesn't fill up, I don't lose any DPS.

I would kill for 200ms "latency" sadly everyone playing from Australia and New Zealand plays with 400-500ms as the best ping you'll ever get most of the time. You can get 300ms in completely empty zones at odds times of the night. Latency does make a huge difference and yep the spell cast, gcd and cast bar systems are very buggy with high latency.

Australian ping pvp dagger rogues would disagree with rogues being one of the best classes for high latency

You should have seen Thaddius and Heigan with 40x 500ms players + typical Lagrock (Blackrock) peak raiding time conditions

Provided you don't have to try and hit a moving target such as a dynamic PvE or PvP setting.

"You must be behind your target", and "Your target must be in front of you" are nearly burnt into the LCD of my laptop.

Melee suffers terribly in a medium to high latency connection. I find playing my mage or druid far easier than my rogue.

Sure, spanking Patchwerk is better for a rogue in PvE than a Mage/Warlock due to cast/latency interaction, but those fights are few and far between in TBC.

hi im fairly new to this awesome site and am trying to catch up with as many threads as possible when i came across this one. i myself play with a 400+ms most of the time and having both a lock and a mage, was wondering if anyone could post the /stopcasting marcos that have been mentioned here? often i find myself chain casting frostbolts and shadowbolts coupled with DOTs and found my casting totally lacking due to latency at times. i understand that someone prob already have posted it elsewhere could anyone maybe direct me to it?

thanks for this in advance

You've got it yourself,

Its simply

/stopcasting
/cast (next spell name)



Personally I get a lot of UI errors using stop casting with 500ms, most problematic being my cast bar frequently not appearing. Which wouldn't be a problem for DPS but can be very worrying MT healing and praying my glowing hands mean something : - (.

I was under the impression that /script is completely disabled by Blizzard since December or so?

Nope. If they removed /script completely you'd have no mods to speak of.

edit: I'm no expert, but I'd guess they've removed a lot of functionality from /script without completely removing it. You can test it yourself with a clicky trinket. Comment out the unregister/register calls, change the name of the trinket and spell (to whichever trinket/spell you're using), try it. You'll get "that item is not ready yet" in red text in your errorframe every time you hit the macro. Uncomment the script calls, run the macro again and voila no red text.

In my experience, it's not feasible to use a /stopcasting makro in Raids. I've tried, but I just can't pay attention to the last 200ms of my casting bar all the time. And if you don't, you end up with less DPS or even worse: Die while paying too much attention to your castbar. *g*
I really miss Fastcast. :/

Talking about latency, a tank will drop alot in TPS with any increase in latency, since a tank is limited by GCD in 25 men, the GCD becomes effectively 2 (and up to 3 secs if your connection is fucked up or you are a long way from the servers), which can actually affect the MT chosing :/
I really find it lame, and imo the idea of queueing actions seems like a really nice idea, maybe make it only 2-3 actions so people don't just fire 23409823 frostbolts and go afk to drink a coffee, but make it 2-3 actions and that will solve so many problems!

/script is still available as always, you just can't use /script to cast spells or target people, etc. any more.

the worst death I had with latency displayed something like this in the logs :

gruul hit you for 10k ( crushing)
you die and get 10% durability lost
some paladin heals you for 4k
you gain shield block

those 4 lines were timestamp in the same second and in that order ...