You need to understand what happens when you press the turn key. First, at the time you press it, your client doesn't have the full information of the state your cylce is in. It only has an extrapolation that is based on what the server last sent. The first causes of lag lie directly here, the extrapolation may be wrong. (1) Maybe the reason is a network problem, packets from the server to your client getting lost or delayed. (2) Maybe it is a bug in your client that causes the extrapolation to be wrong. Maybe it is just a regular gameplay thing: (3) you've been riding within the laggometer of another player, and that player turned and threw a wall your way. Obviously, if your client is sending the turn with a wrong gamestate, then the server will have a different view and won't be able to execute your command exactly as you expect. The server has the capacity to detect these errors, but it can't distinguish between (1) and (2). And it can't fix the problem by believing the command data from the client, this would give way to cheating.
So let's assume your client has a reasonable game state in memory. Your turn command is then sent over the network to the server. (4) Of course, it can get lost or delayed on the way. Because the commands carry game time stamps, the server can detect and correct the problem (within reasonable bounds to avoid cheating), and it does so. (5) If there is a server bug, your command won't be executed as your client correctly predicted. After executing your command, the server sends a message back to you with the result of the execution, the client incorporates that into the extapolation, which brings us back to (1). If anything of (1) - (5) goes wrong, you'll be lag sliding/jumping on your own screen.
The same happens to the other players/cycles. After their command is executed, updates about it are also sent to your client. (6, almost the same as 1) Those updates can again be lost or delayed, making the cylces go straight longer than they should, and when the update finally arrives, they jump or teleport around. Or the clients make a mistake in reading the update (7, almost like 2), then you see them jump as well. Or the server made a mistake and delayed the command execution (8, almost like 5), again the result is a jump of an enemy cycle. Those three are almost indistinguishable in their effect.
Hey, I actually get to (9)
Then, there is "Death Lag". Death lag is the server being nice to you. Just before you would die, the server stops your clock and waits for life saving commands from your client that were possibly delayed. The same applies to the others, so if you see another player sitting in front of a wall that strange extra bit, it's the intentional death lag. And if you experience lag and death at virtually the same time, chances are that you were not actually killed by lag, but that the lag you perceived was actually the effect of the server trying to keep you alive. Also, the client ignores all game world events that usually would kill you and does not predict your death, because false positives there would be very disturbing. That's why you sometimes happen to see your cycle pass behind the receeding trail end of another cycle or over a vanishing trail, touching it a bit, going straight for half a second, then warping back and exploding. That's death lag and the intentionally missing death prediction of the client working together.And that's why "BUG! LAG!" is not enough information to fix any of this. The gameplay part and the network parts are fundamentally unfixable, and the other forms of lag are very hard to tell apart by only looking at a serverside recording. That's why I'm asking for clientside recordings that often.
