Starwaster

All on the Releases page https://github.com/Starwaster/DeadlyReentry/releases

It's a shame you don't bother to keep up with current events.

of course I have! I know about the Underpants Gnomes. I was just making a joke. I guess not a particularly funny one. I mean, it was funny to me and I was giggling the whole time I was typing it out.

Step 3 and 4 instructions unclear. Lost money and am now filing for Chapter 11 (p.s. congratulations on getting things sorted out)

Yeah, it's mostly just parts. I do suggest though that you download my plugin Layered Animations, which fixes a problem with the centrifuge animations: https://github.com/Starwaster/LayeredAnimations/releases/tag/1.1 It also requires Module Manager (not included). Included in the download is a config file that will patch the centrifuge when Module Manager is installed.

Unless you have explicitly disabled logging then you ALWAYS have a log. I wouldn't have sent you to that link to learn how to retrieve logs if I wasn't 100% sure a log existed.

Has anything else been docked to that particular port on the station previously? If so, the port's data might be corrupted. Something didn't get reset properly and it thinks it's not eligible for docking. There's a number of threads in the support section talking about that particular bug and how to fix it.

Logs people, LOGS! If you want help provide logs. This link provides instructions on how to find your logs. http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29

It IS a resource. Look at how DRE heat shields are set up. As mentioned though by someone else, most wings have builtin shields that are non-ablative. That's really the way to go too IMO because if you're putting ablative on the wing, it's going to be heavier which means greater ballistic coefficient. (unless you're playing stock drag where 95% of all parts are assigned the same drag value)

In fairness though, I can't put a beta up and not expect feedback on it. And some of Jacke's problems were caused by me meddling with part heat conductivity. (which is a really great idea for a heat shield part but had unanticipated side effects when applied to a capsule with a built in shield and that can have parts attached to it) Most materials can't be heated to temperatures that high without serious problems. Arguably, some parts of a high performance jet engine and its intake might operate at temperatures that high but the intake part as a whole probably not so much. (though I can see something like an intake that acts as shielded when closed but unprotected when opened. Easily accomplished with Deadly Reentry.

So.... I shouldn't bother sending an expedition there? I thought maybe aliens did it....

I don't often use the Translatron but it has seriously saved my bacon a few times. I was once sending a rescue ship to Duna in one of my favorite canyons. You probably have been there... It's one where you have to make sure your reentry clears the canyon lip before you can land in the canyon. Well I overshot the stranded Kerbals and ended up several kilometers away. So I lifted off about 50m and engaged the Translatron. Settings: Keep Vert, kill H/S (horizontal speed), Speed 0. That makes sure that vertical speed is 0 and actively counteracts any horizontal speed I accumulate. Then I just pitched over enough to gain horizontal speed. Engines automatically throttle to make sure my vertical speed doesn't drop. When I release the controls it pitches back enough to kill horizontal speed. Great for hovering. And flying above the ground in a tail lander rocket to the stranded Kerbals camp. In real life physics, sure absolutely. KSP parts constantly try to transfer heat between themselves even if the part it's trying to send heat to is hotter than itself (forgive the abuse of the word heat seeing as how this doesn't really follow any known model of heating) That's governed entirely by part.heatConductivity and changing it or part.heatDissipation can result in some screwy situations. I first experimented with it when trying to improve Real Fuel's heat pumps and it's possible to make parts explode with a bad combination. I could probably demonstrate what's happening by working it out on spreadsheet. The problem doesn't seem happen with externally attached shields. I suspect because they don't allow for attachments. So you think I decided it should be reduced below the melting point of steel because we had the default set to 1250? Well I guess that's a better explanation than 'I was on drugs' especially since I don't do drugs.... Yeah, I just saw that today. I knew but had forgotten that BTSM is overriding some things. DRE has a special file used for saving player settings which also uses :FINAL and usually overrides those overrides (because it happens later in the patching process which is alphabetical in order) However, I was experimenting with changing the order in the beta so I'm not sure that's still true. Have you checked that your settings are still being kept in the debug menu? Or do they revert to BTSM defaults? For now, yes, but I'm still calibrating things so the next beta update will probably use a higher multiplier. In theory, setting all of those to 1 would result in a more natural reentry experience except that Kerbin's smaller size requires faster heating, and KSP also dissipates heat much faster than it should. (read: reduces temperature faster than it should) One final thought to this very long reply is that in the next beta update I'm going to tie one change I made to the new heating model instead of it being default behavior because it seems clear from our exchanges that my changes are stomping all over Flowerchild's balancing of things. It's one thing for that to be contingent on player's choices because players should have final say in things, but it's another for it to be doing that out of the box. So next update you might want to try going back to the defaults that BTSM imposes, if you were happy with the way that was working pre-beta. It should work that way again when I'm done.

Edit your DeadlyReentry.cfg file and find the Mk1pod entry Find the line that says @maxTemp = 1250 // 1700 Change that to @maxTemp = 1700 You might also do that reentry with SVEL- (in MechJeb SMARTASS) I have a sneaking suspicion that because you're basically coming in unguided that as the dynamic pressure eases off right before the end, the batteries (the POT2-XL at the top) are getting exposed and the shockwave is still strong enough to heat them up. I can see in the log that they are catching fire well before the Mk1 is. Ordinarily that shouldn't be an issue but as you can see above, the Mk1 pod had its maxTemp lowered to 1250. (why the HELL did I do that? I have no idea but it's clearly an act of stupidity on my part) Even then, that STILL shouldn't be an issue. Overheated parts are only going to transmit enough heat to their parents (the RCS tank) to heat it up to 25%-50%. Which in turn should pass on a like amount of heat to the Mk1. My suspicion is that another change I made (across the board to all heat shielded parts) is causing the Mk1 to basically act as a sponge. Its conductivity is 0.01 (stock value is 0.12.... or was it 0.22. I forget) What that means is it can only conduct 0.01 of its own heat back at its parents or children. So I think that the other parts are sending heat into it that it can't get rid of. (basically 12% of their own heat) The idea behind the conductivity change by the way is that heat shields would serve to actually insulate the things they are shielding because in the old days attaching a shield to the bottom of a part would still cause that part to soak up a lot of heat just through the shield connection. Enough even to potentially destroy some of them (where maxTemps were around 600 or so)

Doesn't matter. If either tank runs dry, MJ will stage. I routinely use stages with H2 in them which means there was some boiloff so that stage depleted its fuel before its oxidizer. MJ doesn't care about that.

I don't even know how that's possible. DRE checks to make sure that the shockwave temperature is actually greater than the part's temperature or it can't increase temperature of the part. Was that log file you posted before from the time that this was happening?

Check your KSP settings in Graphics from the main menu? Maybe your AeroFX quality got turned down. I'm not seeing any telltales in those pictures as to why. I even looked at those logs you referenced earlier but I don't see anything in them either. (unless it wasn't doing it at that time? Errors in the wrong place at the wrong time can make parts heat up but that would be a very VERY slow and gradual thing..... so it's probably not that) Can you put it through that again but this time with the Debug menu open and right click the part? Take a screenshot of it when it starts to flame, or just note down the shockwave temperature and whether that had started to increase and let me know here.

If you look at those log files that you've provided, you will note that RealChute is deactivating the part shortly after staging on several occasions. That's something it does when the chute does not meet requirements for deployment and is not configured to arm. That is the only time of which I know that it ever does that. Regardless of which, that's RealChute that's doing that. It's a RealChute issue, not a MechJeb issue. Examples from your log: Also, a reference to RealChute's code that does that. StagingReset() DeactivateRC() So either you don't have it configured for arming or RealChute has an issue that needs taking up with Chris. Take your pick. (On a probably unrelated note, another of your mods (For Science) is throwing exceptions repeatedly in FixedUpdate.)

No, because that would be you reserving rights to something that Bobcat reserved all rights to. That's what the phrase means. So what has to happen is that he either changes the license publicly or gives you permission to do what you need to do. Edit: And then you'd have the text on your front page saying 'used with permission'. (or a CC license if he changes to that or PD if he public domains it, etc etc)

'lack of reentry heating' sounds like a bug, and this is very much a subjective thing influenced by a person's mod environment and (all too often) their own expectations. I'm working on consistent behavior based on better control for the former. The latter will always be an ongoing problem because sooner or later someone is going to launch a pod straight up into the air or on some other suborbital and then complain because they didn't burn up or didn't burn as much ablative as they thought they should. I can't fix the latter 'bug'. Complain to your local deity, or to evolution. That sounds about right. There is a definite area of peak heating based on velocity cross referenced with density at a given altitude. The precise altitude varies with reentry angle. For a 500km x 20km orbit that's somewhere around 28km. For an Apollo reentry (Moon return I think) reentry heating starts more gradually peaking somewhere around 60km. (again, YMMV) Obviously for something the size of Earth, not Kerbin Are these parts that were at a distance from your actual vehicle? If so there's probably not a lot that I can do right now. Or rather there is but it's not important enough to dedicate coding time to. (it's based on camera distance. The camera that renders reentry effects won't render past a certain distance which is the far clipping plane)

Correct. Inside the actual body of the patch you can do things like @MODULE[superCoolModdingModule],* and it will edit every single SuperCoolModdingModule the part has. Or you can do @MODULE[superCoolModdingModule],0 to just do the first one or @MODULE[superCoolModdingModule],1 to do the second one.

A steeper reentry will get that pod down safely. Are you still having overheating trouble on the ascent?

Set the first 4 to 1 and leave them there. Set Multiplier to 10-20. (probably 10... the build I'm working with is a bit different where I'm working with values much higher but that would be suicide with the build that's up for download right now)

Need to see pictures of that rocket and your staging arrangement. Something about your staging has MJ confused about whether it should stage. The RealChute issue sounds like a Real Chute issue. It doesn't auto-arm like stock does unless you configure it to do that in the settings. (click the parachute icon in the Space Center)

Thanks but logs are only really useful in tracking down errors. It would be more useful for me to know what your settings are and how they differ from defaults. it should be really hard for you to burn anything up on ascent now. Unless you're not using the new heating model. (Says Alternate and it should be enabled by default except that I think BTSM changes DRE defaults?)

Don't worry, you have time for all the sandwiches in the world. You will not run out of sandwiches.