-
Notifications
You must be signed in to change notification settings - Fork 32
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
Input Settings Menu #100
Input Settings Menu #100
Conversation
@@ -22,7 +23,7 @@ getrandom = { version = "0.2", features = ["js"] } | |||
bevy_mod_debugdump = { version = "0.4", optional = true } | |||
bevy-inspector-egui = { version = "0.11", optional = true } | |||
bevy-inspector-egui-rapier = { version = "0.4", optional = true, features = ["rapier2d"] } | |||
leafwing_input_manager = { git = "https://github.com/Leafwing-Studios/leafwing-input-manager.git", rev = "e8bd6e0" } | |||
leafwing_input_manager = { git = "https://github.com/zicklag/leafwing-input-manager.git", branch = "backport-leafwing-dev-to-bevy-0.7" } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: Because I had to make a fix to leafwing, and they've already migrated to the pending bevy 0.8, there's no way around using my temporary fork for this anymore. I think we'll just have to wait 'till we migrate to Bevy 0.8 to switch this to a more permanent release.
To get my fix in, I had to apply it to their latest dev branch, then backport the dev branch to Bevy 0.7.
Just did a more thorough review of my own code: added lots of comments, removed some unneeded code paths, and fixed a minor usability issue with button hovering and focusing. I think this is ready now. |
Gonna try to review this tomorrow. One thing to consider for a future pr is a "bind all" mode which when entered prompts for input to bind for the first Action on list, then immediately progresses to the next Action after pressing a key/button until all actions are bound to buttons. |
Going to give a review as well tomorrow or the day after, as I'm about to travel 😄 |
- Simplify Controls Metadata and Move to Settings - Remove camera controls - Update leafwing input manager to get support for virtual dpads with axes in them.
This allows us to say how widgets should be navigated when pressing directions on the gamepad or keyboard.
This makes sure that you can still use keyboard/gamepad navigation, even if the mouse is idling over a button.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! I didn't have much meaningful feedback, noticed few small things that looked like spelling errors.
None of this should block this work or be included in this pr but some thoughts came up while looking it over.
I think maybe we will want to think more about what options players have for binding in the menu, I feel like maybe it should allow for selecting an input type and then only showing a map for that type instead of gamepad + keyboard 1/2 at the same time.
This might also relate to how we expect bindings to work in multiplayer both in local multiplayer and networked multiplayer. Which player gets to set their bindings once the menu is triggered? Right now it sets for all players correct? (I haven't actually pulled and tried it out yet so I could very well be misinterpreting)
Co-authored-by: odecay <[email protected]>
Good catch, I fixed those now. 👍
That's a great idea. We could definitely do that in a next iteration. It would be an easy update.
Yep. Every player shares the same gamepad bindings, and there are the two keyboard bindings so that you can play two players with one keyboard. If we added a way to rotate through which bindings you are actually setting, like you mentioned, then that would make it easier to set different gamepad bindings for player 1 and player 2. I'd have done separate gamepad bindings for both gamepads if it weren't for the fact that I ran out of room. :) Selecting which binding you are setting first solves a lot of problems. |
Yep all totally makes sense. Lets add an issue for next steps for input binding after we get this PR merged in. Feel free to merge whenever you feel its ready. |
Since nothing I'm doing next needs this I'll wait a day to let @64kramsystem look at it. |
What are you planning on working on next btw? I was thinking of starting to work on making the attacks defined via startup + active + recovery frames that correspond to when hitboxes are live. Which would implicate #53 and #54 but I saw you assigned yourself #54. Would you mind if I took that one? |
Oh, not at all, go ahead. That one looked easy and I was trying to find what the most important things to get out before the next release were, but I'd rather you took it anyway.
Right now I'm working on a quick experiment to see if an idea I had regarding scripting is feasible or not. I figured that if we have a solution for scripting, it might have an impact on how we program the players or items, so it'd be good to have some idea of what that might look like earlier rather than later. It should just take a day or two to see if my idea has any merit, and it's kind of fun experimentation work so I figured I'd take a quick look as sort of a "break". Then I'll come back to the #83 if nobody else wants it, or I'll just work on the update binding menu. |
okay perfect! scripting sounds awesome, followed along with the threads/issues on mun scripting/bevy_mod_scripting, were you thinking something like #107? |
Replied here to make it more visible: #107 (comment) |
Looks good to me (although I'm not very familiar with the areas 😬) 😄 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Gettn it in then |
It's working!
Opening as a draft because I need to do a self-review, but it's functional. 🎉