Rollback requests ignored when `max_predictions` number of local inputs is saved
aleksa2808 opened this issue · 4 comments
Describe the bug
Take a sample situation that can occur in a P2P session in laggy conditions:
- A peer sends you input different than you predicted.
- In
adjust_gamestateyou schedule a rollback/LoadGameStaterequest and modify the session's internal state in preparation for it. - However, because of the laggy conditions, you already have
max_predictionsnumber of local inputs stored so you drop all created request and instead return aPredictionThresholderror from theadvance_frame/add_local_inputmethods. - On the next
advance_framecall, since the session state was modified in preparation for a rollback as if the rollback was guaranteed to happen, you now think there is no need to rollback anymore.
Following these steps leads to a desync as you received a peer's input that didn't match your prediction but didn't rollback.
Expected behavior
In the described situation I would expect the next advance_frame call to remake the requests which were cancelled in the last frame, including the rollback one.
Here is a (messy) patch I'm using for my game currently. It boils down to checking if the local player should advance the frame (if it isn't predicting too far ahead) at the start of the advance_frame method and then skipping most things in the method if the frame is being skipped. This is in contrast to the current behavior of dropping all pending requests and returning an error if we decide mid-method that the local player's frame cannot be advanced.
Oh I totally missed that this issue already existed and opened #75, totally welcome to close my issue as dupe if desired.
@aleksa2808 I implemented my own attempt at fix here: #77 and a unit test to reproduce this case - will take a look at yours later and see how they compare.