The Linux compatibility thread!

[Eleven]

0.24.2 doesn't run at all for me. Segmentation Fault. I get that with the stock version, and after applying the offsets. I've never had the binary NOT run at all

(EDIT) Ok, not sure what happened but I rebooted and tried again and it worked like normal...wierd

Edited July 26, 2014 by Eleven

[Voidi]

Also.. I ran into a weird thing.. If I right click on my desktop and create a launcher to run KSP RealSolarSystem will NOT work at all. If I double click the executable in a file manager then RealSolarSystem does work.

What is happening when launching the game via a desktop icon Vs running it from a file manager that is causing that?

Desktop Enviroments are somewhat picky about the path in Desktopfiles. Be sure to specify the full path in the Exec-key, and Quote if some special characters (all other then normal Alphanumeric chars) occur.

[styckx]

Thanks Voidi..

Anyone figure out a way to get numberpad keys working? Using the numbers on the normal row is ok but it is a nightmare with craft with action groups.

[ahbahlut]

EDIT :

LC_ALL=C ./KSP.x86_64

Solves my problem !

Hi,

I've got a problem with my KSP. I can't launch the game, it's stop loading at Squad/Spaces/mk1PodCockpit/model

It's a fresh install of KSP from Steam on my Laptop with Ubuntu 14.04. I've tried to start KSP from Steam and i've also tried to start from the bin file KSP.x86_64 that's the same.

I've tried to delete the local content nothing change.

There is the KSP.log : http://pastebin.com/61K2Hf6k

Thanks for helping

PS : Sorry for my poor english...

Edited July 29, 2014 by ahbahlut

[sal_vager]

styckx, does KSP not register the numpad keys when you use them in the controls screen?

[styckx]

styckx, does KSP not register the numpad keys when you use them in the controls screen?

Yeah, the numpad numbers don't work at all. Like entering numbers in a mechjeb field etc, or even in the name field when saving a craft. Numbers from the numpad just don't register a single thing (yes numlock is on and they do work in other applications).

Again, we're forced to use the number keys on the main keyboard which are usually tied to action groups which makes things interesting sometimes.

[Kaa253]

@styckx. As I posted in the bug thread. In the KSP input settings control you can assign the numpad keys to your action keys. This in effect swaps the alpha-pad keys with the numpad keys with respect to the way they should be set up. I am finding it difficult to re-train myself to initiate actions on the numpad and enter numbers into MechJeb etc., with the alpha keys, but at least (if I remember) it fixes the problem of actioning staging events whenever I want to type a new value into a MechJeb window.

In truth, I really wish this bug could be addressed soon by a hot-fix.

[Dunbaratu]

I don't know if this has been mentioned yet or not (I am *not* reading through 106 pages to find out, and a text search of the thread didn't seem to find anything mentioning it). This may be important for people to writing mods trying to support Linux to know.

In the kOS mod, some users discovered that the RETURN key wasn't being read by kOS on Linux (pressing RETURN after typing a command is essential for the mod to be usable at all so it effectively blocked all linux users from using it).

We've squashed the bug now, but it turns out to have been due to the Linux build of Unity itself, and we had to make an ugly work-around to deal with it.

That Unity bug is this:

- The correct unicode character for carriage return is 0x000d.

- But on Linux, when you call Event.current.character, it returns 0xff0d for carriage return.

I think it may be related to control characters in general, because some people were having the same problem with the tab key, and it seemed to be giving a unicode of 0xff08 instead of the correct 0x0008.

However, it's not a universal problem with all the low unicode characters (the ascii part of unicode) - only a few special control characters were being padded with 0xff instead of 0x00. Most characters are being padded with 0x00 correctly.

Anyway, the workaround we used was to funnel all uses of Event.current.character through a function that looks for when the high byte of the unicode is 0xff, and if it is it turns it into 0x00 instead. There's *hopefully* no keyboards out there that actually use the unicode characters in the range 0xff00 through 0xffff so this should be okay.

I posted about the problem over on the Unity forums and it seems to definitely be a bug in Unity. It's not supposed to be doing this.

[sal_vager]

