Starwaster

Sigma88: Re: child nodes. Again, It used to work in previous versions of MM. It no longer works now. Below is an example of some fairly complex patching for KSO depending on whether or not RSS was installed or not: Yes, these all worked. (these are for example only, of patches that I know for a fact worked before. They are currently obsolete and deprecated) @PART[super25rudderkso]:BEFORE[DeadlyReentry]:NEEDS[DeadlyReentry] { @maxTemp = 1500 MODULE { name = ModuleHeatShield ablative = HeatCapacity direction:NEEDS[!RealSolarSystem] = 0, 0, 0 // omnidirectional light shielding direction:NEEDS[RealSolarSystem] = 0, 1, 0 // forward standard shielding (only when playing Real Solar System mod) reflective:NEEDS[RealSolarSystem] = 1.8 // 180% of heat is ignored at correct angle (no, seriously. You have NO idea until you've attempted this in RSS with FAR) reflective:NEEDS[!RealSolarSystem] = 0.05 // 5% of heat is ignored at correct angle //adjustCollider = -0.015 loss:NEEDS[RealSolarSystem] { key = 650 0 0 0 // start ablating at 650 degrees C key = 2000 1000 0 0 // peak ablation at 2000 degrees C key = 6000 2000 0 0 // max ablation at 6000 degrees C } dissipation:NEEDS[RealSolarSystem] { // dissipation is based on the part's current temperature key = 300 0 0 0 // begin dissipating at 300 degrees C key = 800 250 0 0 // maximum dissipation at 500 degrees C } } RESOURCE:NEEDS[RealSolarSystem] { name = HeatCapacity amount = 3000 maxAmount = 3000 } MODULE:NEEDS[RealSolarSystem] { name = ModuleGenerator isAlwaysActive = true OUTPUT_RESOURCE { name = HeatCapacity rate = 0.2 } } }

It's an error/warning that is new in recent versions of Unity. The behavior that it is throwing the errors for is not new, just the error reporting. Serialization is where you take some bit of data and turn it the format that it gets stored in memory as. I wouldn't worry too much about it; I get the same errors even in pure stock KSP and I've seen it in every single log file posted by other players since KSP 1.0

Did you lower conductivity as advised? If so, how low have you lowered it? And did you make the change permanent?

What he's trying to do should still work though and WAS working with past versions of MM.

I'm pretty sure that IRL that there is no technology that will save you from a 1 million meter orbit around any star. That's just suicide. (1000 kilometers....) The fix is not to orbit at that altitude. (when you stop doing that, it will stop hurting...) I did make a ship with a huge sun shield made out of stock procedural fairing that was rather like a giant umbrella. Coupled with active radiators screened by the shield it did get a lot closer inside Moho's orbit than previous attempts, but we're still only talking 1 million kilometers. Even that's pushing it.

Values of rescaleFactor other than 1 are at the heart of the problem, but only when a MODEL node is defined (which has its own set of scale values). The problem is that rescaleFactor is applied twice to parts that have MODEL defined unless the part is root or you've reverted or switched vessels in flight. So if you're changing rescaleFactor then you also have to rescale the MODEL scales as well AND rescale the attach nodes as well. (the default value for rescaleFactor is 1.25, so if you don't see it in a config then it's using the default) This is what I used to use to automatically rescale all KWR parts before they fixed scaling. It tries to fix any KWR part lacking an explicit rescaleFactor line. (there's a second part that deals with KWR parts which DO have it but the part you listed doesn't need that) I provide it as-is. Please note that I do not currently use this myself anymore and it's probably better for you to adapt it to your specific needs by replacing the bit that says 'KWR*' If you try to use it in the form that I presented it, I am not sure what will happen with current, up to date KWR parts. In theory it shouldn't cause a problem but I wasn't even willing to take that chance myself. @PART[KW*]:HAS[~rescaleFactor[]]:FIRST { @MODEL,* { scale_x = #$scale[0]$ scale_y = #$scale[1]$ scale_z = #$scale[2]$ @scale_x *= 1.25 @scale_y *= 1.25 @scale_z *= 1.25 @scale = #$scale_x$, $scale_y$, $scale_z$ !scale_x = DELETE !scale_y = DELETE !scale_z = DELETE } rescaleFactor = 1.0 topX = #$node_stack_top[0]$ topY = #$node_stack_top[1]$ topZ = #$node_stack_top[2]$ @topX *= 1.25 @topY *= 1.25 @topZ *= 1.25 @node_stack_top = #$topX$, $topY$, $topZ$, $node_stack_top[3]$, $node_stack_top[4]$, $node_stack_top[5]$, $node_stack_top[6]$ !topX = DELETE !topY = DELETE !topZ = DELETE top1X = #$node_stack_top1[0]$ top1Y = #$node_stack_top1[1]$ top1Z = #$node_stack_top1[2]$ @top1X *= 1.25 @top1Y *= 1.25 @top1Z *= 1.25 @node_stack_top1 = #$top1X$, $top1Y$, $top1Z$, $node_stack_top1[3]$, $node_stack_top1[4]$, $node_stack_top1[5]$, $node_stack_top1[6]$ !top1X = DELETE !top1Y = DELETE !top1Z = DELETE bottomX = #$node_stack_bottom[0]$ bottomY = #$node_stack_bottom[1]$ bottomZ = #$node_stack_bottom[2]$ @bottomX *= 1.25 @bottomY *= 1.25 @bottomZ *= 1.25 @node_stack_bottom = #$bottomX$, $bottomY$, $bottomZ$, $node_stack_bottom[3]$, $node_stack_bottom[4]$, $node_stack_bottom[5]$, $node_stack_bottom[6]$ !bottomX = DELETE !bottomY = DELETE !bottomZ = DELETE bottom1X = #$node_stack_bottom1[0]$ bottom1Y = #$node_stack_bottom1[1]$ bottom1Z = #$node_stack_bottom1[2]$ @bottom1X *= 1.25 @bottom1Y *= 1.25 @bottom1Z *= 1.25 @node_stack_bottom1 = #$bottom1X$, $bottom1Y$, $bottom1Z$, $node_stack_bottom1[3]$, $node_stack_bottom1[4]$, $node_stack_bottom1[5]$, $node_stack_bottom1[6]$ !bottom1X = DELETE !bottom1Y = DELETE !bottom1Z = DELETE // 2 bottom2X = #$node_stack_bottom2[0]$ bottom2Y = #$node_stack_bottom2[1]$ bottom2Z = #$node_stack_bottom2[2]$ @bottom2X *= 1.25 @bottom2Y *= 1.25 @bottom2Z *= 1.25 @node_stack_bottom2 = #$bottom2X$, $bottom2Y$, $bottom2Z$, $node_stack_bottom2[3]$, $node_stack_bottom2[4]$, $node_stack_bottom2[5]$, $node_stack_bottom2[6]$ !bottom2X = DELETE !bottom2Y = DELETE !bottom2Z = DELETE // 3 bottom3X = #$node_stack_bottom3[0]$ bottom3Y = #$node_stack_bottom3[1]$ bottom3Z = #$node_stack_bottom3[2]$ @bottom3X *= 1.25 @bottom3Y *= 1.25 @bottom3Z *= 1.25 @node_stack_bottom3 = #$bottom3X$, $bottom3Y$, $bottom3Z$, $node_stack_bottom3[3]$, $node_stack_bottom3[4]$, $node_stack_bottom3[5]$, $node_stack_bottom3[6]$ !bottom3X = DELETE !bottom3Y = DELETE !bottom3Z = DELETE // 4 bottom4X = #$node_stack_bottom4[0]$ bottom4Y = #$node_stack_bottom4[1]$ bottom4Z = #$node_stack_bottom4[2]$ @bottom4X *= 1.25 @bottom4Y *= 1.25 @bottom4Z *= 1.25 @node_stack_bottom4 = #$bottom4X$, $bottom4Y$, $bottom4Z$, $node_stack_bottom4[3]$, $node_stack_bottom4[4]$, $node_stack_bottom4[5]$, $node_stack_bottom4[6]$ !bottom4X = DELETE !bottom4Y = DELETE !bottom4Z = DELETE stackX = #$node_stack[0]$ stackY = #$node_stack[1]$ stackZ = #$node_stack[2]$ @stackX *= 1.25 @stackY *= 1.25 @stackZ *= 1.25 @node_stack = #$stackX$, $stackY$, $stackZ$, $node_stack[3]$, $node_stack[4]$, $node_stack[5]$, $node_stack[6]$ !stackX = DELETE !stackY = DELETE !stackZ = DELETE }

How about from street level?

But I don't actually care if another modder makes their parts indestructible. I might not agree with it, I might think it's stupid and pointless but I don't think the original intention of ridiculousMaxTemp was to flat out prohibit that sort of thing. Only to try to sanitize max temp choices that were made without proper consideration as to consequence. (most of those choices were made at a time that predated any sort of reentry heating at all)

No, you are correct. They are helium pressurization tanks. See page twelve of the linked document. http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20150002600.pdf

But what does that mean? And, why is it an advantage? And what IS the proposal? Can you provide a clear and concise example of it in action? And demonstrate why doing it that way is an advantage to a setting which if applied allows other modders to not have their part's maxTemperature tampered with at all? Because I'm still not getting it

Added a missing bracket and fixed spelling. (also indented because I'm an indentation [CENSORED POLITICAL PARTY THAT WE ARE APPARENTLY NOT ALLOWED TO SAY]) @PART [*]:HAS[@RESOURCE[WasteHeat]]:NEEDS[DeadlyReentry] { %leaveTemp = True }

what are the advantages over a setting that let's modders opt out and say they'll be responsible for their own max temps?

If KSPI engines also have a problem then they'll need the updated version of this file: https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry/EngineHeatAdjuster.cfg (it'll be in the next update for DRE)

Since RF Engine Configs itself is primarily just a set of configs for other plugins, it's likely that the problem is with one of those other plugins, probably RCSFX given that it happens when placing RCS parts. Make sure you have the latest version of it. And check your logs for errors. That may well have more data on the problem and give you an idea of where you need to be reporting this.

I remember KSPI issues being brought up a couple of months back and some suggestions were made, including suggesting the use of leaveTemp after that no further mention of KSPI problems was made so I assumed that that was the end of it. If people want to have radiators dissipating gigawatts and gigawatts of heat and DRE compromises their ability to do that.... Well, I think suggesting the use of something that was put in place to allow people to exempt their parts from DRE modification is a reasonable solution.

I just pretend the black lines are caused by the energy shield protecting Kerbin from unwanted asteroid strikes that might cause a Kerbal Extinction Event.

Why not put leaveTemp in the main body of your part config? That is checked for and added to the part's ModuleAeroReentry during MM config processing.

wait really? But FOR also specifies scheduling passes and NEEDS can be used to run in the absence of a specific mod. There's times where you do want to use both.

Ok, eightiesboi, I just put a capsule with one of those cone chutes through a reentry from the Mun and it came through ok. Are you keeping it properly shielded the entire way down? (keeping the capsule between the chute part and the airstream with no bits peeking out)

I'm guessing he added the extra shield because he was doing a Munar return. The Mk1's builtin shields aren't meant to handle a reentry at those speeds; it can be problematic.

I'll take a look at some things to see if DRE is a factor but definitely without a doubt (stock heating or DRE) having a higher thermal mass (skin or internal) is not even a possible cause.

Yes, they do and I've suggested it myself long before 1.0

Seems like you're unclear on the role that thermal mass plays. The cone chute is not overheating because it has a higher thermal mass. In fact if it had a lower thermal mass it would heat up even faster. That's what thermal mass is. It's a measure of how much heat the thing has to take in to raise its temperature by a given amount. It is based on the part's specific heat times its mass. You only have it selected in a few shots so it's not clear where the heat was coming from that destroyed it. It did record some convective flux at some point (apparently not fully turned away from the shockwave I guess) but that was of negligible levels in that one shot.

The VAB does give costs even in Sandbox. It also displays total vessel cost. It just doesn't have anything to deduct them from and doesn't use cost to determine if a craft can launch or not.

You know what I'm thinking.... someone needs to make a Space 1999 Eagle... (or something inspired by one)