ialdabaoth

In this case, it was mine. I can make the necessary changes. But in the larger scope, you're right. I'm not sure that there's a good solution to this. I'm not loving that either. One of the problems that I frequently have when I look at ModuleManager, is figuring out use-case tradeoffs. (This is one of the reasons I'm so adamant about not doing wildcards, for example). The sheer number of ways that things can go subtly wrong in specific circumstances, while being completely logical and not in-point-of-fact incorrect, is staggering. At this point in my modding career, my sole evaluation criterion for whether to implement a new feature - or even fix an existing bug - is "will this cause more, or fewer people to bitch that it's broken?"

Agreed - Kerbin is a VERY forgiving environment. Making it actually "deadly" at such low velocities would require ignoring several laws of physics.

That is correct, but it has nothing to do with deleting or reloading the modules, it's purely a matter of what the in-memory ConfigNode ends up looking like. ANY sub-node within a ConfigNode that gets modified has to be removed and re-added. If you look at ModuleManager.cs, you will see this happening on line 93 and 94. This is because funky things occasionally happen if you just modify a subnode that is parented to a larger configNode (or at least they did in 0.19; I didn't want to risk introducing new bugs in 0.20 so that code remained untouched). As a consequence of this, yeah... it looks like every subnode that gets modified gets bumped to the bottom of the subnode list. One simple solution might be to include a blank patch node for the nodes that you want to ensure show up after the node you're modifying, so you'd wind up with something like this: @PART[liquidEngine2] { @maxTemp = 1800 @MODULE[ModuleGimbal] { @gimbalRange = 2 } @MODULE[ModuleEngines] { @heatProduction = 200 } @MODULE[ModuleGimbal] {} @MODULE[ModuleAlternator] {} @MODULE[ModuleJettison] {} } Note that this has the additional advantage of allowing you to position an inserted node precisely between any two existing nodes, by spelling out the entire new node order explicitly.

Note! That isn't actually the current code at all; that's an old fork. This is the actual code: ModuleManager.cs Note that this doesn't actually touch the modules at all; ALL it does is edit the config node before the PartLoader gets to it.

Sorry, fixed!

2.3 is up.

farram4, if I were to rewrite your UI to be less obnoxious, would you be interested?

It considers IntakeAir as reaction mass.

Partially. You get an option to fill with 100% LH2, but not an option to fill with LiquidOxygen, because it only sees the 'active' engine.

Unfortunately, I wasn't able to get RCS blocks to allow user-selectable fuels in the VAB. Also: I'm pretty sure 'Oxidizer' *is* H2O2, and MonoPropellant is actually HAN, not Hydrazine (Hydrazine can't get 260 isp). I had tried to allow Oxidizer as a selectable monopropellant at 190 isp, but alas, it was not to be.

Yep, added to FP.

ok! will do.

Updated! I think the delta-V problem has been solved. Confirm?

I've found that if I'm reentering Kerbin, as long as my apoapsis is between 15k and 30k I do fine. This is with a mk2 pod, 2.5m shield, 3 side-mounted chutes and a shielded dock-o-tron on the nose.

Funny you mention that! That is now fixed for 2.3 (to be released Monday unless people find more bugs for me). Kerbals catch on fire around 500C and die at 900C.

It's all good - here's the reason why, if you're curious. Let's say I want a 27% LOX / 73% LH2 mix. Let's say that for this tank, LOX has 0.9 Utilization and LH2 has 0.8, and my available volume for the mix is 1000. 1000 * 0.27 * 0.9 = 243 1000 * 0.73 * 0.8 = 584 that's 827 units of actual LOX+LH2. note that 243/827 is 0.294, and 584 / 827 is 0.706; we do NOT have a 27%/73% ratio, and will wind up with about 65 volume worth of LH2 left over after our engine runs out of LOX.

note that you don't have to wait until you're under mach 1. Parachutes are safe to open as soon as the reentry shockwave stops glowing, which is usually around 1000 m/s (around mach 3). You *can* do it at speeds of up to 1500 m/s, but you're taking a little bit of a risk.

Note: The method you described will NOT give the expected results if you have different utilization factors. But, since I already have the correct formula built into the 'configure for engines' code, there's no reason not to just reuse that. Here's what I'm doing for the next version: 1. "efficiency" will be changed to "utilization" (I like this better, I just couldn't find the right term when I was writing the mod) 2. this syntax: { name = LiquidH2 efficiency = 0.99 mass = 0.0 temperature = -253 loss_rate = 0.0000000002 amount = 0.73 * volume maxAmount = 0.73 * volume note = (requires insulation) } will change to this: { name = LiquidH2 utilization = 0.99 mass = 0.0 temperature = -253 loss_rate = 0.0000000002 amount = full maxAmount = 73% note = (requires insulation) } 3. All tank definitions with a '%' in their maxAmount will be processed AFTER all tank definitions with a static maxAmount. 4. amount will no longer take proportional values. It's either a static value, 0, or the word "full". Anything else is semantically ambiguous.

Sound effects will be MUCH better in the next version, don't worry. The newer version adjusts volume and pitch based on how much damage has occurred, and how quickly it's occurring.

Hmm. Hopefully this is just a cfg file problem; do you have a copy of a savefile before it enters Jool? I'd hate to have to fly all the way out to Jool just to test this; my computer is terrible.

Do vertical SSTO's count? If so, then behold the S.S. Buck Rogers:

Can you try with this one? Module Manager v1.3

Let me second SchroedingersHat's suggestion, and yes, this is how you'd want to do it. Although you don't need to parse the textfile; you just need to parse the confignode from the GameDatabase - that's where KSP puts it after KSP automatically parses the textfile for you. What you'd do is something like this: RESOURCE_COST { name = LiquidFuel cost = 0.1 max_storable = 99999999 upkeep_cost = 0 } and then your plugin would do: foreach(ConfigNode node in GameDatabase.Instance.GetConfigNodes("RESOURCE_COST")) { string resource = node.GetValue("name"); float.TryParse(node.GetValue("cost"), out resourceInventory[resource].cost); double.TryParse(node.GetValue("upkeep_cost"), resourceInventory[resource].upkeepCost); float.TryParse(node.GetValue("max_storable"), resourceInventory[resource].maxStorage); } After which you could just refer to your resourceInventory[] dictionary. (I added upkeepCost in case you decide to work with something like my ModularFuelTanks' RealFules resources, where fuels like Liquid Oxygen have refrigeration needs).

Ok everyone, other than tweaks to the sound effects, I believe I'm done - prove me wrong! If no one notices anything utterly bizzare with 2.2f by Monday, I'll update to the final sound effects (adding pitch and volume changes based on how quickly damage is occurring), and release 2.3! And then we'll finally be out of this alpha cycle and back on a 'stable' release.

it's supposed to be a bunch of creaks and pings of metal deforming under stress.