You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Allow components to perform cleanup (with access to the World) when they are removed #723
Allow components one last access to the world when they are deleted. This could be done by either:
Allowing some sort of call inside of Drop that gets the encompassing World (unlikely, probably really unsafe, stinks of globals)
Creating some sort of trait that acts like Drop but allows the component to access the world like a System does. Perhaps it could be named Cleanup or something?
Motivation
I have a component that represents ownership over some physics objects. When the entity holding that component is deleted, I want the physics objects to also be deleted. The problem is that inside Drop, I have no access to the physics world because it's a resource. :(
Drawbacks
Is it a breaking change? No, features are only added
Can it impact performance, learnability, etc? The performance of deleting large amounts of entities with components that require cleanup may be impacted. However, due to monomorphization, if you go with the cleanup trait then there will be no code generated for components without it, just like Drop. That means only code that explicitly opts into this feature will be impacted
changed the title [-]Accessing resources in Drop[/-][+]Allow components to perform cleanup (with access to the World) when they are removed[/+]on Feb 23, 2021
I think the main barrier here is that typically other parts of the world can be borrowed mutably and immutably while removing components from a particular storage.
I think the most effective way to do this is to have a zero-sized 'delete' marker component and a system that runs at the end of the tick to go through entities with this marker performing whatever operation you want to do with them and then deleting them.
I think the most effective way to do this is to have a zero-sized 'delete' marker component and a system that runs at the end of the tick to go through entities with this marker performing whatever operation you want to do with them and then deleting them.
maaaayybbeeee? It feels extremely awkward and very not right but I guess it would technically work?
@LoganDark This is the most correct way to do this within the ECS paradigm. Zero-sized marker components are extremely cheap (they're usually completely allocation-freeze).
Activity
LoganDark commentedon Feb 23, 2021
wha twhy does enter submit the issue
give me a minute...
[-]Accessing resources in Drop[/-][+]Allow components to perform cleanup (with access to the World) when they are removed[/+]Imberflur commentedon Feb 24, 2021
I think the main barrier here is that typically other parts of the world can be borrowed mutably and immutably while removing components from a particular storage.
zesterer commentedon Feb 24, 2021
I think the most effective way to do this is to have a zero-sized 'delete' marker component and a system that runs at the end of the tick to go through entities with this marker performing whatever operation you want to do with them and then deleting them.
LoganDark commentedon Feb 24, 2021
maaaayybbeeee? It feels extremely awkward and very not right but I guess it would technically work?
zesterer commentedon Feb 25, 2021
@LoganDark This is the most correct way to do this within the ECS paradigm. Zero-sized marker components are extremely cheap (they're usually completely allocation-freeze).