Controller Woes

[Christoph Lipka]

Currently, KSP has several serious problems in controller-heavy set-ups:

1. Only a subset of controller buttons is supported.

Game controllers can have as many as 32 buttons plus an 8-way hat switch, as exemplified by the Thrustmaster HOTAS Warthog throttle. However, KSP only supports the first 20 buttons of any controller. (Also, it does not support any of the 8-way hat switches on any of my controllers, though I am not sure whether this is due to the 20-button limit or whether KSP doesn't support 8-way hat switches at all.)

2. Controller #0 buttons are treated special.

Any function assigned one of the buttons of controller #0 ("JoystickButtonN") will also respond to the corresponding button of any other controller ("JoystickXButtonN"), making the buttons of controller #0 pretty useless in any multi-controller set-up.

3. Controller button assignments are unstable.

For the sake of button mappings, KSP identifies the controllers by a numeric ID (as opposed to the controller name, as appears to be the case for axes), which is assigned by Windows in an arbitrary fashion at each system start-up and may be subject to change, even if the set-up is left entirely unchanged. Disconnecting and reconnecting a controller, or a hub with multiple controllers connected, may also mess up the ID assignment. This makes controller-heavy set-ups in KSP a PITA to use, as every once in a while the buttons will fail to work as expected due to a change in the controller IDs.

4. Not all essential functionality can be mapped to game controllers.

For controller-heavy set-ups It would be desirable that all essential in-flight operations can be performed without having to reach for the mouse (or the keyboard for that matter). However, one functionality that I deem essential, namely activating flight controls (including bringing up the artificial horizon) while in map mode, currently seems to be only possible by using the mouse.

5. Primary and secondary axis mappings do not mix well.

Primary and secondary axis mappings currently work on a "highest amplitude wins" basis. Although this is good enough for cases where you might want to use one controller at some time and another controller at some other time, adding the amplitudes would work just as well for those cases, while at the same time improving the use of the secondary mapping as a trim input (e.g. using a joystick for pitch control and a slider for pitch trim). As it is now, using the secondary axis as trim input has the negative side effect of introducing a variable deadzone to the primary control input.

Can we expect the above to be fixed in 1.1?

Edit:

I might add that I'm currently using a combo of 5 game controllers, integrated into a homebrew cockpit (originally designed for a different game, but it also works ok for KSP, but it would work a lot better if the aforementioned issues didn't get into the way):

• a Thrustmaster HOTAS Warthog joystick (19 buttons + one 8-way hat switch + 2 axes)
• a Thrustmaster HOTAS Warthog throttle (32 buttons + one 8-way hat switch + 5 axes)
• a Saitek Pro Flight rudder pedal set (3 axes)
• a custom switch panel hooked to a JoyWarrior24GP32 generic controller IC (up to 32 buttons + 2 axes synthesized from a 4-switch array)
• two gamepad-style mini-joysticks hooked to a JoyWarrior24A8L generic controller IC (up to 16 buttons + 4 axes)

I'm running Windows.

Edited March 27, 2016 by Christoph Lipka
Added information about my set-up.

[SMILIE]

I'm also struggling with #1 and #3 a lot. I have a self built console with lots of buttons which also registers as joystick and I can only use the first 20 Buttons as you said and I have to remap them on every PC reboot because they always switch positions in the config... even if I manually edit the ids in the config file this doesn't help.

So the Unity 5 update didn't help anything...