RetroPie-joystick-selection - One Controller As Both? Failover?

obsidianspider

@edmaul69 Yeah, it's doing input for both controllers if the controller that was set to player 1 is unplugged. I guess I'll have to mess around with it some more.

meleu

@obsidianspider said in RetroPie-joystick-selection - One Controller As Both? Failover?:

I understand that if a disconnected controller is there the system is going to use the retroarch default, but it's almost as if there needs to be a way to say "don't also use it for player 2 if you're defaulting to player 1"

I got what you're saying. I'll try to take a look into this issue when I have enough time. ;-)

obsidianspider

@meleu thanks! I wasn't sure if I was making sense. Hopefully what I was asking is a reasonable thing for it to do.

meleu

@obsidianspider it's a fair request. I think I'll sacrifice some Pac'n'Pal sessions to sort it. :-)

meleu

@obsidianspider I tried to sort it today but the solutions I found would bring an unwanted complexity to the joystick-selection scripts. I'm not sure if I want to go this way...

But I have a workaround that will solve your issue for a while. When you have the "one controller as both" issue, invoke RGUI and

Main Menu -> Settings -> Input -> Input User 2 Binds -> User 2 Device Index

With the cursor on User 2 Device Index press right until it says Disabled. If the Save Config on Exit is turned off (the default on RetroPie) this change won't persist between RetroArch sessions.

Is it enough for you?

obsidianspider

@meleu Thank you so much for looking into it. That workaround does work for a temporary fix. Also, thank you for writing the controller selection utility.

meleu

@obsidianspider
You're welcome.

Let me share some thoughts about the problems I faced when thinking on a solution for it. I think I'm being a little verbose here, but I know you are a curious guy that likes to know how stuff works. And maybe with a client feedback we can find a satisfactory solution. :)

Let's consider the following scenario for our analysis:

index = joystick
----------------
  0   =  joyA
  1   =  joyB

If the user wants to use the joyB for player1 and let the player2 unset, this is what happens:

player  =      index      = joystick
------------------------------------
player1 =        1        = joyB
player2 = *defaults to 1* = joyB

And this is what I think that is happening to you.

This is an unwanted behavior, but the solutions I'm thinking can bring another unwanted behavior.

Example: If the script automatically disables the player2 when this kind of conflict happens, this disabling will persist. And then when I change the player1 from joyB to another joystick, player2 won't recover its default joystick (joyB).

I could make this recovering happen using runcommand-onend.sh, but there's no guarantee that the onend script will execute 100% of the time (e.g.: unclean runcommand shutdown). And this results in the script changing configs with no user consent... This is the unwanted complexity/behavior I'm talking about.

I think I'll go with this solution:

Add an option to disable player2-4 (disabling player1 is not a good idea).
After finishing the joystick selection for a system (or the global), the script will alert the user about the possible conflicts.
If the user don't want such conflict it needs to choose what to do itself. On our example the user could disable the player2. And this will be a conscious change.

What do you think about this approach?

obsidianspider

@meleu Having it as something that the player is alerted to and gives them the option to accept is a great way to handle it. Thanks again for looking into this. I wasn't trying to give you more work!

meleu

@obsidianspider after 4 months I've finnally took a look at it... :)
I've added an option to disable player2-4 (disabling player1 is not a good idea).
talked about it here.

Thanks for the feedback.

obsidianspider

@meleu I'll have to give it a try some time! Thanks for looking into it.