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

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

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

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

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.

 

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