Forums » Suggestions
Add an option to disable chords and forced buttons on game pads.
After seeing a few people mention this, I think it should be an option. Why you may say? Can you just not bind these buttons manually? Well, with the chords, even binding them to NONE has strange effects when holding down two buttons that are usually chorded. For example, on my Moga, I have B bound to accelerate, and Y bound to turbo. Before the chords were available, I used to be able to hold down B to accelerate, and tap Y to turbo in small amounts during combat to fling rockets. If I do this while the ChordYB is bound to NONE, nothing happens. I have to actually release B before I press Y to tap turbo (I actually got around this by binding ChordYB to +turbo, but not everyone is a smartass like me). Disabling the chords altogether would be the preferred option.
There are a few buttons that are also forced that cannot be rebound manually without plugin help/config file editing. An example is the "select" button on my Moga (same with the back button on an xbox360 pad). Trying to rebind this button on the keyboard page simply takes me back to the previous menu (It didn't historically, but I cannot remember the update that changed this). Also on Android, in A mode, the B button is always "Quit" or "Open Menu" and cannot be rebound no matter what trickery I use. If I change it in my config files, the button then has two functions. It opens the menu AND does whatever I bound it to. I can get around this by setting the Moga to B mode, but seeing some forums posts and in game chatter, not all controllers have the HID mode setting.
Can we please have an option to treat gamepads just like joysticks, and even not be used for menu navigation? I know about the "force gamepad for UI navigation" option, but this does not disable chords or forced buttons. Especially on PC, since the gamepads get treated differently to joysticks, it can be a real pain to get things setup as I would like.
There are a few buttons that are also forced that cannot be rebound manually without plugin help/config file editing. An example is the "select" button on my Moga (same with the back button on an xbox360 pad). Trying to rebind this button on the keyboard page simply takes me back to the previous menu (It didn't historically, but I cannot remember the update that changed this). Also on Android, in A mode, the B button is always "Quit" or "Open Menu" and cannot be rebound no matter what trickery I use. If I change it in my config files, the button then has two functions. It opens the menu AND does whatever I bound it to. I can get around this by setting the Moga to B mode, but seeing some forums posts and in game chatter, not all controllers have the HID mode setting.
Can we please have an option to treat gamepads just like joysticks, and even not be used for menu navigation? I know about the "force gamepad for UI navigation" option, but this does not disable chords or forced buttons. Especially on PC, since the gamepads get treated differently to joysticks, it can be a real pain to get things setup as I would like.
+1, I have a gamepad I don't use for this reason. I mean, when you have a bajillion controllers it doesn't matter too much, but it is my only wireless gamepad, and sometimes id like to sit back past the wired limit.
I agree with all of this. We know our gamepad / joystick configuration stuff needs a big overhaul; we've "bolted on" a number of improvements lately, without really re-assessing how the entire system works.
As much as our stuff is at fault, there are also fundamental problems with the underlying platforms and APIs that we're trying to converge together into a single coherent model.
Like, Microsoft, for instance, used to have this thing called "DirectInput" that let you do all sorts of nice things with game controllers. Now, however, they've deprecated this (it still technically works for the moment, but it may get scrapped) in favor of this other thing called "Xinput" that's very Xbox-controller focused and practically makes advanced flight-sticks and other use cases into non-entities.
Similarly, Android has a console-style controller case, but fundamentally supports USB joysticks, which means you can even made wacky flightsticks work on Android. But then iOS only supports Gamepads That Apple Likes (because they decided to re-invent the gamepad, and make it different from every console game controller of the last 20 years, in their infinite wisdom), and will not support anything else ever.
So, we definitely need to allow proper disabling of chording and handling of other cases, but from a development perspective, it's also a mixed bag of a bunch of different.. concepts that we need to integrate and make work together in ways that are as-sensible-as-possible.
As much as our stuff is at fault, there are also fundamental problems with the underlying platforms and APIs that we're trying to converge together into a single coherent model.
Like, Microsoft, for instance, used to have this thing called "DirectInput" that let you do all sorts of nice things with game controllers. Now, however, they've deprecated this (it still technically works for the moment, but it may get scrapped) in favor of this other thing called "Xinput" that's very Xbox-controller focused and practically makes advanced flight-sticks and other use cases into non-entities.
Similarly, Android has a console-style controller case, but fundamentally supports USB joysticks, which means you can even made wacky flightsticks work on Android. But then iOS only supports Gamepads That Apple Likes (because they decided to re-invent the gamepad, and make it different from every console game controller of the last 20 years, in their infinite wisdom), and will not support anything else ever.
So, we definitely need to allow proper disabling of chording and handling of other cases, but from a development perspective, it's also a mixed bag of a bunch of different.. concepts that we need to integrate and make work together in ways that are as-sensible-as-possible.
Thank you for the reply Incarnate, and yes I understand all the different input API's can make things a little troublesome from a development view point. I guess because joysticks and gamepads did used to be treated the same by VO, I presumed that a simple toggle to change back to the way things were would be an ideal solution, but I guess I was only thinking about the Windows client when I considered that.
Oh, if only every OS used SDL right? As for dropping DirectInput, to be fair, most newer games for Windows have done the same and now require Xinput support, which is why projects such as x360ce exist; so if you do decide to drop DirectInput there will still be a way to use classic controllers under Windows anyway. As far as Apple goes, hmm, Think Differently, Think Broken.
Personally I have been able to work around most of the kinks that have popped up with the newer gamepad support (although I still have the odd issue on Android - like that back button), and do not mind sharing these tricks with others, but I do see more and more controller threads/comments in-game these days, hence this thread.
Oh, if only every OS used SDL right? As for dropping DirectInput, to be fair, most newer games for Windows have done the same and now require Xinput support, which is why projects such as x360ce exist; so if you do decide to drop DirectInput there will still be a way to use classic controllers under Windows anyway. As far as Apple goes, hmm, Think Differently, Think Broken.
Personally I have been able to work around most of the kinks that have popped up with the newer gamepad support (although I still have the odd issue on Android - like that back button), and do not mind sharing these tricks with others, but I do see more and more controller threads/comments in-game these days, hence this thread.
This should be to disable all of the fooling around VO does with our setups....not just dpads.