ialdabaoth

Well, permanently for that game session.

Confirmed; this will be fixed for the next release. This is what happens when you muck with ModuleEngines blind. Squad could really use a 'decompiling any class descended from PartModule for the express purpose of plugin compatability' exception to their EULA.

ExsurgentEngineering was a compatability fix for B9; it will no longer be included as of the next version of ModularFuelSystem. I will make sure to keep RealFuels.zip packed in the next release, thank you.

Aha, I know exactly what's happening here. I tried to detect when the chutes were deployed, so that a deployed chute would burn up even if it's at the back of the rocket. DRE2.2e counts a chute as 'deployed' even when its still fully packed, if its staging icon has been activated. Obviously, this is a problem. I've fixed this for 2.2f, which I'm releasing now. As a side note, do NOT pop your chutes until the reentry F/X stop glowing! if the parachute silk hits a 1200-degree slipstream, it WILL catch fire.

I just figured out what's causing that bug, actually - apparently, I accidentally disabled the internal gyro forces. Working on a fix now.

I basically want to craft a system whereby parts can have criteria to 'unlock' them, which are fulfilled by flying missions. Everything past that is just cfg-overriding, but I would like to turn the entire potential inventory (Squad, KW, B9, everything) into one massive tech tree.

Actually, this isn't bugged. Look at the mass of your rocket. LiquidH2 is significantly more efficient than LiquidFuel, kilogram-for-kilogram. But it is much, MUCH lighter. Try this instead: Fill with standard liquidfuel + oxidizer, note delta-V. Now, empty and refill with liquidH2 + liquidOxygen, and then *keep adding more fuel tanks* until you reach the same vehicle mass that you had with liquidfuel + oxidizer. THOSE are the delta-V's you should be comparing. This is why LiquidH2 is usually an upper-stage decision in real life, btw - because the consideration isn't just how much delta-V you can get, it's how much delta-V you can fit in an upper stage with a given payload weight. Your bottom stages are better off with LiquidFuel + LiquidOxygen; down in the lower atmosphere the delta-V differences won't be that substantial anyways. Save the LH2 for when you reach space, unless you're using SABREs or something.

Ok, this is amazing. This is the bigger half of the next mod I wanted to do. Would you consider joining forces, once I've got DRE and MFS stable? I'd love to contribute a functioning, unlockable tech-tree to this mod.

Yep, let's walk through it with Liquid Oxygen + Liquid Hydrogen. LOX: Density - 1.14 RESOURCE_DEFINITION density - 1.14 * 0.00625 = 0.007 Ratio - 5.00 density ratio: 5.00 / 1.141 = 4.38 LH2: Density - 0.071 RESOURCE_DEFINITION density - 0.071 * 0.00625 = 0.00044 Ratio - 1.00 density ratio: 1.00 / 0.071 = 14.1 so your density ratios are 4.38 and 14.1; or, if you want to make them add to 1, 4.38 / (4.38 + 14.1) = 0.24 and 14.1 / (4.38 + 14.1) = 0.76. I believe I used closer to a 6:1 ratio instead of a 5:1 ratio, which is also a NASA standard, so I wound up with 0.27 and 0.73. Does that make sense? Oh! Also, all your files have @MaxTemp instead of @maxTemp, this won't work. KSP's node system is case-sensitive.

Remember that you need to specify mixtures as volume ratios in KSP, not as mass ratios! That has bit me in the ass a few times. Actually, I'm pretty sure that the MonoPropellant resource in KSP is intended to be HAN (Hydroxylammonium Nitrate); the Isp is spot-on and the density is close. My last set of experiments were towards making different monopropellants. Really, MonoPropellant (HAN), Oxidizer (hydrogen peroxide), and Hydrazine should all be useable as monopropellant, with MonoPropellant having an Isp of 260, Hydrazine 230, and Oxidizer 190. (if you want to get technical, Xenon should be useable to, with an Isp of around 70 or so since you're just farting decompressed gas out the nozzle). Unfortunately, I can't get ModuleRCS units to switch propellants in the editor, no matter what. The next time I see Mu or C7 I'll probably pester them about that.

