skeevy

[Reserved for skeevy by sal-vager]

[Reserved for skeevy by sal_vager]

I've never tried using the numpad with MechJeb....next time I play I will and post back. What do you mean by the action key? Not sure which one that is. Technically this thread is for unmodded KSP only and you're running a modded install. EDIT: Made a thread for Linux modded installs. What's your distro and what audio system are you using? It could be something as simple as accidentally muting in in the PulseAudio mixer....did that once and couldn't figure out why SMPlayer was always muted for two days....really frustratingly simple. Both of ya'll post some logs, they might contain something useful.

That seems like it would be the best way to do it so nobody would have to choose between mods or wait for tech tree patches to make mods compatible. Personally, I'd like the first node to be Basic Atmospheric Flight, the second node to be Basic Landing which branches off into Advanced Atmospheric Flight, Basic Rocketry, Advanced Landing, and Basic Survivability......you know, the more I think about it, and especially once mods are taken into account, the community-standardized tech tree would have a lot of odd nodes for Basic Boating, Advanced Vehicle Assembly, Robotic Hinges and Gizmos, I don't even know what to name the node with Soccer Balls and Pumpkins...it would suck having to unlock a node that you don't have any parts in because the next node down requires you to have it. This idea really needs its own thread.

Here's the release notes. Has all the new features and updates listed.

@Zuuhis79: One last thing you can try with 14.04 Ubuntu is to use the Xorg-Edgers PPA and a newer kernel. Using the two of those should help. 3.17.1 Kernel install instructions for 14.04 Xorg-Edgers PPA Install the kernel, reboot, add the PPA, do an apt-get update followed by apt-get upgrade, reboot, play KSP. This is exactly what I did back when I was using Ubuntu and it does help. Those two combined contain your GPU driver. Link to 3.17 intel-drm-next Ubuntu kernel Instructions are the same as the other 3.17.1 kernel above, only different wget URLs. Never used that kernel, but you have an Intel GPU so it's worth a shot. EDIT: Post back if you need those wget commands for the drm-next kernel. @Ferram4: I'll just stick with FAR then. Thanks.

I just realized you're running a multi-monitor setup with only 1gb of vram. My card has 2gb of vram; with 0.24.2 and earlier I played KSP at 1920x1080 full settings no problems. I have to play 0.25 at 1600x900 because of the better textures and whatnot (back to 1080p after installing ATM and using some reduced graphics settings). Try running on only 1 monitor then do what Padishar said (or get a better GPU). I used to do the exact same thing in Task Manager back when I KSP'd on Windows as well as tweaking my CPU affinity to run it on my last two cores. You'd be surprised how forcing KSP to work on two minimally used cores helps (true with Windows and Linux I've noticed).

70km, but I like to use 75km after a bad EVA had Jeb do a freefall back to the surface. I almost grabbed the capsule around 45km, but I came in too hot, smacked it hard, and never had a chance to catch it again. He didn't make it. Oh, for some lulz, the other day I had a launch go very badly so I had Bill jump out around around 200m over the ground, the resulting explosion, Bill was about 20m over it/the ground when it happened, sent him up to about 40m where he fell down and had a bit of a tumble...but he survived a 200m free fall.

Here's my flags....though I should probably put on my flame suit for the first two.... First two are from Wikipedia, third one is from a Google search done the first day I owned KSP. Bonnie Blue Flag Virginia Battle Flag Principality of Zeon I haven't made any WWII Socialist Party flags yet....can't wait for Kerbinside to have destructible buildings so I can throw a WWII Socialist Party flag on rockets and start doing V2 strikes on Jeb's Island....Wernher von Kerman approves of this plan. Sorry about the euphemism, but the German N word is filtered. Please don't take offense to these flags -- Since there are only Green Kerbals, I assume they won the race war and therefore need to be flying racist and hateful flags (I have weird logic).

See here for instructions on figuring out the 32bit libs needed. In that link, the libs go 64bit then 32bit (sorry, it's a bit hard to tell what's what because I was lazy and did * commands). Before all of that, run, as root, "apt-get update && apt-get upgrade" to make sure your system is updated. Then follow the instructions in the link; or you can try what I did which is just fire up Synaptic, search for "lib32", and install what's missing when you ldd the 32bit executable. I used to be a big Mint 17 (Ubuntu 14.04) supporter, but recent updates to various projects make Ubuntu 14.04 and lower not worth using (especially if you have an AMD GPU). You really want to be on a distro like Arch, Manjaro, Sabayon...something bleeding edge with decent Steam support. Manjaro is the easiest of those three, what I run, and is based on snapshots of the Arch repos (it's Arch's Ubuntu in a sense; Ubuntu is based on Debian Sid snapshots). If you don't wanna leave the Ubuntu family, you should be running 14.10, period. Trust me when I say that KSP greatly benefits from the updated kernels, xorg, mesa, and more that you just can't get with Ubuntu 14.04. Ferram4 -- FAR runs just fine on Linux provided it's up-to-date and KSP doesn't get ran directly from Steam (unless the user is using something like Manjaro's steam-native package; it replaces Steam libs with native system libs). I haven't ran NEAR, but I'm thinking about switching over to it since I don't really use FAR's menus or advanced features and hoping that I might save some CPU cycles since I wouldn't have to process FAR's stuff I'm not really using. Would changing from FAR to NEAR matter that much or is the difference negligible for CPU cycles used between the two?

I'm surprised that the KSP Linux community hasn't made a distro or a respin of something designed to run off of a USB stick. Even though is a bit rough around the edges and sometimes requires a terminal command or two to fix things, my suggestion would be to use a distro like Manjaro Openbox Edition because it has two Steam versions (standard one that uses Ubuntu libs and a second one that uses system libs), proprietary drivers are easy to install and switch back to open source versions, it's a light-weight desktop, based on Arch Linux so it really up-to-date (and can use the AUR for a lot of stuff), it's a rolling release so it never needs to be reinstalled or have a messy apt-get dist-upgrade to update to the next version, and it has friendly developers and community members.

When you see any KSP picture and try to right click and turn the camera....I do that soooo much it isn't funny. When you're driving down the road and you look over to see the road crews' staging area with various tubes, pipes, conduit, all scattered about and think "huh, looks like Bill had a bad landing".

Thanks for the reply. Gonna give this mod a try. I only started using PP very recently (like a week now) and I've come to love it. Multiple skins, multiple shapes to choose from, damn-near unlimited length and width on some parts, variable sized heat shields, nose cones, boosters, thrusters (size, type, and amount of thrust), stack separators, batteries, fuel tanks, and more. For me, PP replaces a lot of mods that I only used for tanks, boosters, other various odds and ends, and TweakScale. I'm all for mods that do parts in a procedural type manor -- lots of options with less memory usage than a crap ton of various part sizes, what's not to love about that? Your ideas combined with what PP already does for SRB's would become the Holy Grail of SRB mods. Sorry, not trying to come to your thread about a new mod and instantly suggest combining it with something else. It is a bit rude of me, but I saw this and my first thought was "if this was combined with PP, it would be the next Whiskey and Coke" -- procedural boosters with built-in separator engines, more shapes, and more engine types would double as being extremely useful and help with lowering part count on ships -- 1 srb, 1 decoupler, 2 struts, and a nose cone versus 1 srb, 1 decoupler, 4 seperatrons, 2 struts, and a nose cone. I'd be saving a minimum of 4 parts per srb. With PP, I can already make giant srb's that can take multiple stages of 4-8 stock srb's into one stage of 4 to 6 (I've turned 60+ parts into around 12). The two concepts combined would drastically lower part count for the lifting stage(s) allowing us to focus on building better stations and ships. And since we're both here, I do have a Science BOX suggestion -- add some experiments to the Mobile Processing Lab, like have the UMTC built into it with slightly higher science rewarded if Kerbals are occupying it and study the experiments before transmitting. The MPL is a heavy lug to carry around just to use for Mysterious Goo and the Science JR.

That's a bash script and you run it from a Linux terminal. It would be interesting to combine that script with Shaw's DDS converter. If I understood all the fine nuances of the various image formats and converting them, I would. @Lilleman You said you're still working on the user-friendly version for Windows....does that mean you have something working for Linux or am I just thinking too hopeful? And I'd be happy if your tool supported some ATM like functions like resizing/scaling images for those of us with crappy CPUs or GPUs...and if possible, the ability to change textures like Texture Replacer. An all in one texture tool/mod for KSP would be awesome.

What are the benefits of this over the procedural boosters that are in Procedural Parts? Could you not submit this as a pull request for Procedural Parts? Since Swamp_LG isn't working on PP any more and NathanKell and OtherBarry are maintaining it, anybody with the ability to add new parts and possibly fix things would probably be welcome. Only asking/suggesting that because it would mean one less mod I'd have to keep up with as well as not having to install multiple mods that do the same thing (I know I can't be the only one thinking this). Also, PP already does variable tank sizes, two different thrust nozzles, adjustable thrust, adjustable nose cones, etc; making a bit of what you want to do with this already done or started on. This looks pretty awesome and I'm looking forward to more thruster types and the separator engines.

Linux x64 is the only way to take full advantage of your 16GB of ram, for now. Windows x32 and OSX have the ram limit and Windows x64 isn't worth the hassle. With OSX, you can only run KSP in high mode with a vaporizer.

Distro and Kernel? Only asking because a combination of Xorg 1.16, Kernel 3.17, and Mesa 10.X has some good improvements for the Radeon driver. Manjaro with all of that is really close in performance to Mint 17 with Catalyst. Manjaro Linux x64 w/ Catalyst driver from Ubuntu 14.10 (it's the only Catalyst driver that supports 3.16+ kernels and xserver 1.16; in the Manjaro repos as default Catalyst driver and AUR as catalyst-test for Arch users). Kernel 3.18 should bring us an even better Radeon driver. It's currently in RC1. I've never noticed this issue with Catalyst or with Xorg/Kernel/Mesa/Radeon all being updated to damn-near bleeding edge. If you run the Radeon driver, it's best to be using a really up-to-date distro like Arch, Manjaro, or Debian Sid because driver updates come in the form of Kernel/Xorg/Mesa updates. If you use the Catalyst driver, it really doesn't matter as much because driver updates come from AMD and don't normally rely on bleeding edge stuff. That said, with the right combination of stuff, bleeding-edge + Catalyst is the best for gaming, though it can be unstable. Hopefully we'll be getting the Catalyst 14.10 or 14.11 beta driver soon. The 14.9 driver release, while good, was a bit lackluster; likely because it's both a WHQL driver and designated as Linux stable.

Post those logs. Sucks defragging didn't help any. Have you tried deleting you settings file? That's helped others. Other than that, I think we've gone through almost everything else that can be done without logs.

Even better, connect 4 pods end on end, turn them sideways 90 degrees, and go rolling around the KSC. I was able to get soil, eva, and crew reports for 9 different KSC biomes on my first "launch" before I ran out of electricity to roll around and transmit. I could have gotten more if I figured out the quirks of driving it faster. Quick and easy 109 science points without even firing up a rocket. Do it like that, only put an extra pod on each end with antennas on the tips, maybe a few more in the middles just for backups. Try not to roll faster than 9m/s or you'll explode yourself or the launchpad or a building...

The latest Nvidia driver for Ubuntu is 343.22 with the Xorg-Edgers PPA. It also has an updated Bumblebee package. The newer the GPU, the more bleeding edge you have to be in the driver department. I'm not really sure on the primusrun/optirun stuff, but I don't have an Nvidia card or have I used a laptop with hybrid graphics (and I don't think I ever want to from the sounds of it). On that bleeding edge GPU stuff...with the 3.17 kernel, I'm able to use MSAA with KSP, and, believe it or not, it actually looks better and has a higher framerate in the VAB (I assume that's just the updated radeon driver at play). I was doing a bit of searching and found out that apparently the radeonsi driver can use MSAA with Linux 3.17, so I installed a 3.17 kernel and sure enough it does. This is only for AMD GPUs using the radeon driver with a 3.17.0 and up kernel, to enable MSAA, in a terminal use "export GALLIUM_MSAA=2" followed by launching KSP or add it to a script like below #!/bin/sh LC_ALL=C LD_PRELOAD="libpthread.so.0 libGL.so.1" export __GL_THREADED_OPTIMIZATIONS=1 export GALLIUM_MSAA=2 exec taskset -c 2-3 ./KSP.x86_64 Valid options 2, 4, & 8.. Next Day Edit: GALLIUM_MSAA is being depreciated in upcoming Mesa revisions. Don't get too used to that command.

IMHO, yellow [Linux], [OSX], or [Windows] tags would be better than the generic [support] ones we currently have and should be easy to do and/or moderated in. What other reason is there for posting a new thread in the support sections? Supporting Squad by providing pizza and beer? There are a lot of Windows users, but that seems to be changing as KSP matures and needs more and more resources by default. Forcing OpenGL and using Active Texture Management can only do so much...once that limit is reached, the only viable alternatives are removing mods or KSP x64 on Linux...and that's true with both OSX and Windows users. That reason alone should warrant a Linux Support subsection...or at least as stickied thread or two (like this one).

@Starman4308 AND STEAM LINUX USERS One of the problems with running KSP through Steam is you're forced to use old Ubuntu 12.xx libraries. Running KSP directly, with a script, or in a way that doesn't involve starting it with Steam will force KSP to use your system libraries which are more up-to-date than the ones shipped with Steam. Some Linux distros like Manjaro have a steam-native package that tweaks Steam so all Steam games use your system libraries instead of the ones packaged with Steam (they also have a Steam compatibility mode allowing you to run Steam using its libraries for the tiny amount of games that like Steam libraries...it's like 2 or 3 games from what I've seen, KSP isn't one of them). I suspect this right here is why Linux Steam users seem to have a lot more issues than Linux KSP Store users. Specifically for Starman4308 and/or Nvidia Optimus users Looked up that Nvidia Optimus/Bumblebee stuff. Apparently, when you want to run a 3d app using the Nvidia GPU, you have to start it with "optirun [optirun flags] app-to-run [app-to-run flags]". I've modified my KSP start script to do this for ya. Just make a file in the ksp directory called "ksp.sh", copy/paste the below into it, and set it to be executable (either in the right click properties menu or in a terminal with "chmod +x /path/to/ksp.sh"). Then just double click ksp.sh to play KSP (this is how I do it**). #!/bin/sh LC_ALL=C LD_PRELOAD="libpthread.so.0 libGL.so.1" __GL_THREADED_OPTIMIZATIONS=1 exec taskset -c 2-3 optirun ./KSP.x86_64 I have a quad core and "taskset -c 2-3" tells it to have KSP run on my 3rd and 4th core, 0=1st core, 1=2nd core, and so on and so forth. KSP likes being forced to two threads and my 3rd and 4th run the lightest. I'm unsure if taskset should be before or after optirun so you might need to experiment with their orders a bit. From what I can tell from reading some man pages, the above should work as expected. You'll probably also want to install the latests available GPU drivers that you can. Check over at Nvidia.com and see what their latest driver version is, then search for a PPA with that driver in it. For the latest Intel driver...just like my radeon driver, it comes with new kernels and xorg revisions....if you're running Ubuntu, look up the xorg-edgers PPA...and you're gonna wanna be running Ubuntu 14.10 because you'll benefit more from it for playing games with it's more up-to-date stuff. If you're not bothered by the terminal or having to learn a bit, Manjaro Linux is a good way to get a very up-to-date desktop going. It's a little rough around the edges and requires a few terminal fixes from time to time, but it is fast, comes with Steam, has a steam-native package (highly recommended), and you'll be able to use the Arch Linux Wiki as your guide book (Arch Linux Wiki is one of the best sources of Linux information there is). I also read that Nvidia Optimus can have issues when dynamically switching from Intel to Nvidia. One method of fixing those is to completely disable the Intel GPU and run it as straight Nvidia, though you will lose some power savings (if that matters to you); reread your post and that's what you did...Look into Arch Linux or Manjaro if you want to take advantage of Prime/Bumblebee/Optimus. Arch has does have quite a bit of information on all this Nvidia tech and I'm not sure if they can be converted over to Ubuntu/apt commands. **technically I run it from a script on the desktop that replaces ./KSP.x86_64 with '~/Documents/Kerbal Space Program/KSP.x86_64' I do that so when KSP updates, all I have to do is rename the ~/Documents/KSP folder with the version (like /Kerbla Space Program 0.24.2/, copy/paste the updated KSP from Steam into my Documents folder, and start playing the updated KSP with my desktop script. The script I posted is a generic one that I place into all my KSP directories in case I want to play older versions.

I hope it does change. Even if they're just general support areas that are for modded and unmodded installs, it would still make it easier for users to find specific OS support without having to search the forums (which we know people love doing) or starting multiple topics for the same thing because whatever thread that would have helped them was buried 6 pages back and in between "Windows x64 crashes too much, help me" and "how do I get my joystick to work".

Honestly, it depends on what distro you're running. The more up-to-date the distro, the better. Intel drivers are a combo of Xorg, Mesa, and Kernel parts, so all three need to be as up-to-date as possible for the best performance. For example, with Ubuntu 14.04 and my AMD R7 GPU, I had to use the FGLRX proprietary driver because I didn't have good success with the Radeon open source driver. Earlier this week I changed to Manjaro which has near bleeding-edge stuff; now I can use the Radeon driver with no issues and it's just as fast as my previous Ubuntu setup (ahem, technically Mint) with a proprietary driver. Regardless of what ya do, those HD4000's aren't know to be the best on Linux, but with some reduced graphics settings and updating Xorg, Mesa, and Kernel as much as you can, you might get some better performance. Post your distro and specs if you need help updating those. @sal_vager Two things, 1) Would it be possible for the support section(s) to have some by-OS subsections? Like Windows Support, OSX Support, and Linux Support. It would make it a lot easier to find help and get assistance with operating system issues if we weren't all lumped into the same threads. And 2) Just posting the updated ldd for 0.25 so post 2 can be updated (from Manjaro 8.10) 64-bit then 32 bit...I prefer lazy * commands [skeevy@nebula Kerbal Space Program]$ ldd ./K*4 linux-vdso.so.1 (0x00007ffff1bfc000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f83fac12000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f83fa9f6000) librt.so.1 => /usr/lib/librt.so.1 (0x00007f83fa7ee000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00007f83fa56d000) libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f83fa2d3000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f83f9f91000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f83f9d7f000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00007f83f9b74000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007f83f996a000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f83f9665000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f83f944f000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f83f90ac000) /lib64/ld-linux-x86-64.so.2 (0x00007f83fae16000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f83f8d9d000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f83f8b73000) libglapi.so.0 => /usr/lib/libglapi.so.0 (0x00007f83f8949000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00007f83f8746000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007f83f8540000) libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0x00007f83f833e000) libxcb-glx.so.0 => /usr/lib/libxcb-glx.so.0 (0x00007f83f8124000) libxcb-dri2.so.0 => /usr/lib/libxcb-dri2.so.0 (0x00007f83f7f1f000) libxcb-dri3.so.0 => /usr/lib/libxcb-dri3.so.0 (0x00007f83f7d1c000) libxcb-present.so.0 => /usr/lib/libxcb-present.so.0 (0x00007f83f7b19000) libxcb-randr.so.0 => /usr/lib/libxcb-randr.so.0 (0x00007f83f790b000) libxcb-xfixes.so.0 => /usr/lib/libxcb-xfixes.so.0 (0x00007f83f7703000) libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0x00007f83f74f9000) libxcb-shape.so.0 => /usr/lib/libxcb-shape.so.0 (0x00007f83f72f5000) libxcb-sync.so.1 => /usr/lib/libxcb-sync.so.1 (0x00007f83f70ee000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f83f6ecc000) libxshmfence.so.1 => /usr/lib/libxshmfence.so.1 (0x00007f83f6cc9000) libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00007f83f6ac3000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0x00007f83f68b6000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f83f66ac000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f83f64a8000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f83f62a2000) [skeevy@nebula Kerbal Space Program]$ ldd ./K*86 linux-gate.so.1 (0xf7707000) libdl.so.2 => /usr/lib32/libdl.so.2 (0xf76d3000) libpthread.so.0 => /usr/lib32/libpthread.so.0 (0xf76b7000) librt.so.1 => /usr/lib32/librt.so.1 (0xf76ae000) libGLU.so.1 => /usr/lib32/libGLU.so.1 (0xf7628000) libGL.so.1 => /usr/lib32/libGL.so.1 (0xf757d000) libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7446000) libXext.so.6 => /usr/lib32/libXext.so.6 (0xf7431000) libXcursor.so.1 => /usr/lib32/libXcursor.so.1 (0xf7426000) libXrandr.so.2 => /usr/lib32/libXrandr.so.2 (0xf741b000) libm.so.6 => /usr/lib32/libm.so.6 (0xf73cd000) libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf73b2000) libc.so.6 => /usr/lib32/libc.so.6 (0xf71fa000) /lib/ld-linux.so.2 (0xf770a000) libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7104000) libexpat.so.1 => /usr/lib32/libexpat.so.1 (0xf70db000) libglapi.so.0 => /usr/lib32/libglapi.so.0 (0xf70c1000) libXdamage.so.1 => /usr/lib32/libXdamage.so.1 (0xf70bc000) libXfixes.so.3 => /usr/lib32/libXfixes.so.3 (0xf70b6000) libX11-xcb.so.1 => /usr/lib32/libX11-xcb.so.1 (0xf70b3000) libxcb-glx.so.0 => /usr/lib32/libxcb-glx.so.0 (0xf7098000) libxcb-dri2.so.0 => /usr/lib32/libxcb-dri2.so.0 (0xf7092000) libxcb-dri3.so.0 => /usr/lib32/libxcb-dri3.so.0 (0xf708d000) libxcb-present.so.0 => /usr/lib32/libxcb-present.so.0 (0xf7089000) libxcb-randr.so.0 => /usr/lib32/libxcb-randr.so.0 (0xf7079000) libxcb-xfixes.so.0 => /usr/lib32/libxcb-xfixes.so.0 (0xf7070000) libxcb-render.so.0 => /usr/lib32/libxcb-render.so.0 (0xf7065000) libxcb-shape.so.0 => /usr/lib32/libxcb-shape.so.0 (0xf705f000) libxcb-sync.so.1 => /usr/lib32/libxcb-sync.so.1 (0xf7057000) libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf7031000) libxshmfence.so.1 => /usr/lib32/libxshmfence.so.1 (0xf702e000) libXxf86vm.so.1 => /usr/lib32/libXxf86vm.so.1 (0xf7028000) libdrm.so.2 => /usr/lib32/libdrm.so.2 (0xf7018000) libXrender.so.1 => /usr/lib32/libXrender.so.1 (0xf700d000) libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7009000) libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf7002000)

While Xtoro's post above has some good information, since you didn't post system specs, Kubuntu may or may not be a good choice to use because it's one of the heaviest running Linux systems there is (as in ram and processing power used by the base system). If you have an AMD card, 14.04 isn't what you want to be using. Use 14.10. AMD GPU's really, really benefit from the updated kernel and Xorg that only the newest distro's have. I have an R7 260x, with Ubuntu 14.04 I had to use the fglrx driver to get 20-30 fps with heavy mods. I can do the exact same with Manjaro Linux running the latest Xorg and Radeon driver (radeon is the open source AMD driver...it's in the kernel so you have to be running the latest kernel, xorg, and mesa to be using it's updates). Manjaro is a snapshotted, Arch Linux, really good blend of bleeding edge and stability. While I think Manjaro is awesome, it is rough around the edges and does require a bit of terminal maintenance to deal with a few quirks it has. One benefit with Manjaro is Steam comes preinstalled, and in the Manjaro repos, you'll find a steam-native package that tweaks the default Steam install to use your system libraries and, for a lot of games, run better than with using the Ubuntu 12.04 libraries that Steam comes with. That steam-native package also comes with a Steam compatibility mode that forces Steam to use it's old libraries for the few games that have issues. KSP benefits from using the system libraries and is why a lot of us copy/paste it to somewhere else and run either directly or with a script. Oh, and one other AMD/FGLRX issue you need to know -- don't use the driver from the driver manager....seriously, you'll regret it....go to AMD.com, download the latest available driver (14.9 the last I checked), and build and install it manually (it's two terminal commands you can copy and paste). With Nvidia cards, for GPU drivers and Ubuntu, do a search for the Xorg-edgers PPA and install the Nvidia driver it has. Another option for GPU drivers is the SMXI or SGFXI scripts. SMXI works with Ubuntu/Debian based systems and does a lot of neat stuff. SGFXI is a driver installing script that works with Ubuntu/Debian and Arch/Arch based systems. If you just wanna play KSP, go with Ubuntu 14.10. If you wanna play KSP and also wanna learn a bit of Linux with an optimized and up-to-date system, go with Manjaro 8.10 or 9 testing (recommended over 8.10...it's old and about to be replaced...you'll thank me when you don't have to hit the terminal on first boot to fix some very minor annoyances...or ' sudo pacman -Syyuu'). Both have easy installers and Xtoro's 30GB shrink rule is true with both (I think all us Linux people have been repeating that like a broken record lately). If you don't have the greatest of system specs, steer clear of Kubuntu and instead use Xubuntu or Lubuntu. They all have the same installers and instructions to install, but they have different desktop environments when you're done. X and L run with the least amount of bloat out of all the Ubuntu based systems. With Manjaro, go with either the XFCE version (what I'm using) or the Openbox version (what I used last year) for the light weight . Once you get it installed..or not..come to the Linux support thread and we'll help ya as best as we can. I wish there was a Linux support subsection. EDIT: I forgot to mention that I'm referring to the AMD GPU's from the 5000 series and up, especially the 79xx and Rx 2xx cards. If you have a GPU older than those, it really doesn't matter what distro you go with because you'll be using the old, legacy drivers, but you will still benefit more from an up-to-date OS because the legacy driver is one of the various radeon open source ones (the legacy flgrx is kinda crap). If you bought KSP through Steam or from a vendor that sells Steam keys (what I did...at Gamefly on sale for $15 USD), you don't have the option of downloading KSP from the KSP Store...it's Steam or bust. Just install Steam, log-in, and KSP will be in the Games tab. From there, just download and install it. Really easy and simple...it's same on every Linux distro that has Steam and identical to how it's done on Windows. After that, I like to copy/paste KSP to a different folder so my Steam KSP is always unplayed and untouched in case I do something dumb and screw up my mods or whatever. It's just nice having a clean KSP around versus having to have clean it all up, repair the install, blah, and blah.