Ensure that events are updated even when using a bare-bones Bevy App (#13808) #13842
+281
−15
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Objective
Solution
As discovered in
Leafwing-Studios/leafwing-input-manager#538, there appears to be some real weirdness going on in how event updates are processed between Bevy 0.13 and Bevy 0.14.
To identify the cause and prevent regression, I've added tests to validate the intended behavior.
My initial suspicion was that this would be fixed by #13762, but that doesn't seem to be the case.
Instead, events appear to never be updated at all when using
bevy_app
by itself. This is part of the problem resolved by #11528, and introduced by #10077.After some investigation, it appears that
signal_event_update_system
is never added using a bare-bonesApp
, and so event updates are always skipped.This can be worked around by adding your own copy to a later-in-the-frame schedule, but that's not a very good fix.
Ensure that if we're not using a
FixedUpdate
schedule, events are always updated every frame.To do this, I've modified the logic of
event_update_condition
andevent_update_system
to clearly and correctly differentiate between the two cases: where we're waiting for a "you should update now" signal and where we simply don't care.To encode this, I've added the
ShouldUpdateEvents
enum, replacing a simplebool
inEventRegistry
'sneeds_update
field.Now, both tests pass as expected, without having to manually add a system!
I've written two parallel unit tests to cover the intended behavior:
iter_current_update_events
works as expected inbevy_ecs
.iter_current_update_events
works as expected inbevy_app
I've also added a test to verify that event updating works correctly in the presence of a fixed main schedule, and a second test to verify that fixed updating works at all to help future authors narrow down failures.
bevy_app
version of this test fails but thebevy_ecs
version does notEventRegistry::run_updates
isn't working properlyEventRegistry::run_updates
is never getting calledevent_update_condition
is always returning falseEventRegistry::needs_update
is always falsesignal_events_update_system