Bug #5996
Game is unplayable with Steam Controller since update that officially supports it.
0%
Description
Description:
[Context:] Squad recently released an update to make KSP compatible with the Steam Controller. The relevant change is the game should now detect what mode it is in (Menu, Flight, Docking, etc.) and change the button/keyboard bindings appropriately.
Unfortunately it seems no matter what scenario the game is in, the Controller configuration stays in Menu mode, making it impossible to move the ship around, increase/decrease throttle, stage, etc.
I have tested this on two different systems both fully updated, with the Steam Controller otherwise working fine for other titles.
Both machines are running Arch x64 with open-source ATI drivers.
Steam Controller firmware is up to date.
One other user on reddit reports the same issue on Linux Mint.
Steps to reproduce:
1. On Linux, run Steam in Big Picture mode
2. Select KSP and configure the controller to use Squad's official bindings
3. Launch KSP
4. Proceed to an in-flight mission or launch
5. Notice the keybindings do not change from Menu mode to the relevant mode
Expected behavior:
Steam Controller bindings switch to the relevant mode for the game state (ie. flight, docking, etc.)
Current behavior:
Keybindings stay in Menu mode making gameplay with the Steam Controller impossible.
Additional information:
I tried turning on the Steam Controller on-screen HUD, apparently it is supposed to show a popup indicating the keybinding mode has changed but this is not the case; it only shows the keyboard binded key associated with the last button press.
History
#1
Updated by geosmin over 8 years ago
Updated by Note: Running the latest Steam Beta client
#2
Updated by sal_vager over 8 years ago
Updated by - Severity changed from High to Low
hi geosmin, thanks for the report but can you also provide your Player.log, it may show any error messages thrown by the Steam controller.
You can find it in the hidden .config/unity3d/Squad/Kerbal Space Program/ folder
Also, as this is not an issue that breaks the game I am adjusting the priority as per the guide
High Game Breaking Game crashes when transitioning SoI
Normal Game Affecting, but not Game Breaking. SAS is draining electricCharge incorrectly.
Low Visual issue that occurs often, or Gameplay issue that can be avoided. Landing Strip has texture artifacts.
If you can figure out a way to make the controller change modes that would be very useful info to know until this can be fixed.
#3
Updated by geosmin over 8 years ago
- File Player.log Player.log added
Sure thing, I've attached it.
Apologies for not checking out the guide before setting priority. That said, as per those guidelines shouldn't the issue be Normal priority? It's an entire new feature that's broken. Closer to "Game Affecting, but not Game Breaking" than something like a "Gameplay issue that can be avoided"; it isn't avoidable within the context of the feature (Steam Controller support). If your browse SteamOS and Steam Big Picture's library listing for KSP there's a big "Steam Controller Support!" banner, considering that once the game is launched within that setting (Couch, controller) it completely fails to work I'd argue it isn't a low priority issue.
I'll let you be the judge, cheers.
#4
Updated by sal_vager over 8 years ago
- Severity changed from Low to Normal
Hmmm I assumed you could just use another controller, but this may be an issue when using a Steam box as the player would expect to use the official controller.
Technically it's external to KSP but I do see what you mean, I'll change it to "Normal" and leave it to the devs to change it if they see fit.
The only thing in the log that looks (to me) to be related is this.
Fallback handler could not load library /home/user/.local/share/Steam/SteamApps/common/Kerbal Space Program/KSP_Data/Mono/x86_64/CSteamworks
It's a guess but the plugin may not be loading correctly.
#5
Updated by HarvesteR over 8 years ago
Updated by - Assignee set to HarvesteR
That line there tells the whole story. The plugin couldn't find the Steam API libraries it needed, so it failed to start.
The good news is that this can be fixed 'at home'. The libraries are all there, but they might not be located in the right folder.
The steam api is a native library, which means it's different for each platform. On windows they're .dll files, on OSX they're an app bundle, on Linux they're .so files. Each one has its own particular setup requirements (fun, isn't it?) So, usually, libraries for an application should live in the same folder as the executable that uses them, assuming the application isn't looking for them anywhere else. In this case, the libraries are in the root folder, along with KSP.exe. However, this didn't quite work, and some files needed to be moved up to GameData/Squad/Plugins. That's the entry point for the plugin dll, and it seems library paths can be local to that.
On Windows, the CSteamworks.dll file (the native binder to steam_api.dll) had to be moved to to the plugin folder. On OSX, the CSteamworks.dll.config file had to be moved (not the binder itself, but the linkage that hooks it to the app, or something like that)
On Linux then, I reckon either the libCSteamworks.so or the libsteam_api.so files (most likely the former, and only that one) needs to be moved to GameData/Squad/Plugins/
so, TL;DR version:
Try moving the libCSteamworks.so file to GameData/Squad/Plugins/It should work if it can find the files it needs.
Let me know if that does the trick, so I can update the plugin deployment setup and fix it for everyone.
#6
Updated by geosmin over 8 years ago
- File Player.log Player.log added
Still no dice, unfortunately.
Copied /home/user/.local/share/Steam/SteamApps/common/Kerbal Space Program/libCSteamworks.so to /home/user/.local/share/Steam/SteamApps/common/Kerbal Space Program/GameData/Squad/Plugins/libCSteamworks.so
That didn't work so I then copied /home/user/.local/share/Steam/SteamApps/common/Kerbal Space Program/libsteam_api.so to /home/alwi/.local/share/Steam/SteamApps/common/Kerbal Space Program/GameData/Squad/Plugins/libsteam_api.so
You did mention moving the files, not copying them, so I tried deleting the original files. As expected though that didn't work either.
I've attached Player.log again (448KB is the new one). Let me know if there's anything more I can do.
#7
Updated by geosmin over 8 years ago
You mentioned the libraries are .dll on Windows and .so on Linux, so is it normal that the only files originally in the Plugins directory were:
KSPSteamCtrlr.dll Steamworks.NET.dll Steamworks.NET.dll.config
#8
Updated by sal_vager over 8 years ago
Just a thought, KSP is looking in /home/user/.local/share/Steam/SteamApps/common/Kerbal Space Program/KSP_Data/Mono/x86_64/ so why not copy them there ?
#9
Updated by geosmin over 8 years ago
- File Player.log Player.log added
Just tried, still not working.
#10
Updated by sal_vager over 8 years ago
Does it work without using Steam big picture mode? I.e with KSP and the Steam controller on your computer directly.
#11
Updated by geosmin over 8 years ago
Nope
#12
Updated by JLSalvador over 8 years ago
Updated by HarvesteR wrote:
That line there tells the whole story. The plugin couldn't find the Steam API libraries it needed, so it failed to start.
The good news is that this can be fixed 'at home'. The libraries are all there, but they might not be located in the right folder.
The steam api is a native library, which means it's different for each platform. On windows they're .dll files, on OSX they're an app bundle, on Linux they're .so files. Each one has its own particular setup requirements (fun, isn't it?) So, usually, libraries for an application should live in the same folder as the executable that uses them, assuming the application isn't looking for them anywhere else. In this case, the libraries are in the root folder, along with KSP.exe. However, this didn't quite work, and some files needed to be moved up to GameData/Squad/Plugins. That's the entry point for the plugin dll, and it seems library paths can be local to that.
On Windows, the CSteamworks.dll file (the native binder to steam_api.dll) had to be moved to to the plugin folder. On OSX, the CSteamworks.dll.config file had to be moved (not the binder itself, but the linkage that hooks it to the app, or something like that)
On Linux then, I reckon either the libCSteamworks.so or the libsteam_api.so files (most likely the former, and only that one) needs to be moved to GameData/Squad/Plugins/
so, TL;DR version:
Try moving the libCSteamworks.so file to GameData/Squad/Plugins/
It should work if it can find the files it needs.
Let me know if that does the trick, so I can update the plugin deployment setup and fix it for everyone.
@HarvesteR, that's not correct. The correct path to put the files is "KSP_Data/Mono/x86_64/".
So...
cp libsteam_api.so libCSteamworks.so KSP_Data/Mono/x86_64/
Remember that you need the 32 bits library in the x86 path (actually the libsteam_api.so and libCSteamworks.so from KSP it's 64 bits only). HarvesteR needs to compile the proper 32 bits and copy to KSP_Data/Mono/x86/
Launched through Steam Big Picture with the command line LC_ALL=C %command%_64 and running perfectly.
#13
Updated by HarvesteR over 8 years ago
- Status changed from New to Being Worked On
- % Done changed from 0 to 30
That's great info. The documentation for how to install the steamworks bindings were rather lacking in this area... I tried to make as much sense of it as I could, but there were some pretty ambiguous directions there.
Knowing what the proper file setup for the native libs should be makes all the difference. I'll set it up so it deploys like that from now on.
#14
Updated by HarvesteR over 8 years ago
Ok, I've found the x86 native libs here (they did come with the bindings), and set up the deployment pipeline, so they now deploy like this (relative to the KSP install directory):
0 KSP_Data\Mono\x86 208,408 KSP_Data\Mono\x86\libCSteamworks.so 202,648 KSP_Data\Mono\x86\libsteam_api.so 0 KSP_Data\Mono\x86_64 209,568 KSP_Data\Mono\x86_64\libCSteamworks.so 193,919 KSP_Data\Mono\x86_64\libsteam_api.so
hopefully this should work now.
#15
Updated by JLSalvador over 8 years ago
HarvesteR wrote:
Ok, I've found the x86 native libs here (they did come with the bindings), and set up the deployment pipeline, so they now deploy like this (relative to the KSP install directory):
[...]
hopefully this should work now.
Thank you so much @HarvesteR. I really appreciate each forward steps for the Linux version becomes better. :-)
#16
Updated by lilphil over 8 years ago
Updated by HarvesteR wrote:
Ok, I've found the x86 native libs here (they did come with the bindings), and set up the deployment pipeline, so they now deploy like this (relative to the KSP install directory):
[...]
hopefully this should work now.
Thanks for looking into this HarvesteR. Is this still possible to 'fix at home'? I have tried putting libCSteamworks.so into KSP_Data\Mono\x86_64, however my logs still state could not load CSteamworks. Are there additional steps? The logs show it looking in this folder.
#17
Updated by JLSalvador over 8 years ago
lilphil wrote:
HarvesteR wrote:
Ok, I've found the x86 native libs here (they did come with the bindings), and set up the deployment pipeline, so they now deploy like this (relative to the KSP install directory):
[...]
hopefully this should work now.
Thanks for looking into this HarvesteR. Is this still possible to 'fix at home'? I have tried putting libCSteamworks.so into KSP_Data\Mono\x86_64, however my logs still state could not load CSteamworks. Are there additional steps? The logs show it looking in this folder.
lilphil, you need to launch the KSP.x86_64 (and copy the libs in the KSP_Data\Mono\x86_64 path) because the current Steamworks that KSP shipped it's the 64 bits version. Or wait for HarvesteR to publish both versions with the correct path.
#18
Updated by lilphil over 8 years ago
JLSalvador wrote:
lilphil, you need to launch the
KSP.x86_64(and copy the libs in theKSP_Data\Mono\x86_64path) because the current Steamworks that KSP shipped it's the 64 bits version. Or wait for HarvesteR to publish both versions with the correct path.
Thanks, although this doesnt seem to work for me. I've tried setting launch options to KSP.x86_64, and launching this binary directly. The logs seem to show that its looking in KSP_Data\Mono\x86_64 so not sure why it can't find it. I guess I'll just have to wait for an update :)
#19
Updated by Enroy over 8 years ago
Updated by lilphil wrote:
JLSalvador wrote:
lilphil, you need to launch the
KSP.x86_64(and copy the libs in theKSP_Data\Mono\x86_64path) because the current Steamworks that KSP shipped it's the 64 bits version. Or wait for HarvesteR to publish both versions with the correct path.Thanks, although this doesnt seem to work for me. I've tried setting launch options to KSP.x86_64, and launching this binary directly. The logs seem to show that its looking in
KSP_Data\Mono\x86_64so not sure why it can't find it. I guess I'll just have to wait for an update :)
Did the same steps and no success. Should not have updated Steam 'cause now I can no longer play KSP :D
Edit: was able to downgrade Steam on Ubuntu (to 1.0.0.48 instead of 1.0.0.51) and it works fine now. So for now that'll do.
#20
Updated by lilphil over 8 years ago
lilphil wrote:
I guess I'll just have to wait for an update :)
So I got bored waiting and tried some more things. I removed all the steamworks and steam api libraries from KSP, copied them from MiniMetro, moved them round loads and ended up with it working. I'm not entirely sure which bits I've changed now so hopefully the below md5sums and locations will help:
$ find . \( -name libCSteamworks.so -or -name libsteam_api.so \) -exec md5sum {} \;
4f78d760ff281c554ea115cf0dbd5ff8 ./libCSteamworks.so
9276fb4be8a29e6b63323a78b8d79788 ./libsteam_api.so
4f44163ab4c6b5242afbadb3ad875fa9 ./KSP_Data/Mono/x86_64/libCSteamworks.so
211b61dc7b0772a4a8423021654c0c7a ./KSP_Data/Mono/x86_64/libsteam_api.so
4f78d760ff281c554ea115cf0dbd5ff8 ./KSP_Data/Mono/x86/libCSteamworks.so
9276fb4be8a29e6b63323a78b8d79788 ./KSP_Data/Mono/x86/libsteam_api.so
#21
Updated by minego about 8 years ago
Updated by I copied libCSteamworks.so and libsteam_api.so to the KSP_Data/Mono/x86_64 directory, and now it appears to load, but I'm not actually able to change the bindings. In the game it shows me in the bottom left what mode it is in, and the log shows it working.
The log shows this:
[ERR 12:28:43.904] [KSPSteamController]: Action set handle for MenuControls has &0. That's probably not right. [ERR 12:28:43.904] [KSPSteamController]: Action set handle for FlightControls has &0. That's probably not right. [ERR 12:28:43.904] [KSPSteamController]: Action set handle for DockingControls has &0. That's probably not right. [ERR 12:28:43.904] [KSPSteamController]: Action set handle for EditorControls has &0. That's probably not right. [ERR 12:28:43.904] [KSPSteamController]: Action set handle for MapControls has &0. That's probably not right. [LOG 12:28:44.916] [KSPSteamController]: Controller connected
#22
Updated by minego about 8 years ago
- File Player.log Player.log added
Here is my Player.log that has the errors from my previous post. I get this when trying to use a community binding configuration that has the different sections. If I try to use Squad's official bindings then those sections don't show up.
I actually purchased the game again in hopes of getting this working since I had the non-steam version. I'm really looking forward to getting this to work.
#23
Updated by minego about 8 years ago
- File Player.log Player.log added
Here is my Player.log after installing the 1.1 pre-release build.
#24
Updated by Squelch about 8 years ago
Updated by minego wrote:
Here is my Player.log after installing the 1.1 pre-release build.
Please can you report this on the Pre-Release tracker for 1.1? Thanks.
#25
Updated by minego about 8 years ago
Squelch wrote:
Please can you report this on the Pre-Release tracker for 1.1? Thanks.
Done. http://bugs.kerbalspaceprogram.com/issues/8144
Thank you
#26
Updated by TriggerAu almost 8 years ago
Updated by - Status changed from Being Worked On to Needs Clarification
- % Done changed from 30 to 0
#27
Updated by Beale over 7 years ago
Updated by #28
Updated by cabanur almost 7 years ago
Updated by This hasn't seen any activity in some time, but It's still an issue.
As of pre-relase 1.2.9.1800 (LinuxPlayer)-pre the game will correctly switch modes when appropiate, but analog controls (like pitch, yaw and roll, asigned by default to the joystick and analog triggers) will act on a binary basis (on/off) instead of progressively as expected.
Is there anything I can do to help debug this?