Jump to content

[1.12.*] Deadly Reentry v7.9.0 The Barbie Edition, Aug 5th, 2021


Starwaster

Recommended Posts

45 minutes ago, Starwaster said:

what the 'onion' is nor what the justification would be for it withstanding reentry so have no idea how to treat it.

A wiki link. A bulbously shaped crew pod similar to the Mk1 command pod. It has no reaction wheels or mono-propellent, but can carry 20 units of ablator and a 500K Threshold temperature (similar to the stock Heat Shield (1.25m) ). MH-DLC contains 3 of these 'Reentry Module' parts, that exist to, well, do a reentry.

Link to comment
Share on other sites

Ok, I guess another player who owns MH can tell what their experience was. 'Onion' is one of the command pods added by the expansion, which corresponds roughly to Vostok capsule and has built-in decoupler and heat shield (with 20 units of Ablator). It's a sort of low-end one-man part. There are also 2- and 3-kerbal variants of it.

Link to comment
Share on other sites

I'm kind of puzzled as to how Ablator works. I've just done a couple airbrakes from an apoapsis of 2Mm at both 50 and 60km periapsis. On the 60 km periapsis my orbit shrinked gradually until after 5 or 6 passes it got fully within the atmosphere and I finally came down with about 20-30 ablator out of 200 (last phase was a rather steady descent with an aggressive-ish final burn). On the 50 km reentry however, I got into the atmosphere much earlier, and spent a whole lot of time inside the atmosphere (without actually burning up) but that steadily drained my ablator at a rate that wasn't too dissimilar when actually going through the thicker parts of the atmosphere. Due to me going down to 50 but then coming up to about 60 and then down again and staying at that altitude for a whole bunch of time, and despite technically being exposed to less heat than on the previous reentry, my ablator ran out at the last phase and the heatshield exploded (still landed though, apparently the shield gave out at the last minute). However, that felt weird. Isn't ablator supposed to go away at different rates according to the density -and heat- you're exposed to? I'd imagine a controlled deceleration at about 60 km should be way less hard on it than coming down to a more aggressive airbrake, but while it's true that if you go down too hard heat will bleed through and eventually burn the craft, ablator seems to drain at a very similar, steady rate?

Edited by Ottomic
Link to comment
Share on other sites

20 hours ago, Ottomic said:

I'm kind of puzzled as to how Ablator works. I've just done a couple airbrakes from an apoapsis of 2Mm at both 50 and 60km periapsis. On the 60 km periapsis my orbit shrinked gradually until after 5 or 6 passes it got fully within the atmosphere and I finally came down with about 20-30 ablator out of 200 (last phase was a rather steady descent with an aggressive-ish final burn). On the 50 km reentry however, I got into the atmosphere much earlier, and spent a whole lot of time inside the atmosphere (without actually burning up) but that steadily drained my ablator at a rate that wasn't too dissimilar when actually going through the thicker parts of the atmosphere. Due to me going down to 50 but then coming up to about 60 and then down again and staying at that altitude for a whole bunch of time, and despite technically being exposed to less heat than on the previous reentry, my ablator ran out at the last phase and the heatshield exploded (still landed though, apparently the shield gave out at the last minute). However, that felt weird. Isn't ablator supposed to go away at different rates according to the density -and heat- you're exposed to? I'd imagine a controlled deceleration at about 60 km should be way less hard on it than coming down to a more aggressive airbrake, but while it's true that if you go down too hard heat will bleed through and eventually burn the craft, ablator seems to drain at a very similar, steady rate?

Yes and no. The only thing that truly controls the rate of ablation is the temperature of the ablative material which is controlled by the speed you are passing through the atmosphere (determines shockwave temperature) and atmospheric density which controls how much of that heat is transferred to the shield.

The shield undergoes pyrolysis anytime it is above 500K so your shield had to be at least that hot and you don't give details about what the temperature actually was or what the actual total absorbed heat was. (that info is available in the part action menu if you enable thermal debugging. It will tell you actual heat lost through pyrolysis, ablation rate in kg, total absorbed heat, peak absorbed heat and heat per cm2)

Link to comment
Share on other sites

I'll defo keep an eye on this next time, to be honest I didn't monitor part temperature, it was more me going by ear and just judging how red the shield got, and since I didn't see any I just assumed the temps would be not high enough to trigger ablator loss. To be fair, I stopped playing back when LKO was 4500 delta v, so I'm probably used to a much more cooperative atmosphere in regards to braking.

Edited by Ottomic
Link to comment
Share on other sites

Just to say, no complaint.

 

Using DeadlyReentry with RealHeat and latest FAR inofficial on RSS but without RO is a pita - I had to fiddle the ReentryHeatScale down to 0.1 and also edit my already used patch to this

GameData\zFinal\zzz_HeatShieldsFix.cfg

// Gordon Dry
// https://forum.kerbalspaceprogram.com/index.php?/topic/174912-cold-reentry-no-ablator-consumed/

@PART[*]:HAS[@MODULE[ModuleAblatorImproved]]:NEEDS[!DeadlyReentry,!RealismOverhaul,ImprovedAblator]:FINAL
{
	@MODULE[ModuleAblatorImproved]
	{
		@name = ModuleAblator
	}
}

@PART[*]:HAS[@MODULE[ModuleHeatShield]]:NEEDS[DeadlyReentry,!RealismOverhaul,!ImprovedAblator]:FINAL
{
	@RESOURCE[AblativeShielding]
	{
		@name = Ablator
	}
	
	@MODULE[ModuleHeatShield]
	{
		@name = ModuleAblator
	}
}

@PART[*]:HAS[@MODULE[ModuleAblator]]:NEEDS[!RealismOverhaul]:FINAL
{
	%maxTemp=1400
	%skinMaxTemp=2500
	@MODULE[ModuleAblator]
	{
		@pyrolysisLossFactor = 6000
		@lossConst = 1
		@lossExp = -7500
		@ablationTempThresh = 500 // was 500K (redunant to the change above)
		@reentryConductivity = 0.001
		// %useChar = True
		// %charModuleName = shieldChar
	}
	@RESOURCE[Ablator]
	{
		// Default to lighter heat shields.
		@amount *= 0.5

		// Allow bigger heat shields. Useful for repeat flybys.
		@maxAmount *= 2
	}
}

@PART[InflatableHeatShield]:NEEDS[!RealismOverhaul]:FINAL
{
    %maxTemp = 1500
    %skinMaxTemp = 2500
}

@PART[InflatableHeatShield]:NEEDS[!RealismOverhaul]:FINAL
{
	@MODULE[ModuleAblator]
	{
		!useChar = delete
		!charModuleName = delete
	}
}

@PART[KADEPT*]:NEEDS[TokamakIndustries,,!RealismOverhaul]:FINAL
{
    // Special treatment of the foldable KADEPT heatshields from TokamakIndustries
    // because they rock - and they're made of high-tech Mystery Goo impregnated fabric
    %maxTemp = 1600
    %skinMaxTemp = 3000
}

// @PART[KADEPT*]:NEEDS[TokamakIndustries,!DeadlyReentry,!RealismOverhaul]:FINAL
// {
	// @MODULE[ModuleAblator]
	// {
		// !useChar = delete
		// !charModuleName = delete
	// }
// }

@PART[ServiceBay_*]:NEEDS[!RealismOverhaul]:FINAL
{
    // Who needs a heat shield when a service bay is totally indestructible?
    // stock max temp was 3000.
    %maxTemp = 1000
	%skinMaxTemp=1600
}

