Kerbal Space Program

Doesn't work in 1.4.2 as well.

It's been more than a month, and this bug is preventing me from playing KSP. Has there been any movement?

You can play KSP with keyboard and mouse. Most of us do, so to say that it is "preventing" you from playing is an unfair assessment of the criticality of this bug.

We are exploring different solutions to this problem. It is not a simple fix, and possible workarounds are also being explored.

What would be helpful is to canvas which game controllers are being used. The make, model and even looking up your controller on the SDL_GameControllerDB to see if it is included would be highly useful. You can also contribute to the effort by submitting your own controller definitions to the project.

Steam does offer a partial solution via the Steam Controller support that extends to XBox One and PS4 compatible controllers, and some limited support for generic game controllers posing as a Steam Controller. Steam is a requirement for this however.

Issue #9679 is related for similar reasons concerning how the input device is named. Identifying the device in a consistent way has always been the problem, and compounded by the switch to SDL support only in Unity. First it must be detected via SDL, and then given an identifier. The Open Source Community are making some great gains with the database, but it is not complete, and is still not a robust system for maintaining a persistent identity on any given system.

Mine is "DragonRise Inc. PC TWIN SHOCK Gamepad" and is included in "GameControllerDB"

In KSP 1.3.1 is named "DragonRise Inc. Generic USB Joystick"

That is my settings in etc/environment
SDL_GAMECONTROLLERCONFIG="03000000790000000600000010010000,DragonRise Inc. Generic USB Joystick,a:b2,b:b1,back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,leftshoulder:b4,leftstick:b10,lefttrigger:b6,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b11,righttrigger:b7,rightx:a3,righty:a4,start:b9,x:b3,y:b0"

Mine is a "Logitech Extreme 3D Pro" and is included in the GameControllerDB under the name "Logitech Logitech Extreme 3D".

Mine is a custom one, a Teensy (Arduino compatible) device. It attaches over USB and looks like a HID joystick with several axes (3 rotation, 3 translation, 1 throttle) and several buttons.

The most valuable pieces of information in my situation are:

• I have an USB HID joystick
• Works under the Windows version
• Worked in the previous version
• Doesn't work with the current version
• It doesn't work with the current version in the same way other popular USB gamepads and joysticks don't work with it.

Because of this, it is highly likely that the problem exists for everybody trying to play KSP with gamepads or joysticks on Linux, and probably most of the custom controller builders are heavily affected.

Squelch wrote:

What would be helpful is to canvas which game controllers are being used.

----
Bus 001 Device 005: ID 0738:1302 Mad Catz, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0738 Mad Catz, Inc.
idProduct 0x1302
bcdDevice 1.33
iManufacturer 1 Mad Catz
iProduct 2 Mad Catz F.L.Y.5 Stick

/tmp/sdl-jstest-master/build $ ./sdl-jstest --list
Found 1 joystick(s)

Joystick Name: 'Mad Catz Mad Catz F.L.Y.5 Stick'
Joystick Number: 0
Number of Axes: 5
Number of Buttons: 14
Number of Hats: 1
Number of Balls: 0

/tmp/sdl-jstest-master/build $ ./sdl2-jstest --list
Found 1 joystick(s)

Joystick Name: 'Mad Catz Mad Catz F.L.Y.5 Stick'
Joystick GUID: 03000000380700000213000011010000
Joystick Number: 0
Number of Axes: 5
Number of Buttons: 14
Number of Hats: 1
Number of Balls: 0
GameController:
not a gamepad
----

This device also worked perfectly in previous KSP versions, and works currently in several other games I have tested it with.

Squelch wrote:

What would be helpful is to canvas which game controllers are being used.

ThrustMaster, Inc. T-Flight Hotas X Flight Stick was also working before. Its not the SDL database as far as I can see.

lsusb¶

lsusb -d 044f:b108 -v

Bus 006 Device 002: ID 044f:b108 ThrustMaster, Inc. T-Flight Hotas X Flight Stick
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x044f ThrustMaster, Inc.
  idProduct          0xb108 T-Flight Hotas X Flight Stick
  bcdDevice            1.00
  iManufacturer           1 
  iProduct                2 
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           34
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower               80mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.00
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength     182
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0018  1x 24 bytes
        bInterval              10

sdl-jstest¶

sdl-jstest -l
Found 1 joystick(s)

Joystick Name:     'Thrustmaster T.Flight Hotas X'
Joystick Number:    0
Number of Axes:     5
Number of Buttons: 12
Number of Hats:     1
Number of Balls:    0

sdl2-jstest¶

sdl2-jstest -l
Found 1 joystick(s)

Joystick Name:     'Thrustmaster T.Flight Hotas X'
Joystick GUID:     030000004f04000008b1000000010000
Joystick Number:    0
Number of Axes:     5
Number of Buttons: 12
Number of Hats:     1
Number of Balls:    0
GameController:
  not a gamepad

Same issue

./sdl-jstest --list
Found 1 joystick(s)

Joystick Name: 'Microsoft SideWinder Precision Pro'
Joystick Number: 0
Number of Axes: 4
Number of Buttons: 9
Number of Hats: 1
Number of Balls: 0

./sdl2-jstest --list
Found 1 joystick(s)

Joystick Name: 'Microsoft SideWinder Precision Pro'
Joystick GUID: 14000000070000000200000000010000
Joystick Number: 0
Number of Axes: 4
Number of Buttons: 9
Number of Hats: 1
Number of Balls: 0
GameController:
not a gamepad

Thrustmaster T-FLIGHT STICK X isn't working in KSP 1.4.3.2152 as well, on Ubuntu 16.04
It has been working with KSP 1.4.x on Windows and works with jstest-gtk on Ubuntu but not in the game on Ubuntu.

Well, I tried setting up my Logitech Extreme 3D Pro joystick in the Steam Controller settings, then loaded KSP 1.4.4 and went into settings. Configured the axes for flight, loaded a game, launched a stock plane, and my joystick pitch and yaw axes were changing the camera view instead of controlling the plane. No mention of any joystick config in the log that I can find, though there is one line:

[LOG 10:47:15.489] [KSPSteamController]: Loaded. Initializing hooks...

The settings dialog doesn't even seem to accept assignments for joystick axes. I note that my old "Joystick1Button*" settings still show up, when I attempt to set axes, they appear to be setting them to "joy0.*", which I assume is trying to use the Steam Controller API, but failing.

Just to add an update, following on from the previous one we continue to explore options with the changes that occurred with the Unity engine update and have generated a task in our backlog of work. We are unable to provide a date as to when that task may be prioritized at this stage.

Just to add an update, this is ridiculous. It's been 6 months, 1.5 is in the works, and the best you have is "We might think about fixing this at some undefined date in the future."
You might as well just close this with "Unity problem. Won't fix." In my experience, that does appear to be your general approach to such bugs.

Your "options" are to a) do nothing, and hope Unity fixes it in time for the next release. b) bypass Unity's broken input layer and use SDL directly, as AFBW does.
One of these actions fixes the problem. The other makes you look incompetent and / or lazy, while an open-source mod fixes the regression you introduced.

Does this work on the new update?

steve_v wrote:

Your "options" are to a) do nothing, and hope Unity fixes it in time for the next release. b) bypass Unity's broken input layer and use SDL directly, as AFBW does.
One of these actions fixes the problem. The other makes you look incompetent and / or lazy, while an open-source mod fixes the regression you introduced.

Really does it? Been searching your device on the SDL database, no matches.
But anyway, why complain so vehemently if AFBW solves your problem? What I'm getting from your rage is instead you can't use your device at all. So, you appear to contradict yourself.

Trying instead to be positive. You reported the problem started with KSP 1.4.0, and doesn't happen with other games; so it appears tied to Unity2017 (KSP migrated to that engine version with 1.4.0). Unity2017 was a major change in many many areas (which required a long effort to rewrite a good deal of KSP, so it took a long time and not all could be fixed as desired early on). Seems like Unity hasn't yet completed development of its new Input System (if you like, follow the discussion on https://forum.unity.com/threads/input-system-update.508660/ ). As often the case, features are first developed for Windows, then ported to Linux. It's unfortunate, as this means we need to wait for Unity to complete their part. Squad developers are real busy on other fronts, trying to develop a custom version of the Unity Input system to make it work for Linux would probably take longer than waiting Unity to fix it. Implementing in KSP a different solution (like AFBW does) isn't either a top priority, thanks to AFBW existence. And in both cases, a solution developed in-house will still probably have bugs or not work for all possible devices.
As you could notice, the issue is NOT being dismissed: the situation is kept under scrutiny and no option has been ruled out. Certainly very different than the "do nothing, wait for Unity to fix" conclusion you implied.

Still a problem in 1.5.1. If there's any more information we can provide to help the investigation of this bug, please let us know. I would really like to play with the Making History DLC, which I have paid for twice. AFBW is not a solution; it makes absolutely no difference (or maybe I just don't know enough to be able to use it properly).

