Starwaster

Radial parts are protected, yes. Convection heating uses occlusion cones that protect stack mounted and radially mounted parts alike.

Ok, so I tried pushing the the latest update from my computer using Github for Windows then deleted the 1.1.3 release and recreated it. Aaaaand.... it still is pointing to the same commit AND promptly marked 1.1.2 as being the latest version instead of 1.1.3.... See, **** like this is why I hate Github. HATE it. EDIT: AND to further add insult to injury it claims that I made that release 3 days ago instead of 3 MINUTES ago. WHAT????? EDIT #2: SoI just made it 1.1.4 and called it a night. (stupid Github. Stupid Starwaster )

Oh no no no.... don't you blame Deadly Reentry anymore! We don't destroy chutes anymore. Both stock and RC do our dirty work for us.

Did SM and CLS ever get their issues between them fixed? (the ones that caused parts to highlight and never UN-highlight, as though Rick Astley had got hold of them?)

Updated Animated Decouplers to not report things as shielded if they aren't coupled. (if you want to try the previously mentioned method of using multiple cargo bay definitions. It's still taking me awhile to get my other system implemented)

If you're talking about just the reentry FX then no, there's no way of doing that right now that I know of. Is that the Oblivion shield? Replace your DeadlyReentry.cfg file with the dev version: https://raw.githubusercontent.com/Starwaster/DeadlyReentry/Dev/DeadlyReentry/DeadlyReentry.cfg Thank you!

Traveller?

That.... wasn't exactly what I was trying to get across in that post, but if it helped you in implementing cargo bays in other parts then that's good.

I don't use hot rockets and the engine works fine for me. FX cut off when the engine runs out of fuel.

No problem, it happens

Not sure what the problem could be. I don't see that here and I don't think anyone else has said anything about it...? Try editing the heat shield file and change charAlpha to 1.0 (see below) file location is: GameData\SDHI\Service Module System\Parts\SDHI_2.5_Heatshield (honestly I don't see a difference between 0 and 1 as long as charMax / charMin is 1) MODULE { // pyrolysisLossFactor changed from stock value of 10000 to 15000 // // Forum user johnsonwax explained that increasing this value allows more heat energy // to be removed per unit of Ablator, which essentially reduces overall Ablator consumption // // This fits the narrative of SDHI's PICA-X heat shield material being more durable than // whatever fictional material is used in stock // // NB johnsonwax noted that 20000 would make for a *very* durable heat shield, but // we agreed that this was probably too overpowered name = ModuleAblator ablativeResource = Ablator lossExp = -9000 lossConst = 20 pyrolysisLossFactor = 15000 reentryConductivity = 0.01 ablationTempThresh = 500 charMin = 1.0 // Disable ablative darkening (hopefully) charMax = 1.0 // Ditto [COLOR=#0000ff] charAlpha = 0.0[/COLOR] } to this: charAlpha = 1.0

The log file you posted earlier indicates no problems with Modular Flight Integrator. MFI is a wrapper for the stock Flight Integrator which allows Deadly Reentry and FAR to override key parts of the Flight Integrator without either of them interfering with the other.

What about the shield exactly? It's too black still? At what times does it do that? You are aware that it's already pretty dark to begin with, right?

Re: colliders. Colliders seem to be used to tell the cargo bay at what point to stop shielding things. See the picture below. The OKTO2 should definitely not be shielded (you can tell that it is because its drag vector is completely zeroed out). For that matter, the tanks sticking out the side should not be either. ModuleProceduralFairings seems to be generating colliders as you build the mesh. @NecroBones: In the long run it might be better to wait. What I have planned will function similarly to stock's procedural fairings and hopefully be immune to the above. (if I can generate a collider to match...)

I downloaded your mod and had a look at the problem involved in trying to shield payloads in stock with ModuleCargoBay / Animated Decouplers (which has had shielding capability added to it). I have had some success in getting this to work but with some caveats. The following MM config demonstrates what I did: @PART[0Pfairing2mW1] { @MODULE[ModuleDecouple]:HAS[#explosiveNodeID[top04]] { @name = ModuleAnimatedDecoupler } MODULE { name = ModuleCargoBay DeployModuleIndex = 9 closedPosition = 0 lookupRadius = 4.5 lookupCenter = 0, 4.5, 0 } } The caveats: Animated Decouplers don't actually check to see that anything is connected to them initially. (specifically not through their explosiveNodeID, though they do check that in the event that vessel modification occurs such as through decoupling or damage). What that means is that it doesn't matter if anything was connected to top04 or not. It still will try to shield. It probably wouldn't be a big deal for me to add such a check; I just didn't think it would be necessary since I didn't anticipate a particular decoupler module deliberately not having anything attached to it. However, even if I did that, you need a ModuleCargoBay section for every single ModuleAnimatedDecoupler that exists on the part. Its lookupCenter would be set to its explosiveNodeID's coordinate Its lookupRadius would be set to half the distance to its explosiveNodeID's Y axis value. (see example above). DeployModuleIndex has to be set to each particular ModuleAnimatedDecoupler's ordinal position. For example, the decoupler module with explosiveNodeID top04 is the tenth MODULE on the part so the index is 9. (0 = first) I thought there might be a #3 but I can't recall what it might have been just now... So, assuming I do put the necessary check in, you'd need 4 cargo bay modules on that part and on every other part for as many decouplers as they support. Definitely possible in the manner that I described, but what would be better is a single pair of modules on the fairing base. One ModuleCargoBay and one other module which I've been working on for use with KWR and its legacy fairings. I'm still finalizing the exact procedure but your fairing system is similar enough in that it has a top part that has to be attached that would be used to determine the size of the cargo bay. One other thing... the DRE support file that you have no longer functions with the current version of DRE. ModuleHeatShield should only be used with ablator style shields. Passive protection such as fairings should instead have a high emissiveConstant

Might be better to use CoPOffset ... I think that the effects of CoMOffset can be magnified as mass on the part varies. As it might in the case of resources. Unless perhaps there some cases where that might be desirable....

Design something that will have some lift. Curiosity for instance flew a lifting reentry much as Apollo capsules did. That will give you more braking time at higher altitudes. Use Real Chute and properly design a chute for that planet. Real Chute will let you select which planet the chute is for and it takes that into consideration when choosing how big the chute has to be. The thinner air should let you get away with higher speed deployment than usual. Depending on the mass of the craft you may also need to use rockets to successfully land. (again, just like Curiosity)

The only serious memory leak issue I'm aware of was allegedly linked to the thermal gauges and not heatshields specifically.

Updated Animated Decouplers Fixed sounds/FX not playing Some additional handling for shielded parts not being unshielded when parts like the aero shroud are decoupled from anywhere other than the decoupler part. (i.e. if the shroud is decoupled from an attached docking node) https://github.com/Starwaster/AnimatedDecouplers/releases

I wonder if that's a typo.... 902 versus 920.... because the SDHI total volume is exactly 920

Actually, I thought they were already working with DRE given that by default it's replacing all stock ModuleAblator with DRE ModuleHeatShield. Only just noticed that they weren't yesterday when I tried to use one on my Jool probe. Oops. Replace your existing DeadlyReentry.cfg with the development version here: https://raw.githubusercontent.com/Starwaster/DeadlyReentry/Dev/DeadlyReentry/DeadlyReentry.cfg

I've broached the topic before and there's some question as to whether there's a real need for inflatables so it doesn't seem likely to happen. - - - Updated - - - Post an output_log.txt (or player.log if Linux/Mac). I'll take a look at it and see what's happening.

All these worlds we give to you. Except Jool. Attempt no landings there. (no really... don't do it.... I'm seriously you guys!)

I don't think Procedural Parts are compatible with DRE at all right now. As for where Jool's atmosphere ends, that's up to Squad unless you try RSS. (when it's ready that is)

You're worrying too much if you think it is going to cause bugs... use the fixes that people have posted here and you'll be fine.