Closed shelbyd closed 2 years ago
I am currently a bit busy with my actual job, but I have been thinking about allowing variable-sized inputs for some time. Currently, I use the fact that all inputs are same-size to make LRE-XOR encoding of input sequences simple. I am however thinking about how to change that elegantly.
MAX_INPUT_BYTES
does not exist in the main branch anymore, by the way. But all inputs still are required to be of same length. When choosing some absurd lengths, some packets constructed by GGRS might exceed the maximum UDP payload. In these cases, GGRS will panic.
Inputs are now generic over all POD structs. I am closing this issue, since the disussion is outdated.
Is your feature request related to a problem? Please describe. The input for the game I'm working on is difficult to serialize into a fixed size
Vec<u8>
. Each player has different abilities that change over the course of the game. I don't want each client to have to keep track of the input mapping for each player, or worse, the UI for changing input mapping. I'd like to basically serialize the following:I'd certainly serialize using something like bincode to minimize the bytes, but I can't in general use a fixed size input.
Describe the solution you'd like I'd like the ability to specify that my inputs are variably sized. Probably having constructors take an explicit enum or
Option<usize>
. For variably sized inputs, theVec<u8>
can be prefixed with a compact representation of the size, at it should usually be small. We could use the existing SCALE codec'sCompact<T>
.Describe alternatives you've considered I could have a queue of actions and send whatever I can fit each frame. That could potentially add unwanted delay to actions and would interfere with the ability to "hold down" an action. I'd additionally likely need to write a custom serialize implementation for my actions as a naive one would likely be too large.
Alternatively, remove
MAX_INPUT_BYTES
and allow the user to determine the fixed size large enough to fit their inputs.Additional context Add any other context or screenshots about the feature request here.