In MP, this happens if 1+ clients have not finished sending commands for turn N+2, as new commands could change the state.
We want to avoid 'freezing'. At turn N, clients send commands for turn N+COMMAND_DELAY (= 2 in svn).
This gives at least TURN_LENGTH*DELAY (= 500*2 = 1 second in SVN) to receive all commands for turn N+2 (which means all clients inform the server, which informs them back). This is generally enough for smooth-ish gameplay, as you'd expect pings to be around 200ms max, and turn lengths around 100-200ms, so about 500ms round-trip in the 'average worst case'.
Unfortunately, this has the side effect of making MP turns large, which:
- makes pathfinding worse
- makes the game more 'lag-spikey', since computations are done less often, but thus take more time.
This is all summarised on #3752's comments.
To avoid all that, we could schedule commands for a farther turn, but reduce Turn Lengths. This is similar to CPU pipelining instruction.
The game still computes commands with a large delay, but turns become smoother.
This changes the delay to 4 turns instead of 2, and moves the turn length back to SP levels of 200 ms. This gives 800ms delay instead of 1s.
It fixes various hardcoding to achieve that.