steve_v

Hmm, can't say I'm convinced TBH. Better the devil you know and all that, especially since I can see the code. Shall I assume that anything curse produces will likely be closed source? Also, appreciate the (possibly unintentional) heads up on latest CKAN issues.

Sorry to say it, but KSP is most definitely the buggiest released game I have played. A testament to the awesome concept though as anything comparable, bugs wise, never got past 5 minutes game time.

Err, this is a thing? As in people actually want this? Much confused. What does it offer that KerbalStuff + CKAN doesn't? Honestly, I haven't used curse in... well, ever. It's horrible, at least in comparison to KerbalStuff.

While possible, they tend to be time consuming to build and both fiddly and temperamental in flight... I'd suggest building a few "normal" VTOLs with separate lift engines first. If you don't have any reason to stay totally stock, both the Mk.2 Expansion and Quiztech Aero part packs have some nice VTOL lift engines that work and look a lot more like the real thing.

IMO it was only a matter of time before this blunt tool broke something it shouldn't or enabled a fool to do something dumb... And started this all again. Pass the popcorn, this ought to be good.

It's been a while, but I recall openelec was pretty good. Or just install XBMC/Kodi/MythTv on any old distro if you don't mind some setup work.

Agreed, however experience tends to reveal that "common sense" isn't actually all that common. So you get what we see here today.

No, if you don't know how to build a car you shouldn't be allowed to drive one that has known problems and cannot be serviced by a mechanic or granted a warrant of fitness. Go drive the supported 'car' and you will get support from the pros, otherwise leave alone the thing you do not understand. Making it so easy to do simply opens the door to people who don't understand why they shouldn't. It was made 'hard' so that those willing to learn and fix issues themselves still could, while the ignorant were not spamming useless bug reports.

I have not mucked about with a laptop in a long time, so this may be out of date: IME, many laptops use(ed) the battery as a kind of power filter / buffer, as such some machines will not power up at all without some battery (even a dead-ish one) installed. If this is the case with yours, weird things may happen without a battery, and if you have particularly unreliable mains you could even do damage to the machine. The only solution I see here is the obvious one: get a new battery. If you must run without one, at least plug it into a surge protector.

Oh yay, here we go again. I truly do not understand why Win64 users (ok, not all users, but obviously someone did it) must repeatedly shoot themselves in the foot. The warnings were not enough. Again. @the nit who started this again, whoever you are, thanks a bunch. You have a) made life harder for those who run Win64 and keep quiet about it, and aggravated one highly respected modder. Not just any modder mind you, but one who provides a core facility that many other mods rely on. Here, folks, is a perfect example of why the automated "unfixer" should not exist. While it makes life easy for those willing to play nice, it also makes things far too easy for the few who are entitled and dishonest enough to ask for support while hiding the fact they are running an unsupported build. RIP x64 ModuleManager, and hopefully RIP unfixer. If you want to run Win64, learn to code. Again, no amount of well intentioned warnings will fix this, it's been tried again and again. Please stop now.

CKAN says: 104. There's some split mods counted twice ofc. KSP-AVC says 42. I say, whatever is fun

Well I've certainly been able to reproduce it in stock, though FAR does exacerbate it, for reasons explained previously.

Ahh, but vernors for "soft" landings. And why ya think there's so many wheels? Can stand to loose a few All other parts rated for impact

Set the top of the stack as the root part, save it as a sub-assembly, then put it on top of a rocket. Or flip it upside-down and build the lifter under it. You may need a bug ugly fairing to keep it out of the airstream on launch though, time to get creative. My personal favourite is to build a skycrane type landing stage with the tanks parallel to the lander and radial engines... then the lander can be launched facing the "right" way. - - - Updated - - - You can get some pretty funky things to orbit, I can't remember where this was going... but it worked nicely I got bored with slow rovers, that'll do 150km/h+ on the mun

Yeah, you'll need a mod for that

Yeah, that's a good point. Any mods involved?

