ialdabaoth

1. No, that doesn't work that way (or at least, I'd be VERY surprised if it did). 2. The part's name.

That isn't an oversight; the T30 is the "dead simple" model, and thus doesn't have any switchable configurations. In the next version, it will have a ModuleEngineConfigs, but it won't have any alternate configurations. (Also, in the next version, ModuleEngineConfigs and ModuleHybridEngines will also fix the Isp bug, where atmospheric Isp causes increased fuel flow instead of decreased thrust.)

You don't. RCS can only use one propellant at a time. Unless you mean set it up so you can choose in the VAB which to use, in which case... wait for 0.21 to come out.

You can absolutely do this, but you have to replace all the values instead of adding new ones. You'd do the following: @MODULE[TracksMain] { @TorqueCurve { @key,0 = -15 -1 // changed from -20 0 @key,1 = -12 -0.5 // changed from -10 0.5 @key,2 = 10 0 // changed from 0 15 @key,3 = 15 0.5 // changed from 10 0.5 @key,4 = 30 1 // changed from 40 0 } }

Hrm. I had honestly never considered derivative works. I'll need to think about it; I've always been a fan of complete open-source CC style licenses, but I'm afraid of too many incompatible ModuleManager derivatives cluttering things up and leaving me a debugging nightmare. HOWEVER, since ModuleManager seems to be highly stable at this point, I don't see much reason not to release it into the wild and see what kind of mutant offspring it produces. From this point forward, I'm releasing ModuleManager's source under a CC share-alike license. Anyone is free to do anything they like with ModuleManager's source, with two caveats: 1. You credit me as the original creator that your code is based on 2. You make it ABSOLUTELY CLEAR that your code is not the original ModuleManager, and that any problems that people have with your fork should be taken up with YOU, not me. Beyond those caveats, knock yourselves out, but in the interest of politeness and code extensibility, it would be nice if people who are writing wildcard systems could make them interface with and extend the ModuleManager.dll assembly, rather than overwriting it. I.e.: ModuleManager.dll should give you all the tools necessary to do ConfigNode merging and exact-match ConfigNode referencing, so please make a module that *interfaces* with ModuleManager.dll rather than making your own DLL that *replaces* ModuleManager.dll, or we'll BOTH have a nightmare horde of angry and confusing users who don't know who to yell at when things break. And since the wildcard genie is out of the bottle and I'm not responsible for granting its wishes, I'll go ahead and muse how I think wildcarding SHOULD work. I think your ideal syntax looks something like this: @PART[*]:HAS(@MODULE[ModuleEngines]:HAS(PROPELLANT[Oxidizer]), @MODULE[ModuleAlternator], !MODULE[ModuleGimbal]) { } That would apply itself to any PART that contains both a ModuleAlternator and a ModuleEngines MODULE and DOESN'T contain a ModuleGimbal, but only if the ModuleEngines contains an Oxidizer PROPELLANT. I think the IF/AND/OR stuff sounds like a good idea at first, but you'll inevitably wind up over-engineering it. Really you just need AND and NOT; OR can be handled by making multiple cases.

I mean that the white spherical shell in the radial RCS tank has a radius of approximately 0.33 meters, while the standard RCS tank has a radius of 0.625 meters and a height of 0.625 meters. pi * r * r * l = (3.1415926583 * 0.625 x 0.625 x 0.625) = 0.767 (4/3 * pi * r * r * r) = (3.1415926583 * 0.33 * 0.33 * 0.33) = 0.113 Thus, the radial RCS tank can't have more than about 15 fuel units in it. The KSPX's mini-RCS tank is a straight scale-down of the standard, and is exactly the size of the Oscar, so *it* can't have more than 12.5 units in it. I'm somewhat hesitant to make this change, because it's pretty sweeping. If I do, I'll probably change the density of MonoPropellant to match HAN, which is 0.007. Which means the radial-RCS effectively becomes 26.25 effective-units and the Oscar-size becomes 21, but the 1m and 2m tanks almost double in effective fuel.

