-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix false positives in remote desync detection #64
Conversation
And fix bugs with checksum interval > 32
I keep getting the following panic right after peers connect in my
The frame not found seems to depend on the specified desync interval.
Changing the max prediction window and max frames behind didn't do much either
Is there anything that has to be configured in order for this PR to properly work in |
It's expected to work with bevy_ggrs. But very possible that I overlooked something. I tested with box_game_p2p on this branch https://github.com/gschup/bevy_ggrs/compare/main...johanhelsing:bevy_ggrs:trigger-desync-issues?expand=1 and in my own game. |
@PraxTube are you able to reproduce your panic by modifying this branch? https://github.com/gschup/bevy_ggrs/compare/main...johanhelsing:bevy_ggrs:desync-debug?expand=1 EDIT: Managed to by setting input_delay back to 2. Will look into the issue |
Ah yeah, for |
I added a test, which is good in itself, but for some reason I don't get the panic there :/ EDIT: managed to repro with a higher input delay :) |
This is ready for review now. There is one thing that bugs me (see comment above), but I'm giving up trying to understand it for now. This is a lot more correct than the previous implementation. And has a test case that failed prior to this PR (and another one to make sure the panic reported by @PraxTube is fixed) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks correct to me and everything is structured the same as it was before, so I really can't complain. Nice cleanups here and there :)
I am still baffled that this very obvious detail of comparing checksums only for confirmed frames didn't occur to me in the original PR.
Fixes #63 and also fixes a bug that checksums are removed prematurely if the interval is >
MAX_CHECKSUM_HISTORY_SIZE
Confirmed working with the test case for #63
Bonus: Remote checksums are now only checked once (removed once verified).