Skip to content

WIP Despawn using a disabling component#127

Draft
adammitchelldev wants to merge 6 commits intogschup:mainfrom
adammitchelldev:despawn_markers
Draft

WIP Despawn using a disabling component#127
adammitchelldev wants to merge 6 commits intogschup:mainfrom
adammitchelldev:despawn_markers

Conversation

@adammitchelldev
Copy link
Contributor

This PR implements a new way of despawning entities using a disabling component that records which frame the entity was despawned on. If the simulation performs a rollback then we can simply remove the component to resurrect the entity. If instead, the confirmed frame count moves past the despawn marker, then we can safely full despawn the entity.

This is a first pass at an implemention to support further discussion, with a couple of intended features missing. It has not been tested yet.

I haven't yet looked into which other systems are going to need to build in explicit bypass for the disabling component, but my theory is that existing systems will continue to work fine. Because we resurrect the entities at the start of LoadWorld, the existing mechanism for respawning entities that are present in the snapshot but don't exist in the world should simply see that the resurrected entities are there, as though they never despawned.

Looking for comments/feedback on the approach and any steer on what can be accepted as a PR down the line.

@adammitchelldev
Copy link
Contributor Author

So the approach appears to be working overall, but I'm getting desyncs that I believe are related to the way entity IDs are re-allocated after despawning; this probably breaks iteration orders in Avian.

I don't think bevy_ggrs has ever aimed to make iteration order deterministic anyway, so I don't think it would be in-scope for this PR to solve that. I think all we need here is some testing and then I think it'll be ready for review.

Whilst I'm working on my project, the intended side effect is to give others a way to use Avian out of the box in multiplayer, along with anything required to ensure that it's desync free. I'll be working on solving this problem downstream for now but I think it would be great to upstream that at some point!

@johanhelsing
Copy link
Collaborator

johanhelsing commented Feb 14, 2026

@adammitchelldev Where is the downstream issue (if there is one)? I'm really interested in following progress on this.

Also I like the sound of a Disable approach. The despawn/respawn that currently happens is a huge footgun.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants