Ensure that events are updated even when using a bare-bones Bevy App

[alice-i-cecile]

Objective

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-bones App, 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.

Solution

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 and event_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 simple bool in EventRegistry's needs_update field.

Now, both tests pass as expected, without having to manually add a system!

Testing

I've written two parallel unit tests to cover the intended behavior:

1. Test that iter_current_update_events works as expected in bevy_ecs.
2. Test that iter_current_update_events works as expected in bevy_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.

Outstanding

• figure out why the bevy_app version of this test fails but the bevy_ecs version does not
• figure out why EventRegistry::run_updates isn't working properly
• figure out why EventRegistry::run_updates is never getting called
• figure out why event_update_condition is always returning false
• figure out why EventRegistry::needs_update is always false
• verify that the problem is a missing signal_events_update_system

[rparrett]

Maybe I also ran across this while updating bevy-ui-navigation as a couple failing tests. At the time I just assumed there was something breaking change I wasn't understanding or the tests themselves were broken so I worked around it.

rparrett/bevy-alt-ui-navigation-lite@d742bf2

[hymm]

looks like you have to add the event_update_system manually now if you're not using the default app https://github.com/bevyengine/bevy/pull/12936/files#diff-b2fba3a0c86e496085ce7f0e3f1de5960cb754c7d215ed0f087aa556e529f97fR94

[alice-i-cecile]

looks like you have to add the event_update_system manually now if you're not using the default app

The event update system is being added already, but event_update_condition is always returning false.

[alice-i-cecile]

@mockersf once this is merged, please bother me to replicate it on the 0.14 branch. I know this is non-trivial to cherrypick due to #13801.

[rparrett]

After reverting my workaround and pointing at this branch, bevy-alt-ui-navigation-lite's tests are green again, for what it's worth. My experience with that crate is just ripping a bunch of stuff out of it, so I don't know much about the tests other than that they worked with Bevy 0.13.

[hymm]

Fix seems good. Are there any tests for events with FixedTimestep active?

[alice-i-cecile]

Not currently. I'll think about how to write those 🤔

[alice-i-cecile]

The FixedUpdate logic is working as expected: testing that was substantially harder than I expected but I'm quite happy with the net result.

[rparrett]

Approving with the caveat that I don't particularly understand the fixed update schedule / event machinery.

But this code seems to be very-high quality, the new tests look great, and it fixes existing tests in a crate I'm looking after.