Make initial StateTransition run before PreStartup

[MiniaczQ]

Objective

• Fixes OnEnter schedule is not ran when calling next_state.set() in Startup system #14206

Solution

• Run initial StateTransition as a startup schedule before PreStartup, instead of running it inside Startup as an exclusive system.

Related discord discussion:
https://discord.com/channels/691052431525675048/692572690833473578/1259543775668207678

Testing

Reproduction now works correctly:

use bevy::prelude::*;

#[derive(Debug, Clone, Copy, Default, Eq, PartialEq, Hash, States)]
enum AppState {
    #[default]
    Menu,
    InGame,
}

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .init_state::<AppState>()
        .add_systems(Startup, setup)
        .add_systems(OnEnter(AppState::Menu), enter_menu_state)
        .run();
}

fn setup(mut next_state: ResMut<NextState<AppState>>) {
    next_state.set(AppState::Menu);
}

fn enter_menu_state() {
    println!("Entered menu state");
}

---

Changelog

• Initial StateTransition runs before PreStartup instead of inside Startup.

[CooCooCaCha]

I just tested this and it looks like it works 👍🏻

[benfrankel]

I haven't looked at the code, but: IMO this approach is fine for 0.14.1, but a state disabling / enabling approach would be preferable for 0.15.

[MiniaczQ]

I've thought about it, a little bit

If we do introduce NextState::Disable, running the initial transition as the first frame transition would be much simpler, because when initializing states we simply set the initial NextState.
Right now we need to do some events magic which isn't ideal, but NextState doesn't work with optionals yet.

[benfrankel]

Running a schedule within another (commonly-used) bevy-provided schedule, without even exposing a system set or the system itself to order around, is problematic -- this is a clear improvement over the current behavior, and makes the code simpler.

No reason not to merge afaic. Better solution can be implemented later.

[alice-i-cecile]

This function signature change is a semver violation by Rust's rules.

[alice-i-cecile]

I agree with this design, and I think that the technical semver violation isn't important enough to worry about. I would be very surprised to see users calling that method themselves, even though it is pub.