Starwaster

I don't think that ablator consumption or other reentry matters should be considered, at least not at this time given the current state of thermodynamics in stock KSP. The situation as it stands now with stock is that you could configure that shield with 0 ablator and probably come through a 120km orbit just fine. If that's inadequate for anyone, it pretty much boils down to either Deadly Reentry or wait for the stock situation to change. (which it will and SDHI behavior vis a vis stock reentry should evaluated at that time)

TO ALL: (just in case it gets buried below and missed) Please go get version 1.1.1 of Animated Decouplers. Just updated it. Please grab the latest Animated Decouplers (I just now updated it again) and re-test drag. * Also, caveat: testing for 0 drag is not reliable. Test for cD and drag vector. Uninitialized they are 0. Pad drag will probably be 0 even unoccluded. In-flight, if they started shielded and then were shielded after they will freeze at their last updated values. (not that that applies to us; just a little FYI) If you still notice problems, please find your ModuleManager.ConfigCache and submit it here as you would a log file. I think the LES problem is two-fold. IRL, Apollo LES propelled the command module to an altitude of 2.8km. (almost 3km!!!) while I notice an altitude of about 700m which seems to be barely high enough to safely deploy using the stock chutes. I had forgotten to install Real Chute; which I think imparts less drag while disreefing. The other half of that problem is that Apollo deployed its drogue chutes first which had faster deployment than the mains. (the drogue chute on the SDHI docking ports won't deploy at such low altitudes; that's just the way they're designed - both stock chutes and Real Chute chutes). So I think the real question there is.... is it an SDHI issue? To be solved in the SDHI parts pack? If not, then it's a player issue and players should add an extra drogue chute designed to open at low altitudes and it will be up to the player to properly deploy it. when aborting. it could maybe be mounted directly to the boost cover) On the other hand, if it's treated as an SDHI issue then one or both of the following solutions may do the trick. 1) increase LES (stock and KSPX) solid fuel 4x. That should provide the altitude required for successful chute deployment. boost cover rockets probably need to be more powerful if this is done. (to account for the added mass in the tower) 2) Redesign the chutes as necessary to ensure that the drogue chute will still deploy at LES apoapsis and the main chute shortly after. (i.e. design to allow for drogue chute deployment as low as 2km with main chute shortly thereafter) On the subject of fairings not decoupling: that sounds like you set their action groups before enabling symmetrical placement. Action groups won't update all symmetrical counterparts if the group was created before enabling symmetry mode. Groups have to be created (or recreated) after symmetrical placement

No, it should not be getting to that point in the code if the animationName is blank but it's harmless because all it's trying to do there is find an animation to play. I think the reason it gets there is because animationName is never equal to a blank string if animationName is not supplied. Instead, animationName would be null. I'll fix that in the next update, which will be soon. As soon as I'm finished making sure that it's not doing anything that might be interpreted by KSP as 'I should decouple this part'

I just had a sudden bad thought about this... I wonder if there's a problem in AnimatedDecoupler's logic.... my code is only supposed to detect decoupling and not decouple on its own but because I'm extending Squad's code, I'm wondering if a certain part of the base decoupler works differently than I thought and is maybe interpreting something I'm doing as a desire to decouple. ...

QFT and ++1 on Notepad++

Don't tell it to me, I'm just another player (and modder with other mods) who's nice enough to stop in and either help with solutions or point people at other solutions (which all too often happen to appear on the very page their plaintive cry for help appears on that they would have seen if they'd taken a moment to glance at the last page or two)

The attach nodes need reversing Look at the config file and find something like this: node_stack_connect = 0, 0.5, 0, 0, 1, 0, 0 First three numbers are coordinates for the node's location (relative to its origin) second three numbers are a vector defining which way it points. These three numbers are why things don't connect in KSP 1.0 (the node is pointing +Y or up) You want it to look like this. node_stack_connect = 0, 0.5, 0, 0, -1, 0, 0 The node is pointing -Y or down.

You know, all of the shields now have their center of pressure adjusted to be stable blunt end first, so if you orient them to be retrograde at interface then they'll stay that way. Or you can set them gently spinning for additional stability.

Oh hell, if you used the link I provided then I screwed you over because I (apparently) was grabbing a link from one of the commits from ... a week ago? a month ago? If you haven't already downloaded using the freshly updated links from the first post then here is the correct link: https://github.com/sumghai/SDHI_ServiceModuleSystem/archive/master.zip VERY VERY VERY VERY SORRY! - - - Updated - - - (but it could be used as a lander engine....)

I think I'd have to see your craft file; I can't tell you if you're doing anything wrong as far as your abort system but I can say that action groups work fine for me. (I've always had to do it that way too; didn't think to check module ordering) What I can tell you is that you don't have the very latest SDHI build because of that thing with the shield. I just went and checked and it already has the charring thing turned off for it. And verified in-game that it works properly to disable the charring effect. So, completely uninstall SDHI from your system and then download using this link: https://github.com/sumghai/SDHI_ServiceModuleSystem/archive/ea95ee158d0aa547e834b672a238b26e9109649a.zip

