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.
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
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.
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.
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.