Is there a way to get this working with something like bevy_ggrs?

[goodiesohhi]

bevy_ggrs is a rollback netcode library and the rolling back of entities and components completely loses it because when things rollback entity references don't work.

[bilowik]

From the quick glance I made I don't see a reason it wouldn't work. As it currently functions, sending the despawn particles event also despawns the entity. The way this library works doesn't rely on referencing back to the original entity to create the particles so that shouldn't be an issue.

Those warning messages come from an error that is thrown when the Entity does exist, but didn't have a mesh or sprite to create the particles from. EntityCommands::despawn is still called for that entity for that event still, so the following Errors for that same entity not existing may be bc it was already despawned by the event handler.

I'll take a closer look tomorrow!

[goodiesohhi]

not sure exactly what the mechanism but replacing the event with just a normal despawn has no problems, but then using the event causes that.

[bilowik]

The best help I can offer is that the warnings mean the entity does in fact exist but doesn't have a Handle<Mesh> or a Handle<Image>. There is a DespawnMeshOverride component if you want to add a Mesh only for the despawn particles. There's also a field in the event that can include a mesh handle as well for entities with no visual components. If you expected them to have either of those handles, I would triple check that they do.

I would also triple check you are not both calling despawn and also sending the event.

I tried wrapping my head around ggrs, and I understand it on a conceptual level, but have no idea how it would be implemented, so it is hard for me to tell exactly how these libraries would interact, but my initial thoughts are that it should not conflict and should work fine with that library.

The only instance where I can imagine an issue occurring is if that library is despawning an Entity after you send an event but before the event is handled. In which case, I'm unsure of how to handle that aside from ignoring the warnings and errors.

[bilowik]

You could try scheduling your system that is sending the event directly before this plugin's system set DespawnParticlesSet.

Or if it may be possible, modify the schedule of ggrs systemset to run after DespawnParticlesSet

All that aside, my original goal of this plugin was to directly hook into the despawn process so that way an event wouldn't be needed at all, and it would do the particles if a component (essentially the Event but with Component implemented) was found on the Entity. Which would provide so many nice guarantees and avoid issues such as this. I may look into this again tho since i'm thinking about it again.

[goodiesohhi]

well that's the thing, with ggrs rollback, the system is under control of the rollback schedule I'm not sure if I can really control it like that. Say for example, in my system I tell the eventwriter to despawn a projectile, then rollback decides to roll things back, I think that's why things are messed up. I told rollback to actually rollback the image handles and that seems to have fixed the image handle part but that still happens. I guess the rollback doesn't like that the event works like that because the event uses a reference to the entity id right? that entity may or may not be there because the despawn particles exists in its own schedule set and that conflicts with ggrs's schedule set? Maybe I could see if I can create a fake projectile with the same imagehandle one that isn't rolled back and lives freely from the rollback cycle and then use despawn particles on that.

[goodiesohhi]

Oh okay that did the trick, definitely a hack but if I just despawn the thing, spawn a duplicate then call the event on that, I can decouple it from rollback and it will be fine, it doesn't mean a big deal if a visual effect that only lives a few frames is desynch'd sometimes when rollback happens, not even very noticeable.

[bilowik]

Glad you figured something out! You may have done this already, but you can also set the visibility of the duplicate to be invisible and it should still produce the particles on despawn just fine, if you want to avoid having them both be visible.

[goodiesohhi]

Glad you figured something out! You may have done this already, but you can also set the visibility of the duplicate to be invisible and it should still produce the particles on despawn just fine, if you want to avoid having them both be visible.

I simply destroy the original, then create the duplicate, the destroy that XD it works fine.