triggering state transition from player input locks the game

[mockersf]

Bevy version

c78b76b

What you did

In my game, I have several screens which I can go through by clicking the mouse (with just_pressed on Input<MouseButton>). Each screen has its own state.

Very dumb example that reproduce my issue:

use bevy::prelude::*;

fn main() {
    App::build()
        .add_plugins(DefaultPlugins)
        .add_state(AppState::State1)
        .add_system_set(SystemSet::on_enter(AppState::State1).with_system(enter_state.system()))
        .add_system_set(SystemSet::on_update(AppState::State1).with_system(next_state.system()))
        .add_system_set(SystemSet::on_enter(AppState::State2).with_system(enter_state.system()))
        .add_system_set(SystemSet::on_update(AppState::State2).with_system(next_state.system()))
        .run();
}

#[derive(Clone, Eq, PartialEq, Debug)]
enum AppState {
    State1,
    State2,
}

fn enter_state(state: Res<State<AppState>>) {
    eprintln!("entering {:?}", state.current());
}

fn next_state(mut state: ResMut<State<AppState>>, mouse_button_input: Res<Input<MouseButton>>) {
    if mouse_button_input.just_pressed(MouseButton::Left) {
        match state.current() {
            AppState::State1 => state.set_next(AppState::State2),
            AppState::State2 => state.set_next(AppState::State1),
        }
        .unwrap();
    }
}

What you expected to happen

One click to go from State1 to State2, then one click to go from State2 to State1.

What actually happened

On first click, it changes state in a loop and lock the game.

Additional information

Now that system set can rerun in same frame, input isn't reset between two passes so just_pressed is always true

[Ratysz]

Looks like it's working as intended: state chanes are the inner loop, compared to input processing. You'll have to break that loop yourself.

[mockersf]

Yup I know, but I think that's very user-unfriendly, I would hope we have a better solution for that

[Ixentus]

From my actual game (but not compiled like this):

use bevy::{app::AppExit, prelude::*};

fn main() {
    App::build()
    .add_state(AppState::Menu)
    .add_system_set(SystemSet::on_update(AppState::Menu).with_system(menu_input.system())
    .add_system_set(SystemSet::on_update(AppState::Menu).with_system(game_input.system())
    .run();

pub enum AppState {
    Menu,
    InGame,
}

pub fn menu_input(
    keyboard_input: Res<Input<KeyCode>>,
    mut app_state: ResMut<State<AppState>>,
    mut app_exit_events: EventWriter<AppExit>,
) {
    if keyboard_input.just_pressed(KeyCode::Space) {
        app_state.set_next(AppState::InGame).unwrap();
    } else if keyboard_input.just_pressed(KeyCode::Escape) {
        app_exit_events.send(AppExit);
    }
}

pub fn input(
    mut app_state: ResMut<State<AppState>>,
    keyboard_input: Res<Input<KeyCode>>,
    mut pause_events: EventWriter<PauseEvent>,
) {
    if keyboard_input.just_pressed(KeyCode::Escape) {
        app_state.set_next(AppState::Menu).unwrap();
    }
    if keyboard_input.just_pressed(KeyCode::Space) {
        //pause logic omited
        pause_events.send(PauseEvent);
    }
}

On 0.4 you could start the game by pressing space and the game would start unpaused, on current main it starts paused.
On 0.4 you could exit the game to the menu by pressing Esc, now it exits the whole game.
Unless I'm misunderstanding something, there is no loop to break here and just_pressed() is just broken on state transition.

[mockersf]

a workaround is to add a on_enter system for your states that just does:

fn reset_input(mut keyboard_input: ResMut<Input<KeyCode>>,) {
      keyboard_input.update();
}

I hope we can find a better fix 😄

[Ratysz]

There is no loop, but the gist of the problem is the same: state changes are processed faster than input, so if you're consecutively switching several states based on an input edge you're gonna experience this issue. I still don't think this is something that needs fixing on Bevy side.

My solution would be a layer of indirection that converts inputs into app-specific events (the same layer would also handle keybindings). So, when a key or a button is down (or just pressed), instead of changing state an event is emitted, and the state change system consumes that event.

[Ixentus]

a workaround is to add a on_enter system for your states

No need for a whole new system. I ended up taking your suggestion, but simply updating right after reading just_pressed:

if keyboard_input.just_pressed(KeyCode::Space) {
        app_state.set_next(AppState::InGame).unwrap();
        keyboard_input.update();
}

Still feels against the spirit of just_ to me, but simple enough.

[cart]

My solution would be a layer of indirection that converts inputs into app-specific events (the same layer would also handle keybindings). So, when a key or a button is down (or just pressed), instead of changing state an event is emitted, and the state change system consumes that event.

In this case I think it probably makes sense to just use a shared ManualEventReader<KeyboardInput> resource to ensure a given set of systems only consume the event once.

This is a bit of a foot-gun though. Worth playing around with ways to make it fool-proof (edit: I'm not implying that people that hit it are fools 😄)

[cart]

I've removed this from the 0.5 milestone because I don't think theres much we can do in the short term about this and we do have workarounds.

[cart]

If we find a better solution before release (and its not a major change) I'll consider including it.

[mockersf]

not a fix, but I added documentation and helpers around this issue in #1781

[CooCooCaCha]

I just ran into this when porting to 0.5 and I have to say this is surprising behavior. My mental intuition was that states own the entire frame. So if a state transition happens, it doesn't apply until the next frame.