Revisit event handling inside of SimulationUpdate and use of run_if conditions once Bevy addresses underlying issues #46
Description
Consider this Bevy issue and related PR:
- Events aren't being cleared properly bevyengine/bevy#10877
- Wait until
FixedUpdatecan see events before dropping them bevyengine/bevy#10077
I'll summarize:
- There exists two main Schedules in which to perform work:
UpdateandFixedUpdate. - Update runs once per frame.
FixedUpdatemay run multiple times, or not at all, per frame - The use of
run_ifconditions may prevent a System from running when its associated Schedule runs.
Given these scenarios, when should Bevy automatically clean-up emitted Events such that all consumers are happy with the default behavior? This is a challenging problem to solve.
Prior to the above PR, if user clicked on the screen, and an Event was emitted representing their click action, it was possible that systems within FixedUpdate would fail to detect the Event because the Event would be cleaned up prior to the systems running. This is why ExternalEvent exists in Symbiants, https://github.com/MeoMix/symbiants/blob/master/src/story/pointer/mod.rs#L115. By manually managing an Event queue, and draining it from within FixedUpdate, the issue is mitigated.
After the PR merged, a different (opposite) issue now exists. Now, if a system isn't ran due to a failing run_if condition, and that system attempts to read Events, it will read stale events. The events are being intentionally preserved as a way of being able to give FixedUpdate access to them.
Additionally, this behavior applies to change detection (Added<_> and Changed<_>) and component removal (RemovedComponents<_>). Notably, the implementation of RemovedComponents relies on Events, but change detection does not rely on Events.
Ultimately, the desired behavior is one where a user can skip running a system without accruing a backlog of stale Events or change detections while FixedUpdate is provided a guarantee that it will always have a chance to see emitted Events.