How realistic is it to manage all ambiguous system ordering operating on the same resources manually?
I found the ambiguity detection setting, and ideally I'd want to set it to error, to eliminate a whole category of undefined behavior/bugs, but I'm running into issues with conflicts with or involving base bevy or plugin systems.
And since you need a system to be exposed publicly to even set another system to run before/after/ambigous with it I'm not sure the best way to handle them, or even if they can.
Is it possible at the level of the ambiguity detection setting to be able to ignore certain systems/resources, or only care about ambiguities in systems that are in the current library?
#Best practices on ambiguity handling?
1 messages · Page 1 of 1 (latest)
Is it possible at the level of the ambiguity detection setting to be able to ignore certain systems/resources, or only care about ambiguities in systems that are in the current library?
Yeah, this is feasible 🙂 https://docs.rs/bevy/latest/bevy/prelude/struct.App.html#method.allow_ambiguous_resource
App is the primary API for writing user applications. It automates the setup of a standard lifecycle and provides interface glue for plugins.
I would 100% welcome PRs for any problems that you run into when trying to do this
Including inadequately public Bevy systems or internal ambiguities
I tried to squash them all in CI, but testing all feature combinations is hard
Cool, so ambiguities in bevy core considered something am issue to fix if they come up?
What does:
conflict on: bevy_ecs::world::World
It's not a resource or component, right?
Systems can request &World or &mut World, but doing so "accesses" everything
Systems with &World are mutually exclusive with any systems that have mutable accesses (ResMut, Query<&mut T>, etc...), and systems with &mut World (aka Exclusive systems) are mutally exclusive with all systems