gamecontrollerdb issue braindump

[briaguya-ai]

after seeing https://github.com/HarbourMasters/Shipwright/issues/3879#issuecomment-2002552704 i decided it's probably a good idea to write down some thoughts around gamecontrollerdb issues

the main issue is id conflicts. there are multiple controllers that end up with the same id for gamecontrollerdb. the upstream repo refuses to replace existing mapping strings, and even if they did that wouldn't be a good solution because it would mean other controllers are broken

one potential solution would be to move away from using SDL gamecontroller, and just use joystick instead. i don't think this is a good solution to this problem as it would complicate a lot of the gamecontroller stuff we take for granted. we'd basically need to create the joystick and then try to create a gamecontroller to support gyro etc. and if that doesn't work fall back or something. we'd also lose the ability to know button names when in joystick only mode. overall this would move the complexity into a place that feels hard to maintain.

i think there are a few things we can do to provide a solution that works

• maintain our own fork of gamecontrollerdb, and ship our db text files from there

  • right now we pull this in at build time, we could also allow updating the db file at runtime (opt in)
  • not quite sure how this would work in appimages but it's definitely something we can figure out, something as simple as "use a file that's a sibling to the appimage file if it exists, if it doesn't fall back to the file inside the appimage"
  • we could provide multiple db files - default to using the ones that our players use most commonly (mayflash adapters as n64 instead of snes for example) - but offer alternatives for people to try if their controller is showing up as the wrong thing - and with runtime switching (even if game restart is required)

  i think this could change the support flow from player my controller isn't working (turns out it's not in the db or has the same id as a different controller in the db) support: ask player to do the thing to make a mapping string and share it player: makes mapping string, gets it working in game after manually changing file, sometimes shares string back so it can be PRd to the db support: tries PRing string to upstream DB, maybe gets it accepted maybe doesn't

to

player: controller not working support: get mapping string from player, updates fork of db, any other players with the same controller can now just hit the update db button in game to get a db that works for them

closing thoughts

• maintain fork of db
• keep track of id conflicts, resolve them towards most commonly used controllers by players of soh
  • in the case of multiple controllers with the same id being used, have alternative db files with the alternative controller
  • if this gets overwhelming, we could even set up some scripting to generate the db files instead of having multiple giant text files checked in
• provide a way to pull updated db at runtime

[Malkierian]

My first thought would be to agree with downloading it at runtime, if it doesn't exist, in case people make modifications themselves, so they don't lose them.

[briaguya-ai]

I was thinking we still just ship one with the build, but have the option to pull a new one down at runtime

[Malkierian]

The problem is that we still tell people to extract everything, with good reason. But that means overwriting their GCDB, and if they made changes, needing to map again. Would be easier to download at runtime than to put "Don't extract your GCDB file if you added your own mapping" in the update instructions and trust that they'd read and understand that.

[Malkierian]

And there's no guarantee we'll get everyone who needed to map to submit their mapping strings.

[briaguya-ai]

the issue i have with not shipping one is that we'd then be requiring the game have network access (at least once) for controllers to work

[Malkierian]

Then how about we have the one it ships with in a different directory from where it ends up being used from, and if it's not present on a fresh install, we can just copy the one it shipped with?

[briaguya-ai]

Directory or name could possibly work

[Malkierian]

Or, maybe, we could have a dummy file in the main directory that goes unchanged except by the user, and load both that one and the shipped one, with the user one taking priority?

[briaguya-ai]

we'd need to look into how possible loading multiple files is but maybe