-
Notifications
You must be signed in to change notification settings - Fork 108
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
DPad Buttons Presses Not Detected #149
Comments
I think is that this is an oddity in
Yes please! See #78 for initial thoughts. |
I was able to trace this to |
Since this is verified as a Bevy issue I think it's reasonable to close this now. I opened a PR that should fix on the Bevy side: bevyengine/bevy#5220. |
# Objective - Enable the `axis_dpad_to_button` gilrs filter to map hats to dpad buttons on supported remotes. - Fixes Leafwing-Studios/leafwing-input-manager#149 - Might have fixed the confusion related to #3229 ## Solution - Enables the `axis_dpad_to_button` filter in `gilrs` which will use it's remote mapping information to see if there are hats mapped to dpads for that remote model. I don't really understand the logic it uses exactly, but it is usually enabled by default in gilrs and I believe it probably leads to more intuitive mapping compared to the current situation of dpad buttons being mapped to an axis. - Removes the `GamepadAxisType::DPadX` and `GamepadAxisType::DPadY` enum variants to avoid user confusion. Those variants should never be emitted anyway, for all supported remotes. --- ## Changelog ### Changed - Removed `GamepadAxisType::DPadX` and `GamepadAxisType::DPadY` in favor of using `GamepadButtonType::DPad[Up/Down/Left/Right]` instead. ## Migration Guide If your game reads gamepad events or queries the axis state of `GamePadAxisType::DPadX` or `GamePadAxisType::DPadY`, then you must migrate your code to check whether or not the `GamepadButtonType::DPadUp`, `GamepadButtonType::DPadDown`, etc. buttons were pressed instead.
# Objective - Enable the `axis_dpad_to_button` gilrs filter to map hats to dpad buttons on supported remotes. - Fixes Leafwing-Studios/leafwing-input-manager#149 - Might have fixed the confusion related to bevyengine#3229 ## Solution - Enables the `axis_dpad_to_button` filter in `gilrs` which will use it's remote mapping information to see if there are hats mapped to dpads for that remote model. I don't really understand the logic it uses exactly, but it is usually enabled by default in gilrs and I believe it probably leads to more intuitive mapping compared to the current situation of dpad buttons being mapped to an axis. - Removes the `GamepadAxisType::DPadX` and `GamepadAxisType::DPadY` enum variants to avoid user confusion. Those variants should never be emitted anyway, for all supported remotes. --- ## Changelog ### Changed - Removed `GamepadAxisType::DPadX` and `GamepadAxisType::DPadY` in favor of using `GamepadButtonType::DPad[Up/Down/Left/Right]` instead. ## Migration Guide If your game reads gamepad events or queries the axis state of `GamePadAxisType::DPadX` or `GamePadAxisType::DPadY`, then you must migrate your code to check whether or not the `GamepadButtonType::DPadUp`, `GamepadButtonType::DPadDown`, etc. buttons were pressed instead.
# Objective - Enable the `axis_dpad_to_button` gilrs filter to map hats to dpad buttons on supported remotes. - Fixes Leafwing-Studios/leafwing-input-manager#149 - Might have fixed the confusion related to bevyengine#3229 ## Solution - Enables the `axis_dpad_to_button` filter in `gilrs` which will use it's remote mapping information to see if there are hats mapped to dpads for that remote model. I don't really understand the logic it uses exactly, but it is usually enabled by default in gilrs and I believe it probably leads to more intuitive mapping compared to the current situation of dpad buttons being mapped to an axis. - Removes the `GamepadAxisType::DPadX` and `GamepadAxisType::DPadY` enum variants to avoid user confusion. Those variants should never be emitted anyway, for all supported remotes. --- ## Changelog ### Changed - Removed `GamepadAxisType::DPadX` and `GamepadAxisType::DPadY` in favor of using `GamepadButtonType::DPad[Up/Down/Left/Right]` instead. ## Migration Guide If your game reads gamepad events or queries the axis state of `GamePadAxisType::DPadX` or `GamePadAxisType::DPadY`, then you must migrate your code to check whether or not the `GamepadButtonType::DPadUp`, `GamepadButtonType::DPadDown`, etc. buttons were pressed instead.
# Objective - Enable the `axis_dpad_to_button` gilrs filter to map hats to dpad buttons on supported remotes. - Fixes Leafwing-Studios/leafwing-input-manager#149 - Might have fixed the confusion related to bevyengine#3229 ## Solution - Enables the `axis_dpad_to_button` filter in `gilrs` which will use it's remote mapping information to see if there are hats mapped to dpads for that remote model. I don't really understand the logic it uses exactly, but it is usually enabled by default in gilrs and I believe it probably leads to more intuitive mapping compared to the current situation of dpad buttons being mapped to an axis. - Removes the `GamepadAxisType::DPadX` and `GamepadAxisType::DPadY` enum variants to avoid user confusion. Those variants should never be emitted anyway, for all supported remotes. --- ## Changelog ### Changed - Removed `GamepadAxisType::DPadX` and `GamepadAxisType::DPadY` in favor of using `GamepadButtonType::DPad[Up/Down/Left/Right]` instead. ## Migration Guide If your game reads gamepad events or queries the axis state of `GamePadAxisType::DPadX` or `GamePadAxisType::DPadY`, then you must migrate your code to check whether or not the `GamepadButtonType::DPadUp`, `GamepadButtonType::DPadDown`, etc. buttons were pressed instead.
Version
Version 0.3.0
Operating system & version
Pop!_OS ( Ubuntu ) 20.04
What you did
I took the
minimal
example in this repo and set the jump action to be bound like this:I also had to add the
bevy_gilrs
feature to the list of Bevy features in theCargo.toml
.What you expected to happen
Pressing up on the dpad should print "I'm jumping"
What actually happened
Nothing.
Additional information
This does work with non-dpad controller buttons.
I'm still investigating, but it looks like Bevy handles the dpad as an axis type, not as a button type, so the "pressed" detection doesn't work for the dpad like it is expected to in the current code.
Also, I would be interesting in adding basic support for triggering user actions based on analog sticks anyway, because I'm wanting that for my game. I'm assuming you'd be open to a PR? :)
I think the implementation direction for fixing this is probably just about the same for supporting analog sticks, because Bevy treats the dpad almost the same or exactly the same as the analog sticks.
The text was updated successfully, but these errors were encountered: