Since inspector_ui<T> and world_inspector_ui take a &mut World and go in the Update schedule, Bevy's ambiguity_detection reporting shows them as having conflicting data access and indeterminate ordering with basically everything. So, your legit determinism problems get drowned out by pairs like these:
-- world_inspector_ui and mobile_fixed_velocity (in set MovePlanners)
conflict on: bevy_ecs::world::World
-- world_inspector_ui and launch_and_fall (in set MovePlanners)
conflict on: bevy_ecs::world::World
-- world_inspector_ui and mobile_chase_entity (in set MovePlanners)
conflict on: bevy_ecs::world::World
Thoughts:
Ordering every gameplay system relative to these seems silly.
Yanking out the inspector systems every time I want determinism warnings is also a drag.
Logically, it seems like these systems belong in a dedicated schedule or something. I don't know if there's extra overhead to doing that, but I note that that's what they ended up doing with scene_spawner_system, which had the same problem in 0.11.x.
If a dedicated schedule's a non-starter, then maybe just moving to a built-in schedule that's not Update would help.
If they still need to go in Update for some reason that I haven't understood yet, maybe there could be a setting in the plugin constructors to mark them as .ambiguous_with_all() (to silence the warnings if you're just using inspectors for dev/debug and not for player-facing gameplay interface).
Since
inspector_ui<T>
andworld_inspector_ui
take a&mut World
and go in theUpdate
schedule, Bevy'sambiguity_detection
reporting shows them as having conflicting data access and indeterminate ordering with basically everything. So, your legit determinism problems get drowned out by pairs like these:Thoughts:
scene_spawner_system
, which had the same problem in 0.11.x..ambiguous_with_all()
(to silence the warnings if you're just using inspectors for dev/debug and not for player-facing gameplay interface).