   Clock syncing mid-game
  So, I've got a little networking system that syncs to the server just fine.  The way it does it is a little weird, though.  Basically, it works like this.Server sends updates to the client (time is 50)Client receives update, declares local time is now 50, local ship shown at time 50+5(lag guess)Client and server each undergo 5 game ticks.Client sends inputs to server, including note about what time it thinks the packet will arrive. (client figures 55+5, so 60).Client and server each undergo 5 game ticks.Server receives packet, notes how far off client's guess was, includes a correction order in next update (time's 60, delta command is still 5, since client nailed it).This seems to be working smoothly, but I worry that always accepting the newest packet from the server as the local time might cause visible jumps on occasion.  Should I be somehow smoothing adjustments to the local time when they're wrong?  It should be fairly infrequent that they get out of sync, but it's certainly possible.   
  Under what circumstances do you expect the clocks to go out of sync?   ;  Well, really the biggest adjustments are in the first second or two of gameplay while the syncing is still occurring.  I suppose I could avoid that by syncing before letting the player start.Hrm...I suppose it is more or less guaranteed that the server and client's clocks will be running at pretty close to the same rate, but I dislike relying on that, it just seems somewhat sloppy to me for some reason.  If the client's got a pretty lousy timer that loses a second every hour, every hour of gameplay is going to add 1000ms of latency, and that seems unacceptable to me.   ;  Yes, you should re-sync the clock. You can re-sync it by adjusting the rate of advance, rather than adjusting it by jumps, though.   ;  Ooo, that's an interesting idea.  No wonder you're the moderator :)Is that the same answer for how I should handle sudden shifts in latency?  If the client's predicting itself 15 states ahead, and suddenly the lag drops 10 frames' worth (the user quit using bittorrent), lowering the prediction to 10 states back would cause an ugly jump.  So presumably the answer is to just update more slowly until we sync up again?   ;  You got it. I would keep a maximum slew rate -- i e, never allow more than 2% difference in rate between client actual rate and rate calculation. If you find you need more than that, something's more wrong, and you should take the hit and do the big adjustment.Also, beware of over-compensating. If you're not careful, you'll end up with oscillation, so some dampening would probably help.   