Skip to content
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

Allow components to perform cleanup (with access to the World) when they are removed #723

Open
LoganDark opened this issue Feb 23, 2021 · 5 comments

Comments

@LoganDark
Copy link

LoganDark commented Feb 23, 2021

Description

Allow components one last access to the world when they are deleted. This could be done by either:

  1. Allowing some sort of call inside of Drop that gets the encompassing World (unlikely, probably really unsafe, stinks of globals)
  2. 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

Unresolved questions

None right now

@LoganDark
Copy link
Author

wha twhy does enter submit the issue
give me a minute...

@LoganDark LoganDark changed the title Accessing resources in Drop Allow components to perform cleanup (with access to the World) when they are removed Feb 23, 2021
@Imberflur
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Author

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?

@zesterer
Copy link
Contributor

@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).

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

No branches or pull requests

3 participants