Unfortunately, due to the way Squad handles the FX loading, any attempts I've made to reload the fx (and believe me, I've tried MANY!) have been doomed to failure. However, I have a second idea for how to proceed, although it's a bit crazy.

Actually, I've decided on a different approach. Because HydraEngineController is careo's baby, as I've modified it I've been less and less comfortable with what I'm doing (if my stuff breaks, I want to take the blame for it rather than careo). So, I've used some of careo's code and most of my own ModularEngines code to create a functional work-a-like to HydraEngineController, called ModuleHybridEngines. My version is cooler, in that it respects PROPELLANT { DrawGauge = true } properly. Luckily, you can convert a HydraEngineController to a ModuleHybridEngines like this: @PART[B9_SABRE_M] { @MODULE[HydraEngineController] { @name = ModuleHybridEngines ...(stuff) } } Now that I've done this, I feel a lot more comfortable adding new 'features' to hybrid engines, so yes - I think I can set it up so that you can switch modes in the VAB/SPH before my next release.

On second thought: I think I'm going to deny this feature request. ModuleManager is used by way too many mods, so I need to make it do one simple thing and do that thing very well. ModuleManager's entire job is to allow you to make modifications to other authors' existing cfg files, for the purpose of making them compatible with your own plugins. The fact that it also happens to allow people to release "playstyle change" cfg files is a nice feature, but not its primary purpose. You can easily create a new PART definition by grabbing another PART and copying it; that's probably how you should do it rather than ModuleManager adding part inheritance functionality. You can add modules to other authors' works by paying attention to what mods are popular, and supporting them; that's probably how you should do it rather than ModuleManager adding wildcard functionality. The past few days have been a nightmare of incompatabilities and patches and re-patches because of a few places where I tried to be clever, instead of being simple, robust, and thorough. If ModuleManager really is going to be a redistributable tool for other mod authors, its functionality needs to be GUARANTEED. The current version does this by paring down what it does to the bare minimum - it scans the entire node list at start-up, immediately after the nodes are loaded but before they are converted into PARTs and RESOURCEs and so on, and merges any node that doesn't start with a '@' with all nodes that do that match @TYPE[name] or @TYPE[name]:Final. It does this, it does it well, and it (finally) does it without any bugs. I need to quit while I'm ahead, so that the rest of the community can know that if they include ModuleManager.dll, there won't be any hidden surprises or incompatabilities with someone else who choose to include ModuleManager.dll earlier or later than them. Hopefully 0.21 will do this natively, and we can all put ModuleManager.dll behind us.

Update: I have abandoned making RCS thruster blocks with choosable fuel types. Squad's implementation of ModuleRCS just isn't compatible with switching. Everything else tests out, so I should have an update soon. Chestburster, may I incorporate some of your cfg file changes?

Have you looked at how I'm doing it in DRE2?

Everything I release is CC-sharealike: mention how awesome I am and you can release whatever derivative works you want.

... YES. Yes it is! Hahahahaha! I think I'd actually want it to look like this, though: PART From PART[strutCube]:Final { @name = strutCubeLarge @etc } hrm. One problem, though - order of operations is going to be VERY tricky.

yeah, I don't think 'Reload All' is going to be particularly kind to the current version of ModuleManager

Not in general, no. Except for VERY rare exceptions (like DRE2.1, because I derped), the latest version of ModuleManager should always work for any mods that use it. All ModuleManager does is manage cfg file changes for you; at one time I experimented with making it do more, and had DRE use some of that, but I have since seen the error of my ways. Not sure if this is the right thread for that.

Yep! Already noticed this and fixed, I'm just trying to test the next release before I break everything (still have a 102F fever )

I definitely want to include them! I would encourage everyone to post any configs they make to this thread. Let's crowdsource this bitch. Also! Next version will be released soon - ModuleEngineConfigs will now work for ModuleEngines, HydraEngineController and ModuleRCS (and theoretically almost any other module)!

Gah, ok... I'm in the middle of adding new features, so I'll try to have a new version soon.

Well, to quote Wikipedia:

Aha! Incompatability with new Module Manager detected and fixed; please download 2.2e!

AHA! It's Deadly Reentry. Just updated to 2.2e; this should fix it.