Starwaster

It's technically possible to rename them and I think you can even do it through the config file, but in the immortal words of Egon....

Not to the point of preventing your craft from loading due to missing parts. However, pre-existing chutes might not work properly. I'd land them to be safe. Or rename ModuleManager/Stock_RealChute_MM.cfg to something non cfg until you have all craft safely dealt with that had stock chutes.

If it's already in existence before you installed the configs then it's not going to be affected by them (at least not pre-beta, which is moving away from persistence). Those configs use no ablative shielding (except for the KSO25 when used with RSS) so if you actually see something that says 'ablativeshield' then it definitely sounds like a craft that already existed when you installed the configs. (note that the KSO25 config has to be copied over the existing KSO25 heat shield config because it wasn't designed as a patch. It's a drop-in replacement)

It's RSS that doesn't work with 64 bit Windows version. This is primarily just a set of configs that happens to have RSS bundled with it. If you have any level of competency with C# then it's not a difficult thing to remove the 64 bit check and recompile.

edit: oops, just saw your older post where you said it was turned off. Sounds like FAR ripping your plane apart with its Aerodynamic Failures feature. Even back when I used FAR I disabled that because I felt it was unnecessarily and unrealistically harsh. That said however, if your plane is losing control then it's more likely to be your design than 'a bug with the atmosphere'. If you're deorbiting in any sort of space plane then you need to design carefully, especially if it's an unpowered reentry. Front page. Links are there to exactly what you're looking for. Also to 6.4x Kerbol system.

Try the configs here: http://forum.kerbalspaceprogram.com/showthread.php?p=1493238#post1493238 Caveat: I haven't used KSO in awhile; it's not installed in my DREC testing environment. There hasn't been anything TOO drastic in the beta that would affect the KSO configs. The cargo bay is problematic, especially the KSO25 with or without FAR. By itself, DRE has to rely on raycasting from the center of each payload part along the flightpath and if it hits something then it treats that part as shielded. The raycast tends to fail if the origin point lies inside the collider for the thing it needs to detect.

Actually, make it a blood orange sorbet. (Ciao Bella or Talenti please) And if you've never had one, you don't know what you're missing.

Granted. Unfortunately, undoing your corruption results in massive quantities of waffles overflowing into the streets because there is nowhere left to keep them. It is impossible to drive anywhere and civilization comes to a grinding halt while people get to work eating their way out of this mess. As a bonus, you are now the most unpopular person on the planet as billions of waffle eaters curse your name. I wish I had a new pair of work shoes that never wear out.

As far as the node scaling, you might need to update KW Rocketry. And delete any hotfix hacks for node size that you might have downloaded after 0.25.

Ok, the fix I did for the AerodynamicFX broke part of it. Here's a replacement dll. Just drop it into the DeadlyReentry/Plugins/ folder and let it overwrite the existing file. I'll push a replacement update to the download page later (you especially want this if you play Real Solar System with a smaller FX Density Exponent or you only get flames at the old default altitude) https://www.dropbox.com/s/moge45bumutdcwj/DeadlyReentry.dll?dl=1

