Multiple Instances Of Retroarch

General
#1

Hi. It seems I cant create an ideal scenario for my arcade setup using Hyperspin as a front end, Rocketlauncher as a back end and some systems using Retroarch so I need to think a little outside the box.

  1. Currently I want to use 3 methods of controller. (2x Controllers each time (Player 1, player 2) a) My arcade machine (A Xin Mo controller that see two controllers) b) Generic USB N64 Retro control pad c) 8Bitdo Controller

  2. Xin mo can cover certain systems like Mame and NES, N64 can cover N64 only and 8bitDo for things that require analog sticks and triggers etc. Thats how I want it.

  3. Retroarch does not distinguish between Port (Device index) and controller. They are interchangable. Yet to me they are different things. A port is not a player or a controller. USB is a bit tricky though and windows does like to reassign things differently. I belive this might be why RA does this.

  4. Controllers will not always be plugged in. The Xin Mo is plugged in permanantly and will not be removed as its part of the arcade machine. The N64 Generic USB will be only plugged in when wanting to use the N64 “wheel” and unplugged immediatly upon retuning to hyperspin. The 8bitdo will be blu tooth and will not always be connected, only switched on for certain systems.

Retroarch will not map a controller to a core. Its far too convoluted a control method to use multiple controllers. It is more ideally suited for an xbox controller that gets either set up manually or autoconfigs and then you just map each core if you want to make any changes. This is absolutely fine and can take a bit to get used to but works solid and is very easy to set up when you get the hand of it and when you are only using one controller across the entire board, like the xin mo, or an xbox controller.

Where Retroarch seems to fall down is index mapping. I have 6 controllers (3 different types). When I plug in a controller I want to use just before I “Enter” that system, RA has a bit of a meltdown and reassigns itself to the orginal config in index 0 or 1, yet still tries to use some of your original mapping for another controller that was previously sat there. This causes all sorts of extremely convoluted mapping options including entire keys disappearing and swapping buttons (I had one system set up correctly and exactly the same for each controller but had to swap “A” and “B” around on only one controller, the other worked fine. It also drops keys so on one controller I needed to map a “z trigger” to a core and it seemed to be attached to the Y button but the Y button disappeard, again no problem for controller 2 but the point is it really doesnt like swapping out controllers). Its annoying but I understand Im trying to use it in a way its not designed to be used so instead I have a kind of solution but dont know if I can properly implement it.

I was thinking of running 3 instances of retroarch. One for each controller setup. Not at the same time of course. Only loading through rocketlauncher and possibly based on paths. In each instance I can correctly default autoconfig the controller in the correct index and just set it up. Then if it doesnt match up with the specific system (which often it doesnt) I can just figure out what to map to what, and change the buttons accordingly, saving the core remap then that should be that.

Before I try all this, is there a better way? Or a reason it wont work? I really want to be able to set these controllers to certain cores (or systems) and so far I can only do one thing at a time, each other set up ruins the previous one so I keep going back to square one. I have a feeling that it might work, as whatever new controller I plug in seems to map itself to index 0 and 1 which is the front of the queue, this pushes the permanantly plugged in xin mo to the back but thats ok if the “currently loaded” retroarch is expecting that device to be in port 0 or 1.

Am I missing anything? I’ve been trying to come up with a better solution for weeks and tired of mapping and remapping every time I hop into a system.

Help and insight is appreciated.

#2

So I tried this and did not get a good response unfortunately. I decided to create two extra folders for two other instances of Retroarch so each one was named something different. I also create two extra modules for RocketLauncher and pointed everything in the right direction, updating paths and such. After mapping one version of RA correctly to one core I turned my attention to the N64 core. After much bashing my head against a wall trying to get controls to work through mapping the autoconfig then having to remap while in the core as well (an absolutely silly system that is grossly convoluted) due to everything it said it was being backwards and upside down and inside out (you map B to B in auto config then go in game and it behaves like the Z-Trigger, why?).

