Skip to content
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

Allow Ruby to get and alter key bindings #144

Open
Eblo opened this issue Jan 9, 2024 · 3 comments
Open

Allow Ruby to get and alter key bindings #144

Eblo opened this issue Jan 9, 2024 · 3 comments

Comments

@Eblo
Copy link

Eblo commented Jan 9, 2024

Currently, the configuration and assignment of keybindings are managed internally to mkxp-z; Ruby can only read direct scancodes or the button names. The view and edit for button assignments is handled by the F1 menu. The F1 menu is a great general solution for those who are simply using mkxp to run existing RPG Maker games. It exists independently of a game, acting as a substitute for the F1 menu that exists in vanilla RM.

However, the F1 menu presents issues. It will not work in environments that don't support pop-out windows in an application (e.g. Android), or in full screen mode. Its detachment from the game presents a seam that can be seen as negative for the user experience. The norm for PC games is to have in-game control configurations.

I believe some hackery is required with that menu to get mkxp-z to compile on MacOS/Metal, though I don't know if that should be considered part of the same issue. Unless it can be made into a compilation flag for those of us who don't want the F1 menu at all. I don't think this main repo should axe it entirely since, as stated above, the F1 menu is a good general solution for playing existing games

If keybindings were exposed to Ruby, developers would be free to implement their own solutions that work with their games.

@JaidenAlemni
Copy link

JaidenAlemni commented Jan 9, 2024

Super big +1 to this. +5 if I could. I'd really like this feature.

Also, for folks who are planning on shipping on Steam, keybindings in the F1 menu means it will be marked as "partially incompatible" on the Steam deck regardless of its actual compatibility. It is ideal in most final release scenarios, I believe, to have the keybindings managed game-side.

I also agree with not axing it entirely--it should just be a config or build option to disable since it is indeed useful as a general-purpose solution.

@Maruno17
Copy link

Maruno17 commented Jan 9, 2024

Another +1. The F1 menu can serve as the default keybindings editor for the default set of buttons, but if a game wants to implement its own in-window editor, it should be able to. mkxp.json already contains "enableSettings" which can disable the F1 menu.

I imagine all that is needed are Ruby bindings to loadBindings, storeBindings and genDefaultBindings (for completeness if a game wants to allow resetting to the default keybindings), probably as functions in module Input.

@Splendide-Imaginarius
Copy link

I imagine all that is needed are Ruby bindings to loadBindings, storeBindings and genDefaultBindings (for completeness if a game wants to allow resetting to the default keybindings), probably as functions in module Input.

If it's this simple, I'd probably accept a PR that adds those Ruby bindings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants