Open MaxCWhitehead opened 3 months ago
Would it not just make sense that you implement the Zeroable
trait correctly for your type that will set your axis value to it's relevant neutral (or Zero) value instead ?
It is after all defined in the required traits for PlayerInput
:
https://github.com/gschup/ggrs/blob/0af1a044b96465bd10398947b7fb5e0a34a75f70/src/frame_info.rs#L28-L35
Describe the bug When GGRS provides a predicted input for a client with no previous inputs on session startup, it uses a zeroed value of PlayerInput. https://github.com/gschup/ggrs/blob/0af1a044b96465bd10398947b7fb5e0a34a75f70/src/frame_info.rs#L56-L61
If the user provided input type does not represent no input when zeroed, this seemed to sometimes lead to desync on session start. Not 100% sure if it actually makes sense that this should've caused desync though, perhaps should have been rolled back on remote once actual input was replicated.
We were representing movement input between [-1.0, 1.0] quantized to integer such that 0 bits represented -1.0 movement and ran into this issue. Changing representation such that zeored represents 0.0 or no movement on axis resolved the issue.
Expected behavior It might be beneficial to document this assumption on
ggrs::Config::Input
. Another option is to requireDefault
trait and use this for blank input.