Onieronaut

Can anyone point me towards a good breakdown of how to enter the Jool system without expending huge amounts of delta V? My general sense is that by doing a few gravity assist maneuvers near the inner moons it should be possible to perform a Jool system capture relatively cheaply ... but I don't know the specifics, or how this would look in practice. What's a reasonable delta V to budget for arrival in the Jool system anyway? 2000 m/s? 500? I honestly have no idea. I'm currently working on my first attempt at the Jool 5 challenge and I'm pretty happy with the hardware I've designed, but the weak link is my own piloting and navigation skill (or lack thereof). Any information about how to efficiently enter the Jool system, as well as how to efficiently transfer between moons, would be very much appreciated. I've seen people mention moon-to-moon transfers for like 50 m/s dV, and I don't really understand how that's possible when you're going all the way to the surface of each moon and back. Basically I'd hate to fail at the Jool 5 challenge just because I don't know how to steer my own damn ship, and I'm looking for anything which will help me navigate the Jool system intelligently.

Good catch Cantab, thanks! As for the Steam launch options, they appear not to be working at all. To test this I disabled my 32-bit KSP executable by renaming it to disabled-KSP.x86 while leaving KSP.x86_64 as it should be, just to be certain that Steam couldn't trick me by launching KSP in 32-bit mode when I asked it to launch in 64-bit mode. I'm glad I thought of that, because sure enough it turns out that when I use the launch option input "%command%_64" and try to open the game through Steam, it gives me a missing executable error. Either that input is incorrect or Steam is just ignoring the input completely. I suspect the latter, in which case when I launch through Steam it most likely is not applying Sal_Vager's suggested GL optimization. Fixing the directory path in my homemade KSP.sh executable did in fact make it work (thanks again), but I'm still having the same problem with disappearing orbit paths. I assume that unlike Steam, this method actually does apply the suggested GL optimization. This would imply that whatever is causing my orbit paths to disappear, this GL optimization does not fix it. (It didn't fix my fairing flicker, either. Oh and I've also tried playing both with and without anti-aliasing enabled, it doesn't have any effect on these bugs.) In another PM, Eleven pointed out to me that I can run KSP in 64-bit mode simply by double-clicking Launcher.x86_64 in my Kerbal Space Program folder. That works, and it seems pretty foolproof, so I'm just going to launch the game that way for the time being (since the executable script isn't having any noticeable effect). I sure hope the new UI system fixes this. KSP without the option of interplanetary travel is pretty disappointing.As an aside, you guys are awesome. I couldn't ask for a more helpful support community.

E.Nygma, that certainly clarifies what you're talking about, but I'm still not sure exactly what I'm supposed to do. Are you talking about reinstalling Ubuntu? Updating KDE? I'm not sure what specific steps I need to take to test this fix suggestion. (Yeah, I'm a Linux newb.) Thanks.

Thanks! With anti-aliasing turned on and "INTEL.Intel" removed from the hex, KSP's game options are now giving me full access to every graphics setting: PPFX, aero FX, etc. Incidentally when I turn on anti-aliasing it doesn't actually look like there's any anti-aliasing happening (all edges are pixelated), but that has zero effect on gameplay so I'm not particularly concerned about it. Curious, though. I got KSP to run in 64-bit mode (again, thanks for your help) and unfortunately it didn't make any difference for either my fairing flicker or my disappearing orbit paths.

I'm having the fairing texture glitch and I'd be happy to test this out, but I'll need to know how first. What is "DE?" I understand what you said about deleting the GameData folder and verifying my cache in Steam, but it sounds like "swapping the DE" is something different. What is this "DE" and how do I swap it? (Apologies for asking so many basic questions, as I'm sure you can tell I'm new to all this.)

This may have already been answered, but I've been grinding away at various KSP glitches all day now and I just don't have the energy for another deep, forum-scouring search. I have a feeling this is an easy fix, so please humor me: KSP is starting in 32-bit mode on my Ubuntu system, despite the fact that I have a 64-bit setup. How do I get KSP to start in 64-bit mode? I discovered this mixup while trying to get aerodynamic effects to work. KSP was telling me I had no hardware support so I applied the generally recommended fix of using a hex editor to zero out "INTEL.Intel" in my KSP.x86_64 file. When that didn't work I PM'd Eleven to ask for help and he convinced me to try it again. (Thanks dude!) I did, but this time I amended KSP.x86 as well as KSP.x86_64. Like magic, KSP suddenly allowed me to show aerodynamic effects! That's a solid demonstration of this particular fix, but much more importantly it revealed that KSP has been running in 32-bit mode this whole time (and still is). In addition to the lack of aerodynamic effects, I've also been having a display glitch on fairing textures, and a serious problem with orbital paths disappearing in map view. It strikes me that running KSP in 32-bit mode on a 64-bit system could potentially be the root cause of all these issues. I wanted to ask you all how I might fix that, but I also wanted to let people know about this because if it turns out this really is what's causing my issues, it's probably responsible for a few other people's issues as well. Hopefully someone can tell me how to make KSP run in 64-bit mode, and then we'll know for sure whether 32-bit KSP is to blame for all these problems in Linux.

I've made a major discovery: my computer is running KSP in 32-bit rather than 64-bit mode. I suspect this may be the cause of all my problems. How can I make it start in 64-bit mode? Steam settings? Another script file?

Thanks for explaining that script file: I gave it a try and something isn't working. I think I may have specified the directory incorrectly? Here's what I'm looking at: ~$ Desktop/KSP.sh Desktop/KSP.sh: 2: cd: can't cd to /home/.steam/steam/steamapps/common/Kerbal Space Program Desktop/KSP.sh: 3: Desktop/KSP.sh: ./KSP.x86_64: not found As far as I know that should be the right directory. Here's a screenshot of my Kerbal Space Program folder for comparison: http://i.imgur.com/LaqQajr.png And here's the text of my KSP.sh executable: #!/bin/sh cd "/home/.steam/steam/steamapps/common/Kerbal Space Program" LD_PRELOAD="${LD_PRELOAD} libpthread.so.0 libGL.so.1" __GL_THREADED_OPTIMIZATIONS=1 ./KSP.x86_64 Any idea what I did wrong? As for the transition between the two orbit path drawing modes, I gotta say I think that is definitely what's causing my problem. I dunno how you noticed such a slight detail, but you nailed it. I wonder if there's a way to trick the game into staying in the close-up orbit path drawing mode even at large zoom distances? It seems like that would be a perfect fix, but figuring out how to implement that change is well beyond my ability. Perhaps someone more knowledgeable could take a crack at it? What would be really ideal is if the developers simply omitted the faraway draw mode from future Linux versions of KSP altogether. IMO the difference between rendering orbit paths in front of bodies versus behind them is a trivial one in terms of gameplay, and eliminating that transition seems like it would prevent this problem from ever happening again on every possible combination of drivers and hardware.

Thanks for the reply Sal_Vager. I think we can be sure this isn't an AMD-only issue, seeing as I do not have any AMD components in this computer. But I suspect you're on to something about OpenGL not working right with my particular drivers. I gathered what information I could about my graphics hardware, which is an Intel model, but before getting to that I have another thought: Intel's website has up-to-date graphics driver downloads for Ubuntu versions 14.10 and 15.04 ... but not for 14.04, which is the version I'm presently running. I installed 14.04 because that's what the Ubuntu website recommended, and I'm relatively new to Linux. I'm wondering if it would be worth switching to one of these newer Ubuntu versions in order to try out the updated Intel graphics drivers. I don't know the difference between these versions, but if Intel has stopped supporting Ubuntu 14.04 then I assume there's probably a reason. Any thoughts? This is a new computer, so if I'm going to try wiping my OS and switching to another it seems now would be the time. I'd like to know if you, or anyone else, thinks there's any possibility that a different Ubuntu version and the latest Intel graphics drivers are likely to fix my KSP problem. Here's the most relevant-looking information from my HardInfo system report (let me know if I missed anything important): Processor: 4x Intel® Core i7-5557U CPU @ 3.10GHz OpenGL Renderer: Mesa DRI Intel® Iris 6100 (Broadwell GT3) OpenGL Version: 3.0 Mesa 10.5.9 (Direct Rendering: Yes) OS Kernel: Linux 3.19.0-28-generic (x86_64) The terminal command "lshw -c video" outputs "configuration: driver=i915" along with some of the same information given by HardInfo. From this I take it that I am presently running the Intel 915 graphics driver. Here's the relevant info from my KSP.log file: OS: Linux 3.19 Ubuntu 14.04 64bit CPU: Intel® Core i7-5557U CPU @ 3.10GHz (4) GPU: Mesa DRI Intel® Iris 6100 (Broadwell GT3) x86/MMX/SSE2 (256MB) SM: 30 (OpenGL 3.0 [3.0 Mesa 10.5.9]) And here's a screenshot of my KSP graphics settings: http://i.imgur.com/SibFWhP.png KSP and HardInfo seem to agree on both the hardware and the OpenGL version that I'm using. From my limited knowledge it seems like outdated Intel graphics drivers are the most likely culprit, though I haven't seen any assurance that new drivers on a new version of Ubuntu would fix this particular bug. Unless someone can think of a different fix, a new OS might be my only recourse. Is there another potential fix I've overlooked? And if not, does anyone know which version of Ubuntu (14.10 or 15.04) is more likely to run KSP properly? Your advice is very much appreciated. Oh, and Sal_Vager, I'm embarrassed to admit I did not try your suggestion of launching KSP with that terminal command because I don't quite understand what I'm looking at. When you say to "change the directory," how would I do that? Am I supposed to include "/path/to/KSP" in the same line as the launch command? And what does this command actually do, anyway?

I'm a little confused, did you do anything other than re-install KSP? Did you re-install through Steam or via some other method? I'm having the same fairing texture issue and I'm curious how to fix it, thanks.

Thanks! (Original post now edited.)

My design can easily reach other planets, but KSP has a weird bug on my new Linux computer which makes interplanetary maneuvers impossible. I leave it to the judge's mercy to determine whether I'm allowed to actually claim the 500 points for orbiting another planet as part of my score. The offending bug is detailed in this thread: http://forum.kerbalspaceprogram.com/threads/134383-Orbit-Paths-Disappear-When-Zooming-Out-in-Map-View-%28Ubuntu%29 My score: (h + 2t = p) altitude is negligible and mass is roughly 8 tons ... 16 Plane Fly back ... 20 Payload has Kerbal aboard ... 30 Payload has science instrument ... 10 Payload has power generator ... 10 Payload has antennae ... 10 Payload is put in orbit around Mun ... 50 Payload is put in orbit around Minimus ... 100 Payload returns to Kerbin post-mission ... 50 For a total of 296 points. I took a Munar slingshot trajectory to Minimus, and after establishing a close circular orbit around Minimus my craft still had over 3,700 delta V remaining. I'm confident this would have been more than enough to make it to Duna and back, if my Linux bug had not stopped me from making a Kerbin to Duna transfer out of Minimus orbit. If 500 points are added for Duna and 50 are subtracted for Mun orbit, this yields a corrected score of 746. (If you doubt I could've made it back to Kerbin then call it 696.) The only disposable part of this design is a small SRB with tail fins. My design: Mission album:

I'm using Ubuntu 14.04 to run KSP 1.0.4 on a brand new Intel NUC with i7 processor and Iris 6100 graphics chip. Everything is in working order, with the exception of one rather upsetting bug: my trajectory and orbit paths disappear from map view whenever I zoom out. This makes planning maneuvers extremely difficult even for nearby bodies, and completely impossible for distant ones. The paths reappear as soon as I zoom in, but I have to zoom in so close that I effectively can't plan any useful maneuvers. I can't do any interplanetary missions at all, even though the game runs flawlessly otherwise. Suffice to say, this is a bummer. I did some searching around and didn't see anything which looked like a conclusive answer. I did try adding "LC_ALL=C" to Steam's KSP launch options because I found several people who recommended it as a kind of general fix for KSP issues on Linux, but in this case it didn't make any difference. I recorded a short video to demonstrate the bug, if anyone wants to see exactly what I'm dealing with. Please take a look and let me know if you have even the slightest idea of why this is happening or how to fix it: