In part one we talked about lag as a concept and some of the different sorts of lag we experience. This post will deal with how lag affects World of Warcraft itself. Part three will talk about practical ways of dealing with lag.
There are two types of lag in World of Warcraft: lag that we can do something about and lag that we can’t. Let’s look at the sort of lag we can’t do anything about first.
Lag we can’t do anything about
The sort of lag that I described as “processor” lag is basically beyond our control, at least when it occurs on the server. All we can do is try not to overload the server with commands because it won’t help anyone. The server seems to usually process movement pretty accurately so long as you don’t cast any spells while moving, so if you’re experience severe lag of this sort you can try to simply run away to safety.
What I described as “graphical” lag is in a similar category as there’s not much we can do about it from a gameplay perspective. What we can obviously do is upgrade our graphics cards and/or turn down our graphics settings to make the game run more smoothly. Remember that from a minmaxing point of view, the only thing that matters in a raid environment is seeing and understanding everything that happens as quickly as possible, which means you want the maximum framerate that allows you to still see all the various puddles of death and whatnot. Pretty lights are secondary to this necessity.
(I have my graphical settings turned up rather higher than they should be because to me pretty lights are not at all secondary, and this unfortunately causes me big problems when I join 25-man raids – often I get less than 2 frames per second even on simple fights like Toravon. However 10- and 5-man environments tend to give me a reasonably playable 20-30 FPS.)
Lag we can work around
The types of lag I referred to as “network” and “biological” are what most of us will actually experience as affecting our daily raid play, and thankfully they are the types we can do the most to mitigate the effects of. However before I begin I must note that WoW is obviously a very complex and advanced piece of programming and is doubtless far more clever and complicated than the picture I am about to present. Likewise for human reaction times. But this, on a very simplistic level, is how the client-server model we looked at earlier translates into WoW, and how human reactions can affect it.
(If you regularly read my posting on the Elitist Jerks forums, you will already be familiar with what follows and can skip to part three.)
The /stopcasting story
As we have seen, the client and server are separated by a time delay (“lag”), which can only be measured by timing how long it takes for a packet of data to travel from the client, to the server, and back again. This is the “latency” figure reported in WoW. This figure is significant because many actions depend on the client asking the server to do something (like cast a spell), the server receiving and confirming the instruction, and then both client and server beginning the action. When the server completes the action, it lets the client know and – prior to patch 2.3 – the client would then and only then enable the sending of more instructions to the server. Before that the player would just have to sit and watch their cast bar fill up.
So prior to patch 2.3, a spellcasting timeline for a spell that takes 2 seconds to cast (2000ms) would look like this, assuming 0 reaction time and 200ms latency:
(I’m really sorry for the rubbishy timelines, I didn’t really know how best to illustrate this – perhaps I will tidy them up later.)
As you can see, with this model, a player’s full lag is inserted before every new spell cast. A 2-second cast with 200ms latency was effectively a 2.2-second cast.
However, cunning players realised that if they told the client to stop their spellcast after the point where that instruction would no longer reach the server in time to actually stop the cast, they could then make sure that the instruction to cast the next spell reached the server as soon as possible. This was risky but if you could pull it off it eliminated the effect of latency.
So you (hopefully) see, under this model people were saving time by “tricking” the client and server into behaviour that contradicted each other. After the initial cast (where latency could not be entirely eliminated), in theory it was possible to make the server chain-cast – at the risk of accidentally cancelling your spells if you timed it wrongly. Obviously this was all a bit ticklish and unpleasant.
Patch 2.3 and the spell queue
In patch 2.3, a system was added whereby the client would no longer ever prevent the player from sending new casting instructions to the server (except for during a “hard” 1000ms lock after each cast is begun). Instead, you can send the instructions at any time and, if there is not much time left on the spell cast, the server will “queue” the next instruction instead of rejecting it. This duplicates the behaviour of the stopcasting macros without requiring the same sort of split-second precision timing and without any of the risk.
Nowadays, if you are half way through a spell and you press the button to cast another spell, you won’t get the “Another action is in progress” message until after the client has sent the instruction to the server and the server has said “hold on yet, I’m not finished!“. And if the spell you are casting is nearly complete when you press the button (the window of opportunity is thought to be about 300ms) then the server will say “thanks, I’ll cast that next” and the client will not give you an error at all.
So using the spell queue it is in theory possible to eliminate most of the effects of “network“ latency. We’ll talk about exactly how that works in part three, where we’ll also deal with the issue of reaction times.