Starwaster

Oh, oops. Use this: https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry/DeadlyReentry-KWRocketryFairings.cfg

Read two posts above yours; there's a link to a corrected file.

Download the file I linked to earlier (DeadlyReentry.cfg) and copy that over the existing file. That should let you adopt a reasonable ascent profile without punishing you.

I don't know. That has not been my experience, not with the Mk1, not the version of DRE you're running. The Mk1's shield was configured to be inferior the Mk1-2 pod shields and I found the Mk1 return from Minmus to be barely survivable. The next DRE update might not even provide for a survivable Minmus return for the Mk1. (likening it to Mercury; the USA's entry into spaceflight designed for suborbital or low Earth orbit only) It could be a FAR issue, maybe the drag levels are such that reaches max Q so quickly that it doesn't have time to heat up. i.e. very high peak heating rate but less heat load. I dunno. (I mostly play stock to make sure that it is stock friendly and compatible with occasional tests with FAR installations to make sure the two play ok but I never noticed what you're describing even with FAR so my previous statement is pure speculation)

Agreed, the problem there is that engines allow you to configure them in unrealistic configurations. On the other hand, the alternative requires a sophistication that arguably is better suited to simulation than a game. It's easier the way it is now even if it allows you to set up engines that don't make sense. Tanks on the other hand are readily fixed. If you haven't tried it, Real Fuels does so pretty well.

Your problem is probably linked to a multiplier that I'm using that increases heat even before you have gone supersonic. Try using the config below (copy that on top of the existing file in your DeadlyReentry folder) It uses an exponent that causes reentry heating to start sooner but without the across-the-board aeroheat multiplier. That should help. (this is the file that's going to be going into the next update, which I hope to have out in the next day or two) https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry/DeadlyReentry.cfg

Welcome to reality. Welcome to the rocket equation. A lot of people just don't get that you have to look at propellant mass, not volume. This comes up all the time. Remember that performance increases are per kilogram of propellant. Your d-v losses re probably due to increased tank dry mass and you should look into drop tanks. Also make sure you're using cryogenic tanks and think about using procedural parts if you need larger tanks. Better to have a few large tanks rather than lots of little ones.

Noted. Is that as of KSP 1.0? I don't recall ever having encountered that.

FYI, my pass on the heat shields is complete. All have had their aerodynamics adjusted so as to be more stable tail first. (or heat shield first). That will be in the next update. There are several misconceptions in the above statements regarding the flag in question (actually PhysicalSignificance) It doesn't mean they are ignored for physics, just that physics is handled differently for them. Both drag and thermals are handled for them. Drag might be handled differently for them but they are not ignored. Also the statement about massless parts is not relevant because there is no such thing as a massless part with the exception of mods that set mass to 0 (to which I say again, don't do it, it's wrong, regardless of how PhysicalSignificance is set). Certainly there are no stock parts that have mass = 0, and they work perfectly fine with DRE until someone goes mucking around with them and zeroes out their mass. As to Deadly Reentry, this mod works WITH the new stock heating system. So if the stock heating system is handling heat for parts that are set to PhysicalSignificance.None (and let me be crystal clear: They definitely have thermals handled for them) then Deadly Reentry will be handling them as well. - - - Updated - - - Addendum to previous statements: DRE will impose a minimum of 1kg in its mass calculations starting next update. Edit #2 To anyone affected by the issue involving massless parts, I will elaborate further, I can't consider that to be a bug in Deadly Reentry because the root cause is not in Deadly Reentry. As I've said before, DRE does not implement its own thermodynamic system. It modifies the existing stock thermo system that was introduced in KSP 1.0 and it relies on the existence of certain data called PartThermalData (that's the actual name of the class, I'll refer to it as PTD) and it is generated for every single part that exists in KSP regardless of whether it is marked as 'physicsless' The absence of the PTD is what was causing the nullref errors for some players before. So I checked to make sure that the PTD was actually present (and not null) before moving forward with further thermal related code. But I was logging the error and that caused performance killing lag for players so I removed the error logging code. That and the aforementioned changes treating massless parts as having a minimum of 1kg of mass is really the best I can do. Bottom line is that if I don't have that PTD to work with then it's going to cause problems. And it didn't go missing because of a bug in Deadly Reentry. That happened somewhere in stock KSP where that data is generated.

I don't know that they ever were truly massless, and if they were then I have to disown any responsibility for cleaning up after other mods. No part should EVER be massless as it can cause all manner of trouble. (The solution there is to not run mods that can inflict that kind of damage and the problems that it can create are not limited to DRE) As I recall from looking at the log the first time, the problem caused was that PartThermalData was not being generated for the parts in question. The current code already checks for that situation and does not run FixedUpdate if PTD is null. That's the extent to which the problem will be dealt with by me.

[TABLE] [TR] [TD]“That is not dead which can eternal lie, And with strange aeons even death may die.â€Â[/TD] [/TR] [/TABLE]

