Entity pool clarification

[TarVK]

Hello, and thanks for this repo.

I've been contemplating doing rollback networking with bevy and rapier, and even went as far as starting to try and write a custom version of bevy_rapier for it because it seems that the entity spawning of bevy_rapier would not allow for deterministic spawning. But I'm slowly discovering that making a bevy <-> rapier connection seems to be a deep rabbit hole I would preferably not go down. I was curious whether you could elaborate on the approach you took to get bevy_rapier to work without problems. I read these lines: https://github.com/cscorley/bevy_ggrs_rapier_example/blob/main/src/main.rs#L78-L90, but do not understand how this solves the problem exactly. Would the rollback not get rid of the rapier body handles in the bevy components, and then reinitialize again on every rollback (with an arbitrary initialization order)?

Any kind of explanation would be appreciated, thanks!

[cscorley]

Rollback will only remove the handles if we instruct GGRS to manage those Components. But we won't be doing that, so they should remain until we remove them ourselves to reset.

The way this was meant to work is to preallocate any Entity that Rapier will use itself (i.e., what we will put handlers onto). Then, Rapier will be operating on all Entities in the exact same order (pending the PR bevy_rapier is pinned to in Cargo.toml) for all of your players. In my experience, this caused Rapier to have more deterministic output w.r.t. rolling back the context, and we also can easily hash the RapierContext for comparing desyncs later since everything inside is serialized in the same order.

I have since moved on to using Avian for projects, which allows me to just skip all this. It is a joy to use in this context in comparison, and I cannot recommend switching enough.