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

[NathanKell]

Nonono, I greatly appreciate your finding that! I wasn't not being grateful, just not wanting to get anyone's hopes up about it fixing things.

Are you blowing up every part in the vessel when that happens? It seems to happen only when the last part is destroyed.

[FlowerChild]

Nonono, I greatly appreciate your finding that! I wasn't not being grateful, just not wanting to get anyone's hopes up about it fixing things.

Oh, I didn't mean to imply there was any offense taken man. Sorry, my writing becomes rather blunt when I'm talking about coding matters which tends to be easy to interpret as something other than my intent

Are you blowing up every part in the vessel when that happens? It seems to happen only when the last part is destroyed.

No, and that's something I was thinking about as well. It's only the cockpit itself which I'm blowing up in my code, with the rest of the craft quickly following by whatever vanilla code causes that to happen.

The other thing I've been wondering about is whether it's actually the DR code which is destroying parts on overheating, whether the vanilla code for doing the same kicks in, or whether there's some weird overlap between the two.

Since you mention the last part bit, one thing I might try with my cockpit code is running a test where I use stack separators to make the cockpit the only part left on the vehicle when it hits vacuum to see if it triggers the bug.

Edited November 3, 2013 by FlowerChild

[FlowerChild]

Ok, just ran the above test with my cockpit code, and no, it didn't trigger the UI bug. Very strange.

I'm basically doing the same thing the DR code is, checking for low atmospheric pressure in the update function of a partModule I've added to the cockpit, and blowing it up with a part.explode() call if it drops too low.

Just in case you spot something I'm doing differently that I didn't, here's my code for the cockpit:

        public override void OnUpdate()
        {
            base.OnUpdate();

            //print( "BTSMModulePressurizedCockit: On update" );

            Vessel currentVessel = FlightGlobals.ActiveVessel;

            if ( currentVessel != null && currentVessel == vessel && currentVessel.state != Vessel.State.DEAD  )
            {
                if ( currentVessel.orbit.referenceBody.bodyName != "Kerbin" || FlightGlobals.getStaticPressure() < minSafePressure )
                {
                    //print( "BTSMModulePressurizedCockit: Below safe pressure of " + minSafePressure + " at pressure of " + FlightGlobals.getStaticPressure() );

                    if ( explodeOnFail )
                    {
                        ScreenMessages.PostScreenMessage( part.name + " failed due to explosive decompression.", 10F, ScreenMessageStyle.UPPER_CENTER );

                        part.explode();
                    }
                    else
                    {
                        KillContainedKerbals();
                    }
                }
                else
                {
                    //print( "BTSMModulePressurizedCockit: " + "at pressure of " + FlightGlobals.getStaticPressure() + " With safe pressure of " + minSafePressure );
                }
            }
        }

Edited November 3, 2013 by FlowerChild

[NathanKell]

Are you running that as a partmodule? Or a partless plugin?

[FlowerChild]

Are you running that as a partmodule? Or a partless plugin?

It's a part module, and the fields tested within OnUpdate() are fields set within the part config file:

    public class BTSMModulePressurizedCockpit : PartModule
    {
        [KSPField(isPersistant = false)]
        public float minSafePressure = 0.5F;

        [KSPField(isPersistant = false)]
        public bool explodeOnFail = false;
    }

[NathanKell]

Huh! Weird. Ok then. If you're consistently not getting the problem then DREC must be doing something to exacerbate it.

Off the top of my head, only thing I could think of was that other partmodules weren't handling on part die events and failing non-gracefully when the part explodes.

[FlowerChild]

Huh! Weird. Ok then. If you're consistently not getting the problem then DREC must be doing something to exacerbate it.

Off the top of my head, only thing I could think of was that other partmodules weren't handling on part die events and failing non-gracefully when the part explodes.

Well, with my limited knowledge of the DR code (and KSP modding in general...I just started poking around in this code base a couple of weeks ago), the only real difference I can see is that the DR code seems to be operating on FixedUpdate() as opposed to the OnUpdate() override of partModule that I'm using. Is it possible this is causing the parts to get destroyed outside of the regular KSP part update loop and thus is being handled differently?

Also, I just noticed that in this portion of the DR code:

		public void FixedUpdate ()
		{
			if (dead || !part.Rigidbody || part.physicalSignificance == Part.PhysicalSignificance.NONE)
				return;

			Fields ["displayShockwave"].guiActive = ReentryPhysics.debugging;
			Fields ["displayGForce"].guiActive = ReentryPhysics.debugging;
            Fields["gExperienced"].guiActive = ReentryPhysics.debugging;

			Vector3 velocity = (part.Rigidbody.GetPointVelocity(part.transform.position) + ReentryPhysics.frameVelocity);
			part.temperature += ReentryHeat (velocity);
			displayTemperature = part.temperature;
			CheckForFire (velocity);
			CheckGeeForces ();


		}

It's possible for CheckForFire() to blow up a part, and then the CheckForGeeForces() function will still be executed on it regardless. Again, no idea if that would be related, but seems to be a similar source of potential issues to what I pointed out earlier today.

And yeah, I get the UI freeze 100% of the time when a vessel burns up on reentry, but have yet to ever run into it when my cockpits explosively decompress, so it looks like there's something funky going on here

Edited November 4, 2013 by FlowerChild

[sidfu]

when it happened to me was when i ran out of power on reentry and insta blue up due to heat. when went back to space center couldnt select any building. onnly button worked was eascape back to start menu when went back to it couldt even hit any of those either had to endtask the game

[DartBoris]

Greetings

Just tryed this mod and it seems awesome , however I have some questions about heatshield mechanics and configs

Take for example 1.25 heatshield:

name = ModuleHeatShield
direction = 0, -1, 0 // bottom of pod
reflective = 0.05 // 5% of heat is ignored at correct angle

Thats about non-abliative part of the heatshield? Just like one direction of a module have 5% heat ignore bonus? And if I set direction= 0,0,0 it will just ignore 5% from all sides? "Ignore" means "get 5% less heat income" I guess.

ablative = AblativeShielding
loss
{ // loss is based on the shockwave temperature (also based on density)
        key = 650 0 // start ablating at 650 degrees C
        key = 1000 64 // peak ablation at 1000 degrees C
        key = 3000 80 // max ablation at 3000 degrees C
}
dissipation
{ // dissipation is based on the part's current temperature
	key = 300 0 // begin ablating at 300 degrees C
	key = 500 360 // maximum dissipation at 500 degrees C

And thats about abliative part , basically the part starts heating up , reaches some heat level and start losing abliative resource. Losing this resource it also loses heat. Highter temperature = highter ablation = highter heat dissipation.

If it gets more heat than it can dissipate even on max - it will overheat and explode like an usual part.

I am Correct?

--wrong guess removed--

UPD: Looked into source code , seems like I cant understand the code and formulas

So what do theese two config values (loss and dissipation) do?

Edited November 4, 2013 by DartBoris

[FlowerChild]

So what do theese two config values (loss and dissipation) do?

From my (admittedly limited) understanding, loss controls how fast your ablative shielding is consumed at specific temperatures, while dissipation controls how much heat is dissipated at certain temperatures.

At temperatures in between, the rate of loss and dissipation are interpolated between the values specified, so in other words they will be somewhere in between.

With the example you provided above then, the part begins dissipating heat above 300 degrees, and your ablative shielding starts getting worn away above 650. While both values appear as zeroes, that's the point at which any further temperature increase will start slowly increasing the values until the next specified temperature is reached (so between 650 and 1000 degrees, your rate of loss is somewhere in between 0 and 64 in the above example).

Basically, as temperature increases your rate of loss and dissipation also increase until they hit the specified maximums.

Edited November 4, 2013 by FlowerChild

[DartBoris]

From my (admittedly limited) understanding, loss controls how fast your ablative shielding is consumed at specific temperatures, while dissipation controls how much heat is dissipated at certain temperatures.

Thanks ,I think I got it.

Dissipation is kind of "effectiveness"

Also found Nathan's post:

actual heat dissipation = dissipation rate * kgs of ablative lost

[SirJodelstein]

Ummm.. this mod has just set Jeb on fire. On the surface of Kerbin while standing still. Whats happening? Debug log shows nothing special...

[NathanKell]

FlowerChild: Yeah, could be re: update. Although, interestingly, you'd think it'd be the other way around. I'll do some tests.

Regarding shields. Most shields have comments describing what they do, but here's the lowdown:

The vector specifies whether the heat shield is directional or not; if the velocity vector doesn't match the direction you won't get shielding. (If direction vector is 0, then it protects in all directions)

Reflectivity is as it says, you will get only (1.0 - reflec) of the heat applied.

loss rate determines how many units of ablative get used up per second at that temperature at sea level air density. Note that the temperature here is the SHOCKWAVE temperature (surf velocity - 275, ironically enough), NOT the part temperature. So it's not that it won't ablate if the part is < 650C; it's that it won't ablate if velocity < 925 m/s

dissipation controls how much heat dissipation each unit of ablative shielding gives when it ablates. Here, temperature is the part's temperature. (This could lead to the odd situation where if the values didn't correspond you could lose shielding without dissipation, a bug I fixed in v3).

