Starwaster

Not yet, I'm working on it. What I have is mostly workable but not yet ready for release. I have to make sure passive shields like inflatables and non-ablative will work well because they wont have a dedicated shield module at all.

It may have been supposed to be that way, but it is very true that there were some parts that FAR did NOT recognize as having changed shape. A prime example being DRE's inflatable shield. The stock animation module had (and still has) problems with it, FAR had problems with it and the new Aero system in 1.0 has problems with it. For both FAR and KSP 1.0 Aero, the solution was the same. Deploy, Quicksave, Quickload. In 0.90 you can also see this in the VAB. Use FAR's analysis tools on the inflatable then inflate it (still in the VAB). The profile remains the same. Save as a craft then reload the craft (you can do this with the inflatable as the sole part). Only after reloading is FAR able to recognize that something had changed. I was in the process of creating some special configs to deal with the situation but I don't remember if I ever updated with them. In any case, I asked someone to take a look at the inflatable and we'll see if it can be fixed.

Ugh, ok so the cause is different than what I was thinking but the end result is the same... all other factors being equal then the engines are going to build up heat at the same rate but the heavier engine will shed it at a slower rate than its lighter cousin.

See the ADEPT thread, towards the back. I posted a MM styled patch that will make them compatible with 1.0, stock heating. When I release DRE, I'll probably have a DRE specific patch for them.

There's some misunderstanding going on about the engines. Engines with higher mass do NOT gain heat faster than engines of lower mass. They do however lose heat SLOWER than engines of lower mass and that's very much in keeping with the way real life physics work. The problem isn't with the the new thermal system itself, it's a problem with the engines. My guess is they're still using the old system where temperature was applied without consideration for heat. There's a method for adding heat to parts where it's applied as Kw and I don't think engines are doing that.

Not really. It's a good thermal insulator but it can't stand up to the heat of reentry and will readily melt and burn.

Lemme do the math here... Nothin' ... into nothin' Carry the nothin'

Shock heating is the shockwave you get on reentry. The air is compressed along the vessel's flight path and compression heats the air. The approximate temperature (in Kelvins) of the shockwave is equal to its velocity in meters per second. So if you're coming in at 2.5 km/s then your shockwave temperature is ~2500 K. The amount of heat energy that will be transferred depends on the density of the atmosphere and the density of whatever it is that's being heated. The hottest part is the bow shock in front (that's being compressed) but you still get a plasma streamer behind that's almost as hot. (though as SC says, you don't even need THAT to destroy the chute)

It's intermittent. I'm seeing it happen at least 1/3rd of the time.

It does not make them overheat faster. It does the opposite. Thermal mass is a measure of how much heat something can absorb before rising a degree in temperature. Of two parts with the same temperature, the one with higher thermal mass has more heat in it.

