Starwaster

... hence why I said there was a problem in some configs

It's not nitpicking to point out that ore isn't a fertilizer and that rocket fuel isn't a good and wholesome food, nor is it my fault if you don't understand the words you used, regardless of what your first language is.

Looked at it, and Engine Ignitors code does look for a value of -1 for infinite, but in the RF config you want it to be 0. Less than 0 and it sets the number of ignitions to tech level - ignitions.

Are you still using Deadly Reentry? I did notice that you had mentioned installing it. I was made aware of an issue with a few sections of the DeadlyReentry.cfg file could affect RSS adversely. (though I didn't experience any such issue myself) I don't plan on pushing a full update but the file in question will get patched on the repository before that happens and you'd be able to download just that file. I think that would probably fix your problem....

It depends on how much higher the part's temperature is than the boiloff temperature. Temperature delta = part temp - boiloff temp. loss amount = loss_rate * temperature delta per second. (actual loss is implemented per physics frame so loss_rate * delta * fixedDeltaTime) If you can read code then this is relevant: https://github.com/NathanKell/ModularFuelSystem/blob/34e5474c350c27a459404c07caa6be7d3865b83f/Source/Tanks/ModuleFuelTanks.cs#L329-L354 Technically, this implementation is wrong because part temperature (as of KSP 1.0) includes any resources, which means that the tank contents would already have exceeded boiloff for the entire contents with explosive results. Heat loss due to boiloff is implemented but it doesn't seem to have much impact. Probably because actual loss rate is independent of heating rate. At some point that needs addressing and I think Nathan has some ideas about it but I'm not sure what they are. (my own idea about it is that it should be based on incoming heat flux; with loss being calculated each frame based on how much heat gets through so that both loss and cooling (due to vaporization) are concurrent rather than disconnected as they currently are.

Carbohydrate???? Why would you think LiquidFuel is a carbohydrate? Perhaps you're thinking hydrocarbon which is something entirely different from a carbohydrate. Carbohydrates are things that the body can turn into sugar. Rocket fuel is not a carbohydrate and your body cannot process it into sugar or any other nutrient. Dear god what are they teaching people in school these days?

You were asked for logs, not screenshots. output_log.txt if Windows or player.log if Linux or Mac. If you're not sure here to find those then read this post: http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST

What affects boiloff is part temperature. That's the internal temperature which is not the skin temperature. For mitigation I suggest the Heat Pump mod. It actually used to be a part of Real Fuels until it was dropped. I modernized it for KSP 1.0.4 and released it as a separate mod. It comes with one radiator part and it removes heat from whatever it is attached to and sends it directly to the radiator's skin for rejection. (it incorporates both active cooling and insulation; whatever part it is attached to is treated as insulated) http://forum.kerbalspaceprogram.com/threads/128502-Heat-Pumps-for-Real-Fuels-v1-0-BETA-RC1-7-12-2015

But it's not ore either.

Mainly active cooling (refrigeration) but it also simulates insulation by lowering skin-internal conductivity and adjusting some other conductivity settings. The end goal is that Heat penetrating the skin should be comparable to that of a tank insulated with ~60 layers of insulation for an Earth->Mars trip. (having a radiator does this automagically) Active refrigeration coupled with radiators to take care of the rest; heat penetrating the skin is moved to the radiators. http://forum.kerbalspaceprogram.com/threads/128502-Heat-Pumps-for-Real-Fuels-v1-0-BETA-RC1-7-12-2015 It works but (issues) Timewarping at speeds of 1000x and above use a special analytic mode for temperatures that immediately raises internal temperatures. (stock problem) Conductivity may not be properly balanced and was done so with RSS in mind so numbers could use adjusting for stock Electrical consumption for stock. But, it works. Feedback would be nice but is lacking and I won't hold my breath waiting.

I don't like to use the 'C' word, but I have to agree; those changes aren't even necessary. Might as well just turn aero reentry heating off.

Using 'ore' doesn't make sense anyway because it doesn't imply anything organic...

Ok, looks like there's a problem a few places in the general config as all ModuleAblator shields are supposed to have already been converted before getting to the RSS section.

On the other hand, if you should happen to see any Ciao Bella (or in a pinch, Talenti) Blood Orange Sorbet, immediately buy it, pack it in dry ice and ship it to me ASAP as I am unable to locate any, anywhere. Thank you and that will be all.

Watch your TWR. It's probably too high for the mass of your rocket coupled with a turn that is too sharp. (starting TWR should be between 1.25 - 1.6. Your turn should start at ~100m/s and be gradual not abrupt)

Enclose the capsule in a fairing. The latest DRE version will let you add heat shield to the fairings (right click and use the tweak bar) (preferably from the Procedural Fairing mod rather than the stock ones, which can throw errors if you jettison the fairing while the temperature is above ablation temperatures) - - - Updated - - - If you have the latest DRE then it will reconfigure its shields to withstand a RSS reentry. Perhaps your reentry profile is the problem (too steep or too shallow). Try aiming for a periapsis of about 60?

Mulch should be a byproduct of recycling organics. Also. Mulching is a process of inbred fertilization which employs certain decomposed organic materials-- including, but not limited to animal sediment-- to blanket an area in which vegetation is desired. The procedure enriches the soil for stimulated plant development while, at the same time, preventing erosion and decreasing the evaporation of moisture from the ground.

He probably means it's possible from a boolean standpoint but that MM doesn't actually support it. That's the only explanation that makes sense because Correct. It's not possible to do what you want it to do while cloning a part since all detection has to take place in the :HAS immediately following your +PART [*] and there are no conditionals that support checking for resource(s) that exist but failing when there are more resources than were designated. Edit: If you want to EDIT an existing part, there's a somewhat convoluted means you might achieve it. It would require copying the monoprop resource node (using MM variables) then deleting it. Then adding the stuff you want IF zero resources exist. Then adding back in the monoprop node reconstructing it from the variables stored in step 1. (none of which is possible on a single line that only accepts conditional checking)

You either have an outdated version of Deadly Reentry where parts had bad part node orientations or you need to keep trying. With very thin parts like heat shields attaching can be tricky. Sometimes it'll even seem like they snapped together but the part is red. Move the cursor very slowly down and the part turns green. (unless you really do have an older version...)

No, what you need doesn't exist in MM.

This is what I do in Deadly Reentry: Add a heat shield with 0 ablative resource. (amount 0; maxAmount = 1600) so player can then use the tweak slider to add as much protection as they want. https://github.com/Starwaster/DeadlyReentry/blob/master/DeadlyReentry/DeadlyReentry.cfg#L207-L232 Note that it's necessary to manually add in the cost of the resource or bad things will happen.

No that sounds about right. Does it last you enough to get down? I'm not sure what that first part means. Unless you're talking about ModuleManager patches not being applied, but it makes more sense that the configuration is missing something to begin with.

That 'vacuum' nozzle is Awful short for a 'vacuum' nozzle

[noparse] [/noparse] (btw to get BB tags to display like I did, you use [noparse][noparse][/noparse][/noparse])

Ok, no, you don't want to do that. You will literally copy the node and end up with 1 ModuleParachute and 1 RealChuteFAR on the same part. Change that + to a @ @PART [*]:HAS[@MODULE[ModuleParachute]]:NEEDS[!RealChute]:FOR[FerramAerospaceResearch] { //Edit the node with ModuleParachute to transform it into RealChute @MODULE[ModuleParachute] { @name = RealChuteFAR sizeMultiplier = #$@PART[parachuteSingle]/mass$ @sizeMultiplier != -1 // 1 over ... @sizeMultiplier *= #$../mass$ @sizeMultiplier != 0.5 // multiplier = sqrt(multiplier) %deployedDiameter = 25 // default @deployedDiameter *= #$sizeMultiplier$ } } - - - Updated - - - works only if I target the first CLOUD_LAYER node, but not if I try to target any other? I've checked and double-checked this, and it only works when the #body and #altitude values are those from the first CLOUD_LAYER node, and not from any of the others. In the log there is no error, MM simply never applies the patch since (I assume) it doesn't find anything after the :HAS search This is problematic given the lack of named nodes. And your code example is missing about 3 brackets. As for your 'stuff' you probably want to put your #body and #altitude checks in whatever is going in the 'stuff' to target individual layers @CLOUD_LAYER_PACK { @CLOUD_LAYER:HAS[#body[Laythe]] { @DEFAULTS // Only has one DEFAULTS per CLOUD_LAYER so don't do any targeting here { // your stuff } } }