entt icon indicating copy to clipboard operation
entt copied to clipboard

Allow entities and components of specific entities to be disabled/enabled

Open Domiran opened this issue 2 years ago • 5 comments

It would be super helpful to be able to disable either an entity or a specific component on an entity, both without actually deleting entity or component. The entity or component continues to exist, does not get overwritten by entt during creation (retains its id and version), and might be re-enabled later.

What

  • get<T> and try_get<T> should not return component T if it has been disabled for the given entity.
  • get<T> and try_get<T> should not return an enabled component T if the given entity is disabled.
  • A view should skip a disabled entity.
  • A disabled entity or component should be able to be deleted.

Imagine two entities exist with components:

Entity A -TransformComponent -RenderComponent -CollisionComponent

Entity B -TransformComponent -RenderComponent -CollisionComponent

If I disable Entity A, it should not be returned if I create a view on CollisionComponent.

If I disable CollisionComponent on Entity B, only Entity A should be returned if I create a view on CollisionComponent.

(Why you would disable CollisionComponent I have no idea. This is just to demonstrate that disabling a component applies to a specific entity, not all components of that type.)

Nice to Have

  • Something that could return all disabled but not deleted entities and components (by type) but at worst the user could just be maintaining a list of disabled entities.
  • An alternative version/overload of view that returns all entities, enabled or not.

How

I'm purposefully not suggesting how an entity or component might be enabled or disabled.

Why

Presumably entt's own check would be far faster/efficient than the method I employed to do this. All of my components derive from a Component class, which has an enabled member. All entities get a GeneralComponent on creation. Among other things GeneralComponent does, its enabled is treated specially: to determine if the entity itself is considered enabled.

Background

I was working on a pathing system that has three pieces: FollowComponent, WanderComponent, and PathingComponent (and the corresponding systems). The problem is simple: the first two components must stop all work for any entities involved in cutscene scripting (unless a script specifically turns them back on). I can't simply disable the systems because they should continue to process other entities not involved in the script. I need to disable FollowComponent and WanderComponent on the entities involved in the cutscene.

Another practical usage scenario is undo/redo in a level editor. Deleting an entity could simply disable it, and then upon save all disabled entities are ignored. Undo'ing a delete would simply re-enable said entity (presumably the undo/redo list stores the entity). The major benefit of this approach is preserving the original state of the entity after the user requests an undo. Redo would simply disable the entity again.

Domiran avatar May 12 '22 21:05 Domiran

I suggest you look into exclusion.

eg:

auto view = registry.view<position, velocity>(entt::exclude<renderable>);

Green-Sky avatar May 12 '22 21:05 Green-Sky

I suggest you look into exclusion.

eg:

auto view = registry.view<position, velocity>(entt::exclude<renderable>);

That would exclude all "renderable". This is about disabling specific components on specific entities. I updated the original text to hopefully be more clear.

Domiran avatar May 12 '22 21:05 Domiran

Added a bit about optionally allowing view to return disabled entities. I'm finding exceptions to the rules in my own code as I try to take this feature into consideration under real world use.

Domiran avatar May 14 '22 20:05 Domiran

Added a bit about optionally allowing view to return disabled entities.

I think this goes without saying because of the implementation I've in mind. When you iterate the storage for a given type T, it returns all entities, disabled and enabled ones. On the other hand, when you iterate the same storage and combine it with the entity storage, it only returns valid entities.

skypjack avatar May 15 '22 08:05 skypjack

We have almost the same use case and would love to see this feature. Right now we use tags to enable / disable rendering, transform updates and collision handling.

maidenone avatar Sep 07 '22 11:09 maidenone