Anyway, I eventually got a satisfactory set of correct controls nailed down, saved everything to the core profile under core control mapping and left it there. Exited out of everything, total restart and tried the Atari 2600 (something I had mapped to the arcade controls) success. Tried going into the N64 and the janky controls were back again so it seems to be forcing it to use the oringinal port configuration.

So its conclusive then. Retroarch does not accept multiple controllers hotswapped in for certain systems. And a workaround solution of having multiple retroarches handle different controllers also does not work as something always sees the original and takes its configs from that folder in spite of remapping all directories. Its a shame because the only work around is to use individual emulators to map each system to that isnt just using the one control type. Now this wouldnt be a problem if it were easy enough to map controls in every emulator but some are trickier than others (try mapping a bluetooth controller like the 8bitDO in PCSXR, its not fun and doesnt work anyway, everything gets mapped instantly to the mouse click as you click it to map, absolutely ridiculous). However its all we have for now until I do some further digging to try and solve this solution the retroarch way.

#3

Multiple instances aren’t really necessary if you just use the -c /path/to/custom_config.cfg command line switch, or even --append-config /path/to/config_fragment.cfg.

The important part would be disabling autoconfiguration and then hard-mapping your inputs. As long as you’re adding the new devices after RetroArch is running, I think you should be able to get predictable behavior from the device allocation (that is, the xin mo will be in the first slots and the additional controllers will be added afterward in the order you connect them).

Nevertheless, having multiple instances should work fine. There’s a guy on reddit who swears by it to do exactly what you’re describing.

1 Like
#4

Thats interesting. How would I go about disabling autoconfig and then hardmapping inputs? I think one of the issues comes from when certain controllers are plugged in (which they will not always be) they tend to “jump the queue”. So the Xin mo is port 0 and 1 but when I add the N64 controller it jumps to 0. Hence why I was trying to use multiple instances. I am wondering if I have missed something when creating duplicate modules because I have pointed to all the correct paths but maybe an ID on the modules are the same so it keeps wanting to use configs for other ones. I am not sure I can use custom command switches in RocketLauncher so didnt try that path, there isnt a lot of documentation on how to launch it that way however there is certainly a lot more tabs to look through, I may be able to get a custom switch that way.

Is there a way to force RA to consider each controller ‘type’ (I say this because I am not bothered about which controller would then end up being P1 or P2 apart from the xin mo because its literal position is fixed, the other controllers can just be swapped if necessary so by type I mean Xin mo, 8BitDo or Generic N64 and not actually the exact individual controller which I wouldnt expect it to do) and map it to a specific device index? I dont mind having them all plugged in together at once in order to do this. Its just they wont always be on and therefore the order moves around to unpredictable results when plugging them in either before RA is launched or after.

Thanks for the reply.

Edit: I just found CLI perameters in Rocketlauncher, would that be useful in launching the different instances if I were still going down that route? Using the command line switch like you said?

#5

In settings > input, there should be an ON/OFF switch for autoconfiguration. Once it’s off, it won’t do any of the autoconfig stuff, so it should be more predictable but also much more limited:

image
image1034×432 102 KB

If you don’t see it, make sure you stop by settings > user interface and set ‘show advanced settings’ to ON.

Once it’s disabled, you can just go into settings > input > port 1 (or 2 or whatever) controls and map your inputs there and they’ll be written to the config on exit (or if you manually save via main menu > configuration file), just like any other settings.

EDIT: yeah, seems likely. Again, though, it really shouldn’t need entirely different instances, since the only differences among them would be configuration files/values

1 Like
#6

