Input System

The Proposal: Much like the “Save Core Overrides” function, “Save Controller Overrides” and “Save Controller Core Overrides” would be very helpful. Allowing controller autoconfigs to store general settings as retroarch.cfg overrides would be the most straightforward way of doing it.

The Reasoning: Let’s say you own two controllers: an xbox 360 controller and an N64 controller clone.

Say you set up an N64 controller as expected with retroarch. The C buttons are set to the right axis and the Z button is set to L2. There are no X, Y, or R2 buttons. It works perfectly in N64 cores.

Now you want to use it on an SNES core. You don’t have an X or Y button set. Easy, right? Core remap to set the A, B, X, and Y buttons to the right axis. Done. Except now your xbox 360 controller has to use the right joystick instead of the A, B, X, and Y buttons. And the menu controls are messed up on both controllers. If you could set a Controller Core Override, You could only affect the N64 clone and force the menu controls to still use the A and B buttons.

Now let’s say you’re used to using the xbox 360’s scheme on hitting “okay” and “cancel” in menus. Right now, you’d have to invert these two settings in your retroarch config. But this would also invert the buttons for your N64 clone. A Controller Override could make this change controller specific.

Finally, let’s say you’re playing an NES core with your xbox 360 controller. You notice that the L and R buttons are unused. You decide to set them to rewind and fast forward as a core override. But you had to save it as buttons “4” and “5”. Buttons “4” and “5” on your N64 clone are A and B. Now when you try to press A or B while using your N64 controller, you fast forward or rewind instead of actually pressing A or B. Once again, a Controller Core Override could help.

The Conclusion:

The input system is perfectly adaptable to any single controller/core configuration you could imagine. However, when you start to play with two different controllers, shortcomings become apparent. These changes could really help with these shortcomings. I hope you’ll take them into consideration.

I don’t think that’s a dumb idea, but i think it would be a mess.

I have kinda the same issue on fbalpha with different controllers : let’s say i use a gamepad with R1/R2 buttons (like my hori fighting commander 4) and a gamepad with only L/R button (like my 8bitdo snes30), having L/R (strong puch / strong kick) remapped to R1/R2 for capcom games would make a ton of sense for the first (especially with capcom games being played that way on modern systems), but would be an issue for the second.

I think i’ll soon work something through a core option in my case, especially since i want something i can easily switch on/off depending on the player playing / controller used, but i understand where this thread comes from.

This is an issue I’ve been frequently running into myself and complexity aside, I’d be 100% for this.

As of now there’s no easy solution to this rather than constantly remapping controllers. Honestly, I would even settle for a way to manual load bind .cfg files via file browser.

@GameDragon

if you don’t care about the core, why not use joypad-autoconfigs? these allow you to have separate controller binds for each different controller you use.

Is it really that much of an edge case to have two types of controllers that need mapped independently of each other on various cores?

Under what set of configuration could I use both an N64 controller and xbox 360 controller on an SNES core? The N64 controller has no X or Y buttons. I would have to use the C buttons for A, B, X, and Y. I could either do that by changing the controller autoconfig, which would screw up the controller for other cores, or a core remap, which would screw up the xbox 360 controller.

why not create joypad-autoconfigs for each core-controller combo, then put all the ones for coreA in /folderA/, and coreB in /folderB/, then create two separate core-overrides. first with joypad_autoconfig_dir = /folderA/ second with joypad_autoconfig_dir = /folderB/

[QUOTE=dankcushions;47893]why not create joypad-autoconfigs for each core-controller combo, then put all the ones for coreA in /folderA/, and coreB in /folderB/, then create two separate core-overrides. first with joypad_autoconfig_dir = /folderA/ second with joypad_autoconfig_dir = /folderB/[/QUOTE]

You brilliant man. That takes out the first case of the OP without any code modification.

Edit: With this trick, the only thing that would need to be done to solve the rest would be allowing autoconfig files to handle menu controls and hotkeys.

[QUOTE=tony971;47900]You brilliant man. That takes out the first case of the OP without any code modification.

Edit: With this trick, the only thing that would need to be done to solve the rest would be allowing autoconfig files to handle menu controls and hotkeys.[/QUOTE]

they can i think :slight_smile: eg https://github.com/libretro/retroarch-joypad-autoconfig/blob/master/udev/VenomLimitedPS3PS4ArcadeJoystick.cfg#L9

[QUOTE=dankcushions;47891]@GameDragon

if you don’t care about the core, why not use joypad-autoconfigs? these allow you to have separate controller binds for each different controller you use.[/QUOTE]

I do care about the core. I was just replying that core remaps wouldn’t solve the issue. It’s more of “separate controller binds for each individual controller” is what I was looking for.

[QUOTE=dankcushions;47893]why not create joypad-autoconfigs for each core-controller combo, then put all the ones for coreA in /folderA/, and coreB in /folderB/, then create two separate core-overrides. first with joypad_autoconfig_dir = /folderA/ second with joypad_autoconfig_dir = /folderB/[/QUOTE]

This is a great workaround and would probably work just fine.

Being honest, a game specific controller layout would be great. Autoconfig is great no question about that. But having a certain layout for only some games would be great.

[QUOTE=papermanzero;48050]Maybe not clear enough a per core -per game -per controller layout would be good. [/QUOTE] you can already do this. see my previous workaround, but replace the core override, with a game override.

Yes, that’s true. However it’s a workaround. On the other hand I can see the complexity with regard to the retropad abstraction layer. …anyway, I only thought it is a good idea.