Incorrect WARN when using sub states

[jonathandw743]

Bevy version

0.14.0-rc.2

use bevy::prelude::*;

fn main() {
    let mut app = App::new();
    app.add_plugins(DefaultPlugins);
    app.insert_state(RootState);
    app.add_sub_state::<AppState>();
    app.add_sub_state::<PauseScreen>();
    app.add_systems(Update, foo.run_if(in_state(PauseScreen::On)));
    app.run();
}

// I want everything to be substates for copacetiousness
#[derive(States, Debug, Clone, PartialEq, Eq, Hash)]
pub struct RootState;

#[derive(SubStates, Debug, Clone, PartialEq, Eq, Hash, Default)]
#[source(RootState = RootState)]
pub enum AppState {
    #[default]
    MainMenu,
    Game,
}

#[derive(SubStates, Debug, Clone, PartialEq, Eq, Hash, Default)]
#[source(AppState = AppState::Game)]
pub enum PauseScreen {
    On,
    #[default]
    Off,
}

fn foo() {
    info!("in pause screen");
}

This program gives the warning:

2024-06-14T21:06:10.480930Z  WARN bevy_state::condition: No state matching the type for On exists - did you forget to `init_state` when initializing the app?

This doesn't seem to happen with only one layer of sub-states.
If it you do need to init_state, this is not suggested in the docs.

[alice-i-cecile]

FYI @MiniaczQ @lee-orr

[MiniaczQ]

Oh, that's an interesting issue.
So in_state uses the existence of State<S> to decide whether a state "exists", but computed/sub states work on optional resources.

We can either use a different resource to verify that a state is installed (e.g. Events<StateTransitionEvent<S>> is something I use), but then we need to add it as an argument to in_state 😛

Alternatively we can just remove the warning, it warns about something pretty obvious

[jonathandw743]

Oh, that's an interesting issue. So in_state uses the existence of State<S> to decide whether a state "exists", but computed/sub states work on optional resources.

We can either use a different resource to verify that a state is installed (e.g. Events<StateTransitionEvent<S>> is something I use), but then we need to add it as an argument to in_state 😛

Alternatively we can just remove the warning, it warns about something pretty obvious

The warning makes sense for States because it is assumed that they are initialised (idk how appropriate this assumption is). But it doesn't make sense for sub-states as they are inherently optional.

As an outsider, I will cautiously make the suggestion that sub states can be generalised so that all states are sub states. I don't think there needs to be two classes of states in this way (which makes the interface more complex). A regular state could then just be a sub state of some built-in unary root state.

Then if add_sub_state was not called for a state, then any in_state calls for that would only return false which is how sub-states behave.

[lee-orr]

The warning makes sense for States because it is assumed that they are initialised (idk how appropriate this assumption is). But it doesn't make sense for sub-states as they are inherently optional.

I'm uncertain what you mean by "it is assumed that they are initialized"? Can you elaborate?
I think my confusion is that all state types need to be registered with the app to work, so "initialized" in that sense applies to everything - but if you mean they can or can't be None that's a different distinction.

[lee-orr]

@alice-i-cecile - can you mark me as assigned here? I'm working on a solution RN