More state driven entity disabling components

[izarma]

Objective

• Fixes More state driven entity disabling components #24156
• Adds EnabledIn, EnabledIf, DisabledIn, DisabledIf Components for State driven Entity Disabling.
• Adds DisabledControl component that defines how Disabled propagates to its children/descendants.

Solution

For each new state driven disabling component

• Systems that read StateTransitionEvent<S> Message and update the Entity on state transitions.
• Observers On<Insert, Component> to sync when component is inserted. So user does not have to manually supply the Disabled component when the Entity spawns Disabled.
• Observer On<Remove, Component> to remove DisabledControl
• new propagation functions. Disable component removal stops at any child carrying DisabledControl and its addition only stops at DisabledControl::Independent.
• require DisabledControl::Independent so their children are independent.

The children entities that only want Disabling to propagate can use DisabledControl::InheritDisable

Testing

• Did you test these changes? If so, how? - unit tests with cargo test

• Are there any parts that need more testing? Combining more than one of these components on a single entity.

• How can other people (reviewers) test your changes? Is there anything specific they need to know?
  Insert any of the new components to an entity, the Disabled Component can be added or removed based on the current state at insertion and then any further state changes(specifically on state enters) - which can be enabled for querying by using Allow<Disabled>
  Also can try spawning children entities to test propagation of Disabling

• If relevant, what platforms did you test these changes on, and are there any important ones you can't test? - Windows11

---

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide, as well as our policy regarding AI usage, and we look forward to reviewing your pull request shortly ✨

[ncthbrt]

The recursive removal of Disable on children makes me uneasy. I'm not super read up on how the Disabled state is normally propagated to children but it feels like a child should be able to remain disabled if it was already disabled prior to entering or leaving the state (depending on what was specified).

[ncthbrt]

Removing Disabled from Children feels a little iffy. Is it not possible to have an enabled parent but a disabled child?

[izarma]

is it alright to mark this as resolved?

[amtep]

Perhaps define the logic such that a child with its own DisabledIf / DisabledIn kind of component is skipped?

Might get unintuitive though.

We might have to add a ManuallyDisabed component or something, to cover all cases.

[izarma]

The recursive removal of Disable on children makes me uneasy. I'm not super read up on how the Disabled state is normally propagated to children but it feels like a child should be able to remain disabled if it was already disabled prior to entering or leaving the state (depending on what was specified).

I have added a new OwnsDisabled component that can be used to shield the Disable propagation. Would love to know if this is alright?

[ncthbrt]

Hmmmm... I'm wondering if the design needs a rethink.

The behaviour isn't quite what I'd expect.

I wanted children to be disabled when their parent was disabled, as this still makes a lot of sense but crucially, when the parent is re-enabled, it shouldn't automatically remove disabled from entities that were disabled through other means.

One potential design, though might be a bit contentious, would be a component that tracks how many times children have been disabled through the mechanism of their parents being disabled.

An alternative design would perhaps be a DisabledSelf component that would shield itself and its children from being re-enabled when the parent is reactivated. This is very similar to your current implementation, however it would still allow the Disabled state to correctly propagate to all children.

[izarma]

Hmmmm... I'm wondering if the design needs a rethink.

The behaviour isn't quite what I'd expect.

I wanted children to be disabled when their parent was disabled, as this still makes a lot of sense but crucially, when the parent is re-enabled, it shouldn't automatically remove disabled from entities that were disabled through other means.

One potential design, though might be a bit contentious, would be a component that tracks how many times children have been disabled through the mechanism of their parents being disabled.

An alternative design would perhaps be a DisabledSelf component that would shield itself and its children from being re-enabled when the parent is reactivated. This is very similar to your current implementation, however it would still allow the Disabled state to correctly propagate to all children.

I went with DisabledSelf here. Would love a re-review :)

[ncthbrt]

If you're not going to rename it to disabled self, I'd suggest that you call it OwnsEnabled as that is more accurate to the behaviour of what the component does. Otherwise if you choose to rename it to DisabledSelf or similar, you will probably need to add an observer that adds the disabled state when the DisabledSelf component is added

[copygirl]

Are there similarities to InheritedVisibility? Perhaps a similar approach, functionality and name would help not confuse users. (If you understand one, you understand the other.)

[izarma]

Are there similarities to InheritedVisibility? Perhaps a similar approach, functionality and name would help not confuse users. (If you understand one, you understand the other.)

the functionality we have is kinda different - since there is a case where we want only to propagate the insertion of Disabled and not its removal. However - I went with a similar enum for our case here.

pub enum DisabledControl {
    #[default]
    Independent,
    InheritDisable,
}

Also this should be better naming for what we have right? @ncthbrt

I'd love any more feedback in this regard as well I had tried exploring to use PropagateStop + PropagateOver for a similar functionality to DisabledControl::Independent but since it comes from bevy_app that is an optional dependency of bevy_states i didn't.