Brotoro

Since the Moholes were just terrain glitches (and not intended Easter eggs), how do you know they haven't gone away after the refurbishment of Moho's surface in 0.21?

Practicing and testing in version 0.21. Yesterday was a bit disappointing because of the SAS situation in version 0.21...rockets that used to be fun to fly were suddenly a huge struggle. But once I got the 0.21.1 update downloaded, all was happiness and light again. My Crew Carrier SSTO worked fine (under 0.21.1), and I was pleased that I even got it to land back at KSC with no MechJeb. But where MechJeb would have showed off and landed the rocket on its engine flames, I used too much of the landing fuel just to keep from overshooting the KSC, so I landed with the parachutes and a little engine thrust cushioning.

Excellent mission! Good job, Tokay.

Resources for me, please. I don't even know what career mode is and why I would want it.

One thing that isn't important in your sandbox, but will be important when you have to PAY for your parts: One Mainsail is much cheaper than five LV-T45 engines.

I use the avionics package or SAS (previously the old ASAS) on my rovers... and I also use the rover control keys re-mapped to i,j,k,l for steering... Could you please allow manual inputs from the rover steering keys change the SAS heading lock? Currently in 0.21 when I steer with SAS turned on, the rover will turn...but when I release the steering keys, the rover will turn back to the previously locked heading. It would be very helpful if the ASAS system allowed rover controls to change the SAS heading lock in the same manner that yaw, pitch, and roll inputs do. Otherwise, I have to keep toggling the SAS with T or F to lock in a new heading after turning the rover. Thank you.

It's not a "problem," but I don't think it occurred to C7 that people using rovers might want the rover steering to change the heading lock of the SAS system when they do manual steering inputs. I hope that gets changed.

Zephram sounds like he's having trouble with all the diodes down his left side.

Of course. But hopefully there will be time in the future for improvements. So it helps to point out possible improvements now.

Hyperion is quite unusual in having dark areas in the bottoms of many of its craters (which don't look like the uniformly-dark bottoms of the nu-Mün's craters in any case). The various theories I've heard to explain Hyperion's dark-bottomed craters rely on the fact that Hyperion's surface is primarily made of ice, and sublimation of that ice can leave darker dust behind...but the Mün looks like a rocky object (and it's distance from Kerbol would make explaining an icy surface for it difficult -- the "Minmus Problem" all over again), so I don't think the same process is at work here.

It's not about being OUR moon. It's about how solar system bodies form. There is no physical mechanism that should give you lots of craters of two different sizes...you should get something much closer to a power law distribution. So the nu-Mün looks weird. And maria form later in the history of a moon, when there has been time for radioactive heating to melt the interior enough for the basalt flows to fill up the large impact features...so there should be many fewer craters on the maria (this was an important consideration when choosing the initial Apollo landing sites). And even if there was a late bombardment that added lots of craters to the maria, it should have added even more to the already cratered highlands. Now, if you want to tell me that Squad chose to order a Mün from the Magratheans that deliberately looked unphysical, I'm fine with that explanation.

Why do my Peril-Sensitive Sunglassesâ„¢ keep going opaque whenever I let Jebediah pilot the ship?

I don't agree.

You mean my possible explanation #2?

I was hoping part of the delay in releasing 0.21 was some tweaking being done on the Mün...but it appears not. It still has basically two different sizes for the small craters... And lots of craters on the maria... And the craters have dark bottoms. None of this looks realistic. I think the idea of procedurally generated craters is great, and this looks cool and all...just not realistic.

The orientation of the control pod is not really the issue. My BirdDog rover/plane has its controlling cockpit oriented horizontally (so the yaw keys, a and d, can turn it), but I do my controlling from the rover keys remapped to the i, j, k, l keys. With the old Avionics Package on the plane, I could turn with j or l and the rover would carry on going in the direction I pointed it. But with the new Avionics Package, if I use j or l to turn the rover, after I release the key, the rover will slowly move back to its previous heading. If I steer using the a or d key, the rover will stay where I pointed it when I release those keys...but it turns slowly, since it's just using pod torque to do the turn. What I have to do now when turning using the j or l keys is to tap the f key once I am pointed the way I want...and then the rover keeps going in that direction. I had to do this in the past with other rovers that had the old ASAS on them, so I'm used to this. I don't know that having an option to disable SAS control on my turning axis would be the best solution, however, since I still want SAS to hold my new heading (and if SAS was selectively disabled on that axis, I wouldn't have that heading lock). But I would like the new SAS to allow rover steering inputs to change the SAS's heading lock (the same way that the yaw, pitch, and roll work) when I release the rover steering control after manually changing the rover's heading.

I already knew the theory. But as for the practicalities of how to do it in KSP, I learned much from watching Stomp Thompson's videos.

Jet engines don't work on Duna -- it has no oxygen in its atmosphere.

They are there. What is your question about them?

Deactivate fuel flow from the front tank. Then the plane will be LESS likely to pitch up violently as time goes on. Just remember to reactivate the front tank just before the rear tank runs dry.

Good. I thought my eyes were going.

I tried to find Magic Boulder by editing the quicksave file to put a ship at the same point in space and time where my ship was the last time I visited Magic Boulder in 0.18 ...but I see nothing there. The ship does end up in what appears to be the correct orbit around Ike, but there is nothing in the vicinity. So, either... 1) Magic Boulder is still MIA 2) Magic Boulder is elsewhere 3) I did something incorrectly when I edited the save file

Go to Map view, then Recover the capsule (button in bottom left).

That article (from 2004) says that NASA did create protocols for contacting officials after this incident.

I did all this, on and off, during the last couple weeks, still in version 0.20. I don't know if it will be possible to update my old save game file to 0.21.