@PART[ServiceBay_*]:HAS[!MODULE[ModuleAeroReentry]]:NEEDS[DeadlyReentry,!RealismOverhaul]:FINAL
{
	MODULE
	{
        name = ModuleAeroReentry
		skinMaxOperationalTemp = #$/skinMaxTemp$
		leaveTemp = true
	}
}

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[KerbalEVA],!MODULE[ModuleAblator],#CrewCapacity[>0]]:NEEDS[!RealismOverhaul]:FINAL
{
	// This is a crewed pod - is it supposed to be hotter than a hardcore finnish sauna inside?
	// Caution!
	%maxTemp=500
	%skinMaxTemp=1200
}

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[KerbalEVA],!MODULE[ModuleHeatShield],#CrewCapacity[>0]]:NEEDS[DeadlyReentry,!RealismOverhaul,!Kopernicus]:FINAL
{
	// This is a crewed pod - is it supposed to be hotter than a hardcore finnish sauna inside?
	// Caution!
	%maxTemp=500
	%skinMaxTemp=1200

	MODULE
	{
		name = ModuleHeatShield
		ablativeResource = AblativeShielding
		lossExp = -7500
		lossConst = 1.6
		pyrolysisLossFactor = 6000
		reentryConductivity = 0.001
		ablationTempThresh = 500
		depletedMaxTemp = 1200
		charMin = 1
		charMax = 1
		charAlpha = 1
		useNode = true
		nodeName = bottom
	}
	RESOURCE
	{
		name = AblativeShielding
		amount = 2
		maxAmount = 10
	}

	%MODULE
	{
		%name = ModuleAeroReentry
		%skinMaxOperationalTemp = #$/skinMaxTemp$
		%leaveTemp = true
	}
}

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[KerbalEVA],!MODULE[ModuleHeatShield],#CrewCapacity[>0]]:NEEDS[DeadlyReentry,!RealismOverhaul,Kopernicus]:FINAL
{
	// This is a crewed pod - is it supposed to be hotter than a hardcore finnish sauna inside?
	// Caution!
	%maxTemp=1200
	%skinMaxTemp=2400

	MODULE 
	{
			name = ModuleHeatShield
			ablativeResource = AblativeShielding
			reentryConductivity = 0.001
			ablationTempThresh = 500
			lossExp = -40000
			lossConst = 150000
			pyrolysisLossFactor = 4000
			reentryConductivity = 0.001
			depletedSkinMaxTemp = 1200
	}
	RESOURCE
	{
		name = AblativeShielding
		amount = 20
		maxAmount = 100
	}
	%MODULE
	{
		%name = ModuleAeroReentry
		%skinMaxOperationalTemp = #$/skinMaxTemp$
		%leaveTemp = true
	}
}

// is this even useful anymore?
@PART[*]:HAS[@MODULE[ModuleAblator],@MODULE[ModuleLiftingSurface]]:NEEDS[FerramAerospaceResearch]:FINAL
{
	!MODULE[ModuleLiftingSurface] { }
}

// @PART[*]:HAS[@MODULE[ModuleAblator]]:NEEDS[!DeadlyReentry,!RealismOverhaul]:FINAL // ,!FerramAerospaceResearch
// {
	// @thermalMassModifier *= 0.5
// }

// @PHYSICSGLOBALS:NEEDS[!FerramAerospaceResearch]:FINAL
// {
	// @convectionVelocityExponent = 3.35
// }

// @RESOURCE_DEFINITION[Ablator]:NEEDS[!FerramAerospaceResearch]:FINAL
// {
	// @hsp = 1000 // KSP 1.4.x stock value is 400, it was 100 way earlier
// }

@PART[*]:HAS[@MODULE[ModuleAblator]]:NEEDS[!DeadlyReentry,!RealismOverhaul,ImprovedAblator]:FINAL
{
	@MODULE[ModuleAblator]
	{
		@name = ModuleAblatorImproved
	}
}

@PART[*]:HAS[@MODULE[ModuleAblator]]:NEEDS[DeadlyReentry,!RealismOverhaul,!ImprovedAblator]:FINAL
{
	@RESOURCE[Ablator]
	{
		@name = AblativeShielding
	}
	
	@MODULE[ModuleAblator]
	{
		@name = ModuleHeatShield
		%depletedMaxTemp = 1200
		%ablativeResource = AblativeShielding
	}
}

// I could try to alter it that the values differ, for example by taking mass into account and using  "low pass filters" and "high pass filters" to have set minimum and maximum values.

But it could be that I have to change these values again - actually I'm still in early career and barely manage it to make a 6000 m/s+ suborbital trajectory - and this is with a bad periapsis of -3000 km when reaching an apoapsis of ~ 200 km - so the reentry is steep.

As soon as I manage a proper orbit and then a deorbit burn I will do more tests with the same probe.

And yes, I do properly play instead of cheating to do tests ...

Link to comment
Share on other sites

@dlrk actually I came to the conclusion that the unofficial FAR compile* is NOT working well - besides some UI glitches in the VAB UI - is throws a lot of exceptions when used with MJ and/or PF under some circumstances.
Either without PF it can be weird.

Now I removed FAR, but still RSS / DRE / RF / RealHeat and all the trizillion other mods ...
booting up KSP ...

*https://github.com/asdfCYBER/Ferram-Aerospace-Research/releases/tag/v0.15.9.3_ferram4.1

 

Edit:
@dlrk

Spoiler

 

with PF on vessel (still on launchpad):
many of these


NullReferenceException: Object reference not set to an instance of an object
  at FerramAerospaceResearch.FARAeroComponents.FARVesselAero.SimulateAeroProperties (UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, Vector3 velocityWorldVector, Double altitude) [0x00000] in <filename unknown>:0 
  at FerramAerospaceResearch.FARAPI.InstanceCalcVesselAeroForces (.Vessel vessel, UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, Vector3 velocityWorldVector, Double altitude) [0x00000] in <filename unknown>:0 
  at FerramAerospaceResearch.FARAPI.CalculateVesselAeroForces (.Vessel vessel, UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, Vector3 velocityWorldVector, Double altitude) [0x00000] in <filename unknown>:0 
  at (wrapper delegate-invoke) MuMech.VesselState/FARCalculateVesselAeroForcesDelegate:invoke_void__this___Vessel_Vector3&_Vector3&_Vector3_double (Vessel,UnityEngine.Vector3&,UnityEngine.Vector3&,UnityEngine.Vector3,double)
  at MuMech.VesselState.AnalyzeParts (.Vessel vessel, MuMech.EngineInfo einfo, MuMech.IntakeInfo iinfo) [0x00000] in <filename unknown>:0 
  at MuMech.VesselState.Update (.Vessel vessel) [0x00000] in <filename unknown>:0 
  at MuMech.MechJebCore.FixedUpdate () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)


with non-PF fairing on same vessel (still on launchpad):
not that many, but a lot as well of these:


NullReferenceException: Object reference not set to an instance of an object
  at FerramAerospaceResearch.FARPartGeometry.GeometryModification.StockJettisonTransformGeoUpdater..ctor (.ModuleJettison engineFairing, FerramAerospaceResearch.FARPartGeometry.GeometryPartModule geoModule) [0x00000] in <filename unknown>:0 
  at FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.SetupIGeometryUpdaters () [0x00000] in <filename unknown>:0 
  at FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.Start () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)


 

 

Edited by Gordon Dry
Link to comment
Share on other sites

1 hour ago, Gordon Dry said:

@dlrk actually I came to the conclusion that the unofficial FAR compile* is NOT working well - besides some UI glitches in the VAB UI - is throws a lot of exceptions when used with MJ and/or PF under some circumstances.
Either without PF it can be weird.

Now I removed FAR, but still RSS / DRE / RF / RealHeat and all the trizillion other mods ...
booting up KSP ...

*https://github.com/asdfCYBER/Ferram-Aerospace-Research/releases/tag/v0.15.9.3_ferram4.1

 

Edit:
@dlrk

  Hide contents

 

with PF on vessel (still on launchpad):
many of these



NullReferenceException: Object reference not set to an instance of an object
  at FerramAerospaceResearch.FARAeroComponents.FARVesselAero.SimulateAeroProperties (UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, Vector3 velocityWorldVector, Double altitude) [0x00000] in <filename unknown>:0 
  at FerramAerospaceResearch.FARAPI.InstanceCalcVesselAeroForces (.Vessel vessel, UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, Vector3 velocityWorldVector, Double altitude) [0x00000] in <filename unknown>:0 
  at FerramAerospaceResearch.FARAPI.CalculateVesselAeroForces (.Vessel vessel, UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, Vector3 velocityWorldVector, Double altitude) [0x00000] in <filename unknown>:0 
  at (wrapper delegate-invoke) MuMech.VesselState/FARCalculateVesselAeroForcesDelegate:invoke_void__this___Vessel_Vector3&_Vector3&_Vector3_double (Vessel,UnityEngine.Vector3&,UnityEngine.Vector3&,UnityEngine.Vector3,double)
  at MuMech.VesselState.AnalyzeParts (.Vessel vessel, MuMech.EngineInfo einfo, MuMech.IntakeInfo iinfo) [0x00000] in <filename unknown>:0 
  at MuMech.VesselState.Update (.Vessel vessel) [0x00000] in <filename unknown>:0 
  at MuMech.MechJebCore.FixedUpdate () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)


with non-PF fairing on same vessel (still on launchpad):
not that many, but a lot as well of these:



NullReferenceException: Object reference not set to an instance of an object
  at FerramAerospaceResearch.FARPartGeometry.GeometryModification.StockJettisonTransformGeoUpdater..ctor (.ModuleJettison engineFairing, FerramAerospaceResearch.FARPartGeometry.GeometryPartModule geoModule) [0x00000] in <filename unknown>:0 
  at FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.SetupIGeometryUpdaters () [0x00000] in <filename unknown>:0 
  at FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.Start () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

 

 

 

 

 

Please take this discussion outside this thread. If you have a problem with either FAR or MJ or both interacting with each other than discuss it in a valid forum where it can be addressed.

This thread is for the discussion of Deadly Reentry and nothing else.

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...
3 hours ago, Gordon Dry said:

Damn it which parameter I have to change to avoid so much heat transferred from the heatshield to the pod?

The pod's skin is getting hotter than the heatshield's skin ... (with heat cheat enabled).

Cheater, if the pod is getting hotter than the shield then it is NOT because it is receiving heat from the shield. 

KSP thermodynamics may not be perfect but it still follows the real world laws of physics and heat conducts from hotter to colder. In your provided example, heat will be flowing by conduction from the pod to the shield

Link to comment
Share on other sites

I had to cheat to see what's going on. I did it before the pod reached 1200 K skin temperature - at that time the heatshield skin temp was 1600 K - then the heatshield's skin did no more increase temp - the pod's skin still increased up to 1800 K.

It's like the charring of the ablator balances out at 1600 K and the pod always increases temp until the velocity goes below ~1800 m/s.
And it's like the heat shield just conducts the temp to the pod instead of properly charring it away. All other parts, like attached geiger counters, which are even more inside the danger area of the airstream / plasma stream - never go above 300 K.

Edited by Gordon Dry
Link to comment
Share on other sites

2 hours ago, Gordon Dry said:

I had to cheat to see what's going on. I did it before the pod reached 1200 K skin temperature - at that time the heatshield skin temp was 1600 K - then the heatshield's skin did no more increase temp - the pod's skin still increased up to 1800 K.

It's like the charring of the ablator balances out at 1600 K and the pod always increases temp until the velocity goes below ~1800 m/s.
And it's like the heat shield just conducts the temp to the pod instead of properly charring it away. All other parts, like attached geiger counters, which are even more inside the danger area of the airstream / plasma stream - never go above 300 K.

This is how conduction works: (grossly simplified)

conductionFlux = (part1.temperature - part2.temperature) * (some other conduction factors)

That first bit in parentheses is the temperature delta and it not only helps determine how much heat is conducting but it also determines which way it is conducting!

If the result is negative then part2 is losing heat is part1 is gaining heat. If it is positive then part1 is losing heat and part2 is gaining heat.

Let's say part1 is your heat shield at 1600K and part2 is your pod at 1800K

1600 - 1800 = -200 = (heat is flowing FROM your pod TO the shield) 

That's true no matter what the other conduction factors come out to be since it is the temperature delta governs heat flow direction. It's also true in all possible heat flow paths here which are not just skin-skin. Heat always flows from hot to cold until the temperature delta zeroes out. At that point you have thermal equilibrium.

The practical point of all this is that if your pod is getting hotter than the shield then it is not fully protected by the shield and is itself exposed to convective flux. (unless some other part that you are not mentioning is exposed and getting even hotter than the pod is at 1800)

Edited by Starwaster
Link to comment
Share on other sites

@Gordon Dry, what is the actual part being used for the pod, and which heatshield is being used? I had a problem with a part that was larger than it visually appeared and a tweakscaled heatshield that wasn't sizing properly. Admittedly, this was a few versions of KSP ago, as I am taking a break from the too-numerous updates that break all my mods, but in my case, the culprit was that my pod appeared to be protected (and should have been by the stats) but actually wasn't. I determined this by using a larger (not-tweakscaled) shield and then trying a different pod. Hope this helps!

Link to comment
Share on other sites

17 minutes ago, Gordon Dry said:

@eightiesboi it's the Bluedog_DB Gemini pod with the dedicated Gemini Heatshield, which btw got a rescaleFactor of 1 so it should be fine.

I don't use TweakScale actually (as usual, sometimes I give it a go and later then regret it).

I'd recommend grabbing a DRE (or stock) heatshield that is bigger than necessary and running a quick test reentry. Obviously, you might have to cheat a bit to get the test started, but if an oversized heatshield protects the pod, the dedicated one that comes with the Gemini might be a bit too small or the Gemini pod might be hanging outside the coverage of the dedicated heatshield due to the reentry angle. If the oversized heatshield does indeed work, you could use tweakscale to make it smaller until you narrow down the problem (no pun intended). If it *doesn't* work, then something else is wrong.

Again, I hope this helps. It worked for me but it took several passes.

Link to comment
Share on other sites

  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...