DerekL1963

I am *so* stealing this.

Nuclear reactors can be quick on the draw or slow on the draw, it's all a matter of how they're designed... and submarine reactors are VERY quick on the draw. They have to be, because there are situations where you want to change your throttle settings rapidly, such as needing to go from all ahead full to all astern full to avoid hitting something, or when maneuvering in a confined space. The battery is an emergency backup and is used mostly while we claw our way up to the roof so we can raise the snorkel mast and start the emergency diesel generator set. If we're somewhere where we *can't* do that... well, that's why submariners are a special breed, because we'll have to fight like hell to rectify whatever caused the loss of electrical power before we die. (Ah, I should introduce myself - in a former life, I was FTB2/SS Lyons, USN Submarine Service 1981-1991.) Commercial power reactors can all be throttled, because otherwise they couldn't be started up... but their throttle response is slow by design, because it increases safety. They generally aren't throttled though, because stable operating conditions are the safest. The also generally run at full power because that makes the most economic sense given the cost of fuel. Not even close. The RBMK reactor used at Chernobyl was unstable at low power, but that's not what caused the explosion. The explosion was caused by the low power instability combined with a flaw in the control rod design that actually briefly *reduced* moderation as they were driven home. So a spike in power combined with a reduction in moderation, which lead to a further spike, equals pieces of reactor scattered across the landscape. Um, no. There was not a lag of "hours" between control input and reactor response - such a reactor would be impossible to operate. (And hideously unsafe even by Soviet standards.)

Do Kerbal accelerometers have a sensitive axis? If so, it's quite possible for it to be reading zero despite the vehicle being accelerated... if the sensitive axis isn't parallel to the direction of the pull.

And that goes triple for VASIMR - it's a power hog, not the miracle drive it's sometimes believed to be.

If the mine was viable at all that's generally a (relatively speaking) slow seepage - not the Niagara Falls quantities that a reactor needs for cooling.

Keep in mind that even if you select Ap for your burn, the actual maneuver node will appear some time before Ap as it's generally most efficient to split the burn so it's midpoint is at the node.

I've sent a probe to Jool with two Gigantor, two RTG's, five fuel tanks, and eight batteries and have been able to do long burns quite easily so long as I'm not in Jool's shadow. The tricks to ion engines are: Patience. Roll your vehicle so your Gigantors get full sun. Monitor your throttle and resources to minimize your electrical depletion rate. Patience. They'll get the job done even out at Eeloo, but it's not "firewall the throttle and done in a minute or two". Let the game run in the background while you browse the forums.

How long it takes to leak depends on how much effort is put into sealing... the early Mercury capsules leaked up to 80cc/min! That was no problem with the shorter missions, they carried enough reserve O2 to make up for the leaks, but Faith 7 had to be heavily modified in order to remain in orbit for 24 hours.

Actually the number of protesters and lawsuits against RTG powered spacecraft has dropped noticeably over time - to the point they were virtually absent for Curiosity.

Not quite true... there's only Soyuz for the manned side, but there's also Progress, Dragon, ATV. and HTV over on the unmanned side.

Today, we went to the Mun and returned safely, but not without a little trouble on the way... Mission Control forgot to enable the autopilot, and when the launch clamps released gravity took over. Jeb was philosophical about the whole thing, reasoning that since the craft had technically been in free fall between the clamps releasing and the booster hitting the ground he'd earned his flight pay for the day. He wasn't very happy to learn that there wasn't any flight pay to begin with. The second flight got off to a similarly inauspicious start... Mission Control forgot to enable autostaging, resulting in "severe underperformance" of the booster. Quick work by Mission Control did manage to bring Jeb down safely not too far from KSP. Once again, Jeb was philosophical, reckoning that today was a fine day for a swim while waiting for the Kerbin Navy to come fetch him. When he was informed that there was no such thing as a Kerbin Navy... his reply was ungentlemanly and unprintable. Since Jeb was still swimming home, Bill volunteered for the next flight, reckoning that it would help him get dates. After a stern lecture to Mission Control about paying attention, he climbed into the capsule and blasted off... Mission Control did however take a moment to sneak this shot as the Mun rose over the horizon right at the end of the TMI burn. Braking into Munar orbit... Kerbinrise... Bill was getting a bit seasick from watching the Kerbin landscape zoom by just 10k below while Mission Control was setting up cool screenshots... and insisted that we start the landing sequence. After a bit of trouble getting the engines to light, Bill began his descent. (Seriously, Mechjeb wouldn't fire off the engines until I right clicked and enabled them... dunno why.) Contact light! Bill enjoys a moment on the Mun. I'm not sure if that smile is one of joy for being first on the Mun, or terror that his life is still in the hands of Mission Control. Kerbinrise again, right at the end of the TKI burn. Bill, safely on home on Kerbin... He told Mission Control to "bring on the babes!". We didn't have the heart to tell him.

Even (space) programs using current hardware (most of which is old enough to be considered legacy by consumer standards*) tend to avoid Linux (or any other commercial OS) for pretty much that reason... It's just not suited for the task. Hard real time and deterministic behavior is... very hard (read; expensive) to accomplish and pointless for PC's, so consumer grade OSes don't even try. I think a lot of people don't realize there's a whole heck of a lot more to the computer world than consumer hard- and soft- ware. *Mostly because consumer grade gear is on permanent 100 000× time warp because it's driven by the bottom line over pretty much anything else. Space programs want proven reliability and 110% certainty. An obscure processor or OS bug or one-in-a-billion convergence that causes a fault that causes KSP to crash is no biggie for you and me, but when a half a billion dollars or lives are on the line, that's generally unacceptable.

Throttle up *before* releasing the launch clamps... Oh well, any landing you can walk away from is a good landing.

Yes, there's a very good reason - Linux essentially didn't exist when the main control systems were being designed and developed. (Some of this stuff runs back into the late 80's.) By the time Linux was anything even remotely approaching mature enough to be considered for such a purpose, the station's design was long since frozen.

I've built and launched several probes with nothing but probe cores, and have no problem maneuvering with them. The vehicle has to be small though, or you need several of them.

Fuel transfer is complicated and difficult, and the associated pumps, piping, and couplings add complexity (things to go wrong) and weight. Also, there's considerable ram drag when the atmosphere tries to flow between the stages. Also supersonic and hypersonic flow can do funny things - forcing the stages apart at one speed while sucking them together at another, adding significant dynamic forces. Then there's the issue of all those interacting shockwaves....

I dunno. I just start it loading and then head out to the porch for a smoke. It's done by the time I get back.

Jool... after building a Really Big Rocket with a Really Tiny Payload and accidentally ended up Kerbal orbit...

I saw KSP in a friends FB feed, and had to give it a try... now I'm semi addicted and losing sleep.