Update to Bevy 0.12

[100-TomatoJuice]

No description provided.

[alice-i-cecile]

Looks good so far: thanks for preparing this.

[100-TomatoJuice]

This check-test failure is interesting. The only thing that could have made a difference I think is the new Time<Real>? Which means that something with Time is wrong or there is an issue with VirtualAxis that has just now shown up? Or, some other third reason I haven't seen yet.

.iter() to .read() is a name change, and .configure_set() to .configure_sets() isn't it as the problem exists before changing that.

[alice-i-cecile]

Yeah, I was surprised too. We also changed some default settings on axes: perhaps bevyengine/bevy#10090 was responsible?

[100-TomatoJuice]

I threw this into the plugin to reset back the defaults back to before

.insert_resource(GamepadSettings {
    default_axis_settings: AxisSettings::new(-0.95, -0.05, 0.05, 0.95, 0.01).unwrap(),
    ..Default::default()
})

It still failed, so I think we can rule out #10090?

[100-TomatoJuice]

Another thing to point out is that in the game_pad_virtualdpad() test, it passes on the .pressed() assert. But, fails on getting actual input values.

[100-TomatoJuice]

Some more interesting information: the virtual_dpad example works just fine. It displays .value() as expected. This leads me to a few questions:

• Could the issue lie with input mocking possibly?
• Would a change in Time have an effect on how events are sent?
• If so (and just in general), why is VirtualDpad the only failing test?

[100-TomatoJuice]

Even more interesting information, bevyengine/bevy#9446 is the pr that breaks the game_pad_virtualdpad() test. I reverted the changes to bevy_input, but not bevy_gilrs, from that pr and the test works again!

My current running theory is that moving button_axis from the system prevented buttons that acted as an axis didn't have their values updated in test? This is further evidenced by this line of code in input_streams.rs:

leafwing-input-manager/src/input_streams.rs

Lines 379 to 387 in fc3e348

	UserInput::Single(InputKind::GamepadButton(button_type)) => {
	if let Some(gamepad) = self.associated_gamepad {
	// Get the value from the registered gamepad
	self.gamepad_button_axes
	.get(GamepadButton {
	gamepad,
	button_type: *button_type,
	})
	.unwrap_or_else(use_button_value)

When getting the input value of a VirtualDpad button, it checks gamepad_button_axes which is type Axis<GamepadButton>, which is the same type moved in that pr. The only question left is why does it work for the example but not the test? I'm guessing because it still gets updated in bevy_gilrs?

I would love to know what you think! I tried to reorder the bevy_glirs system to be like run like the bevy_input system as before, but that didn't work. And reverting the pr doesn't feel right either, as then multiple inputs can't be pressed per frame. I'll continue looking to see what exactly isn't working.

[100-TomatoJuice]

Did some more searching and I think I found the root of the problem! The issue is only with input mocking, or more specifically, sending inputs by events. Before the mentioned pr, gamepad_button_event_system() changed the Axis<GamepadButton> resource from events send by bevy_gilrs.

https://github.com/bevyengine/bevy/blob/756fb069b10c14bf06cc4ab07d0fce1e80fc559d/crates/bevy_input/src/gamepad.rs#L1178-L1211

https://github.com/bevyengine/bevy/blob/756fb069b10c14bf06cc4ab07d0fce1e80fc559d/crates/bevy_gilrs/src/gilrs_system.rs#L29C1-L35C4

After the pr, bevy_gilrs updates the resource directly and doesn't receive any bevy_input gamepad events, hence why input mocking for an axis button fails but the example works.

So now the only remaining question is, "what is the proper way to fix this?" Maybe reverse the part in the pr where reading EventReader<GamepadButtonChangedEvent> to set ResMut<Axis<GamepadButton>> in bevy_input was removed? I don't know how this would affect the changes from that pr though.

[alice-i-cecile]

Excellent detective work. I'll take a proper look at this in the next day or two and try and fix the input mocking either here or upstream.