Open redpandamonium opened 2 years ago
Why does F work then?
You need to cache the system state values somewhere. See https://docs.rs/bevy/latest/bevy/ecs/system/struct.SystemState.html#warning
Why does F work then?
Probably something to do with events being double buffered and the event update systems running in First.
Could we change our examples to not use uncached SystemState
? It would be easier once we have Local
s in exclusive systems
Bevy version
0.7.0
What you did
I was playing around with EventReader in exclusive systems and found some inconsistencies. I have tested 7 scenarios that are inconsistent. Systems are not exclusive unless mentioned. Reading is done using an
EventReader
unless specified otherwise.CoreStage::PreUpdate
. It is read inCoreStage::Update
CoreStage::PreUpdate
. It is read with an exclusive system inCoreStage::Update
inat_begin
using anEventReader
CoreStage::PreUpdate
. It is read with an exclusive system inCoreStage::Update
inat_begin
using anResMut<Events<EventC>>
CoreStage::PreUpdate
. It is read with a normal system that is ordered to run after it was written, in the same stage.CoreStage::PreUpdate
. It is read with an exclusive system inCoreStage::PreUpdate
inat_end
using anEventReader
CoreStage::Update
. It is read in the next tick by an exclusive system inCoreStage::Update
inat_begin
CoreStafe::Update
. It is read in the same tick by an exclusive system inCoreStage::Update
inat_end
The expected output order would thus be: D -> E -> (C and B) -> A -> G -> F (next tick)
What went wrong
However the actual order is: D -> E -> (C and B) -> A -> G -> E (next tick) -> (F and B) (next tick) -> G
E, G, and B were read twice. This is inconsistent because both systems before and after them worked as expected, and an exclusive system at the same time using
Events<EventC>::drain
works as expected. The exclusive system running in the next tick (F) is also working as expected. The issue only seems to happen with exclusive systems that read events usingEventReader
in the same tick as the event was fired. It does not seem to matter in which stage the event is fired or in which stage the exclusive system reads it, only the order seems to matter. This issue does not apply to non-exclusive systems.I would expect all of the variants to only read the event the first time.
Additional information
Here's my test code to reproduce this issue: