Hey all! I've had a really lengthy process of trying to circumvent the inevitable problem of being unable to rewind physics states. Currently, I forward predict the client inputs so that they arrive "in time" (running the agent ahead). In theory (superficially) this looked to be a reasonable solution, and any minor error correction would be fine, playable (the best I could do!). But, when I started ripping apart the movement code to determine the unknown source of error, I found a snag. Simply assuming the inputs arrive at time current_time + rtt/2 is a perfect concept until input batching is used. But when you batch your inputs into a packet, they are delayed. So, firstly, here is a visual representation of my problem.

[attachment=13079:error.png]
Now, If I assume that the "formula" written at the bottom would be correct, can anyone suggest any better alternatives, or offer any better insights. I feel less comfortable with the more variables in the prediction, and whilst the batch size should not change, it still unnerves me! Thank you for your time, in advance

Simply assuming the inputs arrive at time current_time + rtt/2 is a perfect concept until input batching is used.

No, it's a perfect concept until your latency changes, which can and does happen all the time. Deliberately holding back data to batch it up is just one of several ways in which your data could arrive later than you hope. Any estimate of time differences between client and server are always just estimates and are subject to error and future change.

It's not clear to me what you mean by 'forward simulate the client inputs' - usually inputs are the only things that cannot be predicted (and thus predicted behaviour after an input usually has to be discarded or blended towards a corrected value).

If the underlying problem is that the Server receives input 0 at time 7 and assumes it happened at time 4 due to the batching latency, then have the client include timestamps alongside its inputs so the server can replay them in a way that matches the client. Obviously this introduces the capability for the client to lie to the server, so server-side validation would be necessary.

Herein lies the problem, i can't replay inputs.

I'm pretty use it's length - 1?

Although, i did miss something from the diagram. Basically, if the packet is 5 inputs worth, and each input was sampled every 2 ticks when compared to the game tick rate (which is the benchmark rate for all game data, and usually the server runs at the same tick rate, the client runs at half game tick rate for example) then it means that it took a total of 5 * 2 game ticks worth of time to populate. For any input in that packet, it now has to wait until the rest of the entries in the packet are read before it arrives. If it is the last input in the packet, it still has to wait until the server has processed all the first inputs, whereas if it is the first in the packet, it has to wait until the client has filled the batch. Taking the first entry for example, it has to wait (n entries - 1) * sample_rate_compared_to_game_tick_rate time. (This is because the batch is sent on the same tick as the last is processed)

Herein lies the problem, i can't replay inputs.

By 'replay inputs' I literally meant applying the client input to the server model, which you must already do in some form. If you have a server-side buffer (as hplus0603 suggests) then you can soak up some of that latency jitter. But it's not theoretically possible to completely solve this problem, as all it takes is one message to get held up for longer than your buffer and the system breaks, so you must always have the capability to either ignore a late message entirely or accommodate it. (And besides which, you wouldn't want an oversized buffer anyway because that gives you too much latency.)

In general terms the whole batch issue is irrelevant here - it's just another form of jitter, albeit one you introduce yourself via the client.