You *can* sort of do this now... not exactly the way you're describing, but for drogue chutes you can configure them with a desired speed at a target altitude... then set them to cut at that altitude. So let's say you want them to cut when they reach 100m/s and you know you want them at 100 m/s at 3000 meters, or you choose that altitude arbitrarily. Then set autocut to 3000 meters. It's a work around but you can do that.

Do you mean 7.0.3? 1.0.3 sounds like a KSP version # Anyway, the resource is irrelevant. It's just a resource to be consumed, nothing more. I just mounted a stock shield to the front of a solid booster and it's being consumed and it's ablating and protecting. The new shields mass is probably less of an issue than their center of pressure, which can be offset, and probably SHOULD be getting offset. I can't remember if I already did that but it will be going into the next update. FAR or no-FAR? Have you changed any settings, including the stock reentry difficulty? The ONLY effect that other resources have is that they alter the part's overall thermal mass just as they do its mass. (in other words, if applying the same amount of heat flux to an empty tank and a tank full of water, the empty tank will be heated to a higher temperature than the one that has water)

It's not unusual.

Sorry, I guess you keep falling between the cracks. Looking at that last picture I see you have high temp on the part but there's no flux, not even conduction or internal. I'm not sure where that's coming from and I don't get that on my end. I'll get back to you on this. btw, the categories are conduction = heat transfer from part to part. From skin to internal uses similar code and falls in this category but shows up as 'Int Flux' convection = heat transfer from the atmosphere. Subsonic or at rest this mostly equalizes your temperature to ambient. At supersonic or hypersonic you get lots of heating from compression of the air. (the shockwave) radiation = Mostly from ambient or from the sun, but hypersonic speeds also result in radiation flux. IRL, for very high speeds this can account for more flux than from convection for planets like Mars. (not sure we're modeling that accurately.... but there is definite radiation flux from reentry) internal (int Flux) = this is heat from any other sources. A catch all group.

the stock animation module has a really interesting looking option called allowManualControl. Upon discovering it I immediately edited the config that adds the umbilical port and jumped in the game to try it out. It completely disabled the animation in the VAB and in-flight or EVA. I guess action groups probably would have worked. I bet that's what it was for

Sounds like a side effect of a setting designed to ensure that reentry heating starts early and higher up in the atmosphere. I don't think there's a lot I can do about it but I'll look into it. And is that the latest release version of DRE or the development build that I posted a few pages back?

IRL, they would radiate into the enclosed environment of the cargo bay where it would be absorbed and reeradiated by everything around, including the cargo bay. Both stock and DRE suspend convection / radiation for a part that is marked as shielded. (except for when it's in analytical mode I think. i.e. faster than timewarp x100)

How about saying you'll provide a craft file in stock parts that will let me repro your problem? I'm not learning anything from those pictures. I put up craft with jet engines and service modules and didn't see anything unusual.

The only current limitation that I am aware of is when two concave colliders meet, they will not interact. A concave collider and a convex collider will (mostly) work just fine. A concave collider will work with the terrain just fine as well. Objects inside of a concave object tend not to collide with the inner surface. I've tested with a fairly complex shape and it worked well aside from my Kerbal not colliding with the interior, but it wasn't a big deal. HOWEVER. I have read somewhere (can't find the article; will try to find it) that concave colliders have changed in Unity 5 and don't interact with with anything properly. I have no idea how true that is. It might be totally false. Or it might represent trouble down the road. But we've got time before it becomes an issue, IF it becomes an issue.

There's no big mystery as to where the heat is coming from. This mod doesn't create heat out of nowhere. You've got an engine there cranking out quite a bit of it. Which engine I don't know. It would probably be more useful to know that than all those small parts in that bay. A craft aft file with just stock parts would be good too. I really can't learn much else from that barometer that I don't already know.

Most of those picture don't really tell me much though. I can see they're a bunch of small parts in a service module but I don't understand what you're trying to convey about them.. The engine is another matter. Just to confirm, THAT is the part that is exploding? (I see no errors in your log btw. at all)

It very much does sound like an 'old Kerbal's tale'. I mean, those rockets get bigger and bigger with each retelling! Still, we try stuff. Sometimes it works. Looking at the configs, in the case of the 2.5m shield, their order was already bottom first, top second.... and they still need a little mouse tweaking..... so I don't know. I'll try playing with the order and see if anything changes.

It's a problem with any part which has 2 or more attach nodes in close proximity; I can even repro it on stock part. You don't have to do those convoluted gyrations you describe to get around the problem. Just careful move the cursor slightly away from whatever you're attaching to but not quite enough to unsnap from the part.

That's wrong, that's not even close to what I gave you before. You can't use something like: MODULE[ModuleAeroReentry] because you are ADDING a module. That's why it's MODULE { name = ModuleAeroReentry (other stuff) }