Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revisit event handling inside of SimulationUpdate and use of run_if conditions once Bevy addresses underlying issues #46

Open
MeoMix opened this issue Jan 24, 2024 · 0 comments

Comments

@MeoMix
Copy link
Owner

MeoMix commented Jan 24, 2024

Consider this Bevy issue and related PR:

I'll summarize:

  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant