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_gamestate you schedule a rollback/LoadGameState request and modify the session's internal state in preparation for it.
- However, because of the laggy conditions, you already have
max_predictions number of local inputs stored so you drop all created request and instead return a PredictionThreshold error from the advance_frame/add_local_input methods.
- On the next
advance_frame call, 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.
Describe the bug
Take a sample situation that can occur in a P2P session in laggy conditions:
adjust_gamestateyou schedule a rollback/LoadGameStaterequest and modify the session's internal state in preparation for it.max_predictionsnumber of local inputs stored so you drop all created request and instead return aPredictionThresholderror from theadvance_frame/add_local_inputmethods.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_framecall to remake the requests which were cancelled in the last frame, including the rollback one.