[Bug] Duplicate controllers conflict because they share the same controller ID

[ToppyTopology]

Current Behaviour

I have a setup with 2 wired Xbox 360 controllers and it seems that only one controller (which is the first to be connected) can be selected and used. Ive confirmed this by checking the config, connecting the controllers one at a time, and saw that both have the same id. Them sharing the same id might be causing a conflict. This issue is also not present in MidnightControls.

Expected Behaviour

Both controllers should at least be able to be selected and used individually, which can be really useful when playing with 2 instances of the game (splitscreen).

Screenshots

No response

Reproduction Steps

1. Connect 2 Xbox 360 controllers
2. Launch Minecraft with the mod
3. Try to check if both controllers appear in the select screen

Logs

No response

Mod Version

2.0.0-beta.14+1.21

Controller

Xbox 360 Controller (Wired)

Bluetooth

• [ ] Yes

Operating System

Windows

ARM

• [ ] Yes

Additional Information

No response

Just to make sure...

• [X] I have made sure I am using the latest version of Controlify for the latest version of Minecraft.
• [X] I have made sure there are no other issues describing the same problem on the issue tracker.

[N0aW]

Can also be replicated with two PS5 controllers, It's definitely an issue with duplicate controllers

[isXander]

What do you mean, same id? What ID are you referring to? I don't have two identical controllers to test this.

[N0aW]

I think it could mean that the mod cannot differentiate between two identical controllers and ends up ignoring one of them?

[ToppyTopology]

Hello, sorry for the confusion but yes if you were to connect duplicate controllers, it seems that it cannot differentiate between the 2 of them and ends up ignoring the second controller. The id I'm referring to is the one that shows up in the config, which only shows 1 controller despite that 2 controllers are connected

[ToppyTopology]

since the 2 controllers use this same id, only the first that is connected can be used

[EssGeeEich]

I second the issue, three identical DS5 gamepads showing this issue which doesn't happen with other mods (ie. Controllable). "Too bad" that Controlify has a superior virtual cursor support which actually lets us interact with JEI...

I don't currently have the technical willpower (nor any more time for today) to debug Java code, but following all the various things let me believe that the issue lies near https://github.com/isXander/Controlify/blob/66f312107dc7efe5a85e2c1bfce090144f46c0ec/src/main/java/dev/isxander/controlify/controllermanager/SDLControllerManager.java#L120

I believe that the issue should lie within the count of same-HID devices that happens in line 120-122. Perhaps it has to do with whether or not the list is subsequently populated with HID's?

[ToppyTopology]

@isXander any updates for this?

[EssGeeEich]

Got it! https://github.com/isXander/Controlify/blob/66f312107dc7efe5a85e2c1bfce090144f46c0ec/src/main/java/dev/isxander/controlify/controllermanager/AbstractControllerManager.java#L140

This line is comparing an Optional\<HIDDevice> (c.info().hid()) to an Optional\<HIDIdentifier> (Optional.ofNullable(hid)), thus equals(...) always returns false, never matching any controller HIDs.

I'm not as versatile in Java so I'm unable to post a pull request, but for whoever already knows Java this should be pretty trivial to fix!

[EssGeeEich]

Additionally, if you want to generate a GUID from SDL without relying on how many other controllers are connected, you can have this depend on the Serial Number of the controller (see SDL_GetGamepadSerial/SDL_GetJoystickSerial). The only major difference is that SDL_Get*Serial requires the instance of a controller, not just the controller ID, so you would end up creating a controller without knowing its GUID before.

That would be a pretty cool solution too (i.e. the same controller always has the same configuration, and the behaviour wouldn't change depending on the connection order of the joysticks anymore).

[EssGeeEich]

My pull requests seems to not be properly referencing the issue. See PR #412.