How to bypass "duplicate" state access to modify state in multiple systems?

[Rratic]

There's little information I can find on scheduling after 0.10, so I don't know whether I must use direct world access.

Currently I'm using state to mark processing states:

#[derive(States, Debug, Clone, PartialEq, Eq, Hash)]
pub enum ProcessState {
    None,
    LoadScene,
    PostLoadScene,
    SaveScene,
    PreEnterPlay,
}

They mark different stages of processing, and note that this process may be done multiple times when player intends.

For different stages, I use OnEnter to specify and write system with argument mut next_state: ResMut<NextState<ProcessState>>, but the program panics with error B0002. So I turned to using event but it won't fix the error.

[jfouche]

Are you shure the ProcessState state is always existing ? How are you initializing it ?
Do you have some code to share ?

[Rratic]

I don't know what you mean by "is always existing?".
Here's an example I hope:

#[derive(SystemSet, Debug, Clone, Copy, PartialEq, Eq, Hash)]
struct ProcessSet;

#[derive(States, Debug, Clone, PartialEq, Eq, Hash)]
enum ProcessState {
    None,
    LoadScene,
    PostLoadScene,
    PreEnterGame,
}

struct RegisteryPlugin;

impl Plugin for RegisteryPlugin {
    fn build(&self, app: &mut App) {
        app.insert_state(ProcessState::None);

        app.configure_sets(
            Update,
            ProcessSet
                // .run_if(in_state(/* ... */))
        );

        app.add_systems(
            OnEnter(AppState::InGame),
            load_scene_system.in_set(ProcessSet),
        );

        app.add_systems(
            OnEnter(ProcessState::LoadScene),
            process_loaded_scene.in_set(ProcessSet),
        );
    }
}

fn load_scene_system(
    // mut commands: Commands,
    // asset_server: Res<AssetServer>,
    mut next_state: ResMut<NextState<ProcessState>>
) {
    next_state.set(ProcessState::LoadScene);
    /*commands
        .spawn(DynamicSceneRoot(asset_server.load("scenes/debug.scn.ron")))
        .observe(
            |_: Trigger<SceneInstanceReady>, mut next_state: ResMut<NextState<ProcessState>>| {
                next_state.set(ProcessState::PostLoadScene);
            },
        );*/
}

fn process_loaded_scene(
    // ...
    mut next_state: ResMut<NextState<ProcessState>>,
) {
    // ...
    next_state.set(ProcessState::PreEnterGame);
}

[jfouche]

Have a look to : https://bevyengine.org/learn/errors/b0002/, it might help you to find where you use an immutable and a mutable access to a Resource (maybe you use a ResMut<NextState<ProcessState>> and a Res<State<ProcessState>> in the same system).

[Rratic]

Nope I've checked several times I didn't write any Res<State<ProcessState>> in my code. It's possible it's used in some bevy-provided utility, but when I cut down the number of mutable ref I write to 1 (does not count the observer), it works. Or when I mutate the system for OnEnter(ProcessState::PostLoadScene) which does not ref <ProcessState>>, it works.
It's really weird.

[Rratic]

It seems when there's world: &World, mut commands: Commands, mut next_state: ResMut<NextState<ProcessState>>, all together in my process_loaded_scene argument, it causes the problem.

[Rratic]

I turned to

(
    process_loaded_scene,
    |mut next_state: ResMut<NextState<ProcessState>>| {
        next_state.set(ProcessState::PreEnterGame);
    },
)
.chain()

and it works.

[jfouche]

The problem comes from the fact the world: &World, mut commands: Commands, mut next_state: ResMut<NextState<ProcessState>>, system params :

• world: &World implies a read only lock to the whole world
• mut next_state: ResMut<NextState<ProcessState>> implies a exclusive write access to the NextState<ProcessState> resource, which is part of the world

So you break the Rust rules on references (either one mutable reference or any number of immutable references) on a resource.

The question is why do you need an acces to the whole World instead of using Query<> or Res<> system params ? An access to &World will block all other systems that need an mutable acces to a part of the world to run in parallele, which might result in performance issue. Instead, you'd better use query, which will lock only a part of the world, and allow other system to run in parallele, accessing other part of the world for exclusive mutable access.

So, out of curiosity, which World function do you use in your system ?

[Rratic]

So, out of curiosity, which World function do you use in your system?

world.get_reflect

[jfouche]

Fair enough :)
Your solution seems a good one