Sprite Component doesn't get respawned after rollback

[PraxTube]

Describe the bug
The Sprite component doesn't seem to be respawned when
despawning an entity with .despawn_recursive().
Other components like Transform and custom Components
get properly respawned. The issue results in the entity
fully functioning but being invisible (as there is no sprite).

I fully expect this to be my fault for overlooking something,
but I just can't think of anything I would be doing wrong.
Are there any known pitfalls for using Sprite?
Any issues with rollbacks with them?

To Reproduce
The setup to reproduce this rather cumbersome as you need to
despawn an entity and rollback right after. The way I consistenly
do this is by setting a high ping (>100ms) and then almost
kill one player but save him in the last second.
This results in the receiving client mispredicting and despawning
the player and then rolling back and respawning him.

Expected behavior
The Sprite should be respawned as well.

Screenshots
I don't expect anyone to try to reproduce this, so instead here is
a video showing what I mean. The perspective is from the still (orange) player.
The sprite shows normally on the other player (as he doesn't mispredict his own input).

Desktop

• OS: Linux (Ubuntu 16 based)

Additional context
Note that I am also using matchbox in my game and it might
be caused by matchbox instead of bevy_ggrs, however I believe it is a rollback
issue and so I suspect the bug to be in bevy_ggrs
(if there is a bug at all, totally possible that I am just missing something).

Again, I am not asking for anyone to do my work and debug my own game, I am just wondering if there are any known issues with the Sprite component.

[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.