Nathan updated the heat shield code to be like the one in the game, where it darkens as it burns away. (which really means 'when it has no more ablative left') The SDHI one isn't set up for that and it's already black to begin with so that has to be disabled. I'll submit something to sumghai to turn that off. Edit: Also, not understanding what you mean about Animated Decoupler. That shouldn't have any impact on using your LES. I did an abort test last night and it performed just fine. What are you trying to do exactly and where is it failing? And where is drag occlusion not working exactly? Screenshots demonstrating please.

look a few posts back. someone already posted a fix for it.

If I'm understanding Bomoo's proposal, it involves moving the AnimatedDecoupler module in the part file? That will require that the ModuleCargoBay be updated. DeployModuleIndex will have to be changed with the new location of the AnimatedDecoupler. And it can affect existing craft in the world. KSP will try to detect and correct the problem but I don't know how robust it is in handling module order changes.

Just to make sure everyone understands, but you need the very latest version (which I just pushed yesterday) of Animated Decouplers. If it says it's ten months old then you're in the wrong place! This link will display all releases past and present. The very latest is at the top and is labeled with white text on green tag next to it. https://github.com/Starwaster/AnimatedDecouplers/releases Can't miss it! Make sure that all dependency mods are updated. And then try duplicating with a freshly constructed craft. Do not load an existing craft file, create it from scratch. It sounds similar to a problem that has happened in the past with Real Chute but could be triggered by other things too. But if it is Real Chute then that craft (both in the world and craft files) are corrupted.

I'll think about it but I'm not inclined to on the grounds that it falls under the purview of general spaceship construction.

You do understand that fairings themselves have drag....?

I'd think that's better than the flip side of that which is people complaining that their jets keep burning up.....

What counts is whether or not items under the fairing take drag. Are you saying that you're seeing that or... what? (the fairing itself as well as the boost cover should be subject to drag. Though the location of the drag itself could be an issue.... that could be fixed by offsetting the center of mass) Sounds like an issue with another mod. I don't think that's because of the chute.... Sumghai, is the heat shield's origin exactly centered on the X and Z axis? That's the only thing I can think that would cause that. There's no danger of flipping and it's offset exactly 15 degrees. I saw it but I didn't pay much attention because frankly a little offset on a pod like that helps lifting reentries.

Let the fuh-USE be lit!

Update regarding fairings: I have this working right now as is, to my satisfaction without Sumghai having to do anything that will break saves. (turns out that ModuleCargoBay lets you specify an offset from the part's origin. So, kudos to Squad for doing that right) The way that this will work is that it I'm adding this functionality to my animated decoupler plugin. The only thing I have left to do is to ensure that there is no hard dependency on an animation being specified. (so basically it will always work just like a stock decoupler if no animationName is given). I should have Animated Decouplers fully updated by the end of the day and a pull request sent to Sumghai with the necessary updates to fairing and aeroshroud. The reason for me doing it this way is that AnimatedDecoupler is already an SDHI dependency so everyone will already have it and no new dependency created. When THAT is out of the way, I move to phase 2: Making a system that will work with KW Rocketry's fairings so that those will work with stock aero. I will have those working. Know that for sure.

IRL it would be but the mechanics of Kerbin are by necessity different. You don't have enough ablative shielding for a move like that (and by necessity I mean, in order to make it 'Deadly')

20 is a good go to periapsis. If the problem is that you're burning up, you can go steeper but too steep and also run the risk of G force damage.

It's graphical in nature. The bottoms of of heat shields supporting it will darken as they burn through their ablative material.

Update 7.1.0 released https://github.com/Starwaster/DeadlyReentry/releases * Added heat shield char support. (not all shields) * Major changes to skin conduction, radiation and convection * Skin percentage is now actually a percentage of thermal mass. (i.e. part thermal mass goes down as skin thermal mass goes up) * Heat shield aerodynamics fixed. (stable when blunt end forwards for all DRE shields & ADEPT shields) * Heat shield decoupler: texts fixed. Unused decouplers removed. 0.625m decoupler added. * NaN checking * MOAR NaN checking * Moved away from foreach usage. (you shouldn't use foreach, m'kay? foreach is bad.... m'kay?) * Delete audio on destroy * reimplemented engine detection * RO support * Depleted shields burn easier * 1kg minimum part mass enforced. (in calculations only; part mass is not touched) * Fixed 3.75m shield normal map * Patching of KSO parts to remove obsolete pre DRE 7 configs. * Lowered convection/radiation factors to 10 * KWR configs fixed. * Other general config fixes 'changes to conduction/radiation/convection' is understating things a bit. It made things hot enough that I had to reduce convectionFactor to 10 to keep certain reentries survivable. Mk1 pod can handle LKO reentries just fine but munar or Minmus returns will probably burn its shields out before it can slow down to safe velocities. radiationFactor reduced to 10 to keep it even with convection.