Retroarch: Remapping menu buttons not working?

[verybadsoldier]

Hello gentlemen,

in the past (like 4 weeks ago?) I was able to swap A and B menu buttons using this in my config:

menu_ok_btn = "0"
menu_cancel_btn = "8"

For a while I did not touch RetroArch but now I updated it and noticed that remapping the buttons using those config options does not work anymore. I also tried entering other "IDs" but those options don't seem to have any effect for me at all.

I am quite new to RetroArch so it might actually be a sideeffect of something else I am not aware of (just a warning).

I am using RetroArch in RetroPie on Lubuntu x64 16.04 on Intel i5 NUC with Xbox360 Wireless pads and xpad driver.

This is a log:
http://pastebin.com/sZxHtU8S

Anything else I could provide or test? Thanks!

[Awakened0]

Menu input was changed to be completely separate from retropad input a few weeks ago. Right now all the menu inputs are hard coded.

I was thinking up a feature request on how to implement configurable menu controls. I guess I can put that here.

I think it'd be great to use the same mapping system retropad uses where you can map one axis, one button and one key to each menu input. You'd have a sub menu in Settings, Input, Menu Binds where you can map your controller and keyboard. In the config the inputs would look something like:

input_menu_confirm_axis = "nul"
input_menu_confirm_btn = "0"
input_menu_confirm = "z"

This would replace the functionality of the old "menu_" settings and maybe make that new a-b confirm/cancel swap option unneeded.

I also noticed something odd with the newer nightlies that must be caused by the new menu input system. I have a custom menu hotkey set (Tab) and when I'm in game it opens the menu, but if I press it again it won't go back to the game. I have to press F1 to go back; I'm guessing that's because it's hardcoded to that when in the menu. That should be fixed, and I think the menu open/close hotkey should be moved to Menu Binds if configurable menu inputs are added like I'm proposing.

[meleu]

@Awakened0 could you show in which file this config is hardcoded?

[Awakened0]

I'm not sure. I bet @fr500 knows where it is in the source.

[lasers]

Tab / F1 Confirmed.

[meleu]

@Awakened0 I think I've found it in menu_event.c: https://github.com/libretro/RetroArch/blob/951f3f3e196777d0538fba1219d20e614519ae22/menu/menu_event.c#L208

And it seems that the current option for swap the ok/cancel buttons is the boolean menu_swap_ok_cancel, but it still isn't documented in the retroarch.cfg skeleton.

[fr500]

It doesn't need to be documented :p it's on the GUI

[meleu]

@fr500 Some users prefer to config things editing the retroarch.cfg. In RetroPie, if the user enable config_save_on_exit it results in a big mess, then most of RetroPie users doesn't configure RetroArch via GUI. Please, I'm not complaining :-). I know it's not a RetroArch's fault. I just love to be guided by the comments on the skeleton retroarch.cfg when I am editing it.

If you guys don't mind I can edit the skeleton and submit a PR. I just need to know this:

• is the menu_ok_btn and menu_cancel_btn deprecated?
• is the menu_swap_ok_cancel the setting to (duh!) swap the OK/Cancel functions?

[fr500]

yes and yes

[i30817]

A option to swap buttons is not enough to replace menu key remapping. For example, in my case the issue is that my direction arrow keys are ruined in the keyboard so i depend on remapping them. This worked before when the mapper was the same for menu and games, doesn't now.

[meleu]

@i30817
I think they removed the previous options because they were bound to button numbers and each joystick manufacturer uses different button numbers. Then the users would get confused when switching controllers.

Example: on my 8Bitdo NES30 the button 0 is the A, and the button 1 is the B, while on my PlayStation-like USB controllers the button 0 is the X/triangle, and button 1 is the A/circle. If I hardcode these numbers on my retroarch.cfg it would be annoying when switching the controllers.

Every decision has its price (in this case the price is people complaining), and I think that the decision made here has a cheaper price than maintaining the previous method. Also, I think your case is a software workaround for a hardware failure.

EDIT: sorry! actually I think that this keyboard case can bring issues for those who use devices that act like keyboard for the OS (e.g.: IPAC2). Maybe this should be addressed...

Cheers!

[Awakened0]

@fr500 mentioned in IRC awhile back that with the new separated menu input system it'd be trivial to make the inputs configurable. I'm not sure if making both pad and keyboard menu inputs completely remapable like in game RetroPad inputs and hotkeys are (like I suggested above) is what he had in mind.

My use case is remapping menu open/close to Tab (which is bugged currently because of menu and hotkey inputs being separate) and Left Stick click, Cancel to X and Xbox X and Confirm to Z and Xbox A. Those are just my preferences that feel comfortable to me. And with the separate menu input system I no longer have to worry about my core override retropad remappings messing with my menu inputs.

[i30817]

@meleu, i wouldn't be so insistent if retroarch worked like most other applications and the numpad arrow keys worked, but it doesn't. In addition to your custom device example, i can give others that are slightly impeding, like someone without some fingers on his right hand wanting to remap the zone that requires more sensitivity to his other hand, or someone with a much more dominant hand (i don't really imagine stroke victims playing twitch games but hey).

Thankfully, once you're in game the mapping works (in most cases, my numpad open issue is about problems with that).

[fr500]

This isn't really important for me so I won't work on it personally but I'm open to offer some guidance.
It's easy enough to implement (at least the settings, the menu would be complicated)

   if (current_input->input_state(current_input_data, binds, 0,
      RETRO_DEVICE_KEYBOARD, 0, RETROK_RETURN))
   {
      if (!settings->input.menu_swap_ok_cancel_buttons)
         BIT64_SET(ret, RETRO_DEVICE_ID_JOYPAD_A);
      else
         BIT64_SET(ret, RETRO_DEVICE_ID_JOYPAD_B);
}

This is how RETURN is mapped to "OK"
So it's only a matter of adding a setting for that parameter and referencing the setting instead of the hardcoded RETROK_RETURN.

The rest of the keys are the same.
https://github.com/libretro/RetroArch/blob/master/input/input_driver.c#L631

[fr500]

Woops didn't mean to close

[meleu]

I think this issue can be closed. The original issue is solved and that mentioned by @i30817 too (menu_unified_controls = "true")

[twinaphex]

Alright then, the OP can reopen it if he is still not satisfied.

[danny6869]

The problem with the solutions mentioned here is. IF you remap the A/B buttons for a particular emulator, then inside the system menu, the OK/CANCEL buttons change with the remap. I would love to have the freedom of remapping the buttons for the emulator while leaving the system ok/cancel buttons alone, so that is consistent across every emulator. (it only makes sense)

I cannot seem to be able to make this happen with the current configuration options. The old menu_* configs probably were what I needed.

[meleu]

@danny6869 this is how I achieve what you're trying to do:

• Start a game of the system you want to remap the buttons
• Invoke menu
• Go to Quick Menu and then Controls
• Configure the buttons the way you want
• Select Save Core Remap File
  OR, if you want to save this remapping for the current game only, select Save Game Remap File

Using this method doesn't affect the OK/Cancel mappings ;-)

[danny6869]

Hmmm...everything works ike you said, EXCEPT I cannot figure out what save option to use? It seems to always revert back when I reboot. (man...there are a ton of SAVE options...sigh)

CORRECTION...what you said worked perfectly. (I must have clicked the wrong save before...I hope I didn't store some config file somewhere that will screw me over later)