-
Notifications
You must be signed in to change notification settings - Fork 272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove systems if their parent entity is removed #2232
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2232 +/- ##
==========================================
- Coverage 65.64% 64.78% -0.87%
==========================================
Files 324 358 +34
Lines 30937 29213 -1724
==========================================
- Hits 20308 18925 -1383
+ Misses 10629 10288 -341 ☔ View full report in Codecov by Sentry. |
I thought of this possible alternative implementation:
A possible extension could be to also have a kind of E.g.: consider a system attached to a model and which acts on some subentities of that model:
|
I like the thought process behind your suggested API addition. However, in my mind that would be an added feature. We need to be able to remove systems safely. That is something that will take a fair deal of work right now and what this PR hopes to (eventually achieve). Your proposed API could be bolted on top in Ionic once we are able to perform safe removal. The current state of this PR is we can safely remove some plugins, but it causes weird breakages in the |
I think this works now... Will have to write some unit tests to verify. But it does not go 💥 on the warehouse world. |
I haven't had a chance to look into this deeply, but one thing to keep is how this interacts with the levels feature. If a model that contains a system is unloaded by the levels feature and gets loaded back again, what would be the behavior? Would the system get configured and start anew? If that works properly, that would cover most cases, but we might also want the ability for a system to stay loaded even when its parent entity is removed so that if the parent entity is loaded back in, the system might continue from where it left off. |
Thanks for pointing that out. I'll go check out levels and see how this PR interacts with it. A cursory reading of the levels code though makes it seem like we despawn entities and then respawn them which makes me wonder if holding a reference "entity" in a system is correct. I've not looked into this deeply enough to say anything. Will update this PR when I try it. I'm currently out on my anual firefighting reservist. |
Is any work ongoing in this PR? I'm currently working on a simulation that requires frequent loading and unloading of models. The problem of unloaded plugins really worries me. |
I just need to write some tests for this. |
Tests have been written. I think this is ready for feedback. |
Also hoping to see this merged soon. |
If you'd like to get this checked in faster you could help with reviewing it. One thing to do is to checkout the relevant branch and run it on example worlds to see that things work as expected. |
Unfortunately, I don't have any experience with the gz-sim codebase and can't really comment on whether this is a suitable solution or not. Just need a way to remove models without plugins like JointStatePublisher crashing. |
You can try it out and tell me if it crashes! There may be plugins I've not tested on! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: fix spelling in header file name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks good to me! I just noted two places where comments could be improved, and then I will be ready to approve
See #2473 |
…h interface (#2473) --------- Signed-off-by: Addisu Z. Taddese <[email protected]> Signed-off-by: Steve Peters <[email protected]> Signed-off-by: Arjo Chakravarty <[email protected]> Co-authored-by: Steve Peters <[email protected]> Co-authored-by: Arjo Chakravarty <[email protected]>
I've confirmed that when a level that contains a system get unloaded and loaded back again, the associated systems are also unloaded and loaded properly 🎉 . Regarding the ability for a system to stay loaded and continue where it left off, I propose we open a feature request and not address it right now since it's probably not going to be widely used. Since there are a number of bug reports around this issue and since levels will work fine with this, I'm in favor of backporting this to Harmonic and earlier. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this much needed feature/bug fix and for your patience in iterating!
Thanks everyone for your efforts, I will be making use of this ASAP. |
Thanks everyone for your guidance! Seems like our homebrew build is blocking the merge. |
I can reproduce the test failures on my macOS machine. I'm investigating, but it's a bit strange. The test failures may have been introduced by #2473 or #2475, since macOS CI did not run for either of those pull requests. |
|
actually the tests have been failing on |
rerunning homebrew CI now that gazebosim/gz-math#606 and gazebosim/sdformat#1458 have been reverted after seeing that the reverts fixed tests in #2482 |
n particular if a user despawns an entity, the associated plugin gets removed. This should prevent issues like #2165. TBH I'm not sure if this is the right way forward as a system should technically be able to access any entity in a traditional ECS. The PR has now been reworked and greatly simplified. All we do is stop all worker threads if an entity is removed and then recreate remaining threads.
n particular if a user despawns an entity, the associated plugin gets removed. This should prevent issues like #2165. TBH I'm not sure if this is the right way forward as a system should technically be able to access any entity in a traditional ECS. The PR has now been reworked and greatly simplified. All we do is stop all worker threads if an entity is removed and then recreate remaining threads.
n particular if a user despawns an entity, the associated plugin gets removed. This should prevent issues like #2165. TBH I'm not sure if this is the right way forward as a system should technically be able to access any entity in a traditional ECS. The PR has now been reworked and greatly simplified. All we do is stop all worker threads if an entity is removed and then recreate remaining threads.
n particular if a user despawns an entity, the associated plugin gets removed. This should prevent issues like #2165. TBH I'm not sure if this is the right way forward as a system should technically be able to access any entity in a traditional ECS. The PR has now been reworked and greatly simplified. All we do is stop all worker threads if an entity is removed and then recreate remaining threads. Signed-off-by: Arjo Chakravarty <[email protected]>
n particular if a user despawns an entity, the associated plugin gets removed. This should prevent issues like #2165. TBH I'm not sure if this is the right way forward as a system should technically be able to access any entity in a traditional ECS. The PR has now been reworked and greatly simplified. All we do is stop all worker threads if an entity is removed and then recreate remaining threads. Signed-off-by: Arjo Chakravarty <[email protected]>
n particular if a user despawns an entity, the associated plugin gets removed. This should prevent issues like #2165. TBH I'm not sure if this is the right way forward as a system should technically be able to access any entity in a traditional ECS. The PR has now been reworked and greatly simplified. All we do is stop all worker threads if an entity is removed and then recreate remaining threads. Signed-off-by: Arjo Chakravarty <[email protected]>
n particular if a user despawns an entity, the associated plugin gets removed. This should prevent issues like #2165. TBH I'm not sure if this is the right way forward as a system should technically be able to access any entity in a traditional ECS. The PR has now been reworked and greatly simplified. All we do is stop all worker threads if an entity is removed and then recreate remaining threads. Signed-off-by: Arjo Chakravarty <[email protected]>
🦟 Bug fix
Fixes #2217
Summary
In particular if a user despawns an entity, the associated plugin gets removed. This should prevent issues like #2165. TBH I'm not sure if this is the right way forward as a system should technically be able to access any entity in a traditional ECS.
The PR has now been reworked and greatly simplified. All we do is stop all worker threads if an entity is removed and then recreaye remaining threads.
Checklist
codecheck
passed (See contributing)Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining
Signed-off-by
messages.🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