ialdabaoth

Testing new version! Upcoming features: - different config profile for FAR and non-FAR - spaceplane reentry tiles are no longer ablative; capsule reentry tiles are still ablative (except the inflatable ones). - B9 pack support. - Inspect and repair damage on EVA.

You still have yet to describe how your stuff is broken, which stuff is broken, or in fact do anything but bitch. I am offering to help you, but I need information, not complaints.

Depending on what passive insulation is available, this is utterly untrue. Of course your cabin will have passive insulation; otherwise when the skin reaches 700C, the inside also reaches 700C within a few seconds. But if instead it takes a few *minutes* for the temperatures to equalize, then temperature is only rising by about a tenth of a degree per second or so - and the cabin's active temperature regulation system (which you can describe as AC, or heat pumps, or whatever you want) can keep up with that easily if it's heavy-duty enough. Of course, if the hull is damaged, the passive systems might stop working, and then the AC gets overwhelmed.

The one made by me. It's a dll plugin, not an external application - it allows for cfg file overloading, so you never have to edit stock part.cfg files to make a plugin work.

Note that if you're like me and just use KW for the 3m parts, removing all the 1m and 2m parts will shave KW down from 400mb to about 165mb.

Easy! On the launchpad, when you do OnStart, do the following check: if(part.Modules.Contains("ModuleEngines")) part.Modules.Remove(part.Modules["ModuleEngines"]); Bam! ModuleEngines is gone on the launchpad, but still exists in the VAB.

When KSP hangs, I get one of two blocks as the last line of my log: Kerbal Space Program(1508,0xac9512c0) malloc: *** mmap(size=4198400) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Or: (Filename: /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/MacStandalonePlayer/UnityEngineDebug.cpp Line: 54) Receiving unhandled NULL exception Any ideas?

Edit the part.cfg to not have a space in it, and post in the original mod author's thread that they need to re-release without spaces. I know that the point of ModuleManager is to be able to make changes to parts without editing their config files, but that's precipitated on the idea that those config files don't have errors in them. If a cfg file isn't built correctly, go ahead and edit it to be right, and then apply ModuleManager to make further changes.

Spaces in names are bad.

Just talked with careo; we're testing it now.

Confirmed. ModuleManager's loading system is incompatible with the Exsurgent SABRE's engine-swapping trick. While ModuleManager is causing the problem, due to the way ModuleManager currently has to work the best way to fix it is in the Exsurgent code. Luckily, I can write a forked version of Exsurgent's code which will fix the problem, and submit it to the authors.

I seem to be locking up on the runway about half the time when I use B9 parts. I have to Opt+Cmd+Esc to close KSP. With some planes it happens immediately; with others it happens as soon as I hit 'Restart flight' after crashing.

What problem are you having?

WATCH THIS SPACE! B9 compatability pack coming soon!

Reentry handles external temperature (aka part temperature). I'm talking about cabin temperature in command pods - the temperature of the air that the Kerbals are breathing. You need an electrical A/C system to keep that air cool or warm, and if you don't have power, cabin temperature slowly heats or cools until it matches part.temperature - at which point, if the part isn't too hot or too cold, your kerbals are fine. Otherwise, they start freezing or roasting. Am I making sense? Example 1: during reentry, my command pod heats to 700 degrees. That's totally survivable - the pod is made of reinforced aluminum and composite ceramics, so it can survive temperatures of up to 1700 degrees. As long as the life support system is operational, 700 degrees is no problem for the AC - it just pulls .0625 units of power per second to keep the cabin at 25 degrees. If power goes off, then the cabin temperature slowly raises from 25 to 700 - and the Kerbals get parboiled. Example 2: I'm orbiting the sun, where the ambient temperature is somewhere around 800 degrees. The command pod heats up to 800 degrees, which is totally fine - again, reinforced aluminum, composite ceramics, yadda yadda. But if it runs out of electricity, the cabin is going to slowly roast our little Kerbals.

I would like to make a request, to get people off my back. I'm managing the DeadlyReentry mod, and there are a few things that I think are out-of-scope for DRE, that properly belong in a LSS mod (even though they seem peripherally related to reentry). 1. Can you add a 'Cabin Temperature' readout to the GUI, that will use electricity to try to maintain at 25C regardless of part.temperature (consuming electricity as a fraction of (part.temperature - 25) * CrewCapacity), which makes crew kill rolls at anything below -10 or above +60 (with the percent chance of crew death based on the rate above 50 or below 0, with absolute certainty at -20 and +70? 2. Can you add the following code to FixedUpdate: double avgGeeForce = 0; double lastGeeForce = 0; public void FixedUpdate() { float deltaTime = TimeWarp.fixedDeltaTime; double geeForce = vessel.geeForce_immediate; if (part == null || vessel == null || deltaTime > 0.5 || deltaTime <= 0) return; // don't check G-forces in warp else if (geeForce > 40 && geeForce > lastGForce) { // G forces over 40 are probably a Kraken twitch unless they last multiple frames avgGeeForce = avgGeeForce * (1 - deltaTime) + (float)(lastGForce * deltaTime); } else { //keep a running average of G force over 1s, to further prevent absurd spikes (mostly decouplers & parachutes) avgGeeForce = avgGeeForce * (1 - deltaTime) + (float)(vessel.geeForce_immediate * deltaTime); } } And then whenever avgGeeForce exceeds 15.0, start making kill rolls with a probability that peaks to maximum at say 45G's?

2.1RC4 is up! I need lots of testing for this; I think I've got all the numbers right but I still need as much data as possible.

Yes, just edit your RealFuels/RealTankTypes.cfg and take out all the loss_rate lines - or better yet, make your own CFG with the following lines: @TANK_DEFINITION[Default]:Final { @TANK[LiquidH2] { @loss_rate = 0 } @TANK[LiquidOxygen] { @loss_rate = 0 } } @TANK_DEFINITION[Fuselage]:Final { @TANK[LiquidH2] { @loss_rate = 0 } @TANK[LiquidOxygen] { @loss_rate = 0 } } @TANK_DEFINITION[Structural]:Final { @TANK[LiquidH2] { @loss_rate = 0 } @TANK[LiquidOxygen] { @loss_rate = 0 } } @TANK_DEFINITION[Cryogenic]:Final { @TANK[LiquidH2] { @loss_rate = 0 } @TANK[LiquidOxygen] { @loss_rate = 0 } }

Absolutely you can! And as for mixtures, you'll find that my fuel mixtures are actually derived from the figures you quoted (your mod was actually the inspiration for mine). For example: 73% LH2 + 27% O2 by volume. With LH2 density at 0.00045 and LOX density at 0.007 (which are actually their real densities in Kerbos, where one Kerbo = 1 volume unit (6.25 Liters, if you measure the tanks and do the math), that actually works out to a 5.76 fuel ratio by mass, which is well within the range (1:4 to 1:8) that LH2/LOX engines run. Likewise, if you look at the Isp of all the LH2+LOX mixes, they're in the 390 - 460 range. 35% RP1 + 65% LOX by volume. With RP1 density at 0.005 and LOX density at 0.007, that's a mass ratio of 1:2.6 - pretty close to the 1:2.56 listed above. If you look at the Isp of the RP1+LOX mixes, they're in the 300 - 370 range. 45% RP1 + 55% N2O4. You're right that that's not a common fuel mix, but I didn't want to add too many fuel types, and I figure "Oxidizer" isn't NECESSARILY N2O4, it's just some non-cryogenic oxidizer (who knows, maybe it's even H2O2). In any case, with an Oxidizer density of 0.008, that's a mass ratio of just about 1:2, and they all have Isps in the 250 - 330 range. As for the Nuclear engines, note that the amount of NuclearMaterial used as propulsion is so close to 0 as to BE 0; the rest of it is just used for the Generator and Alternator, where it gets turned into NuclearWaste. And all of it is non-pumpable; it's just there to track how much there is in case I ever make a mod that lets you scavenge parts.

Update! I'm testing a new version that slightly lowers the G-force tolerance of all parts (by about 30%), and moves all the physics from OnUpdate() to FixedUpdate() to help lower framerate issues for those of us (like me) with older computers. Release once I'm satisfied nothing got horribly broken.

None whatsoever; it starts with the PART {name=part} node, searches for all @PART[part] nodes and applies them, then searches for all @PART[part]:Final nodes and applies them. If there's no PART {name=part}, then it never even starts the process so your @PART[part] node just gets ignored by the system.

Be my guest. ModuleManager has an open API; you can add it to your References and call ModifyNode() and ModifyPart() to your heart's content. All the nodes are in GameDatabase.GetConfigNodes(string type), where in this case type is exact (for example, "@PART[*]" would be one type, where @PART[a*]" would be another type, and @PART[a*]:Final" would be a third type). I had less than this to go on when I started, and had a working version within four hours. Let's see how you do.

what version? and what were teh issues?

What problems are you having with ModuleManger?

If the overheat bar is less than halfway, you're clear. Once the overheat bar reaches halfway full, you start taking some damage. Not much, but some; it will accumulate over time until the engine explodes.