I'm already considering that. Right now I'm playing with different options for when 0.21 comes out. Oh! Also. Note how the standard RCS tank has volume=100. Note how the mini RCS tank has volume=40, and KSPX's mini tank has volume=50. Note that there's NO WAY that's possible.

Actually, LANTR solves this by ONLY pushing the H2 through the NTR; LOX is run through the coolant loop and then dumped into the propellant stream after the LH2 goes through the reactor, which effectively makes the whole thing a hypergolic LH2+LOX rocket. Your Isp drops from 920s down to about 540s, but that's still far better than you get from a standard chemical LH2+LOX rocket (and your fuel density goes way up).

Also, ideally each mod maker should have their zipfile contain a /GameData directory, with modulemanager.dll directly in the /GameData directory, and everything else in their own sub-directory. (DeadlyReentry and ModularFuelSystem do this correctly, for example; both being my mods)

Note, the KSPX large LV-N already does this; it's switchable in-flight between 100% LH and 30% LOX + 70% LH.

Afraid not. They're all written to be used by any number of mods. When modulemanager.dll is re-written to minimize clashes, it's re-written to minimize clashes with EVERYTHING. It's designed to be a SINGLE plugin, which any number of other mods can rely on. Having multiple copies of ANY plugin DLL will cause problems, because the same code will get executed multiple times. modulemanager.dll goes in your /GameData root. If there's already a modulemanager.dll in your /GameData root, figure out which one is newer and keep that one.

... or you can wait for the next version, which will have a heat radiator fin that you can attach to your cryo tanks to keep them cool.

"with their own modulemanager.dll's"? You should never, EVER, have more than one copy of modulemanager.dll in your entire /GameData folder tree. EVER.

I can cap out at 15 G's with a 3-man pod pretty easily, if I come *straight* down from 70 million meters.

OMG STOLEN. Thrust Corrector will be added to Modular Fuel System ASAP.

As soon as I have a computer that can run KSP, I'll look into this. In the meantime, I have a feeling it's out of scope But I'll try my best to find a solution.

Ugh... I've actually been working on this for awhile now. The Right Way to do this is some kind of tabbed browsing system, but I've been having a hell of a time getting it to look good and work bug-free.

Exactly, which I then round to 0.005 because we can afford to be a little imprecise in a game about little green dudes.

Update: I have a fix for the roaring sounds in the VAB; I'm waiting till KSP 0.21 to release it to ensure compatibility. While I'm waiting to release it, I AM paying attention to this thread, and I'm making some cfg file adjustments to ensure that heat shields etc. will work better.

I thought planes were shielded?

Five? By my calculations it's 6.25

Here is my usual strategy for reentry: 1. At apoapsis, I lower my periapsis to 20 km. 2. When my altitude drops to 36 km, I blow all decouplers, then rotate my pod so that the heat shield is facing into the shockwave. 3. Watch Bob and Bill start screaming and Jeb start cackling. 4. As soon as my velocity drops below 1000 m/s, I open my drogue chutes. 5. As soon as my velocity drops below 250 m/s, I open my main chutes. I will usually sustain some minor G-force damage at step 5, but nothing that isn't survivable.

Indeed; I think the first actual SSTO design that might actually work is the SABRE-powered Skylon.

Seconded - there is simply no way that velocities below 2000 m/s can cause a fire or explosion. The reason for this is simple: The shockwave temperature is equal to your airspeed velocity - 275. Since almost every part has a maxTemp of 1700 or higher, and damage doesn't start until around 85% of that, you have to be going at LEAST (1700*.85 + 275) = 1720 m/s in order to be in any danger of heat-related catastrophe. Also, spaceplanes do NOT have ablative shielding. They have passive thermal shielding. This means that keeping your belly to the wind (even slightly) will reduce the rate of heat exchange between the shockwave and the shielded part. The only things that have ablative shielding are the mk1 pod, and the heat shields included with the mod.

thank you.