iirc some users requested the opposite way (the current way), because they want to use two different controllers for multiplayer at the same time, and want the config depending on the controller type (i.e. GUID) regardless the order they are plugged. We can't cover all possible but conflicting preference in this corner feature.
I don't by any means understand programming an emulator but this feels like a simple checkbox of allowing one or the other would be fairly simple.
I have a few controllers I use for different emulations and do use multpile controllers for Pokemon trading mostly but I will admit it's a pain when my wireless controllers die and after plugging it in i need to rebind. That's just me though.
Since the current SDL code is not mainly managed by me, I can only provide some referential info and thought.
After reading the code and some archaeology work, here are some important things I've found:
In the current controller config, the port field doesn't represent physical ports and cannot uniquely identify controllers as you might have thought: it represents a sub ID for controllers with the same GUID. i.e. it is totally possible that two connected controllers have different GUID but have the same port=0 - it only means they are both "0-th" controller within their type. So simply ditching GUID for controller identification is not as simple as it sounds.
The old version of this part of code, originally written by me, was indeed idenfying controllers by their physical port (provided by SDL). It was, however, changed to the current version by #4141, due to hotplugging issue, the issue I mentioned above, and some others. The reason you have never seen anyone complain about these stuff might simply because they are (probably partially) resolved and people don't complain any more.
The current controller backend we are using, SDL, doesn't have a robust controller identification system for all use cases. One need to implement a new backend that talks to XInput directly to achieve the XInput-like behaviour.
Does the controller profile system work for you ? You can now create multiple profiles for different controllers (different GUIDs) and quickly load them when you change controller.
btw do you want to know why devs don't want to reply to these kind of issues? Because they know they are going to get 馃憥 no matter how reasonable they think their reply is.
@ToppestOfDogs You didn't understand: We can't use every controller with a different GUID will have port 0. So we can't use that for any of your issues.
Actually, the best solution for this issue is to add autoconfigure for controllers. It's something that is on my TODO-list for a very long time, but I didn't manage to get the time and motivation for it (yet). With that said, and since we have an open issue for autoconfigre, I request to close this (since it's dublicate)
also a general warning of the xy problem here. GUID might not be the essential problem to discuss.
@ToppestOfDogs the point is that what you suggested is likely harder than autoconfig to do
@ToppestOfDogs you realize that GUID was added because port was extremely unreliable and would change on controller disconnects for some people? Everything you suggest here would fix your issues but doesn't fix other issues. Some people have multiple controllers plugged in and on each computer reboot, they'll be assigned to different ports, or worse, each time their controller disconnects, it gets reassigned to a different port on reconnect. Both of these cases should be accounted for in whatever solution we add. Tying it to just a port means they are out of luck and their controller never reconnects.
We all know that input handling needs improvement. But please consider more than just your specific use case if you are going to insist on a specific solution to the issue. Having controller profiles tied to port only works good for you, but doesn't work well for everyone out there. Don't misunderstand me either, I'd like for someone to make controller handling better, and that may mean removing GUID, but it may also mean tackling the problem by using SDL input mappings to auto configure the controller, maybe a little of both. Maybe we could have a system to fallback to other controllers if the configured controller isn't present or if the ports don't match. But let's get it right this time instead of rushing to a quick resolution.
50% people are using one single controller they have for citra (silently, because they don't have problem). You are just a another 5% specific audience. Please stop feeling much more important that other.
People who use their PC for more than just Citra? Do you think everyone just plugs in a controller only when they need it? Plenty of issues have been opened by people who just leave multiple controllers plugged in all day. The worst case of this was people who installed the 3rd party driver that smash melee players all tell them to use for lower latency, leave their mayflash GC adapter plugged in with no controllers attached, SDL would detect the adapter as a controller and crash when opening the device. That was a fun bug to track down.
Want me to add a telemetry stat for number of controllers plugged in? I'd be genuinely interested to see if 99% of people that use controllers in citra only have one controller plugged in.
50% people are using one single controller they have for citra (silently, because they don't have problem). You are just a another 5% specific audience
Now i'm seriously considering setting up a telemetry field for this....
You're only considering one use case and not what 99% of people are actually going to do, which is use one controller at a time for a console that only supports one controller.
I am not talking about people using two controllers simultaneously, I'm talking about people who have multiple controllers plugged into their PC.
You are just finding matters to argue now, but excuse me, even 10% submitted telemetry is more accurate than your talk. Closing as this is going offtopic from technical discussion. Please use the forum or discord for further support.
Its been about a day which hopefully gave everyone a bit of time to cool off. I'm reopening this on the grounds that there is an issue that needs fixing, and should be tracked when someone starts working on controller fixes again.
not 100% sure if this is the right thread for this issue or if i should create a new one, have searched and can't really find another one that's more similar to my issue, but:
i'm using a ps4 controller over bluetooth, and it works fine and great. the problem is when i want to reuse the controller with citra, i have to rebind the whole thing, even with no other controllers plugged in in-between or anything (like if the controller goes to sleep while i have the game running). the controls -> input menu still shows the right buttons (ie, if the mapping for 'A' is 'Button 0', pressing Button 0 [X on my PS4 controller] doesn't work, but if I go through the rebind process for the button again, it'll still show 'Button 0' but it will actually work)
Most helpful comment
btw do you want to know why devs don't want to reply to these kind of issues? Because they know they are going to get 馃憥 no matter how reasonable they think their reply is.