Are you out of electrical power? Check the command pod or probe core. No power = no control, but if this was the case you wouldn't be able to stage either... so ?? What does the right-click menu for the engine say regards it's status? The command pod / probe cores "reaction wheel" (magic gyroscope) will use power. This might be your mystery drain. Engines that show electric charge do so because they have an alternator - they should generate electric charge when running, not consume it (except ions OFC). Pics (with the engine and command part right-click menus open) might help here. - - - Updated - - - Oh, and welcome aboard

Ok, just to get this straight, Are you trying to install Nvidia drivers (for your real GPU) inside a VM? Unless VMware is set up for PCI pass through (No, I don't know how, but apparently it's possible) that's not going to work. The guest OS won't see the real GPU but rather a virtual GPU provided by the VM, this is why games in a VM suck. What's the output of 'lspci | grep VGA' inside the guest OS? Is your Nvidia card listed? If it's not, you are running on a virtualised GPU and the Nvidia driver won't work anyway. FWIW, the guest OS video driver for the virtual GPU is in 'xserver-xorg-video-vmware'. Long story short, don't use a VM, install GNU/Linux on real hardware.

Yeah. Dunno who decided to slap a big "1.0" on the side, but they must be playing a different game to the one I bought.

While I would like to believe that bugs will be fixed in due course, reality and past experience beg to differ. The claw has been extremely buggy since the day it was added to the game - at version 0.25. No fixes have been released for this issue by Squad. Meanwhile, the issue has become so well known that a community fix is now becoming available (thanks Claw). If this were an isolated incident, all good. But it's not. Each new release adds more features and more bugs, while old, well recognised bugs continue to be (or so it seems) ignored. Maybe Unity 5 will be a silver bullet, but I have my doubts - just look at the appalling mess the 1.0 release was. If it were only the new bugs that were unfixed, again, all good. But it's not. The claw bugs are old bugs, bugs that should have been sorted long before 1.0. Instead we get more save-breaking "features", even more bugs and some vague promises of undisclosed improvements with Unity 5. Want to bet that will come with more bugs too? I've been being patient regarding this particular issue since 0.25. My patience is finite. So, when can we expect some fixes for the well recognised bugs? I hope they will be sorted out with the Unity upgrade... but I doubt they will be, because history does repeat.

Likewise. My main gripe with VMware is that they're ripping off Linux, in breach of the GPL. Whether this is actually upheld in court is of no concern to me... there's clearly Linux kernel code in there.

YAnother long shot: You don't have any doubled up parts (z-fighting is a dead giveaway) do you? I find that the symmetry system does get a bit janky at times, and can end up duplicating children of mirrored parts inside each other. Failing that, I usually just pull bits off until I find the culprit. Do you see the same if you duplicate the design from scratch, or is it just this particular craft? It also looks to me that your lift vector is somehow rotated anti-clockwise, however I've been running FAR for so long I have little idea what stock aero is up to these days.

Ironically, installing Deadly re-entry also helps with deadly non-re-entry (buggy) heating... as it sets conduction factor lower than stock. I do wish this instability in the thermal system was sorted sooner rather than later though, it's a real ship-killer. And it's somewhat annoying that it keeps getting attributed to FAR.

There was an issue some time ago: unequal attachment strength / rigidity on mirrored parts causing uneven wing flex and therefore roll, I'm not sure if it was fixed or not. It would be easy to test with the addition of some struts though.

While some distros are focused on home PC users, the vast majority of the GNU/Linux market is on servers. Where GPUs are largely irrelevant.Also, what "money coming in"? You didn't actually pay for your Linux distro, did you? It would of course save considerable time and duplicate advice if you mention the things you have already tried, no?Forums catering for the distro you are using might also be a better place to look than the KSP forum (no disrespect to users of said forum intended), as this is a general hardware issue not specifically related to KSP. If you're certain it's not picking your IGPU over the discrete card, you could also try forcing a generic VESA mode at boot, by passing 'vga=<mode number>' on the kernel command line. Those should be supported by everything, unless of course Nvidia is playing truly silly games with us again. Again, once you have some video up, install Nvidias binary driver - after checking that your card is actually supported OFC. - - - Updated - - - Lean you say? How about RatPoison?The inspiration for the name is particularly amusing