Description
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>
andtry_get<T>
should not return componentT
if it has been disabled for the given entity.get<T>
andtry_get<T>
should not return an enabled componentT
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.