Open i30817 opened 7 years ago
No more X/Z.
Enter = OK button (RetroPad A) Backspace = Cancel (RetroPad B) Shift = Info (Retropad Select) Spacebar = Defaults (Retropad Start)
Yeah, that's a terrible decision then. I don't even know why you wouldn't want the consistency, not to mention that it's often needed to remap system keys (such as in my case of the non-functional keys).
It messes with the keyboard for long time in prompts. I used to not be able to type in "Zelda" without getting "elda". This can be problem for some people wanting to type in X/Z (user, password, settings, etc). It eats z when pressing z. It spits out x1 when pressing x.
I'm still without directional keys due to this decision. Simplifying key config unto nigh usefulness is not the way i'd go to resolve this. For example, there is such a thing as context sensitive focus keybindings.
No worries. I wanted to let you know why obvious No. 2 isn't working. For other issues, I do not know and will leave the floor to others.
Ok. I'm not too mad about Z/X, because the alternatives are actually working on my keyboard, i just want to keep the possibility of 'menu remap' active for obvious reasons
BTW, how can you clear a mapping? Or is this a 'only from the conf file' situation.
I hadn't played with remaps at all. I know you can use spacebar to reset the bind and the answer I can give right now is to find your config and clear them out manually. (This could be the only answer too).
Remaps or input bindings? For remaps you just press start and it will reset the CORE<-->RetroPad mapping to default
For bindings, there is no way to clear them from the GUI
Bindings, but i did it from the retroarch.cfg file. I really think you should reserve a key, possibly pressed and not released for a few seconds to clear them completely (so it can still be used as a binding if released early enough). On a 'good news' the keybindings that didn't work - bug 4) in the OP - were able to be inputed from the cfg file, although i haven't tested if they actually work in game yet.
For the actual menu arrow keys, if remapping is too much to ask I'd be 'satisfied' if
There are far to many emulators that take numlock status when the emulator starts and even if you press it later when it's running, ignore the change completely (ppsspp is one of them), but allow you to map to 'a virtual key' that only exists when numlock is on, so it doesn't work if you happen to start the emulator in the wrong mode.
setting up the keybinds that don't work directly on the cfg file ( 4) in the OP ) works for some (divide,7,8 and 9 formed a correct axis on libretro unstable) but not on others
5,1,2,3 as a left analog stick makes 5 correctly go up (input_player1_l_y_minus = "keypad5") 2 go left when it should go down somehow (input_player1_l_y_plus = "keypad2") and 1 (input_player1_l_x_minus = "keypad1") and 3 (input_player1_l_x_plus = "keypad3") do nothing.
Meanwhile, keypad4 and keypad6 that aren't findable in the cfg file at all are controlling up and right (the missing key directions). I have no idea why this is happening, but it's probably a bug.
I tested this on Valkyria Chronicles 3 on the ppsspp core, where the left analog stick controls running and the normal directional buttons control walking. Another psp game like this is 3rd birthday, where one of the axis controls camera the other movement. Metal Gear Solid psx on the mednafen core with dualshock configuration is the same, if you prefer a psx game to test.
use a newer retroarch config and copy the input text to the emuvr retroarch this is a mostly issue if you wanna use emuvr just headsup!
heres myn
Seems like a minefield of input bugs here. I'm seeing them because i'm trying to use it since i destroyed my laptop keyboard over time, to the point that two of the normal directional keys don't even work.
Let's start with the obvious:
then the less obvious
to remap a numpad key in retroarch you have to use numlock before. This is my least favorite way of configuring keys in emulators on the numpad. I get it that for consistency with the normal keyboard behavior shift+key or keylock+key do different things, but in emulators it is a hassle that doesn't gain you much of anything except a bit more key combinations you won't use. I much prefer that the keylock and shift status are ignored and the keys are also not 'confused' by their equivalents elsewhere on the keyboard (so maybe instead of ignored, treated as always on would be better), in almost all emulators (dosbox being the exception for obvious reasons).
even if you do 3) currently you can't remap certain keys here. For example, numlock_8 remaps but numlock_9 doesn't waaaat?
There are probably other bugs for you to find. Is there even a way to unit test this?