Sprite Component doesn't get respawned after rollback about bevy_ggrs

[johanhelsing]

Have you tried registering all the components in spritebundle?

[PraxTube]

Oh damn, I didn't do that. Though even after registering these Components

.register_rollback_component::<Sprite>()
.register_rollback_component::<Handle<Image>>()
.register_rollback_component::<Visibility>()
.register_rollback_component::<ComputedVisibility>()

(not sure if the handle makes any sense), I am still able to trigger the same bug.
The SpriteBundle only has these Components.

pub struct SpriteBundle {
    pub sprite: Sprite,
    pub transform: Transform,
    pub global_transform: GlobalTransform,
    pub texture: Handle<Image>,
    /// User indication of whether an entity is visible
    pub visibility: Visibility,
    /// Algorithmically-computed indication of whether an entity is visible and should be extracted for rendering
    pub computed_visibility: ComputedVisibility,
}

Interestingly, the Sprite gets respawned now, which was not the case when I didn't register them as rollback components, so that definitely helped.
But the player is still invisible.

I just realized that it's probably the handle that is getting dropped? I only have one single handle that references the player sprite (player one and two have different assets). And so perhaps because the handle gets dropped (despawned) we have a handle that doesn't point to anything when we try to respawn it?

EDIT: The handle doesn't seem to be the issue. I spawned an idle Sprite with the same asset that didn't do anything and was just there to be a strong handle for the asset. The issue was still present.

[ConnorBP]

I am also getting this issue of Rollbacks not restoring everything properly after a despawn_recursive. I would definitely prefer to not have to sync every single component that is attached to the entity to get rollback to work properly. Attached components should be restored when the synced components are restored even if that means registering them somewhere else.

[clinuxrulz]

.despawn_recursive() suggests the entity must have child entities.

When rollbacks happen, the restored entities will not have the same ID number they had. Because it is impossible to spawn an entity with a specific entity ID (the ID on spawn is more or less random.)
However there exists Parent and Children components referencing those entity by their ID, that will end up pointing to a non-existent entities on rollback.

See: https://docs.rs/bevy/0.12.1/bevy/hierarchy/struct.Parent.html

So I suggest making the rollback entities single level only with no parents or children. Then use other non-rollback entities with children/etc. constructed with their transforms updated to match the rollback entities.

I had the same problem with SceneBundle when loading gltf files. But resolved it by creating a FollowPlayer component for the separate non-rollback entity containing the SceneBundle to get it to follow the rollback player entity that had no children.

Demo for separating SceneBundle from the player by using FollowPlayer component on separate entity:

• demo: https://clinuxrulz.github.io/flying-shooter/
• source: https://github.com/clinuxrulz/flying-shooter

[clinuxrulz]

If child entities are really required, you would need to implement your own child/parents system with your own IDs and not entity IDs. As only your ID numbers not entity ID numbers can be restored on rollback.

This can still be done efficiently. Create a HashMap resource that maps your IDs to the entity IDs. Update that resource at the start of every GGRS update frame. Use that resource to convert your IDs to actual entity IDs. You can also have a NextID resource for generating unique your-IDs.

Here is some untested code that serves as a proof of concept: https://github.com/clinuxrulz/bevy_rollsafe_hierarchy
It is a replacement for bevy_hierarchy, but works on generated IDs rather than entity IDs.