Support enum in `Config::Input`

[ThierryBerger]

I would like to use enums in Config::Input to differentiate different possible inputs.

Config::Input is requiring on Pod, which has a lot of constraints, main one is that any bit patterns should be correct, making most enum potentially unfit.

The trait Pod has been split in different traits in this PR: Lokathor/bytemuck#91 ; If I'm not mistaken, ideally CheckedBitPattern should be enough.

This should enable us to have enums within Config::Input.

Somewhat related issue: Lokathor/bytemuck#84

As noted #41 (comment), I think we're dependent on bytemuck to support more than fieldless enums.

[gschup]

Easing the trait bounds on Input is generally good, we just have to check if this remains sound. If you are willing, you could give it a try. PRs are always welcome :)

[ThierryBerger]

I would not consider this closed until we support enum with fields 😈 ; supporting « only » fieldless enum is still quite a big restriction.

It might be possible to support enum with fields currently, but it requires unsafe code which can be hard to write, so I’m advocating for considering:

• an example
• a better support in bytemuck
• some helper in ggrs

[Umatriz]

I'm not very familiar with p2p networks. But why cant we allow sending any kind of data? Why cant we just serialize it and then deserialize?

[gschup]

The constraints on the data come mostly from the compression algorithm being used. If your usecase does not fit the restrictions directly, you can always serialize your inputs outside of GGRS and create Inputs based on your serialization. One important aspect is that all inputs need to have exactly the same number of bits.

[Umatriz]

Is there an example of such serialization?

[gschup]

This input encoding example is from a much older version of GGRS, but the main idea holds:
Either use an u8/u16 where each bit represents a button being pressed or not and encode the input yourself or use a library like bincode. This example does both, which is quite unnecessary :D

Basically, if you can encode your input into a single fixed-size sequence of bits, then you are good to go. With the current GGRS you can simply define the input as a u8/u16/etc that holds these bits.

[Umatriz]

The problem is that I want to send a position where a thing should be spawned. (I use bevy) And I have no idea how to send this position. Ans as I understand its impossible todo, because it cannot be fixed. Right?

[gschup]

GGRS was built with the assumption that each client sends their inputs each frame (e.g. button inputs from a controller) and that nothing else is necessary to keep the gamestate synchronized. The framework does not have a convenient way to sync the gamestate via occasional events. It is assumed that all gamestate logic can be derived from the controller inputs (aka an input from a player under specific condition leads to an object spawning).

If you are looking for more general networking frameworks (that work via events), I recommend asking in the networking channel of the bevy discord. There are lots of great people there that can help you much better than I could!

[Umatriz]

Okay, Thank You!

[caspark]

With #82 merged, you can close this now @gschup :)