DerekL1963

Yes necessarily. Except at the smallest size (where the weight of the engine dominates), if you want the same d/v as a NERV a conventionally powered vehicle end up heavier. That's a mathematical and unavoidable consequence of the drastically lower ISP of those engines. (Or to put it another way, your quoted comparison of the weight of the engines is dramatically and grossly incorrect and misleading because you leave out the weight of the fuel.) Here's a simple comparison: A NERV (vacuum ISP of 800) producing 5k d/v: A Poodle (vacuum ISP of 350) producing 5k d/v: A Rhino (vacuum ISP of 340) producing 5k d/v: (Even though the Rhino's ISP is only slightly lower than Poodle's, it requires much more fuel because it weighs five times as much.) The math doesn't lie. The math never lies. Except at the very smallest scale, where the weight of the engine dominates, a NERV will always have a dramatically higher d/v for the same weight due to it's dramatically higher ISP. Always.

Chang-Diaz didn't do anything to me. What 'did' something to me was endless posts (such as yours) the pronounce the VASIMR to be a viable solution even though (as you now admit) it's still very early in development. As it stands, VASMIR is a power hungry beast - and requires either solar panels of outlandish size, or a very heavy reactor and either way results in a tug with an impractically small payload capacity. (The latter especially when compared with it's cost.) For VASMIR to be practical requires serious breakthroughs in it's efficiency or in the efficiency of it's power supply - or magic pixie dust. (As a point of reference, the current model requires 200KW - the ISS's arrays produce 120KW.) I'm not judging the drive, I'm judging the ungrounded assumption in your first post that it's already developed to the point where one can make reasonable assumptions of it's availability and capacity and thus presume (pronounce really) that it will be useful. I'm not against the drive - I'm against counting eggs that not only haven't been hatched, their great-great grandparents haven't even met yet. A VASIMR engine requires large amounts continuous power for extended periods - something no battery now or in the near or medium term can produce.

Works for me too...

Quoted because I simply must point out how absurd and true this is.

That's why you go high rather than splitting down low - you minimize that inefficiency by minimizing the swept angle. (My rule of thumb is "orbital period <= 1/8 burn time". I've never had to make a larger than normal mid course correction burn using this method. (As compared to the burns made down low with a higher t/w engine.) Except at the smallest sizes, a high TWR engine also considerably increases the weight of your vehicle, significantly reducing the total TWR of the vehicle. I've never seen the problem here. With MJ automating the burn, I just go do other things during long burns. I either swap to my browser and cruise the web, or sit on the couch and watch anime, or go into the kitchen and start dinner... once I even went to the grocery store.

I want to make sure we're talking about the same thing. My objection is not to bundling MOLE and BARIS (that is, I'm not objecting to them being included in the same download), nor to installing BARIS. (I might want to run it at some point, I played the heck out of the original back in the day.) I'm objecting to being unable to completely opt out of what is described as optional functionality. If I've disabled BARIS in a given save, then it shouldn't display an icon in the stock toolbar. Whups, I found the white square error last night just before going to bed and decided to investigate this morning... My fault, I shouldn't have done that while still on my first cup of coffee. Thanks for catching that. My apologies.

