Variable size Config::Input causes crash in delta encoding

[caspark]

If you define an Input type such as:

struct MyInput {
    v: Vec<u8>,
}

and the length of v varies from frame to frame, then the delta encoding in src/network/compression.rs panics due to the "all inputs must be the same size as the reference input" assertion.

Caused by my #82 PR, which enables using varying-size inputs - I didn't actually test with varying input sizes, whoops! I'm working on a fix.

[caspark]

.. although, now that I've written it up, I just realized that actually on main varying the size of Input would be difficult because Input must be Copy (so you can't e.g. use Vec). It would technically be possible to trigger this behavior if Input's Serialize was non-deterministic, but that seems so unlikely to be the case that it's not worth worrying about.

So, although I'm working on lifting the Input: Copy restriction in my fork and this is an issue I need to fix there, it doesn't affect main so I'll just close this issue for now.

[mendelsshop]

Sorry for bumping this, but I am running into this with my game using the latest version of bevy_ggrs, when using an enum with variants of different sizes.

[caspark]

Huh, I didn't consider that bincode might encode enums of varying sizes as different sizes - whoops.

I have a fix in my fork at caspark@7802ee0 but haven't got time to PR it right now - will add it to my backlog!

In the meantime you can either:

• use my fork with a Cargo.toml patch (nb might want to fork my fork since I do force push main occaisionally)
• work around the issue by serializing your input to a byte buffer of fixed size (pick a size guaranteed to be at least as large as your largest serialized input), and submitting that byte buffer to GGRS as input
• take my commit and PR to here yourself, if you like :)

[mendelsshop]

I have a fork with just your commit cherry-picked (other things you changed were incompatible with bevy_ggrs), and it works on my machine.
Maybe I could make a PR, my only worry is that I don't 100% understand the code, but it looks pretty ready to me.

[gschup]

Thanks for tracking this down and providing a working fix! After looking at your approach, I decided to go with a slightly different solution: rather than adding a wrapper struct serialized via bincode, the fix uses a simple 2-byte length prefix before each XOR-encoded input. This lets the decoder split inputs correctly regardless of size, with minimal overhead and no extra dependencies.