1.6 is imminent, and I note this is still "Investigating". Should we not be hopeful for a fix in the next release? To support this game, I've bought it twice for myself and once for a friend, and I've paid twice for the DLC expansion which I can't effectively use thanks to this bug. Fix it in 1.6 and I'll buy two more copies for friends.

diomedea wrote:

Really does it? Been searching your device on the SDL database, no matches.

Mapping a HOTAS flightstick to xbox controller buttons and axes does not solve the underlying problem, and my device works perfectly without this nonsense in every other application.
The database is not the problem, your game engine is.
The SDL joystick API is actually not that complicated, and can indeed be used without lobotomising the device down to the level of a gamepad. If you need a tutorial on using it properly, I can probably whip something up.

Masquerading our joysticks as xbox controllers is not an acceptable solution anyway, even if it worked. It does not, so why mention it?

diomedea wrote:

But anyway, why complain so vehemently if AFBW solves your problem?

Because you are shipping serious regressions and expecting the community to clean up after you?
Or perhaps because rather than owning a problem you introduced, you are suggesting that "the Linux community" is just being lax in populating some irrelevant database?
Your pick, either will cause me to "complain vehemently".

diomedea wrote:

Trying instead to be positive. You reported the problem started with KSP 1.4.0, and doesn't happen with other games; so it appears tied to Unity2017 (KSP migrated to that engine version with 1.4.0). Unity2017 was a major change in many many areas (which required a long effort to rewrite a good deal of KSP, so it took a long time and not all could be fixed as desired early on). Seems like Unity hasn't yet completed development of its new Input System (if you like, follow the discussion on https://forum.unity.com/threads/input-system-update.508660/ ). As often the case, features are first developed for Windows, then ported to Linux. It's unfortunate, as this means we need to wait for Unity to complete their part. Squad developers are real busy on other fronts, trying to develop a custom version of the Unity Input system to make it work for Linux would probably take longer than waiting Unity to fix it. Implementing in KSP a different solution (like AFBW does) isn't either a top priority, thanks to AFBW existence. And in both cases, a solution developed in-house will still probably have bugs or not work for all possible devices.
As you could notice, the issue is NOT being dismissed: the situation is kept under scrutiny and no option has been ruled out. Certainly very different than the "do nothing, wait for Unity to fix" conclusion you implied.

Hang on:
"...wait for Unity to complete their part."
"...do nothing, wait for Unity to fix"

Looks mighty similar to me, except now you're "keeping it under scrutiny" too.
Not fixing mind, just looking intently at it. Because regressions spontaneously fix themselves when observed, right?

For the record, I am entirely aware of the ongoing changes to Unity's input stack. I'm pretty sure everyone affected by this is aware of how and when Unity broke it by this point.

Again, AFBW fixes the problem and the relevant source code is freely available. Why has it not been implemented in your product yet?

Also for the record, it's still broken in 1.6. That scrutiny sure is working wonders for my motivation to purchase DLC.

AFBW DOES NOT FIX THE PROBLEM!

politas wrote:

AFBW DOES NOT FIX THE PROBLEM!

Fix the problem with Unity, no.
Make Joysticks work in KSP, sure does, at least over here.

Well, if you have a link to some documentation that might help me get AFBW working, I'd appreciate it. My experience is that it makes not a bit of difference.

politas wrote:

Well, if you have a link to some documentation that might help me get AFBW working, I'd appreciate it.

It works fine for me in both 1.4.5 & 1.5.0, on Gentoo amd64. I have not tested it on 1.6, as it is not officially compatible yet.
The place to ask about problems with AFBW is the AFBW thread on the forums.
I am not particularly familiar with the internals of the mod myself, but if you provide the relevant information there I'm sure I or somebody else will assist.

Just loaded AFBW in 1.6.1 and it actually worked perfectly for me for the first time. Yay! I can use Making History!

This is more than a year old. Is there any movement on this bug?

I'm building a specialized controller for use with KSP - an industrial joystick, a USB-enabled microcontroller and some other parts. The joystick is now detected as a generic USB HID Joystick by the kernel and the appropriate /dev/input/eventX file is created. I can watch the axis values change as the joystick is moved using evtest.

I expected KSP (I'm running v1.7.0) to pick up any available standard joysticks (of course). I didn't expect this to be a problem, so my testing during development only reached as far as making sure the device was correctly detected by the kernel. Imagine my disappointment when I realise that KSP simply doesn't support joysticks! Who would have thought?!

• Did you (the KSP developers) report this bug (I guess you can call it a bug: a game engine that doesn't support joysticks!) upstream, to Unity? Can we get a link to the corresponding Unity issue? (If you do report this, please request support through the modern, generic HID device event system, not the deprecated joydev system). Thanks!

• Are gamepads supposed to work with KSP? I tried changing my device's USB descriptor so that it is detected as a USB HID Gamepad, but still no dice... (KSP is run as a member of the input group and can access the event file in question, so it should not be a file permission problem.)

Any ideas are welcome.

More info:

Controller buttons do work - I can use my controller's Stage button in-game. But no reaction from Yaw/Pitch/Roll controls.

I have also rebuilt my device firmware to remove periods in the device name, but it makes no difference.

Relevant parts from settings.cfg:

LAUNCH_STAGES
{
        primary = Space
        secondary = JoystickButton0
        group = 0
        modeMask = 1
        modeMaskSec = -1
}
...
AXIS_PITCH
{
        PRIMARY
        {
                name = Kerbin Sticks LTD Rocket Poker v2
                axis = 0
                inv = False
                sensitivity = 0.25
                deadzone = 0
                scale = 1
                group = 0
                modeMask = -3
        }
        ...
}

SDL_GAMECONTROLLERCONFIG="03000000472000001003000001010000,Kerbin Sticks LTD Rocket Poker v2,platform:Linux,a:b0,leftx:a0,lefty:a1~,rightx:a2," ./KSP.x86_64

I also tried running both SDL2's controllermap program and KSP with LC_ALL=C (reassigning the axes in KSP). Did not solve the issue.

Oh, and all this is with a clean install of KSP 1.7.0. No mods.

The axis that is saved as "Kerbin Sticks LTD Rocket Poker v2" axis 0 in settings.cfg above is displayed as Current Assignment: Joy0.1 in the Settings/Input editor in KSP. Maybe this mismatch has something to do with the problem?

The button, which works, is displayed as JoystickButton0 in both settings.cfg and the Settings/Input editor.

steve_v wrote:

I doubt it will make a lick of difference though, we've already seen SQUADs attitude on this one.

Yeah, I know. This is a real shame, because it appears that action axis will be added into the new DLC, which will a) almost certainly do something nasty to ABFW, and b) will mean that there is now a set of features I cannot access.

I love this game, but when the main selling point of what is effectively a $15 mod pack is "it is maintained by Squad", but Squad does not maintain Linux support, I cannot justify dishing out the money.

Even a stressed Debian maintainer style "upstream, wontfix" would be nice, so that we could raise this with Unity, but for all we know, Bill Gates could be personally deleting the axis inputs.

TL;DR: what can we do?

Just to point out, the last closed Linux-specific issue that was marked non-new (i.e. Squad even looked at it) was in January, and was a l10n issue. The last closed bug was in March of last year. =(

Target version 1.8.0? Seems a bit late for that release.

politas wrote:

Target version 1.8.0? Seems a bit late for that release.

1.8.0 was released after the last comment and included a fix for Joysticks on Linux. Tis why this was set to RTT with the version of the fix in target release

Not sure what you're saying exactly. We have 1.9.1 out now. Should we be testing that release, or 1.8.0 (which was released far more than 4 days ago)

Tested under 1.9.1, 1.8.1, and 1.8.0. Joystick axes can be set and work as expected.

Thank you very much <3