Yeah, the numpad numbers don't work at all. Like entering numbers in a mechjeb field etc, or even in the name field when saving a craft. Numbers from the numpad just don't register a single thing (yes numlock is on and they do work in other applications).

Again, we're forced to use the number keys on the main keyboard which are usually tied to action groups which makes things interesting sometimes.

Okay I can understand them not working properly in addons, and they use different scancodes to the keyboard number keys so KSP is probably not set up to use them.

But, I can use my numpad to move the camera when numlock is off, though like you I can't use it to input numbers.

I can use the numpad in the settings screen, again with numlock off, and KSP detects it just fine (it just says numlock if numlock is on) so it can be mapped and used to an extent.

Unity seems not to be seeing the numpad numbers as being numbers, but the arrows and pageup, pagedown and the rest are working.

[Remogeus]

So, I have some kind of problem with Patcher - using Manjaro 0.8.10 (distro based of Arch Linux) with 3.15.6 kernel, when I runned ./Patcher from KSP directory, I have got this

Error loading Python lib '/tmp/_MEIXu6iBn/libpython2.7.so.1.0': /tmp/_MEIXu6iBn/libpython2.7.so.1.0: file too short

So I checked /tmp directory to find that there is no directory called _MEIXu6iBn.

ls output of /tmp

hsperfdata_mdm/
icedteaplugin-mdm-RE9xQt/
_MEIlimimF/
_MEIMtRG9w/
_MEIOBUVIW/
_MEIQgahBU/
_MEIrT2I0q/
_MEIY8N5wd/
_MEI1ywQDP/
_MEI5KP6kz/
plugtmp/
plugtmp-1/
systemd-private-99a1b8d3492448eda1e1cb9e62e32334-cups.service-ZtgZyz/
systemd-private-99a1b8d3492448eda1e1cb9e62e32334-ntpd.service-UdGVuu/
hogsuspend|
qtsingleapp-manjar-2331-3e8=
qtsingleapp-manjar-2331-3e8-lockfile
tmpSZLFNA
tmps75UGm

What seems to be weirder, when ./Patcher is executed, it looks into random /tmp/_MEI* directory (there is always /tmp/_MEI and after that it is random). I tried to look on google, but did not found any suitable solution. Does anyone know, how to solve this?

[sal_vager]

To be honest, the patcher has always been difficult, and all I can really recommend is you get the full zip from the store instead :/

[Remogeus]

...

Well, that kinda sucks... so I will download it from store . And then I will wait until the Patcher is repaired

[Mesons]

To be honest, the patcher has always been difficult, and all I can really recommend is you get the full zip from the store instead :/

I have seen players posts' stating that they are running 0.24.2.259 or something other than 0.24.2.0. Since the patcher doesn't work in Linux, how can I update to the latest version? The .zip to download from the store only contains 0.24.2.0 and as far as I can tell, the "Update" button in the launcher does nothing.

[styckx]

I have seen players posts' stating that they are running 0.24.2.259 or something other than 0.24.2.0. Since the patcher doesn't work in Linux, how can I update to the latest version? The .zip to download from the store only contains 0.24.2.0 and as far as I can tell, the "Update" button in the launcher does nothing.

0.24.2 is 24.2.559 the "559" is just a build identification number the updater seems to tack on when you use it.. Look at your BuildID.txt

[Mesons]

0.24.2 is 24.2.559 the "559" is just a build identification number the updater seems to tack on when you use it.. Look at your BuildID.txt

Oh good, my buildID.txt says 559 as well. Perhaps this is a bug, then? I recall seeing the build ID tacked on when I was playing in Windows, before I made The Big Switch to Linux. All builds are ID'd as .0 in Linux, I'm guessing. I'll try to dig and see if anybody else has posted about this in Support & Bugs or on the bug tracker.

[sal_vager]

Build numbers are not usually added to the menu screen, it's just easier to use the buildID.txt for them

As long as your buildID.txt says 24.2.559 you're fine, no need to file a bug report

[styckx]

Hey Sal I just noticed you didn't update the section of the first posts pertaining to segfaults and how they aren't necessary anymore.

[sal_vager]

Hi styckx, are people not getting segfaults at all now?

