alioth

For very large rockets I find that Mechjeb (and to a lesser extent, SAS) has far too high gain for course correction and tends to start the whole craft oscillating. In some cases Mechjeb's oscillations become divergent and only stop when the rocket breaks up. I've found for the largest rockets it's always best to manually fly them. Manned ones I usually do from FPV (first person perspective) because the navball is bigger in the IVA views making it easier to precisely control the attitude of the rocket.

I have a rover with a skycrane which must be launched 90 degrees from its landing attitude, which leads to a slightly off centre centre-of-mass. This lead to almost uncontrollable rockets when trying to launch. I found putting one of the small orange Rockomax engines on the "heavy side" of the rover stage near the top of the stack made for an almost always successful launch. (It feeds off the rover's fuel tank - I've got to remember to transfer fuel before detaching and landing the rover or bad stuff happens!) I've stopped using the skycrane for these rovers, since munar gravity is sufficiently low (the intended operating environment for this rover) I can land the rover on its tail and use reaction wheels to tip it onto its wheels after landing.

Without knowing the internals of unity (and given it's closed source and proprietary, we can't) I'm guessing you shouldn't hold your breath for it to be multithreaded. Unless you design your software to be multithreaded from the get-go, in the majority of cases you can't just bolt it on later, it often requires a complete rewrite. I wouldn't be surprised if 3 years from now, Unity remains single threaded. This seems like a particularly poor choice in this day and age (given that the writing was on the wall for single core performance ten years ago).

No, it wasn't the time my (3rd replacement) Mantis rover's descent stage (on account of a sloppy de-orbit and landing trajectory) smashed into the Mun after running out of fuel smearing an unfortunate kerbal over the landscape, but the 4th rover - after a perfect detach from the descent stage about 1m off the surface of the Mun, absolutely stationary, without even so much as needing to repair a wheel - within a couple of km while being driven towards the main base went over the edge of an enormous crater and got smashed to a million pieces as it rolled down the side. The kerbal driving did have enough rocket pack fuel to fly himself to the base and arrive very sheepishly without his Mantis rover. After losing the 5th rover in different circumstances (but again involving driving over the edge of a crater), a 6th one is now on its way (and will have to pick up the driver of the 5th who didn't have enough rocket pack fuel to fly back to base).

Well, to be pedantic, given all the cyrillic text on that image, it's what the Russians use not NASA. (But I'm sure NASA do the same, or perhaps even use the Russian kit).

And if the game design wasn't multi threaded to begin with, then it's going to be very difficult to add after the fact. Generally if you want something to be multi threaded you have to design it that way from the get go - trying to convert a single threaded program to something parallelized after the fact is generally very difficult and time-consuming (and effectively will require a rewrite of the thing that you're trying to make multithreaded). So I suspect we should not hold our breath for this one. It's a bit of a shame - the FPS really drops on my machine and the machine isn't even working hard, it doesn't even spin up its fans.