Starwaster

What's the mass of your reentry vehicle? And what's killing it, heat or G force stress? Let me see a picture of what you're trying to send there too please. Are you able to maintain 0 angle of attack or close to it? If not, what is the angle? (if it's too great then the pod is going to be exposed) If you haven't already, do that reentry with thermal debugging on. Press Alt-F12 -> Physics -> Thermal and then check the box next to 'Display Thermal Data ...'. Report back here with the numbers for four fluxes (Cond, Conv, Rad, Int) at the time that your shield begins ablting

Yeah that's why they're 'laws' and not 'really good suggestions

Ah, I'd forgotten you put that in there. Still, I think the 400x radiation is an issue here too

I will give some consideration to moving the engine heat adjustment config from :FINAL to :FOR[DeadlyReentry] HOWEVER.... One way or another, a heat adjustment pass gets done on every single part in the game. Currently it is being done to engines in a config file before the KSP and DRE finish loading up because that was the easiest place to deal with overheating issues involving Real Fuels engines. When DRE actually loads in, one of the first things that happens is it looks at maxTemps on all parts and anything that didn't get handled in configs, or is still too high after configs were loaded is going to get cut down to either half of their current maxTemp or ridiculousMaxTemp, whichever is lowest. It's also conceivable that your problem is not with the adjustment of maxTemps in engines, or that it is only part of the problem. DRE makes changes in other areas including radiationFactor which is increased 10x, a change that I deemed necessary to allow spaceplanes to function in a Deadly Reentry environment. So that means (in the example given above) that your engine effectively has an emissiveconstant of 400 or higher. That's not just radiating heat 400x faster (or 400x the heat depending on how you look at it) it's also potentially taking in 400x as much heat (or 400x faster) depending on which way the temperature delta is flowing. With that in mind, I'd suggest that you not think about overriding parts of DRE. Instead what I would do is find the radiationFactor and cut your emissiveConstant alterations by that much. If instead you choose to override DRE settings and I determine that specific issues presented to me can be traced back to KSPI alterations then I'll have to defer those support requests back to you. Really I wouldn't have a choice. - - - Updated - - - I left DRE's shields in the category that they had always resided in.... I might move it one of these days. DRE's ablative resource and KSP's stock ablator resource are functionally equivalent and the stock heat shield will continue to use the stock resource. Necessary in the event that a player were to uninstall DRE so that they don't have KSP complaining at them that stock parts and craft existent in the world are using unknown resources.

http://forum.kerbalspaceprogram.com/threads/55219-Module-Manager-2-3-5-%28Sept-14%29-Loading-Speed-Fix?p=1416253&viewfull=1#post1416253 That post explains all variable usage

@PART[partNameHere] { //grab and store the value for WasteProductionRate in X X = #$@GlobalSettings/WasteProductionRate$ // module doesn't exist yet MODULE { name = moduleName // somevalue doesn't exist somevalue = #$/X$ } } @PART[partNameHere] { // module already exists MODULE[moduleName] { // somevalue already exists @somevalue = #$/X$ // somevalue might or might not already exist %somevalue = #$/X$ } }

Except that visually the effect does need toning down. It's too intense on ascent. I might need to do something in DRE.

No, they're based on airspeed and atmospheric density modified by aeroFXExponent. Actually, these three settings control that: @PHYSICSGLOBALS { @aeroFXStartThermalFX = 2 @aeroFXFullThermalFX = 3.5 @aeroFXExponent = 3 } where the first two are the mach range where flames start and are at their strongest (so starting at mach 2 and ending at mach 3) and also modified by density. (there's a setting for that too but I'm not sure if it's exposed to config file modification) They're probably your best bet; you could increase the range in which flames occur based on what effect you want to achieve. You could also ask NathanKell, he can probably tell you about the other settings and whether or not you could use them in a config patch. (that's what that code section above does. Put that in any file ending in .cfg and modify the values to taste and then save.)

One problem there is that your error doesn't positively point to any mod; it could even be a stock error

Module Manager isn't really doing anything during actual gameplay. It does all its work before KSP compiles its parts, which it does by modifying configs. Mostly but not limited to, parts. After that, it just sits around doing nothing, unless you bring up its menu at the space center and reload the database. It doesn't sound after all like you narrowed your problem down to Module Manager. It's most likely a race condition between different sections of code operating on the same list. One of them made changes to the list (adding or removing from it) meaning that the second bit of code no longer has a valid list to work on

I think so. With the exception that separated shielded items will stay shielded if they weren't properly decoupled or otherwise came apart accidentally. Stock issue but I'll put some extra handling in AnimatedDecouplers so that they will handle it, and hopefully the stock bug will get fixed soon.

I can make it work.

Wait... you can't do that... people have to complain instead of solving things. WHAT SORCERY IS THIS? (can't do the squiggly lines )

Aside from the near black body level of radiation it's not that far fetched. Certainly no more so than a balute and I just bet you'd love to see one of those in the game... All parts generated an occlusion cone but IIRC, the code is limited to stack mounted parts with surface mounted parts not receiving occlusion..... Most likely reason why they're not heating up is that 0.95 emissive constant I mentioned. That's 0.05 short of a perfect black body radiator. Edit: Ok, the ones you have in that picture are about half the size of the stock AIRBRAKES....

They might, but it has an emissiveConstant of 0.95 so short of ablative shielding, they're pretty well protected. (that's an unrealistically high emissiveConstant IMO... 0.6 would be more likely) What that means is that they reradiate a lot of the heat that they take in. It's a passive solution that's probably better for very shallow reentries like a spaceplane but that crazy high emissivity would probably let them survive.

The image I posted depicts a shield that IS stable precisely because I spent time adding CoP offset to the shield. I'm not refusing to make it stable, I've MADE it stable - - - Updated - - - A proactive solution. Outstanding.

Here is the 1.25m heat shield in question. Sure LOOKS like it has a rounded bottom. About as round as Mercury was anyway. That's round enough for me. More to the point however is the image below proving that yes, this shield is aerodynamically stable when used reasonably and realistically. The probe core is the OKTO2. It has no reaction wheels and no RCS were placed on the craft. That was a design oversight on my part. The vehicle hit its reentry interface sideways and oriented into the position you see. So it is NOT flat, it IS rounded and it is stable. Use it responsibly.

It's not a question of whether the shield itself is right or wrong / stable or unstable. It IS stable if used in a reasonable manner. The craft design that was presented for consideration is unstable. It was actually presented as being stable without the DRE shield but that is not the case. It is not a stable design. (it's not a question of where he grips it...) That's number 1. Number 2: I inherited those shields along with the mod itself when I took it over. Number 3: If you or anyone does not like the DRE shield then you have several options. Use the stock ones (A case was made that it allows that death trap that was posted to be stable. I don't care what 1.25m shield you put on that thing, unless you have something that broadens the base and lowers the center of mass then it is NOT stable and would never BE stable in real life. It is an unstable design. But if the stock shield makes it stable and that makes one happy then one should use the stock shield and be happy with it. But one should not expect me to believe that a small 1.25m shield is going to make that stack stable. Unstable design; period. Just in case anyone missed it: lower the center of mass or unstable) Go download alternate shield pack from the first post. I provided a few to choose from. Lost Oblivion. Very nice looking. NASA ADEPT shields (deployables to replace the broken inflatable that kept breaking worse and worse with each KSP update beyond my ability to repair). Go download a modeling program and craft some replacements. I will always take pull requests into consideration.

Pretty sure that's why we're favoring the KSPX in testing. It's a stock issue and not one that's going to be solved other than Squad. The stock LES has a side firing rocket that has all the force of one of its downwards firing rockets and that's not going to change. All that can be done is to use a different LES or employ some other means to counter the side firing rocket. (such as a sepratron or a KWR small ullage motor) No....

It doesn't change anything with regards to a specified craft configuration that is not particularly stable nor with regards to whether or not I should go to any great lengths (as DRE's main modder - through part or DRE mod work) to make it stable. The game's stock aerodynamics does not think it is stable. FAR does not think it is stable. I do not think it is stable. Whether it could become stable (as opposed to designing a different craft to be stable) is up to the player in general who might do so by deploying ballast? control surfaces or fins? RCS? shifting center of mass through allocation of resources in the craft? (maybe, not a lot to work with there) In short it is not a mod design consideration which is how this situation has been presented to me and what guides my response on the matter.

