I’ll pulling my hair out over trying to figure out how to do this. I have 10 different controllers for 5 different systems, all attached to the computer at the same time. Each controller requires different button schemes, and I’d like to assign 2 controllers to the system in Retroarch. I used to be able to do that under the per-core settings, but with the new per-core options, it always uses the same controller. I do like that I can use any controller on the menu, but now I have to go into the settings and change the controller and set it up manually if I want to use a different one. Retroarch doesn’t even remember the button scheme when changing controllers from one to another, making it a cumbersome process.
I have a similar setup and the controller issues were making me crazy (forgotten settings between sessions, controllers not always recognized by Retroarch at all, etc.) so I’ve gone back to using individual dedicated emulators for the time being. I find the Retroarch UI to be obtuse at best, but I soldiered on until I got it working for most stuff.
The controller support has been the most frustrating part of the experience for me. Maybe someday the cores will include something simple like diagrams of the controllers for supported systems that would let you do a simple button-to-button mapping. As it stands now, trying to map my N64 controllers in Retroarch was so unusable I went back to PJ64, My XBox One controllers are not detected consistently (though they work fine in other emulators) and if I plug in a new controller it shifts the numbering around in Retroarch, forcing me to re-bind everything.
Honestly, Retroarch is a pretty amazing achievement but it’s just too much of a struggle to get things functioning smoothly and consistently. I hope these issues get addressed because the promise of Retroarch is pretty awesome.
[QUOTE=snarfo67;46729]I have a similar setup and the controller issues were making me crazy (forgotten settings between sessions, controllers not always recognized by Retroarch at all, etc.) so I’ve gone back to using individual dedicated emulators for the time being. I find the Retroarch UI to be obtuse at best, but I soldiered on until I got it working for most stuff.
The controller support has been the most frustrating part of the experience for me. Maybe someday the cores will include something simple like diagrams of the controllers for supported systems that would let you do a simple button-to-button mapping. As it stands now, trying to map my N64 controllers in Retroarch was so unusable I went back to PJ64, My XBox One controllers are not detected consistently (though they work fine in other emulators) and if I plug in a new controller it shifts the numbering around in Retroarch, forcing me to re-bind everything.
Honestly, Retroarch is a pretty amazing achievement but it’s just too much of a struggle to get things functioning smoothly and consistently. I hope these issues get addressed because the promise of Retroarch is pretty awesome.[/QUOTE]
I’m glad there is someone out there that understands the frustration. I think everyone working on the project are making great strides in making this the best all in one emulation software, so I’m not complaining, I’m just having a hard time trying to figure it all out and work for issues that you and I have.
This isn’t a scenario that any of the main contributors can reproduce, so it’s not likely to get changed/fixed any time soon. If someone who leaves a dozen gamepads plugged in all the time wants to work on a solution, we’re happy to facilitate it, though. We can point them in the right direction and review their plans to ensure that the code is implemented in a way that’s acceptable to merge.
Couldn’t you resolve this with separate configs? I haven’t used the new Retroarch with new core setting options yet, but couldn’t you do the following:
-
go into Retroarch and load a game for a given system
-
setup the controller as you’d like for that core and whichever controller you’re trying to use with it
2a) if you are super concerned, try disabling the other, non-used controllers under settings> controllers. You can also try making sure the core is set to only use the number of controllers it should (instead of auto detect) and manually assign the controllers to your correct real controllers)
-
Go to Retroarch and “Save as” the config to whatever name you want.
-
Repeat for other cores
-
Create a shortcut or batch file for each core/system and have it use the appropriate config.
Note that, if you store your configs in seperate folders I think you should be able to have different core settings (a developer might want to confirm that).
[QUOTE=atsumori;46746]3) Go to Retroarch and “Save as” the config to whatever name you want.
-
Repeat for other cores
-
Create a shortcut or batch file for each core/system and have it use the appropriate config.
Note that, if you store your configs in seperate folders I think you should be able to have different core settings (a developer might want to confirm that).[/QUOTE] Instead of those steps it’d be easier to use a recent nightly where you can save overrides (I think from the quick menu) and turn on Load Overrides Automatically in Configuration settings. Well, turn that option on when a game isn’t loaded and exit, then start up RA again and load a game, configure your controller as wanted for that core then save overrides.
I agree that there are a number of usability issues surrounding input config.
I came across something online that may help: switching Input Driver from dinput to SDL2.
Retroarch provides different methods for polling inputs. Even if it sounds counter-intuitive for a windows based system, for your config to work properly you should go with sdl (and not with dinput or xinput). What sdl seems to be doing, is to always register native xinput controllers first, any other controller types second. On my system it even manages to keep order within the subtypes itself, meaning whatever xinput gamepad for player1 will stay player1, and xinput gamepad for player2 will stay player2. Same for the controllers connected via my dolphin bar. It’s been that way since I switched to sdl two months ago, and has never failed me. So basically, if you put the dolphin bar into joystick mode, Retroarchs mapping will look like this: 1. X360 Controller #1 2. X360 Controller #2 3. Mayflash Wiimote #1 4. Mayflash Wiimote #2 5. Mayflash Wiimote #3 6. Mayflash Wiimote #4 When the dolphin is being set into mouse mode, it will be: 1. X360 Controller #1 2. X360 Controller #2 It’s perfect.
Worth trying.
How could I contribute? I don’t know how to program or anything like that.
[QUOTE=atsumori;46746]Couldn’t you resolve this with separate configs? I haven’t used the new Retroarch with new core setting options yet, but couldn’t you do the following:
-
go into Retroarch and load a game for a given system
-
setup the controller as you’d like for that core and whichever controller you’re trying to use with it
2a) if you are super concerned, try disabling the other, non-used controllers under settings> controllers. You can also try making sure the core is set to only use the number of controllers it should (instead of auto detect) and manually assign the controllers to your correct real controllers)
-
Go to Retroarch and “Save as” the config to whatever name you want.
-
Repeat for other cores
-
Create a shortcut or batch file for each core/system and have it use the appropriate config.
Note that, if you store your configs in seperate folders I think you should be able to have different core settings (a developer might want to confirm that).[/QUOTE]
I could sort of do this with the old per-core setting, but with the new one, it doesn’t save controller settings. I can’t change the amount of users or controllers to 2 because then it only shows the first 2 controllers, and you can’t select which 2 are active. If I could choose the controllers for that system I’d like to use, that might work.
Could you set it up how you like for, say, SNES, hit Save New Config, and then use the [corename]_libretro.cfg that generates to start RetroArch from the command line with the exact setup you want to replicate (assuming correct controllers are still plugged in)?
Example:
retroarch.exe --config bsnes_mercury_accuracy_libretro.cfg
If you keep all your pads plugged in at once then maybe this won’t work due to the random-seeming reassignment issue discussed above. In that case try the SDL2 workaround I mentioned, I’m curious if that’s helpful.
Alexandra> that’s what I’m trying to say, just run retroarch with a command line argument for the config and load whatever you want. It’s not as automatic as per-core configs but if you create a shortcut for each core it will work pretty much automatically.
blm07> You can choose which controllers to assign, it’s just sort of buried. From the top go to Settings>Input>Input User X Binds (X=whatever player number you want to edit. Select the device by changing the User 1 Device Index value (Using left and right). I don’t have a huge variety of controllers to test with, but I did get it to reliably use my #4 Xinput Controller as player 1 in NES games even after closing and reopening Retroarch on a fresh install of the September 7 nightly. I believe this data is also stored in the
Or just use overrides, which is about the same thing as loading a separate config but automatic. It’s actually better since it only saves the things you’ve changed for the core to the config, then loads it as an appended config on top of retroarch.cfg. So you can still change general settings you want to affect all cores when a core isn’t loaded. And not have to worry about updating settings in the mess of full sized configs you’d have to manually load using --config if you did it that way.
[QUOTE=atsumori;46795]Alexandra> that’s what I’m trying to say, just run retroarch with a command line argument for the config and load whatever you want. It’s not as automatic as per-core configs but if you create a shortcut for each core it will work pretty much automatically.
blm07> You can choose which controllers to assign, it’s just sort of buried. From the top go to Settings>Input>Input User X Binds (X=whatever player number you want to edit. Select the device by changing the User 1 Device Index value (Using left and right). I don’t have a huge variety of controllers to test with, but I did get it to reliably use my #4 Xinput Controller as player 1 in NES games even after closing and reopening Retroarch on a fresh install of the September 7 nightly. I believe this data is also stored in the[/QUOTE]
That’s what I used to do before this new setting, it still took a lot of fiddling around to get it to work, but it worked. It doesn’t switch controllers when you load a new core anymore.
I tried saving the overrides but it doesn’t seem to load what I’ve changed when I load a different core.
Ah, so it sounds like the real problem here is that you’re trying to use RA as a your primary launcher but you can’t easily (or automatically) switch controller profiles by core within RA anymore. Is that accurate?
When you load a different one you’ll need to change what you want for that core and save core overrides again. It will say that the overrides are loaded in yellow text when they’re working.
Yeah, that’s what I’d like to happen.
Holy crap, it seemed to have worked.
edit: nevermind, this is really frustrating. I’m giving up for now.
I’m not sure if you can do it automatically, but you can make manually changing your settings easier. Follow one of the methods Awakened or I mentioned for creating a new config for each core/system/whatever and then manually load the appropriate config through the RA main menu whenever you change systems.
It’s not automatic, but it will at least save you from having to set up your controllers each time you change systems.
I’m trying to understand what was the reason for getting rid of the “per core settings”… it worked flawlessly. Now I can’t figure out for the life of me how to get separate settings for each core.
As stated elsewhere, per-core configs were a mess under the hood and they caused a bunch of weird issues, particularly when porting RetroArch to other platforms. Overrides can do the same stuff (at least for the most part) and now that you can save them directly from the menu, they’re easier to setup and much more predictable than per-core configs were.
If you have a setup that depends on per-core configs, you can always just keep using whichever old build you used before.
There are probably more user friendly ways to convey core and game specific override settings in the UI that could be implemented. It’d be nice to have some kind of icon next to each setting in XMB indicating it’s a core or game override. Or maybe have some color coded highlighting on the text. I’m not sure how you’d convey which color means core or game though.
I was thinking an easier way to save overrides would be to have a dedicated button/key for toggling between changing general, core and game settings. When you press the toggle the OSD tells you which mode you’re in. But I’m not sure how you’d tell the user that toggle exists or that it only works when you have a core and game loaded.