The fix may still be valid for other reasons but I'll put a note there about your findings

[styckx]

Hi styckx, are people not getting segfaults at all now?

The fix may still be valid for other reasons but I'll put a note there about your findings

I don't know if there was other reasons "behind the scenes" problems solved with the segfaults.. I was under the impression they were for the 4GB limit only.

I still don't use any of them and my game runs flawlessly with unmodified executables and I throw addons at it with reckless abandon and the game refuses to crash. I even tossed more RAM in my rig to compensate.

[Mecripp]

As anyone running Linux 3.13 Ubuntu 14.04 64bit have problems with thee F* keys not working can't get debug window up ?

[sal_vager]

It's working here

[taniwha]

Hey Sal I just noticed you didn't update the section of the first posts pertaining to segfaults and how they aren't necessary anymore.

I don't know about 0.24.2 (no crashes yet, and I haven't applied the patch yet), but in 0.23.5, I ran for a long time without the png segfault patch without any problems... until I installed CustomBiomes. KSP crashed when I launched a ship (with a CB part?). I applied the patch and no crash.

I notice you're using "only" 6.3GB: it's entirely possible all of your PNGs are loading below the 4GB boundary and thus not triggering the problem. KSP allocates a lot of memory for PQS (terrain) after loading textures, so the problem might not trigger until you have a huge amount of part textures, or until a png is loaded after PQS has been initialized.

[Kaa253]

Hey Sal I just noticed you didn't update the section of the first posts pertaining to segfaults and how they aren't necessary anymore.

Hi styckx,

I note your comment about the "fix" not being required.

I am currently using the fix and having (almost) no problems with 54 mods installed. I thought I needed it for version 0.24.1 but I am afraid I cannot really make a conclusive assessment.

Anyway, just wanted to say I am following with interest and appreciate you reporting your findings.

[comatosed]

Hi

Thought I'd share my experiences from the last day in the hope it might save someone else some time in the future.

I'm a dual booter with Ubuntu 14.04 and Win 7. I much prefer using Linux, but due to another game I'm playing I've been using Windows a lot recently and that's where I've been playing KSP also.

I decided to try the 64 bit Linux client out to see if it was any more stable than the Win 64 bit (which IMO it is way more stable), however I was faced with a horrendous hit in performance ... pretty much made the game unplayable. Under 3 fps and a high physics load on a ship with less than 150 parts. Space centre, VAB & Tracking station all worked fine, the problem was only apparent when controlling a vessle or in map view. I know that the game runs fine in Linux on my machine as I'd run it before with no issues. Here's my specs :

AMD Phenom 2 X6 1090T BE (OC to 3.8 Ghz)

8 Gb DDR3 1866 Mhz

GTX580 3 Gb

I thought that maybe with one of the recent updates something had gone wrong so I tried various fixes and settings alterations none of which helped the issue.

Turns out that it was my copied (from Win 7) save causing the problems. Really wish I had of checked this earlier as I literally spent the whole day trying different settings, tweaks & mods to no avail.

I'm pretty sure I've seen something similar to this mentioned in this thread (with regards to the settings.cfg?). Not sure, so many pages it's all a bit of a blur, however I would say that if you are migrating a save and are having performance problems this might be the cause.

tl;dr Migrating saves across OS' can cause performance problems.

Update: Looks like I jumped the gun on this one. The problem has just re-occured in my new (linux only) save, so something is causing this to happen. I'll update as I find out more.

Update: It seems that Karbonite (or one of the mods packaged with it) was casuing the performance hit in Linux, updating it solved the problem.

Edited August 13, 2014 by comatosed
Update

[Mesons]

As anyone running Linux 3.13 Ubuntu 14.04 64bit have problems with thee F* keys not working can't get debug window up ?

I noticed that in 0.24.2, the default modifier key in Linux is no longer RightShift--LeftAlt and RightAlt are the primary and secondary keybinds (respectively) for modifier keys when a default settings.cfg is created. Since (at least in my experiences with Ubuntu 14.04) commands with these keys are caught above the program, they don't work for in-game commands. Be sure to change the keybind(s) in your settings.cfg and try again if you haven't checked that out.