Skip to content

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

Open

Description

@LoganDark

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

Activity

  1. LoganDark commented on Feb 23, 2021

    @LoganDark
    Author

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

  2. 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
  3. Imberflur commented on Feb 24, 2021

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

  4. zesterer commented on Feb 24, 2021

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

  5. LoganDark commented on Feb 24, 2021

    @LoganDark
    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?

  6. zesterer commented on Feb 25, 2021

    @zesterer
    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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions