steve_v

I use VirtualBox and QEMU about 50/50. But not for games, as games in any VM suck hard, IME. Running the script via "double click" - dunno, depends entirely on your desktop environment / file manager. I don't use Ubuntu (And I tend to run everything from a terminal anyway ) but: Is from Ubuntu 14.04... so maybe?You could perhaps change the file association to open with '/bin/sh'... but again, depends on your DE. - - - Updated - - - OTOH, quick use of a search engine reveals the likes of this.

if [ $PATCH_090 -eq 1 ]; then echo "0099e747: 00" | xxd -r - KSP.x86_64 echo "0099e74c: 00" | xxd -r - KSP.x86_64 fi This bit probably isn't needed any more, and since it directly modifies the binary I'd advise caution with it. I don't have any issues without that patch so just comment it out. Everything else in that script is pretty generic, and should work fine with the current version. I've never mucked with VMware, as it's not open-source and I dislike VMware for... other reasons. That said, your problems are most likely due to the virtualised GPU in the VM - this is what the forced disable of AA in that script is intended to fix, so give it a shot. You'll probably want to set up your guest OS with a window manager/DE that doesn't use OpenGL (e.g. XFCE) too.

I'm sure going to try building me one of those. As for racing... let's see how exploding goes first.

Ya, I too prefer the old (though still not optimal) setup.

Apparently not, but one could be forgiven for thinking that it was a little insane.

Sounds rather familiar, mine was a hand-me-down 386SX25 with HGA graphics, 4MB RAM and an 80MB HDD... wringing performance out of that brick was a bit of an art, especially with no FPU.Eventually I accidentally put the CPU in backwards... and out came the magic smoke.

Such is the crux of the problem, it's still too unpredictable for an official release. It appears the force is with you.

You returned the intact experiments, right? not just the pod? And you "kept" the data, not transmitting it or discarding it? Silly questions perhaps, but I can't think of any other reasons right now...

Am I right in thinking that removing "resourceFlowMode = STAGE_PRIORITY_FLOW" from the part config will put this back? Jets have it, rockets do not...

The overheating of cubic struts and other small parts under certain difficult to accurately pin down circumstances is a known bug. AFAIK no solutions as yet except to turn down conduction factor (or install Deadly re-entry, which does the same). It's not a fix, but it does seem to help with the thermal instability. As for destroyed / detached parts showing in staging... I have seen this too, but it doesn't seem to be causing any real problems and everything appears normal after leaving and returning to the craft.

Yup, all of the above^. Here's hoping they also do something about the lack-luster OpenGL performance and lack of x64 on OSX. Not that I'm crazy enough to own a Mac , but everyone deserves a fair go - it's not all about Windows.

I seriously doubt anyone on the Linux kernel team has the slightest interest in becoming "mainstream", whatever that actually means in this context. The open source drivers don't support the latest GPUs yet because the manufacturers haven't been nice enough to provide said support, or even the required information for the volunteer kernel hackers to write that code. Linus Torvalds had a few choice expletives for NVIDIA on that very topic not too long ago. As has been mentioned, no video on boot is, with 99% probability, due to lack of kernel modesetting support in the nouveau driver. Disable modesetting, blacklist the nouveau driver or both. Then boot to a console and install Nvidias binary driver. Direct any further complaints to Nvidia. Granted, support for the latest gizmos comes a bit slower when the OEM is blatantly un co-operative, but who you gonna blame here? If hardware manufacturers would get A into G and actually uphold the supposed industry standards, this whole mess would be a lot less trouble. As for hardware support, on my current system: GPU: check (Nvidia driver) CUDA/OpenCL: check, crunching for GPUGRID right now. Wifi: Check, in-kernel driver. Webcam: Check, in-kernel driver. 8-port SAS card: Check, in-kernel driver. Bluetooth: Check, driver downloaded and compiled from manufacturer. Installation was neither painful nor any more time consuming than setting up Windows. - - - Updated - - - If you want help, I'll do my best to assist. If you just want to complain I'll happily argue with you.

Aha, that would actually explain some other (non BB related) strangeness I have noticed in the way male vs. female kerbals react to impacts when ragdolled. I guess it's either a stock bug or someone over at Squad has a very strange sense of humour...

No. The day that happens to GNU/Linux will be the day I roll my own distro (again). Versatility and diversity are the very characteristics that have allowed GNU/Linux to succeed thus far. Make everything so simple a 2 year old could figure it out and you simultaneously slam the door on anyone who wants to innovate and find new ways to use or modify the software. GNU/Linux runs on everything from a network router to a smart TV to the meanest supercomputers in the world. Microsoft cannot claim the same, precisely because of this dumbing-down and "one size fits all" attitude. Good. Excellent in fact. This way Linux gets only the users that are willing to contribute to the project, rather than complaining. You may have noticed, people have different ideas and different needs. I, for example, do not agree with you on this point. Would you like everyone to have identical houses, clothes, cars, ideals etc. too?As far as I can tell, you're just whining because you don't have x64 for your favourite OS. Life is Hard. Despite it's shortcomings, Unity3D is way ahead of the curve in terms of cross-platform compatibility. It'd be nice if it worked equally well on all platforms, but that's just how it is at the moment. Wait for U5, then re-evaluate. As do I, sir. As do I. Learning is good, and new toys are interesting.

No logs, no complete mod list == no clue. Seriously, the logs are the first place to look. You could even try looking yourself, it might be quite obvious which mod is freaking out.

Pics will be spectacular though.

We will probably have to ask the mice about the true purpose of kerbin...

SSTO spaceplanes are a challenge, and challenges are fun? Or because 100% recovery for landing on the runway without anything falling off? I agree, a KSC map marker would be nice.

You're missing a '/'... try 'LC_ALL=C ./KSP.x86_64' './' denotes the current directory, .KSP.x86_64 is a different file name. - - - Updated - - - Yeah, that'll work too Probably some "safety feature" of whatever DE *buntu is using. - - - Updated - - - Pass, don't have Ubuntu or AMD. You could try setting it manually in the settings.cfg file I guess: SCREEN_RESOLUTION_WIDTH = 1920 SCREEN_RESOLUTION_HEIGHT = 1080 Are you set to fullscreen? What's your current desktop res? you probably can't set it above that... Hint: 'xrandr --current' I'm guessing its some vagary of Unity or your graphics driver, but that's just a guess. - - - Updated - - - This editing posts thing makes for an interesting format... if a little hard to follow

$ ls KS* KSP.exe KSP.log KSP.x86 KSP.x86_64 That's a fresh archive from the store. Dunno why there's a Windows binary in there, but there it is.

Holy ...., that's a lot of radiators You should be able to nail a re-entry without any special parts (and with some practice) but airbrakes will help a lot.

Don't open the .exe, that's the Windows binary. You want 'KSP.x86_64', it should be marked executable (*nix equivalent of .exe file extension) already but if not a 'chmod +x KSP.x86_64' will make it so. Dang ninjas Also worth noting, I hear "had to reinstall" far to often... almost any screwup can be fixed without a reinstall on GNU/Linux. Bungled GPU drivers count as a fairly minor problem in that regard. My current desktop is a ~7 year old install and has been several different flavours of Debian in that time, not to mention a bunch of hardware upgrades. No reinstalls though

Part Wizard looks like it might do what you want, though I haven't used it myself. Otherwise, move the camera inside the craft (may need to reposition craft first) to get at hidden parts.

Interesting, I've had this happen to me too... Why would a ragdolled kerbal have a different density to an active one? Very strange.

Monodevelop + the source from git. There's more information to be found on the forums, have a search around. Do not under any circumstances ask for support with KJR on the Win64 build though, you will draw much ire. Honestly, I'd wouldn't recommend the Win64 build, 32bit + ActiveTextureManagement + some restraint re. mods or x64 on GNU/Linux will serve better. There are good reasons it's not just a config edit.