Kerbal Space Program

Note: Running the latest Steam Beta client

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

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 ?

Does it work without using Steam big picture mode? I.e with KSP and the Steam controller on your computer directly.

Nope

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.

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.

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. :-)

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 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.

JLSalvador wrote:

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.

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 :)

lilphil wrote:

JLSalvador wrote:

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.

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 :)

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.

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

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

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.

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

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?