I have done this before, experimentally as a proof of concept (because someone was saying it couldn't be done) and did successfully replace the Mk1 internal texture with something else. I think I used the same syntax you're trying there but I dont have that file anymore so can't double check. Maybe this is a new error in 0.25....

Not for determining the temperature of the shockwave, no. You do care about density when determining how much heat you're getting from the shockwave. Think about it like this: What's going to hurt you more this Thanksgiving, reaching into a 200 degree oven to get the turkey out or accidentally spilling water on your hand at 100 degrees? (Celsius) As far as reflection angle goes I'll only speak to its role in the mod: It controls how much heat your shield is reflecting and in how much your shield is ablating each second. (and that is almost certainly wrong because ablation rate should be constant with part temperature and not dependent on orientation or density, but changing it now would mean breaking all existing shields)

Right now it's looking like it broke something else... will have to reexamine this.

Actually I did see that and was intending to answer it but was trying to compose replies to other posts and get the beta release packaged. There's nothing in the mod that should affect EVA RCS, but errors occurring at just the wrong time can cause any number of problems. The beta traps several such errors that were occurring when one of its modules initialized. (which happens any time a part spawns including Kerbals going on EVA and was causing problems for KAS) So I'd try the beta and see if that fixes it for you.

Ok, new beta release: still keeping beta designation; it took several weeks to bring certain inter-mod issues to light so I don't want to do an official release right now. The highlights of this release are primarily inter-mod issues fixed (hopefully) namely KAS and AJE. And possibly others. (never underestimate the power of the Null Reference error to frack your day up for you) Another issue that I hope is fixed is aerodynamic FX flickering reported by a handful of people. Hard to say if it's really fixed given the small number of people affected, and if my understanding of the problem was actually correct then it SHOULD have affected more and it just hasn't. Unless larger numbers of people were affected but just didn't bother offering feedback. So, here it is: Deadly Reentry 6.3.2 (beta)

Try harder! You have to work at these things

Fair point, but all that really means is that you'll see different specific values. You're still going to (or should be) seeing high altitude heating. shockwave = speed - CTOK; // shockwave temperature is equal to velocity in meters per second converted from Kelvin to Celsius ... bool cut = Math.Pow(density, ReentryPhysics.densityExponent) * shockwave * 10f > part.maxTemp * ReentryPhysics.parachuteTempMult; dynamic pressure (pascals) = one half of atmospheric density (kg/m3) times velocity squared So, no, not really dynamic pressure. Well that's why the chute failure messages. So people don't have to worry about trying to figure out whether it's safe or not to deploy.

That picture is actually quite helpful, but unfortunately a bit too late because I already know what the issue is. Heating there of that part is entirely from the engines behind it. Dynamic pressure is totally irrelevant because that part is shielded from the airstream by the parts in front of it. That said, an SR71's maximum skin temperature is reached at Mach 3.2 at close to the altitudes you're seeing there. Think about that... At any rate, you have two engines feeding heat into the bicoupler, which being a spaceplane part has heat shielding. One change I made is that heat shields now lower heat conductivity so that the parts they are attached to don't get roasted. So it couldn't get rid of the heat as fast as it was coming in. So the next version (sometime tonight) is going to see the default conductivity changed back to the stock value for Part.heatConductivity (which is 0.12). That should also take care of the AJE issue where AJE engines are roasting anything they're attached to. Also, chute failure is based on speed and air density. (really shockwave temperature and density, but shockwave temperature is based directly from velocity so... speed and density) If you don't see the warning then it's safe to deploy. That message is displayed by the same code that checks for and generates chute failure. Well, more precisely, it's the higher velocities that are the issue. If you could somehow get up to those velocities in stock KSP then you'd see that kind of heating easily. One of the goals of the next version is for that to be less of an issue on the grounds that the heat shield temperature should never go above (or even quite reach) the vaporization point of the ablator. (not even if the shockwave temperature is 3x higher).

Ugh, I see why Nathan said to go through camlost. Looks like quite a bit of this is hard coded. Config patches aren't going to save me this time. I'm not going to go get into it with another modder right now about how or why they took their mod in the direction they did. Path of least resistance will have to be that the default conductivity for heat shielded parts doesn't change and then add the necessary config changes to specific heat shields that should insulate. non AJE engines like rocket engines are a separate issue and will be dealt with separately. BTW, has anyone trying the beta version been looking to their Jebadiahs at all?

Well I'd bet donuts to dollars that he's using AJE too. I installed it to examine the problem first hand and those engines put out way too much heat to other parts. (Edit: Clarification. They produce too much heat, which invariably ends up being conducted to other parts as part of stock physics) There is definitely NOT more heat moving between parts in the beta of DRE however. The problem there is two fold being a combination of some parts having lower maxTemp (and therefore less tolerance to overheating) and in heat shielded parts, they have lowered conductivity so they can't shed excess heat to other parts as efficiently. (the exact opposite problem in fact). If the parts you attached the engines to had heat shields on them then the problem definitely gets worse. Nathan mentioned something that looks worth exploring but I'd rather implement something on my on than to bother AJE's developer about it. (especially given that DRE gets the blame for any part that explodes over in the AJE forum) Edit #2: I could use some AJE craft to test with. Preferably with stock parts. I have B9 installed but it's the older version....

Is he likely to be amenable to such a change? And, wait a second... is that value of 3600 supposed to represent Fahrenheit to AJE, in a universe where the scale is emphatically Celsius? Please tell me that's not the case Edit: Let me clarify that last bit. What I'm asking is if numbers that are meant to be in Fahrenheit are actually creeping into the game unconverted. I got nothing.

You said it yourself: inclination. If you aren't launching into the target's plane, MJ will compensate as best as it can and there's extra deltav cost involved in that.

You would find a snipe hunt to be more productive. I'll install AJE myself and take a look at the problem. DRE doesn't just scale down max temp for engines, it also scales down their heat production by a like amount. However it occurs to me however that Real Fuels has its own set of heat production values as part of its engine configs. DRE isn't touching Real Fuels configs at all. I think that's the same thing that someone else already reported. It's fixed in the next version I push out.

RO isn't just some collection of config changes and re-scalings; it's comprised of various recommended/required mods, and if you have the mods it tells you to have then you don't have the problems you describe. If you're not willing to get all those mods then you shouldn't use RO. You're probably not the intended audience anyway so save yourself some aggravation, and the rest of us having to read the ranting and uninstall it. Don't read that wrong; I'm not entirely unsympathetic but right now I'm just not feeling it. I think RO is just not for you. There is a mod that makes realistic ions a tenable proposition. Orbit Manipulator, and it's listed on the front page. I don't think it lets you ignore the ion equipped probe, but you can time warp while the engine does its thing and get through the burn quickly. (not physics timewarp either; off-rails)