Jump to content

The Linux compatibility thread!

sal_vager
 Share

Recommended Posts

taniwha

taniwha

Posted
Posted

Ok, I now have 8GB of memory, and 64-bit KSP is still quite crash-happy (when it gets to around 4GB: I don't know the exact value). also, under the same conditions, 32-bit KSP uses around 2.9GB. That makes me think there are huge collections of nothing but pointers.

Link to comment
Share on other sites
m4v

m4v

Posted
Posted
Ok, I now have 8GB of memory, and 64-bit KSP is still quite crash-happy (when it gets to around 4GB: I don't know the exact value). also, under the same conditions, 32-bit KSP uses around 2.9GB. That makes me think there are huge collections of nothing but pointers.

did you test with the binary patch?

Link to comment
Share on other sites
amo28

amo28

Posted
Posted (edited)

I did some testing this evening in an attempt to optimize memory management. Didn't really collect great numbers, just went on a first pass runthrough.

Using the mbm2png converter, I wrote a script that will batch convert all mbms to pngs and edit the model.mu correctly.

Prior to doing this, I noticed my free memory in the <100MB area. I have 8GB total.

After running this script against the Squad folder (parts, props, and spaces mainly), the size of the folder reduced to 165mb, and upon running KSP x64 I found that a bunch of my RAM was suddenly free. Over 650mb was free after KSP had fully loaded. 575mb in the VAB. 575mb on the lauchpad with a 100part craft. The load time was a little longer than normal, and scene changes took a split second longer to fully load, but all-in-all I found everything to be a lot smoother.

I want to make sure I'm not fooling myself. If anyone else wants to give this a go, I'm curious to see if anyone notices a similar experience.

Script is below for batch converting. You'll need to update the paths.

#!/bin/bash

# MBMConverter Bash Script

export PATH=[location of mbmconverter]:$PATH

find "[GamePath]/Kerbal Space Program/GameData/Squad" -name *.mbm -exec mbm2png '{}' \;

find "[GamePath]/Desktop/Kerbal Space Program/GameData/Squad" -name *.mu -exec muedit '{}' \;

Optionally, you can add find "[GamePath]/Desktop/Kerbal Space Program/GameData/Squad" -name *.mu -exec rm -f '{}' \; to the end of the script to delete the mbms once they're converted.

So far, I ran this against Squad, AIES, KAS, and Taverio's Aerospace. I tested with three different craft built using AIES and stock parts -- didn't notice any issues. It's amazing how smooth the Space Center scene is when there's free RAM available.

My setup: Lubuntu 13.04 x64. Core2Quad 9660. 8GB RAM. Nvidia graphics. Running KSP.x86_64 with a.g.'s fix. All settings on high with Universe Replacer skybox textures and Cloud & City Lights mod.

Edited by amo28
Link to comment
Share on other sites
amo28

amo28

Posted
Posted

More information.

This is a quote from Novasilisko from here:

3. PNGs import VERY slowly, due to a Unity bug

I strongly recommend using one of the TGA or MBM settings for your exported textures instead of PNG. TGAs are just as editable, but slightly larger. For TGA I recommend the TGA_Compressed setting, TGA_Uncompressed is almost as large as an MBM. Have not tested TGA_Smallest but I believe the texture quality of that is fairly low. TGAs import a lot faster as they're using the same compression method as unity does normally[citation needed]. MBMs are not editable and are mostly uncompressed, so are quite large, but import the quickest. However, I haven't done direct time comparisons, so that would help a lot if somebody could get some direct statistics on the loading times for these different formats!

I'm not suggesting that the load times are any better, but the free RAM and performance AFTER loading are much better.

Hoping someone could provide some insight to this. Also, if TGAs are better than PNGs, perhaps the creator of mbm2png could rework his tool to export to that format instead? The suggestion that one compressed format over another compressed format but anything other than MBMs gives some insight into the fact that the system performs better when it's not using MBMs altogether.

Link to comment
Share on other sites
jtaylor996

jtaylor996

Posted
Posted
I am thinking about dual-booting Ubuntu with Windows 7 on my desktop to try to use the 64 bit executable to take advantage of my full 16 gb of system RAM (I already have to use low-res B9 because of memory problems on windows). Reading through the thread, it appears there have been serious problems with heavily modded KSP under linux, but a.g.'s fix has helped with a lot of those. Now that the fix is around, is Linux a viable alternative for a heavily modded KSP (multiple large part packs, Deadly Reentry, FAR, Engineer Redux, Universe Replace, and the list goes on)? Or are there still stability issues when that many mods are in play?

Thanks!

Absolutely not. I've got a serious horsepower linux 64 bit workstation, and KSP is barely playable. It's not native to linux, so you'll never see anything like what the hardware is capable of doing.

Link to comment
Share on other sites
amo28

amo28

Posted
Posted
More information.

This is a quote from Novasilisko from here:

I'm not suggesting that the load times are any better, but the free RAM and performance AFTER loading are much better.

Hoping someone could provide some insight to this. Also, if TGAs are better than PNGs, perhaps the creator of mbm2png could rework his tool to export to that format instead? The suggestion that one compressed format over another compressed format but anything other than MBMs gives some insight into the fact that the system performs better when it's not using MBMs altogether.

An update to my testing. Last night, taking Nova and Bac9's advice that TGA is the better format, I ran a script through the Gamedata folder to convert all textures to TGA from PNG and update the model.mu's to reflect the new format.

I found that, as I said in my earlier post, with PNGs my free RAM was right around 500MB after load.

With the system running only TGAs, my free RAM went to around 115MB. Performance went back to what I had seen prior to converting the .mbm's.

Re-converting every texture back to PNG and re-modifying the model.mu to reflect the change, and I saw free RAM go between 700mb and 500mb.

I'll make a blog post tonight about my specific findings and the scripts used, however I'm hoping that other Linux users can give me their YMMV thoughts on the issue.

TL;DR - The consensus that TGAs are better than PNGs does not hold up in testing.

Link to comment
Share on other sites
Albert VDS

Albert VDS

Posted
Posted
Has anyone else had weird issues with mousewheel scrolling in 0.22? I have one of those old-timey scroll wheels that "clicks" in 3-line chunks or so, but in 0.21 my zoom was nice and smooth. In 0.22 it's not, and tweaking the mouse wheel sensitivity doesn't seem to be changing anything.

Some fun examples:

  • In the VAB, mousewheel scrolling to change elevation goes in about 8 meter chunks per "tick"
  • In the VAB, shift+mousewheel scrolling to change zoom goes in very large chunks per "tick"
  • In the flight map or tracking station map, mousewheel scrolling to zoom in goes straight to maximum zoom level.

TIA

Ok at first I thought I didn't have it in VAB/SPH, but after getting larger parts in carreer mode it seems I have it too.

It zooms and move up and down way too fast. I have to use the numpad + and - to fine tune the view.

Link to comment
Share on other sites
Garek

Garek

Posted
Posted

So, I just set up an Arch Linux with kde, steam and KSP. When I try to start via steam, nothing happens. When I start via a Shell Window, I get the following errors:


./KSP.x86_64 
Set current directory to /home/philipp/.local/share/Steam/SteamApps/common/Kerbal Space Program
Found path: /home/philipp/.local/share/Steam/SteamApps/common/Kerbal Space Program/KSP.x86_64
Mono path[0] = '/home/philipp/.local/share/Steam/SteamApps/common/Kerbal Space Program/KSP_Data/Managed'
Mono path[1] = '/home/philipp/.local/share/Steam/SteamApps/common/Kerbal Space Program/KSP_Data/Mono'
Mono config path = '/home/philipp/.local/share/Steam/SteamApps/common/Kerbal Space Program/KSP_Data/Mono/etc'
Aborted (core dumped)

does anyone know what's wrong there?

Link to comment
Share on other sites
sal_vager

sal_vager

Posted
  • Author
Posted

Not sure from what you've posted, though you will need t ensure your graphics drivers are up to date as Unity and KSP is really touchy when it comes to graphics drivers.

Can you start KSP via the binary directly?

Link to comment
Share on other sites
Garek

Garek

Posted
Posted

Thanks for the quick reply. Graphics driver could be the problem, as I'm currently running on open-source-drivers. Every way I found to install the proprietary one fails because it wants a outdated version of xorg. This will probably take more than one evening of internet to fix.

Is there a more 'direct' way than launching KSP.x86_64 from a shell-Window? Because that doesn't work.

Link to comment
Share on other sites
sal_vager

sal_vager

Posted
  • Author
Posted

From a shell window? Not sure, I'd make a script or a shortcut in that case but you can add the 64bit binary to the steam command box, it's in the opening post.

On linux the graphics drivers are the number one issue, I'm also using the open driver, version 325 for Nvidia, I am guessing you have an old (4000 series or older) ATI radeon card, trouble is those are discontinued/unsupported by AMD so you need to upgrade :/

Link to comment
Share on other sites
Garek

Garek

Posted
Posted

Yes, it's a good old Radeon HD 4850. Still works well on windows with legacy drivers, but now that you mention it, an upgrade could solve my linux driver problems. Not that I didn't expect an upgrade to be necessary soon, I just didn't expect KSP to require it :D

Link to comment
Share on other sites
sal_vager

sal_vager

Posted
  • Author
Posted

It's not KSP at fault here unfortunately, it's AMD refusing to support the old cards with the new xorg :/

I also have an old 4850 which I really liked, but it's in a box now, unused and superseded by an Nvidia GTX 650.

I just got sick to the back teeth of the poor AMD drivers, first for the 4850 and then for the 7660D build into the CPU.

Link to comment
Share on other sites
Unit327

Unit327

Posted
Posted

Just a heads up to linux users that you can use mumble-overlay to view the FPS. I used it to check the difference between the nvidia linux drivers' threaded optimisation thing (__GL_THREADED_OPTIMIZATIONS) and found that it didn't make much difference either way in ksp. Though I think mumble-overlay might hijack the LD_PRELOAD environment variable so it's possible the two don't work in concert. Regardless, when eyeballing ksp's performance it seemed identical with/without the optimisations. This was all on 313 drivers on a 680.

Link to comment
Share on other sites
Stranded

Stranded

Posted
Posted (edited)

I searched for altimeter issues, and the closest result was this thread. I have read through this thread completely and didn't see my issue. I am on KSP 0.22.0, and running the following:

-Computer-

Processor : 2x Intel® Core2 Duo CPU T7500 @ 2.20GHz

Memory : 2020MB (361MB used)

Operating System : Ubuntu 12.04.3 LTS

User Name : stranded (stranded)

-Display-

Resolution : 1280x800 pixels

OpenGL Renderer : Unknown

X11 Vendor : The X.Org Foundation

-Multimedia-

Audio Adapter : HDA-Intel - HDA Intel

Audio Adapter : ThinkPad EC - ThinkPad Console Audio Control

The issue I am having is that the altimeter goes completely wonky at times. The numbers start rolling, and it's like a slot machine, only they don't stop. Even once I have the capsule back on the ground, or safely in the ocean. I did notice last night that while I was in orbit it was fine, then I changed the angle I was looking at the capsule and it went haywire. I moved the camera position back to where it was, and it settled back down. But after sending up another capsule, sometime when I was in space it went crazy again and never settled back down. I did manage to land the capsule, the chutes opened at what I assume was the right altitude, but I can't be sure as the altimeter looked like a random number generator.

I don't have any add-ons installed, and I deleted everything when I upgraded from the demo version, so this is a completely clean install with one save. I don't see anything in the KSP.log file, or the Player.log files, except this, which while it might not be even related is basically every other line of the Player.log

(Filename: /BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/LinuxStandalonePlayer/UnityEngineDebug.cpp Line: 54)

Any thoughts or ideas? I know the altimeter was working fine in the demo.

P.S. If I need to move this into it's own thread just let me know.

Edited by Stranded
Adding P.S.
Link to comment
Share on other sites
wybe21

wybe21

Posted
Posted (edited)

Hello everybody, I got a very strange problem.

The green nodes on which you connect your parts dont appear so I can't connect anything at all.

I do use the LC_ALL=C command to start ksp. I know I have had this issue earlier and fixed it but I can't find the relevant posts anymore (probably due to a forum issue).

Anyone have this issue or have an idea for a fix?

EDIT:

Also I noticed that some of the smaller parts have scaling issues and are much bigger than theyre supposed to be. This all sounds like interchanging of commas and periods, but I already applied the fix for that.

When launcing just the capsule it appears 5000 kilometers above kerbin saying that my velocity is 0.

Edited by wybe21
Link to comment
Share on other sites
twchambers

twchambers

Posted
Posted

Anyone else having problems on Fedora? My steam client updated and now I think it's broken KSP. Running from the terminal it looks like it's an issue with libGLU but sadly I don't have enough knowledge to tell what or know how to fix it. Was fine working fine up until this evening!

/home/thomas/.local/share/Steam/SteamApps/common/Kerbal Space Program/KSP.x86: error while loading shared libraries: libGLU.so.1: cannot open shared object file: No such file or directory
Game removed: AppID 220200 "Kerbal Space Program", ProcID 14606

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...