Input Redundancy Serializer does not check for empty snapshots#573
Input Redundancy Serializer does not check for empty snapshots#573Riordan-DC wants to merge 1 commit intofoxssake:mainfrom
Conversation
|
Wait. I may have caused this bug with my own crappy serialiser. What my serialiser did was overwrite the stream buffer (destroying other data put inside). I think regardless it is still nice to have this error checking (and maybe a log.trace to help programmers find out their data is crap) but not a priority. I'll leave this PR up if anyone finds it useful, otherwise I can close. |
|
@Riordan-DC I'm on the fence whether these checks are needed. Would you mind sharing the buggy version of your serializer? That could provide more context, and maybe we could brainstorm on possible checks to defend against that bug ( if possible ).
There's a difference between no snapshot and an empty snapshot imo. Similar to how |
Issue: Input Redundancy Serializer does not check for empty snapshots
Input redundancy serializer will send a short history of inputs to the server. When a client connects, if it has yet to generate an input history to send. The serializer sends empty snapshots. The input redundancy decoder on the server doesnt know how to handle empty snapshots and decodes them as normal. This reads garbage memory into the snapshot, most importantly, its tick value. A garbage tick value is often a huge unsigned number. When the server's rollback input history buffer tries to find a place for it, subsequent snapshots (with normal tick numbers) will not be allowed in. The server then stores no input it receives, in therefore cant do rollback, cant send rollback updates, etc.
This PR checks if a snapshot is empty on both ends of the input redundancy serializer and skips or breaks if found.
Criticism: Why don't we just not record empty snapshots. Then we wont have the chance to send an empty snapshot.
Answer: I think the system is designed such that a snapshot is going to be recorded at a tick regardless if anything is inside. A more experienced contributor could help me out here.