Thats nice general information, thank you, but it doesn't change anything.

You accuse me of pride? That's rather insulting. I don't think your video will be necessary. Your description was fairly explicit. Let's look at some pictures. A command pod - a Mk1 based on your description (all 1.25m parts) (a chute on top) A T200 tank A 1.25m shield Is this about right? Look at the center of mass. Pretty much dead center of the stack. The entire thing is free to pivot around that point. Look at it in flight. The flight camera focuses on the center of mass. And sure enough, it's pivoting freely around that point; flopping around it basically. Does that look like anything you've ever seen landed on another planet IRL? If its center of mass were further down it would have a chance. A wider heat shield would be helpful too. (in fact IRL it really needs to be broader on the bottom or that tank better protected because it would burn otherwise) So, again: I don't feel that it is realistic to expect that this thing should be stable in reentry. Pride has nothing to do with it. - - - Updated - - - If you increase convection factor that will serve to increase the rate of heating. I like to adjust radiation factor to match; it makes spaceplanes more viable. You can also adjust aero heating production, which I was doing for awhile but it makes things too hot in subsonic. You can also go into the stock difficulty settings and increase reentry heat there by up to 120% and that does affect Deadly Reentry. (mach only)

Don't go so shallow. For Kerbin, a periapsis of 20km is pretty good. I don't agree that the behavior of the stock heat shield is aerodynamically realistic. 'everything lines up as it should' Really? That seems normal to you? Without anything to stabilize it, it will just straighten up on its own? It's a flat plate. By itself (in real life) it wouldn't be particularly stable either flat end on or edge on. It would flutter quite a bit. But especially it wouldn't just present its flat face into a hypersonic airstream and stay stable like that without SOMETHING to keep it stable. Sorry but I think this is one of those times that I have to bounce that ball back into your court and tell you that it's your responsibility to design your craft in a manner that they will stay stable. And it's not that hard to do. I tested every one of those shields and they ARE stable if you treat them right and don't make unrealistic demands of them. They're a lot more stable than they were pre-7.1.0 But don't stick them at the bottom of a stack and expect that they're going to magically keep you from flipping. They're thermal protection, not control surfaces or stabilizers. They're meant for the bottom of pods or very SHORT stacks. in a realistically sized planet where we don't have to speed up heating, you could conceivably do things more shallow than stock sized Kerbin forces us to. As I had to remind someone just the other day, with stock Kerbin, our goal is actually unrealistic amounts of heating, or we couldn't have Deadly Reentriesâ„¢.

Next update of the Animated Decoupler, I'll put in a check to see if the parts have separated for any reason and force the cargo bay module to update itself. It's more a bug in the cargo bay module itself because it should be doing those checks already. Already bugged some folks to try to get it fixed in the stock code itself. (you can see this in action in the stock code if you put something on a decoupler inside a closed cargo bay or procedural fairing and then decouple it) Oh, about the KSPX LES, it has a mass offset. That's why it veers off to one side and does it more extremely if you have more solid fuel in it. (CoMOffset one of those things that should be used sparingly and carefully. Really it should only be used to correct model issues now that we have CoPOffset)

Yeah, the previous values for charMin / charMax work with DRE but not with stock. (Even though they share the same source) right now I'm trying increased amounts of solid fuel for the LES. 4x is way too much so trying less. Edit: Ok, I myself am having inconsistent results when decoupling the aeroshroud where it doesn't stop shielding the payload. Nobody else is having a problem in that area...? Edit #2: Abort tip: A procedure I devised is to extend the flaps on your fins when aborting. It'll stabilize your lifter stage and exert a little drag on it and help keep it away from your pod. (obviously only works if it's a control surface). Works in stock and should work in FAR too. Edit #3: Found out why the aeroshroud was (sometimes) not ceasing to shield the pod et al. I was decoupling from the docking port. The shroud only updates the cargo bay when its own decouple function has fired. So, known issue: Always use the shroud's decoupler function. (at least until I fix that; but there's probably not really a reason to do what I was doing)