This section gives a brief overview of what goes on between the client and the server. It's not complete, and it may not be entirely accurate, since most of the information I learned second-hand, or inferred from the game source and from extensive testing. Still, it should be adequate. It certainly is consistent with all of my observations and tests so far.
It's also very necessary to understand if you want to implement any kind of lag compensation at all. Many mod-authoring readers will need to adjust the Unlagged code to fit their games. That will be considerably easier if they have a solid understanding of what's going on and how it works.
In order to make sure what I write (and you read) brings to your mind images similar to what I imagine when I'm writing about them, we'll have to go through some terminology. Hopefully it's not too dry.
Snapshot: a chunk of data sent from the server to the client that represents what's going on on the server, at the end of every server frame. (The term's reference to photography is very apt.) The client's representation of this data (in models or polygons rendered, and sounds played) is the starting point for how the player perceives the game world.
Since the client game runs at a different rate than the server (usually at a faster rate), it cannot always represent this data exactly as it receives it. It must interpolate or extrapolate.
A snapshot may contain (but is not limited to): positions (origins) and velocities of other players, origins and velocities of non-player entities such as rockets, sounds to be played and effects to be drawn (events), scoreboard information, and custom client commands.
We'll not concern ourselves with exactly what is included in a snapshot (or excluded according to the client's potentially visible set) or any compression techniques. Our biggest concern is with what player origins are sent.
Command: One command is sent from the client to the server every client frame. A command consists of the following data:
Aside from custom commands such as “quit,” this is all the server uses to react to player input.
Interpolate: to estimate a value between two known values. Generally, the Quake 3 client game determines other player origins by interpolating between two known origins, which it obtains from two corresponding snapshots.
Extrapolate: to estimate a value beyond one known value, using additional data. For example, rocket origins are extrapolated using a base origin, a velocity, and a time delta.
Prediction: when the client or server takes a guess at how something in the future will happen. The kinds of prediction we talk about are of course special cases of extrapolation. And normally, when we talk about Quake 3 prediction, we refer only to the client game predicting where its own player will be by the time the client's commands reach the server. (Unlagged has other uses for prediction, such as smoothing out players who would otherwise be skipping around.)
Prediction error: when the prediction is wrong. It must be corrected for, which introduces some of the most severe visual problems when it happens on the client – depending on how far ahead the client was predicting.
Frame: a regularly-scheduled (or semi-regularly-scheduled) period of time in which the server or client gets things done. (In case you were wondering, that's about as specific a definition as we can get.)
There's no need to describe every tiny detail of the process. Here's a rough sketch of what goes on on the server, though:
On the client:
There's obviously a lot more going on than what's listed, but I've listed what we're concerned with for dealing with the many faces of “lag.”
Next: A Solution