sal_vager

Sorry no not without a log from an attempt to start the 64bit version, it's also worth using this line in a terminal. ldd KSP.x86_64 | grep "not found" It'll list any missing libraries, you need to open the terminal in the KSP folder or use the cd command to change to the KSP folder, more info here

Yeah there's no button unfortunately, you have to [noparse] [/noparse] manually. Er, every download button on sendspace just tries to download crudware, and there's a lot of buttons... Found it, and yes it's using the Intel, I think you need bumblebee or nvidia-prime to solve this one, both will be in the software repository.

If the same stick or pad is plugged in before you start KSP, it should work, though it hasn't for everyone. This is actually a known bug and we're pushing to get it fixed for 1.1

Hi More Boosters, please upload the KSP.log from the KSP folder and Player.log from ~/home/username/.config/unity3d/Squad/Kerbal Space Program Pastebin, mediafire or dropbox should work fine for this.

That's really weird, I'm using LightDM but with Xfce rather than Mate, were you using Mate before and only changed the DM or did you change to Mate from Unity? (or even from Gnome) I'll assume just the DE, but can anyone else suffering from this issue please test this and confirm, if this is it then I'll add it to my Linux thread.

Well, fglrx is involved here: Native stacktrace: /home/lilian/.local/share/Steam/SteamApps/common/Kerbal Space Program/KSP_Data/Mono/x86/libmono.so(+0x894bf) [0xb6c264bf] /home/lilian/.local/share/Steam/SteamApps/common/Kerbal Space Program/KSP_Data/Mono/x86/libmono.so(+0x21980) [0xb6bbe980] [0xb774a410] [0xb774a428] /lib/i386-linux-gnu/libpthread.so.0(raise+0x36) [0xb77100c6] /usr/lib/dri/fglrx_dri.so(+0x21d2393) [0xb5e0b393] /lib/i386-linux-gnu/libpthread.so.0(+0x6f70) [0xb7707f70] /lib/i386-linux-gnu/libc.so.6(clone+0x5e) [0xb728bbee] The KSP.log ends with Kerbal Engineer creating an action menu: [LOG 20:56:36.702] ModuleParachuteFix.Start(): v01.03 [LOG 20:56:37.001] KerbalEngineer -> ActionMenu was created. Then there's the segmentation fault above, then nothing... Cantab's right, you need to install a clean copy of KSP, start a new save and launch a vessel with the MPL, if it still crashes we can work on looking at fglrx, but I have to say I don't have this issue and it's the first time I've heard of it, so I don't think it's being caused by the MPL directly. Please reproduce this on an unmodded game and get back to us.

Oh they have, but there's too many different things that could have caused this, we'll need your save folder as well in case it'll take editing to fix

Would you consider fitting a pair of rudders so they are partly clipping? This will double your yaw stability, bring the CoM back a bit further and allow you to use the rudders as a Shuttle style airbrake. Edit: I noticed there's a very long red line in your pic of the aero forces, can you fit stuff to the front internal node of the cargobay or will it not connect?

Hi whateverthing, please delete the settings.cfg, and make sure that your controller is plugged in every time you start KSP.

Okay I'll install the addons and test this in a bit, maybe I can save it, can't promise though. If you have a working quicksave from before this it'd be a good idea to back that up as well. EDIT! I think I fixed it, the saves loaded fine on Linux, but I had to copy the SP333 over from the earliest save, set the Kerbals to Assigned, unclaw and reclaw the Ore Seeker 1.1NR, and do the same to the probe attached to Ast. ZBV-034 after manually offsetting it outside of the asteroid. All the vessels load and I can return to the KSC without incident, you can find the save here [Dropbox]. I don't know what caused the issue to begin with but the claw is a suspect due to being a known buggy element, and I guess linux is a little more robust when handling save files.

Please provide more info.

Glad I could help

Ahh since you are using Steam you can just make Steam start the KSP.x86_64 for you, right click KSP in Steam and open its properties, there is a box called "Set Launch Options". To make it start KSP 64bit put this in the box: %command%_64 For the GL optimisations as well, use: LD_PRELOAD="${LD_PRELOAD} libpthread.so.0 libGL.so.1" __GL_THREADED_OPTIMIZATIONS=1 %command%_64 The script might have failed if it's being run by the terminal emulator directly, right click the file and check what the "Open with" program is, I had to change mine from the xfce terminal to just sh (had to add it manually because the terminal was unable to cope with the spaces in the cd command, and I didn't want to put underscores in all my file paths). As for changing how orbits are rendered, the whole UI including the orbit rendering is replaced in 1.1 so we'll have to see if that fixes it. Edit: just saw the missing username in the path, yes that would be it, thanks cantab!

Well, "no hardware support" will only show in the settings.cfg when trying to enable PPFX edge highlighting, which needs to have anti-aliasing enabled in the KSP settings as well, even if it doesn't actually work in-game, so turn on AA and you'll be able to turn on PPFX. KSP.x86_64 should have started on a 64bit Linux install unless something is missing, the Player.log will say what happened so please upload that, and also check that KSP has the libraries it needs by using the ldd command in the terminal, like this: ldd KSP.x86_64 | grep "not found" More info is here. I have orbit line rendering and no fairing flicker in both 32bit and 64bit KSP on 64bit Ubuntu by the way.

I just used normal 2x symmetry, if you look at the craft I fixed you will see the nacelles are not separate parts, one is the symmetry clone of the other. If the strict part attachment rule was being honoured by symmetry clones this issue would not occur, if you read through the Imgur gallery you'll see what I mean, so next time this happens to you just rettach the nacelles to get it to work correctly. It would be useful to know exactly how you and Clouds are able to trigger this issue when most other players are not, so if you can consistently reproduce the effect with a simpler craft please post step by step instructions.

Don't worry about it, though I'm not an OSX user so if I can't help with an issue on OSX I'd rather not post, I'd just be confusing rather than helping.

I honestly don't know if upgrading will fix this, but it's easy to upgrade from one version to another without reinstalling [Link to updating Ubuntu] (Canonical make things too easy...) Your hardware should be fine and Intel drivers for Linux are supposed to be very good, so really this shouldn't be happening at all, but interestingly the rendering of orbit lines in KSP changes slightly at exactly the point where yours and others disappear. Before that point they do not render behind planets, but after that point they render on top of other objects, so they are definitely being drawn differently and there's a slight hiccup in zooming when transitioning between the two draw modes. I can see the lines even if I zoom out really far, but for some reason for you and others that different mode is just ignored and you get no lines. This is what makes me think the driver is the issue here, I already know that some drivers cannot handle the editor gizmo transparency, they are magenta when using the proprietary drivers, so it follows that some can't handle the orbit lines when in this "cover everything" draw mode. Unfortunately Intel GPU's on Linux don't have many drivers to choose from, actually I don't think older drivers are even available without reverting to an older distro, but there's a few fixes here that may still work and are worth testing. As for the line above, it's supposed to force different behaviour from the OpenGL driver, and some players say it improves performance but I haven't noticed it. Probably the easiest way to use it would be to make a script, this is a text file that starts KSP for you, I and others covered this recently here. Put basically, make a new text document, call it start_ksp.sh and add the lines from that link depending on which version (KSP.x86 or KSP.x86_64) you are starting, so it looks like this: #!/bin/sh cd "/home/user/games/Kerbal Space Program" LD_PRELOAD="${LD_PRELOAD} libpthread.so.0 libGL.so.1" __GL_THREADED_OPTIMIZATIONS=1 ./KSP.x86 Changing the path in quotes after cd (cd means change directory) with the path to your KSP folder. After saving the file you'll also have to make it executable, just right click it and you can edit its properties, there will be a checkbox to allow it to be run as a program.

Unfortunately Claws fix uses module manager, and I'm finding more and more that MM is causing issues lately so I can't rule it out as a cause. You better post the logs and the save folder, I'll try loading it but I'll have to install KIS and KAS to do so, so this is going to Modded Support.

Anything that isn't a pod or cockpit, I just can't get my head around that adapter causing any issues, it's pretty basic as parts go. I'll try your steps and let you know what happens.

Okay, first I'd suggest you copy KSP from the desktop to C:\Games and try the copy, I'd also suggest disabling any Windows compatibility modes you might be using, such as Windows 7 mode. I'd also delete the settings.cfg file and start the KSP.exe directly, not via a shortcut, and I'd try a new save. If it still fails I'd try updating my graphics driver, after that please upload the full log and the report from dxdiag and I'll see if anything stands out

Actually the OSX tags are just as valid as any other, but misreporting will confuse people trying to help. It looks like SURFACE_FX = False in the settings.cfg is what you need, not sure why the settings screen option failed for you, there is a bug with settings being reset if a bound controller is not attached when KSP is started though, that may be why you lost the setting. Changing the settings.cfg changes it in the settings screen as well and it persists across restarts, and I didn't have any ground smoke effect with it disabled. Hope this helps

I suspect Steam may be installing duplicate files, if you delete the GameData folder then verify the cache in Steam, it'll redownload it and should fix the issue.

Okay, so knowing what I know from my previous testing I poked your craft a bit, and sure enough it was not possible to attach a part to the front inner node of the starboard cargobay, it was already connected to the fuel tank in front of it. And flying the craft showed excessive drag on one side, just as you say. But it was fixable in the same way I outlined above, resulting in a low drag craft, further testing showed the drag from the bad bay to be just as high as other cargobays with no streamlining at all. Here's the fixed craft [Dropbox link] The issue with drag can be solved, and is only a symptom of another issue, that being the strict part attachment rules ignored by symmetry clones and can only cause an issue with bays as they are the only parts with dual nodes. But that is an issue for the official bug tracker, this is not the bug tracker, this is the support forum

Had to remove an inflammatory post, and a reference to that post, please don't argue politics on these forums and definitely don't post anything libellous, thank you.

Sounds like a job for the grand forum test thread!