That's exactly where it is. No, thank you, I have BARIS disabled because I don't want it in my game. If it's not in my game, it should not be taking up screen space. It's bad enough that I have to update it so I don't get an error message when I'm loading the game. (Because I don't have the option to not install it in the first place.)

Still working on my science mode campaign prep work... With dMagic's science mod installed and science return set to 50%, I've established to my satisfaction that 50% is too low. (I'm trying to avoid getting too much science.) The key problem is that I have a set of rules that determine how often I can launch (sort of a poor man's roll-your-own KCT), and unless I fill all my slots with unmanned science missions I end up with long 'dry spells' with no manned missions while waiting on more science. And of course, filling up all the slots with unmanned missions to get science for manned means no manned in the first place... The solution comes in two parts: - raise the science return (probably to 75%). - revamp my launch cadence rules, allowing the number of launches per year to rise over time. (Reflecting increased infrastructure as the program matures.) As an aside, I came up with the idea of launch cadence rules to basically force time to go by. Otherwise, if I launched as soon as I landed, I often found myself landing on the Mun by the end of the first calendar week... And since launch slots are limited, I have to consider my priorities and goals when one comes available. (Which is something I enjoy - the planning and scheduling.) I'm also tempted to write a MM patch making *all* antennas into relays...

I'm guessing this goes here, even though the problem was found via M.O.L.E. Last night after installing MOLE 1.8 and BARIS 1.0.5, I encountered some problems, so I started from scratch: - Deleted the Wild Blue Industries folder. - Installed MOLE 1.8 - Deleted the 000BARIS folder - Installed BARIS 1.0.5 Entered an existing Sandbox save, did not get the BARIS popup. Went into Settings and found BARIS disabled. (Which it should have been, just mentioning for completeness.) Bugs: - In the VAB, the Quality Control information is still displayed. - In the flight scene, a white square appears on the stock toolbar, clicking on it I receive a message that "BARIS is disabled" and provides instructions for enabling it. Thinking it might have been a first time startup thing, exited and restarted the game, and the situation persisted. Started a new Sandbox game, double checked Settings and found BARIS disabled by default (as it should have been). When the game (save?) loaded at the KSC scene, the BARIS popup (telling me it was disabled and how to enable it) appeared. The same bugs (in the VAB and flights scenes) also appeared. I guess I can live with the VAB stuff, but if BARIS is disabled it should not appear on the stock toolbar.

Even as a space tug, VASIMR requires a heavy power supply and radiators. Even then, it can only deliver (at the outside optimistic best) a couple of hundred pounds (presuming we can develop a light enough power supply that doesn't require magic pixie dust). Seriously, even it's capability as a tug is mostly hype.

This. Messing about with node splitting complicates things and can require large correction burns.

Use F5 to perform a quicksave before doing anything.... You can use MechJeb's Surface Info window to find the location of the crew you're trying to rescue. Write that info down, and then swap to the lander. Open the Landing Autopilot and enter the coordinates you wrote down, and then click on the arrows by the Lat and Long to offset your landing by thirty to fifty meters - then click on "land" (or whatever the button is, I don't have MJ open at the moment). Once you've landed and recovered your crew, you can use MJ's Ascent Autopilot to return to orbit. If anything goes pear-shaped, use F9 to reload your quicksave, then come back here and let us know what went wrong and we'll help troubleshoot.

"Conceptually simple" != "is actually simple in reality". Closing a submarine's hatch is "conceptually simple". (And procedurally simple too.) However, simple isn't the same as unimportant or without risk. To close a hatch for patrol, if nothing went wrong, involved at least four people and sometimes as much as fifteen to twenty minutes. (One person cleaning and inspecting and closing, two people (one at each end) on the comms circuit, a fourth to inspect and verify. Then the rig for dive team (two more people) would layer check it again when we verified the ship was ready to dive.) If something went wrong*, it could take more people and more time. Why? Because that hatch absolutely had to be properly secured, as our lives absolutely depended on it for the next three months. Once we dove, and it took sea pressure, there was no second chance. We could close it faster if we had to, but if we didn't have to, there was no point in assuming the risk. The station crew is in the same position, there's no hurry, so why hurry? In risky environments, hurrying gets people killed. * On our AMR1 hatch, it went wrong practically every time... The "hatch closed" sensor on either the upper or lower hatch (or both) would get knocked and misaligned by the sheer amount of traffic through the hatch. But the hatch isn't closed until the monitoring panel in the control room said it was closed, so the sensor had to be repaired before the hatch could be declared closed. (Nine time out of ten, I was the guy on the AMR1 end of the comm circuit...)

OK, what happens to the heat you absorb in order to cool it? Like the rest of your cooling schemes, you forget that one all important detail. You have to get rid of it somehow. And there, once again, is the hole in the scheme the amateurs miss - you are radiating heat, that heat can be detected.

The question was about step 1 - the mining process. That's just as big a question as your step 2, and in reality we don't know how to do either at a useful scale.

And not particularly powerful despite all the hype.

That's "4) Profit!" stage. The problem is stages 1-3. Hard rock mining is difficult enough here on Earth with gravity and confinement...

It will help much. And I suspect I won't be the last to ask that question.

I roll my own not because KCT is unstable, but because it's inflexible and does not meet my needs.

Redesigned and rebuilt a series of lifters... then went a performed a mid course correction and an orbit-and-landing with craft launched by their predecessors. And realized I'd made the exact same conceptual error on each and every one of the the new lifters. One that can't be fixed without starting the redesign/rebuild procedure from scratch.

He can say whatever he wants. He can only do what Congress budgets for. Unless the Administration successfully uses it's influence and/or space suddenly gains a constituency... nothing is going to change.

Yes, and they suffered no ill effects from it. And sailors (at least in the USN) drink nothing but distilled water for months on end (and have for decades), and suffer no ill effects from it. The dangers are greatly overstated.

A feature that I would find useful "Show the next n instances of a repeating alarm". I use a repeating alarm to define when I can launch (kind of a poor man's KCT), and being able to see future occurrences would allow me to plan ahead better.

OK, then how do I determine a components MTBF? (That is, you didn't really answer my question - which is: how to determine, in advance, how long I can trust a system for.)

How do you determine the design life?