DCurrent
[Feature Request] Bring back Plombo's controller code
Is your feature request related to a problem? Please describe. Please read this thread.
Basically, for Linux-based retro consoles with no keyboard that comes with a builtin XBox360-type controller, without Plombo's code there is no way to map the controller.
Describe the solution you'd like Apparently, that code auto-maps the XBox360 controller when a game starts.
Describe alternatives you've considered Creating a default.cfg file in Linux and copy+paste it to the console.
I'm sorry friend, that code broke things left and right, a lot of the changes in it are outside the staff expertise, and @Plombo hasn't been a regular presence for years. We are working slowly toward support for various controller schemes, but bringing back those updates whole hog is out of the question.
I thought I fixed the problems with it last year, and until last week, I thought it was currently merged. What was still broken about it? I would like to fix whatever the problems are and bring it back.
As a workaround, I made the controllers work: https://github.com/DCurrent/openbor/issues/292#issuecomment-3529823101
@Plombo's solution was perfect for retro consoles, since they don't have keyboards, but a workaround is to generate the .cfg file from a similar OS distro. In my case, I managed to make the xbox360 controller work on WSL2 and from there I opened any game and set the mapping for the gamepad, then saved as default.cfg.
Next, I copy that file to the Saves folder in the target platform (in my case, TSP retro console), renamed it for whatever game, and it worked!
So, while Plombo's code is not back, maybe you could add a commandline parameter, like -automapgamepad, and when a controller like a xbox360 is found, you could automap buttons and pads with default values for the game.
And when Plombo's code is back, maybe you can integrate it as an option, with say, -altcontroller, and when not present, it uses the currently default method.
So, the TL;DR explanation for the route I'm following now is: everytime the emulator is executed for a game, the default.cfg is copy+paste+renamed for that game before launching. So OpenBOR will see that .cfg file exists and won't generate a new one. It will load it successfully for the game, and presto!
No, wait. There's no need. OpenBOR does automatically use default.cfg to generate the corresponding .cfg file for each game. Nice!
I thought I fixed the problems with it last year, and until last week, I thought it was currently merged. What was still broken about it? I would like to fix whatever the problems are and bring it back.
To be perfectly honest, I don't even remember the details because it's going on two years now. I'd have to go digging through posts and reports. @fgames9000 might recall better than I. They were mission critical breaks though, and since you weren't here, I had no choice but revert them out of the source. Last couple of times you showed up, you promptly disappeared immediately after - I've said this many times, that's not a knock on you and you don't owe us anything. It is however a reality I have to plan on. If you are really interested sticking around and having a look, I will reopen the issue and tag people currently involved.
@msmalik681 @fgames9000 @dbaldan
Auto configuring controllers is a very nice feature to have most modern games support it.
I thought I fixed the problems with it last year, and until last week, I thought it was currently merged. What was still broken about it? I would like to fix whatever the problems are and bring it back.
To be perfectly honest, I don't even remember the details because it's going on two years now. I'd have to go digging through posts and reports. @fgames9000 might recall better than I. They were mission critical breaks though, and since you weren't here, I had no choice but revert them out of the source. Last couple of times you showed up, you promptly disappeared immediately after - I've said this many times, that's not a knock on you and you don't owe us anything. It is however a reality I have to plan on. If you are really interested sticking around and having a look, I will reopen the issue and tag people currently involved.
Based on what I remember, the first version of the new "input_rework" code was causing some crashes due to a few "assert" issues, in all builds.
Later, the second version called "input_rework_revival" worked fine in the Windows build (I didn't test the Linux build), but was not merged in the main source due to a few issues in the Android build when remapping keys. I tested and reported it in the forum.
However, based on Ultrahead's report, he is talking about the first version (not the second one) which remained active in the main source for a short time before the removal.
