You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There exists two main Schedules in which to perform work: Update and FixedUpdate.
Update runs once per frame. FixedUpdate may run multiple times, or not at all, per frame
The use of run_if conditions 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.
The text was updated successfully, but these errors were encountered:
Consider this Bevy issue and related PR:
FixedUpdate
can see events before dropping them bevyengine/bevy#10077I'll summarize:
Update
andFixedUpdate
.FixedUpdate
may run multiple times, or not at all, per framerun_if
conditions 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 giveFixedUpdate
access to them.Additionally, this behavior applies to change detection (
Added<_>
andChanged<_>
) and component removal (RemovedComponents<_>
). Notably, the implementation ofRemovedComponents
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.
The text was updated successfully, but these errors were encountered: