Jump to content

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

Starwaster

By Starwaster
in KSP1 Mod Releases

 Share

Recommended Posts

sarbian

sarbian

Posted
Posted
velusip: I thought wildcards only worked for the root confignode, which is why I didn't adjust RAPIER heat production in the cfg, only automatically.

Heck, just using @MODULE[ModuleEnginesFX,0] and ,1 should work too but that didn't work for me either. I'll bug Sarbian :)

More bugs ;.;

Link to comment
Share on other sites
OnEdge

OnEdge

Posted
Posted

Hi everyone, been searching the forum to try to find what I am sure is an obvious answer to my problem but to no avail. I have just downloaded a bunch of mods and started a new career:

B9

City Lights

Deadly Reentry

Ferram

KW

Interstellar

TAC life support

Kethane

KAS

I am unable to get a parachute to not fail on landing on Kerbin. I am on tech level 0, so MK1 pod, MK16 parachute with a small tank and T30 rocket. "Structural failure on linkage between Mk16 parachute and Command Pod MK1" and then "MK16 Parachute burned up on reentry".

Not sure firstly what I am doing wrong, (tried setting it at different altitudes etc) or which mod is doing it (presume Deadly Reentry hence the post here!)

Link to comment
Share on other sites
Nelien

Nelien

Posted
Posted
Hi everyone, been searching the forum to try to find what I am sure is an obvious answer to my problem but to no avail. I have just downloaded a bunch of mods and started a new career:

B9

City Lights

Deadly Reentry

Ferram

KW

Interstellar

TAC life support

Kethane

KAS

I am unable to get a parachute to not fail on landing on Kerbin. I am on tech level 0, so MK1 pod, MK16 parachute with a small tank and T30 rocket. "Structural failure on linkage between Mk16 parachute and Command Pod MK1" and then "MK16 Parachute burned up on reentry".

Not sure firstly what I am doing wrong, (tried setting it at different altitudes etc) or which mod is doing it (presume Deadly Reentry hence the post here!)

When are you deploying the parachute? Sounds like you might be deploying it far too early.

Link to comment
Share on other sites
team.leit

team.leit

Posted
Posted
This is from a 1.25m shield


	MODULE
	{
		name = ModuleHeatShield
		direction = 0, -1, 0 // bottom of pod
		reflective = 0.05 // 5% of heat is ignored at correct angle
		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
		}
	}
	RESOURCE
	{
		name = AblativeShielding
		amount = 250
		maxAmount = 250
	}

...

Thanks for the assistance, now to test it out and see how it works

Link to comment
Share on other sites
FlowerChild

FlowerChild

Posted
Posted (edited)
When I see the problem all the F3 log says is RAPIER engine exceeded g-force conditions. At the time the craft was in level stable flight, g-force needle in the green, doing 1056 m/s at a height of 17km. Highest g-force experienced was 4.8g, but that was earlier in the flight. Manually switching to the rocket mode does avoid the problem, but that should be unnecessary as there's still enough air intake to stay in air-breathing mode.

Just one thing to note that I think I've figured out about how DR works:

I think a lot of times when it says something is destroyed due to g-forces, heat is actually the problem.

My understanding of how the code functions is that when a part overheats, it begins to sustain damage. This lowers the g-force tolerance of the part, along with a few other variables (like how much torque it can withstand on attached nodes).

As a result, parts will often display as being destroyed by g-forces due to this lower tolerance, but it was the heat that caused that lower tolerance in the first place.

I agree that could definitely be a little clearer though in terms of player feedback, and not saying the Rapier in particular doesn't have issues (which Nathan seems to be on top of), just wanted to point out that when a part is listed as destroyed by g-forces, that isn't necessarily the problem, it's just what finished it off.

Edited by FlowerChild
Link to comment
Share on other sites
FlowerChild

FlowerChild

Posted
Posted (edited)

@Nathan: It appears that version 4.2 has a problem where the visual heat meter in the staging display for engines no longer relates to the actual heat of the engines, causing them to have a tendency to start taking damage and explode when the meter is only around the halfway point. 4.1 didn't have this issue, and it makes managing the throttle of high heat engines rather difficult :)

It seems similar to some of the problems I encountered that I previously mentioned when I attempted to create a custom engine module child class, so I think some of the new optimized code may be failing to recognize parts as engines in some places. I'll dig a bit into the code and see if I can find what's causing it as I put out a new release of BTSM last night, and it's been causing a great deal of confusion amongst players who also updated to the new DR at the same time.

EDIT: One thing that jumps out at me that might have something to do with it is the following change:

Old version:


	[KSPAddon(KSPAddon.Startup.EditorAny, false)]
	public class FixMaxTemps : MonoBehaviour

New version:


	[KSPAddon(KSPAddon.Startup.MainMenu, false)] // fixed
	public class FixMaxTemps : MonoBehaviour

Just a hunch mind you. Will run further tests and keep digging.

Edited by FlowerChild
Link to comment
Share on other sites
NathanKell

NathanKell

Posted
Posted (edited)

FlowerChild: I came up with what it is overnight. Pretty sure; I mean, I have to test, but...

It comes from how KSP .23 does loading, where it appears to reload parts (or rather partmodules) again later (thus clobbering some of DRE's changes). It bit Strethcy and RF any everything else in the butt, causing mucho headaches. Basically, the part's heatproduction will get reset to the way it was before but the gauge won't. I think I know what I need to do to fix it too.

Edited by NathanKell
Link to comment
Share on other sites
FlowerChild

FlowerChild

Posted
Posted
FlowerChild: I came up with what it is overnight. Pretty sure; I mean, I have to test, but...

It comes from how KSP .23 does loading, where it appears to reload parts (or rather partmodules) again later (thus clobbering some of DRE's changes). It bit Strethcy and RF any everything else in the butt, causing mucho headaches. Basically, the part's heatproduction will get reset to the way it was before but the gauge won't. I think I know what I need to do to fix it too.

Hehe...I think I just reached a similar conclusion right before reading this by reverting various bits of the code. It looks like the is_engine tracking variable is basically failing to initialize at the appropriate time and is basically constantly false. I suspect that may also apply to the other tracking variables being set in OnStart(), but I haven't confirmed that bit.

Just about to test a potential solution, and will report back in case it helps you out.

Link to comment
Share on other sites
FlowerChild

FlowerChild

Posted
Posted

Yeah, my test worked. What I basically did was add a tracking variable to the aero module, and the following code to the beginning of FixedUpdate():


public void FixedUpdate ()
{
            // FCMOD:
            if ( !bInitialized )
            {
                is_engine = (part.Modules.Contains("ModuleEngines") || part.Modules.Contains("ModuleEnginesFX"));
				is_eva = part.Modules.Contains("KerbalEVA");
				if (part.Modules.Contains ("ModuleParachute"))
					parachute = (ModuleParachute) part.Modules["ModuleParachute"];
                if (part.Modules.Contains("RealChuteModule"))
                {
                    realChute = part.Modules["RealChuteModule"];
                    rCType = realChute.GetType();
                }

                bInitialized = true;
            }

Which is basically just a copy of your new init bits from OnStart(). Everything works as it did with the above change.

Going to try something a bit cleaner now, like I suspect moving the init over to OnAwake() might do the trick.

Link to comment
Share on other sites
FlowerChild

FlowerChild

Posted
Posted

Yup, the OnAwake() thing worked perfectly:


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

			if (part && part.Modules != null)
			{
                is_engine = (part.Modules.Contains("ModuleEngines") || part.Modules.Contains("ModuleEnginesFX"));
				is_eva = part.Modules.Contains("KerbalEVA");
				if (part.Modules.Contains ("ModuleParachute"))
					parachute = (ModuleParachute) part.Modules["ModuleParachute"];
                if (part.Modules.Contains("RealChuteModule"))
                {
                    realChute = part.Modules["RealChuteModule"];
                    rCType = realChute.GetType();
                }
			}
        }

All that's needed is to move the above code from OnStart() over to OnAwake() and everything works great :)

Link to comment
Share on other sites
NathanKell

NathanKell

Posted
Posted

Great! Although, full props to a.g.--they did the speed refactor with all the new goodies. So that's not my new init bits. I'm going to (when I get a sec) also use a.g.'s profiler for RealFuels too (not that *you'd* care per se, but others will ^_^) and try for a similar speedup.

I'll add this and release 4.3--thanks so much!

Link to comment
Share on other sites
FlowerChild

FlowerChild

Posted
Posted
Great! Although, full props to a.g.--they did the speed refactor with all the new goodies. So that's not my new init bits. I'm going to (when I get a sec) also use a.g.'s profiler for RealFuels too (not that *you'd* care per se, but others will ^_^) and try for a similar speedup.

I'll add this and release 4.3--thanks so much!

My pleasure man!

I hesitate to ask given how much I know you have on your plate, but any chance for a quick patch? Related tech support on this issue for BTSM is becoming quite the headache :)

Link to comment
Share on other sites
Royalkin

Royalkin

Posted
Posted (edited)

I don't think this addon is working correctly with my installation (Perhaps, I screwed up installing it?). I did a re-entry from 30,000k apoapsis to a periapsis of 20k, with the Mk 1-2 Pod. Maximum velocity reached 3,250 m/s, maximum heating reached 860° C, and the craft survived. The shield had 400 remaining of it's 1,000 ablative material.

Is that correct, it seems awfully fast and hot?

Edited by Royalkin
Link to comment
Share on other sites

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.

×
 Share
Go to topic listing
×
×
  • Create New...