I dunno, this seems to be working for me. That is, I enable Aero debugging, bind the boost cover hatch (so that I can readily close it while having another part's menu up in flight) Both the docking port and the pod go from draggy to not-draggy when the hatch is closed. MODULE { name = ModuleCargoBay DeployModuleIndex = 2 closedPosition = 0 lookupRadius = 2.5 NodeOuterFore = top NodeInnerFore = bottom //NodeInnerAft = bottom2 //NodeOuterAft = bottom } I was a bit worried due to not having any inner/outer nodes but the only problem I saw was that the Avionics Ring was being shielded. Assuming that was because there was no aft nodes, or maybe it was because the lookupRadius was too large. But it seems worth pursuing; both port and pod were occluded according to the drag / aero debugging. Edit: Caveat: On 1 (possibly 2) occasions, the chutes would not deploy because they thought they were still being shielded. On two other occasions however, the port stopped being shielded as soon as the cover was decoupled....

One of the ADEPT shields (link on front pate) has one that undeployed is about 4m (slightly larger than 3.75m tank) and deploys out to almost 10m. Other than that; Procedural Heat Shields. (part of the Procedural Parts mod)

BTW, I don't mean for my reply to be mean. Think of it as tough love. Love you guys! (now stop misusing your chutes)

I'm going to go one further and say you've been spoiled. You think you can do these things because KSP has let you get away with it until now. The gravy train ends here and now you get to use chutes the way they get used in the real world. No more free lunches. Deploy chutes hypersonic and pay the consequences. Look at the picture below. Do you see chutes deploying at 65 km? No. 24,000 ft = a little over 7km. Its velocity was no higher than Mach 1.5 (probably less). The highest rated and largest supersonic that I know of was Curiosity at Mach 2.2 (that was what it was rated for max because like everything they overengineered it to err on the side of caution. It deployed at Mach 2 and that was over Mars with low pressure and low density)

Here's a solution to both problems. I gotcher airbrake right here: (well, you still need a chute; the capsule in this image is probably screwed)

Can't speak as to drag, but rocket clipping through the fairings, yes. Strut the topmost part of your stack to the fairing wall. (there is an auto strut option but I've never found that to work, and from looking at the code, it looks like it struts near the bottom of the stack, which is no good and will never be stable. (not for tall stacks or any stack of moderate height)

that's a neat trick considering Ioncross doesn't apply forces. Log files please?

Hypersonic chute deployment isn't particularly realistic. There are chutes that can deploy at low supersonic but they have gaps cut in them to reduce drag. Drogue can deploy while at speeds that would damage the main chutes. (which is one of the reasons for drogue chutes) * Apollo didn't deploy its drogues until something like 7km and mains at 3km altitude. Adding the ability to distiguish between drogues and mains was something I wanted to do in DRE but never got around to it. Future versions of DRE may not have this feature added in as both stock and Real Chutes are adding unsafe chute deployment at high speed.. *high altitude or low density environments increase the safe velocity for chutes. The Curiosity rover featured chutes that were rated for up to Mach 2.2 though they deployed at Mach 2. But, the final answer has nothing to do with realism. It's your sandbox, play however the heck you want. Don't like what DRE does with the chutes? Change it.

Untested idea: Use the stock ModuleCargoBay. Add that to the boast cover. Make sure that DeployModuleIndex is set to the ordinal position of the animation module that closes the hatch. (i.e. if the animation module is the first one then DeployModuleIndex = 0. If second then =1) That worked for KWR's petal adapter pre 1.0 MODULE { name = ModuleCargoBay DeployModuleIndex = 0 closedPosition = 0 lookupRadius = 0.75 }

Nitrogen gas

It will probably work though I haven't been able to get to testing it yet because of Deadly Reentry It's just an extension of the stock decoupler that has some animation code and nothing that I was depending on in decouplers seems to have changed. Animation is straightforward. But as soon as I can get to it I will compile the source against the new KSP binaries And, on the subject of not having been updated; it was last updated for 0.90 - in spite of what the last update date is given as.

Update: Ok so progress; I'm working on getting my existing code functioning with the Modular FlightIntegrator that Sarbian set up for ferram4 and I. It's a little slow going but I'm getting there.

No, it was just oversight. I don't think it really occurred to anyone.

For modders, it lets us replace certain parts of the Flight Integrator, which handles things like aerodynamics and thermodynamics

Look at the stock ModuleAblator for an example. The new DRE ModuleHeatShield will use the same parameters in the same way The resource AblativeShielding will be retained. It may or may not keep the same properties as Ablator resource. (it will initially with an eye to changing it if deemed necessary). So you can use either one. (that way you should be covered seamlessly) One caveat to the above is that DRE (as mentioned previously) will add a new temperature category: skinTemperature which will use only a portion of the part's thermal mass. (that lets me heat the outer surface up faster than usual). For some reason that I havent identified, doing things that way results in slower ablation resource consumption so heat shields will need to have lossConst = 10 added to them. (the number can be tweaked to produce faster or slower ablation consumption) That's all that affects SDHI. As a side note, ModuleHeatShield will no longer be used for space plane style heat shields. Instead, thermalMassModifier and emissiveConstant can achieve the same result as the reflection property in older versions of ModuleHeatShield Center of Lift / Center of Pressure (I think; I saw some mention of this in testing and they're probably pretty self explanatory but you might want to ask Nathan if you're unsure) If you find stock reentry heating adequate then that's good, but as others have said, personally I found it underwhelming and there are definite issues in it that need correcting and so DRE needed updating. The specific issues I have with it is that for any given amount of flux, you're having to apply that to the entire thermal mass of a part, which makes no sense. There's no concept of failure for burn through, you have to raise the temperature for the entire part to its destruction limit and overcoming thermal mass also means RESOURCE mass as well. The system as designed is pretty realistic but for that problem. The source of its convection heating BTW is the same source as I used for the latest DRE betas for KSP 0.90 which is an FAA document that contains an emperical formula for determining heat. (though the formula also includes radiant flux contribution so it wasn't pure convection). Though, my implementation was more simplistic due to the lack of heat flux in KSP 0.90. (i.e. 'temperaturing' rather than heating, as I like to put it)