0.9 -> 0.10 migration errors

[djeedai]

(reopened from bevyengine/bevy#8033)

Here's a list of migration errors with no corresponding items in the migration guide:

• The stageless migration really doesn't explain the basics of how to migrate from e.g. add_system_to_stage() to ... (?) There's not even a single example.
• ReportExecutionOrderAmbiguities (likely: bevy::ecs::schedule::ScheduleBuildSettings::ambiguity_detection)
• ModifiesWindows (?)
• StageLabel (?)
• MonitorSelection moved to inner of WindowPosition, Window::monitor field deleted
• App::add_system_set() removed, how to replace?
• ResMut<State<X>> doesn't build anymore; this needs the new States trait which is not mentioned in the migration guide
• State::current() (likely state.0). (NextState is mentioned but it's not super clear either)
• SystemStage::single_threaded() (?)
• TextPipeline::get_glyphs() (I was using after queue_text() which now returns the TextLayoutInfo so maybe not needed anymore)
• TextPipeline lost its generic ID type, how to replace?!
• EntityRenderCommand (I think [Merged by Bors] - Flatten render commands bevy#6885 so use RenderCommand instead; note that the PR has a Migration Guide section which didn't make it into the guide 😅)

I've tried to upgrade my game, which is very small and doing little at this stage, just a few systems organized at specific points (like changing levels after LoadAssets so that there's no frame delay), and overall it took me over an hour, with examples from bevy_hanabi's upgrade by @NiseVoid, to make it build again, without exclusive systems that I still don't know how to replace. I also have no real idea if the new scheduling is in any way well organized or even working, so I'll probably have to dive into a debugging plugin to verify the entire frame scheduling.

[Weibye]

Additionally: How exactly should one migrate systems that previously ran with a fixed timestep run criteria?

This is somewhat of a migration "guide" for the fixed update, but it does not show how to configure the timestep. And since there is now one global fixed update this particular migration may be better solved using a repeating timer. Edit: Fixed

The migration guide should cover both.

Bevy 0.9

.add_system_set(
    SystemSet::new()
        .with_run_criteria(FixedTimestep::steps_per_second(1))
        .with_system(my_system),
)

Bevy 0.10

This will be added to the global fixed update set.

.add_system(my_system.in_base_set(CoreSet::FixedUpdate)) // Not fully sure if this works or not?
// or
.add_system(my_system.in_schedule(CoreSchedule::FixedUpdate))

This will run once every 1 second

.add_system(my_system.run_if(on_timer(Duration::from_secs(1)))).run();

This will run once every 1 second but use the fixed timestep to advance the time.

.add_system(my_system.in_set(CoreSet::FixedUpdate)
    .run_if(on_fixed_timer(Duration::from_secs(1)))).run() // Not fully sure if this works or not?
// or
.add_system(my_system.in_schedule(CoreSchedule::FixedUpdate))
    .run_if(on_fixed_timer(Duration::from_secs(1)))).run()

The above examples are grabbed from here: https://github.com/bevyengine/bevy/blob/v0.10.0/crates/bevy_time/src/common_conditions.rs

but I am a bit confused between adding a system to the the FixedUpdate schedule vs adding a system to the FixedUpdate system set

[denormative]

It took half a day to upgrade the relatively simple roguelike I was working on and there's no way I could have done it without finding these notes online: https://zenn.dev/hyoi/scraps/5ea4bc5c9f6436 And I've still got a weird bug where the action N only triggers after I've triggered the N+1's action, but I'm guessing that's likely because of needing use NextState instead of just pushing the new state on the stack like I used to.

Anyway, I get how this new stateless system is more flexible and such, but I think the upgrade documentation was way to minimal to be of use to people not following the conversions in the PRs/issues.

[djeedai]

Anyway, I get how this new stateless system is more flexible and such, but I think the upgrade documentation was way to minimal to be of use to people not following the conversions in the PRs/issues.

Yes I agree. I feel reading some descriptions the potential stageless has, and I'm pretty sure it's much better than stages, but in practice being the number one feature of this release, a complete rework of a fundamental system, and not having a single migration example in the migration guide is quite frustrating.

@alice-i-cecile I hope we can fix that guide quickly before too many people struggle. I can try to help but given I genuinely don't understand yet how to fix most of the items listed I won't be able to make a PR for now. Is anyone with ECS insight able to jump on this please?

[alice-i-cecile]

I'll do my best to tackle this in the next couple of days.

[denormative]

Update seems good. I'm redoing my upgrade from scratch following the guide since I botched it last time, I am noticing there's a few things missing though like the old SystemSet::on_inactive_update. I dug into the RFC and it mentions these, but they're not called out as being removed anywhere else, or the fact there's apparently no equivalent for them.

For SystemSet::on_inactive_update I assume it's just a case of adding the systems to all the other states as well, but it might be worth copying the relevant section from the RFC to the migration guide as well since google was particularly unhelpful finding me the exact details.

[alice-i-cecile]

In that case I would make a custom run condition, which checks if the state resource is not equal to the specified state :) Much more flexible and easier to ensure it's correct!

[djeedai]

I found bevyengine/bevy#7258 back from January to add to the list of missing things. I'm a bit surprised this was cut from release given it clearly highlights that users will get confused. In fact until I read the issue I had no idea this could ever be an error. And I think this shows I still don't understand SystemSet.