Actual heat loss = dissipation * loss rate.

[FlowerChild]

FlowerChild: Yeah, could be re: update. Although, interestingly, you'd think it'd be the other way around. I'll do some tests.

Well, I dunno man. My (again limited) understanding is that FixedUpdate() is a Unity engine function that handles physics updates, while OnUpdate() is specific to parts. Thus, my assumption would be that if there's any game specific updates that need to be done, such as handling any cleanup that happens when parts are destroyed, it would occur on (or after) OnUpdate(). If performed outside of that, I would theorize that perhaps the game's update loop isn't even aware that a part has been removed and thus an invalid state may result.

It's all just guesswork on my part since we don't actually have access to the code base, but that's what my instincts are saying. I know that when I created my module I just naturally leaned towards updating within KSP updates rather than the engine's because they seemed to be happening at a higher level.

Anyways, crossing fingers that's what is going on here. I must admit it's rather odd to be coding without being able to see the code base or at least having access to documentation on what's occurring under the hood

[NathanKell]

I was thinking the opposite because FixedUpdate runs once per physics tick, whereas IIRC Update() runs more frequently. But you might have it exactly right--I'll swap over and see what happens. Thanks for all this!

[FlowerChild]

I was thinking the opposite because FixedUpdate runs once per physics tick, whereas IIRC Update() runs more frequently. But you might have it exactly right--I'll swap over and see what happens. Thanks for all this!

My pleasure man. Thanks for being so cool and helpful in terms of accommodating the project I'm working on

One thing that occurs to me as a potentially simple middle-ground is to flag your parts for destruction in the existing FixedUpdate() function, then check that flag within OnUpdate() for the actual explosive bits.

Might be a workaround or at least test without substantially modifying the code base.

Edited November 5, 2013 by FlowerChild

[sidfu]

me i still have the bug where if to many parts blow up at one time lose button use. also should we have higher temps for sheilds for the rescale. was playing with rescale and failed getting orbit so but had a trejectory to skim the air to lose speed but the heatsheild overheated and blew before it even used 1% of its abative.

nathan since u work on rescale also can u make custom DREC settings for rescaled like your custom fuels?

Edited November 5, 2013 by sidfu
bad spelling bahh

[jpinard]

Nathan (or anyone), what was the suggested setting for this if I want to play it with default Kerbal, but want a moderate-to-difficult challenge to burning up? It seems like the base values are way too easy, and I want to put numbers in you all suggest or I'm likely to screw this up.

Thanks!

[FlowerChild]

Nathan (or anyone), what was the suggested setting for this if I want to play it with default Kerbal, but want a moderate-to-difficult challenge to burning up? It seems like the base values are way too easy, and I want to put numbers in you all suggest or I'm likely to screw this up.

Thanks!

I'm actually working on tweaking values at present for what I think you're looking for.

The key value is shockwaveExponent in custom.cfg.

Nathan suggests a value of 1.16 for this if you want a "realistic" type experience. I'm finding a value of 1.09 provides a good compromise between challenge and maintaining a stock KSP style of gaminess to it.

At 1.09, I'm still in the process of tweaking the heat shields to go well with it but for both the MKI command pod and the 1.25 m heat shield changing the upper dissipation to 480 (which is based on Nathan's own tweaking to recreate a Gemini capsule) does a very good job of it in terms of giving you a shield that will survive reentry from low orbit at reasonable angles of reentry. If you drop the following into a config file, it should do the trick there:

@PART[mk1pod]:Final
{

	@MODULE[ModuleHeatShield]
	{ 
		@dissipation
		{
			@key, 1 = 800 480
		}
	}
}

// 1.25m Heatshield
@PART[1.25_Heatshield]
{
	@MODULE[ModuleHeatShield]
	{ 
		@dissipation
		{
			@key, 1 = 800 480
		}
	}
}

When I'm done my tweaking pass, I'll release this stuff in a convenient package in case anyone is looking for the same kind of "game" feel I am with this.

Edited November 6, 2013 by FlowerChild

[15nelsoc]

When I'm done my tweaking pass, I'll release this stuff in a convenient package in case anyone is looking for the same kind of "game" feel I am with this.

Please do. That would be great.

[theSpeare]

Big problem - I'm having my atmospheric ground bases spontaneously exploding due to "burning up on re-entry" when I switch to them in the map view.

[Bloodbunny]

Mk 1 pod is going "pop" on reentry due to overheating, despite my heat shield facing the proper direction, the ablative shield drops from 250 down to 248, doing nothing about the heat.

[ANWRocketMan]

@BloodBunny: You probably need to re-enter at a shallower angle.

@theSpeare: I'm thinking that's the same bug that happened with the launch bug that was fixed in v2.1(It think).

On that point...

@NathanKell: Is DR disabled for the first second after switching to a new vessel? If not, would it be possible to add?

[Bloodbunny]

@BloodBunny: You probably need to re-enter at a shallower angle.

@theSpeare: I'm thinking that's the same bug that happened with the launch bug that was fixed in v2.1(It think).

On that point...

@NathanKell: Is DR disabled for the first second after switching to a new vessel? If not, would it be possible to add?

If I needed a shallower angle, wouldn't the ablative shield burn off and then make Jeb go boom? Doesn't make sense that the pod is blowing up with 98 % of the shield left.

Also, it seems this doesn't dance well with FAR anymore.. not getting much deceleration for my heating troubles... I'm hitting nearly 1200 C with an PE of around 41500m, but hardly slowing down at all.. DRE as is now seems to make realistic reentry from Mun returns, etc basically impossible with FAR, because if you dip low enough to slow down and avoid flying back towards the Mun you die. Even if you set your PE perfectly where you don't die, you won't slow down, and die anyway.

Edited November 6, 2013 by Bloodbunny

[Lexif]

If I needed a shallower angle, wouldn't the ablative shield burn off and then make Jeb go boom?

Do you get destroyed by the deceleration or do you burn up? (What does the post-flight log say?) Generally, if you reenter steeper, forces become limiting, and if you reenter shallower, overhearing sets the limit. You have to find the right balance.

Edit: Ferram4 says he's working on the pod aerodynamics. Last point:

http://forum.kerbalspaceprogram.com/threads/20451-0-22-Ferram-Aerospace-Research-v0-9-7-Aerodynamics-Fixes-For-Planes-Rockets?p=759385&viewfull=1#post759385