Thank you. The more info I have the better. I will try this. I need to ask though. When I am “re-mapping” controls using quick menu, usually because its all fluffed up again, and I save the specific core remap, is it affecting the controllers in the index because thats what it seems to be doing but I thought quick menu then saving the specific core remap only brought up that remap when that specific core was loaded and only that core, is it affecting everything? Because that may be what keeps reversing everything that I am doing. Remember that when I plug in a controller it is shifting everything over by 1 on the index so my xin mo goes from port 0 and 1 to port 1 and 2 while the newly plugged in N64 sits at port 0, until it is unplugged then everything shifts back. I cant seem to stop this so it would be good if I could just get each controller set up in autoconfig but the controls make very little sense. As I said before I plugged the N64 controller in and mapped Start to Start, Z to Z, A to A, B to B etc and then went into a game and absolutely nothing except Start behaved in the correct way, hence the need to “correct” it by then core remapping (I still really dont understand why thats necessary), but if that is throwing all other configs off then this will not be helping.

#7

Remaps can be saved on a per-core basis and will load along with the core regardless of the controller that’s used. They shouldn’t bleed over from core to core, though.

This could potentially be a reason to use >1 instance of RA, though you should be able to ignore remaps altogether if you’re hard-mapping everything. That is, just map it how you want it for the core from the get-go and don’t worry about the general retropad mapping.

1 Like
#8

Yes I wanted to do that, just map it for the core and leave it. The only problem is, is the inputs never seem to match. Remapping at core level seems the only way but it does something to override some other config and I think it may be due to the device index which unfortunalety I cant change. I have heard another solution could be to still use autoconfig but rewrite that as necessary but that would be a complete headache i imagine. Mapping button 4 to Z which is button A that needs to be remapped in the core to L-trigger which was originally assigned to L-shoulder. That kind of headache. Layers upon layers of buttons that dont match up to descriptions or functions. I may maintain that it cant be done due to the index mapping of the controllers. A solution can be found if all controllers are plugged in at all times and never change but not if they are not. I still have one or two things to try before I make that statement though and I might start again by delving into the module section of rocketlauncher to see if it really can descern between different “folders” of retroarches. Reason being is if I can crack that then it doesnt matter about the device index as long as I make sure the appropriate controller is plugged in before launching because it should just go off a main autoconfig for the “device 0 index” controller which will of course change for each different instance of RA.

#9

yes, it would be the same deal with the hard-mapping.

It occurs to me that you should make sure Rocket Launcher isn’t doing anything silly with configs. Sometimes launchers will point to some hidden config somewhere without telling you about it.

1 Like
#10

Yes. I have slights suspicions it might be something here and not actually a RA issue (if the index issue can be bypassed) as such so I am going to try looking into the modules again, also all the individual system settings and other places RocketLauncher can hide paths to configs etc and hopefully can come back with good news :slight_smile:

1 Like
#11

I did manage to get it working this way in the end so I currently now have three retroarches all using different controls and each one, when bound correctly to that core, does not affect the other installation. In case it helps anyone else who uses rocketlauncher particularly.

I copied two extra RA folders and renamed them after the controller so now I had three folders under my Emulators folder.

Retroarch

Retroarch 8BitDo

Retroarch N64

Then I went into Rocketlauncher/modules and did the same for the retroarch modules folders. This threw up an error saying things like duplicate modules and “may have been tampered with” type errors. I opened up the files and deleted the three lines that give the module an id.

They would be the lines that look something like this

MCRC = 9C0576F0

iCRC = B33E9394

MID = 635038268922229162

Now set up new emulators in Rocketlauncer creating three different instances of retroarch, each one pointing to the correct exe in your new folders and each one pointing to the new modules so all your paths are correct and pointing at the right /config folders. Now when you set up a system in rocketlauncher just point it to the version emulator that you want to use and it will use that specific retroarch. Bind your buttons as you see fit but make sure you do the obvious and have your controller in when you select the system and make sure you unplug before you go back to something like hyperspin or certain controls that were set up for that may not work as it will have moved the joysticks that are plugged in around. This should work fine in most cases but what it shouldnt do is rebind things randomly when setting up another controller because it is now rebinding to a totally seperate RA instance.