Allow toggling of components.

[mjstahlberg]

Allow components to be enabled and disabled. Entity::Get<>() should return a nullptr and ForAll<>() should skip an entity if a required component is disabled. Messages shouldn't be handled by disabled components. A component should provide handler methods (HandleEnable and HandleDisable) so that it can react to a state change.

Here's a usage example from Unvanquished:

When I come to the point where there'll be components such as JetpackComponent, it doesn't make sense to have specialized entities for each combination of components anymore (JetpackLightarmorPulserifleGrenadeHumanClientEntity!), so I need a way to enable and disable components on existing entities during runtime. I think this functionality should be provided by the backend, otherwise you'd have a "if (!enabled) return …;" in virtually every component method and the components would falsly show up when iterating over entitites that have certain components.

One problem that could occur is that if you have a reference to a component and then that component gets disabled, you could still call its methods. I think we can/have to live with that though.

[Kangz]

Ideas on how to implement that:

• Allow tagging some entities as dynamic
  • They will get an added vector<DynamicComponent*> (potentially unique_ptr)
  • They will get a AddDynamicComponent(Parameters...);
  • They will get a RemoveDynamicComponent();
  • They will get a messageId->numDynamicComponents listening to it (filled / changed on Add / Remove) this is to avoid looping over all the components for all the messages
• Some components can be tagged as dynamic
  • They will need to inherit from the "DynamicComponent" base class that defines virtual methods for all messages and for HandleEnable HandleDisable
  • They cannot use component dependencies nor inheritance
  • You still need to declare the messages they listen to otherwise they will not be called

Would that work for you?

[mjstahlberg]

The first approach sounds like a good solution but I assume that it would be extremely complex to implement given that dynamic entities need to be special-cased in lots of places, for example ForAll and Get where two distinct component containers would need to be considered. Another thing to consider is that component dependencies would need to be resolved in some way when adding components entirely on the fly. If you really want to go for this I won't stop you but I'd be afraid of the complexity personally.

Tagging components as dynamic also sounds good (and more doable) but I don't see the need to give up support for dependencies and inheritance for that. Dynamic components could have a bool that's initialized as false as well as HandleEnable and HandleDisable handlers for entity's Enable/Disable methods. Non-dynamic components would just have the same bool initialized as true and not react to Enable/Disable in any way. This allows us to otherwise treat dynamic and non-dynamic components identically except for evaluating the value of said bool where appropriate (ForAll, Get and message dispatching would consider a Component with the bool set to false as non-existing).

[mjstahlberg]

Not needed as badly anymore due to changes in my design.