Starwaster

Because I'm spending my own damned time trying to help you and you basically just brush it off in an evasive and snarky manner. The radiator (more properly ModuleHeatPump) code fixes weren't going to go in for RF because it was going to be migrated to another mod but the situation changed. So there will be a fix coming. I can't repro what your're saying I can't rip the fins off with FAR. I made sure failures were on. And I can cool my tank down to the boiling point of hydrogen on two fins. Modified using the same module mananger fix that I provided.

Real Chute has been responsible for problems like you're experiencing in the past, but those were fixed a long time ago. Looks like you found a situation where the bug can still occur. Definitely errors occurring when the vessel is loading in are bad. If I were StupidChris I'd trap errors when loading chutes then log the fact that they occurred because this breaks save games, or at least craft. Question: Did you install other mods that modify Real Chute in any way? Trying without it loading as Obsessed suggests is a solid troubleshooting step but it would also be a good idea to try with just stock + RealChute to see if something else has interfered. Your craft has ONLY RC supplied chutes so that shouldn't be happening...

That ship is either corrupt or one of the PartModule's on it are throwing errors at a bad time. Your ksp.log will not be useful in troubleshooting. Please submit a proper log as detailed in this thread: http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29 I'll take a look at your save file, but statistically speaking, the likelihood of finding the problem with that alone isn't good.

Not so. Unless you disabled logging then you always have logs, and those logs contain errors and all manner of logged events regardless of whether your crash resulted in an error being displayed to you. Visit this link: http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29 It contains information about finding your logs. Create a thread in that forum and post your logs there.

Forgive the double post but I wanted this to be separate from my reply to DaMichel Update to the Version 6.3.x beta: Deadly Reentry v6.3.1 beta The single change is that the toggle for the Alternate Density calculation used for calculating heat has been made persistant unique to each difficulty level as with the other settings. (for the most part, leave this setting alone unless you are trying to make things Hard and the level of heat got to be too much. Then you turn that on and it will cut the heat down which will have a lot of benefit in the lower atmosphere when going supersonic during launch)

Two things: Deadly Reentry is like The Walking Dead: Nobody is safe. Secondly, your code snippet will not be reached more than once, and probably not EVEN once. Stock KSP will destroy the part as soon as it sees that the part's temperature has exceeded maxTemp (I lied about there being two things. I do that) The DRE code you cited does not mean the part will burn up when reaching their damage threshold (85% or 97.5%) it means they will start to take damage. They are not immediately destroyed. Taking damage has several deleterious effects such as reduced ability to withstand excessive g-force or in the case of heat shields, they may not protect as well. Destruction is neither immediate nor certain.

Some Real Fuels configs. (made the tank type Cryogenic to facilitate nuclear fuels) @PART[asimovfueltank]:NEEDS[RealFuels]:AFTER[RealFuels] { MODULE { name = ModuleFuelTanks volume = 18000 type = Cryogenic } } @PART[asimov_reactionwheels]:NEEDS[RealFuels]:AFTER[RealFuels] { MODULE { name = ModuleFuelTanks volume = 750 type = RCS } }

Do you have the plugin too? The config by itself does nothing. And it can go anywhere. Also you need modulemanager. As to whether it can be integrated into the part file, it can be. Just look at anything that starts with a @. That modifies the part or module whose name appears in brackets.

Stop trying to pass off NASA Earth images as in-game! we're onto you..

A Kraken did it.

Yes, I don't know why loss isn't based on part temperature; I assume that predates your involvement as well. Unless perhaps the intent was to simulate skin temperature without raising the entire part's temperature, which makes a certain amount of sense. One might assume that the shield is going to pick up X amount from the shockwave. Involving air density seems a bit strange though because most of the shield's loss would be from pyrolysis. Using air density makes me think erosion, which should really only happen to the charred part of the shield. I don't agree though that dissipation should be a constant because it's losing heat because some of it was carried away by the shield material that ablated away. It's like the water in the paper cup analogy. Where did the heat go that should have ignited the paper cup? Answer is, it boiled off with the water. Bottom line is probably that I'll come back and revisit this at some point. Maybe make loss dependent on part temperature outright instead of playing around with yet another curve. If I did that then I would bump the dissipation rate to compensate for letting the shield get so hot. (which is actually ok now because we're setting heatConductivity to 0.01 now for ModuleHeatShield. It can get as hot as it wants and not transmit any of that to other parts) BTW, I did reduce ridiculousMaxTemp, but not nearly as much as I was talking about doing before. Given your experience with high TWR rockets in full sized RSS, I'm interested in how that turns out for you. If you set difficulty to Hard, it should actually reduce the lower atmosphere heating enough to be survivable. (EDIT: Oops, Alternate Density calc isn't being saved by difficulty setting so it may be turned off. That configuration was meant to have it enabled) To All: One thing not in the changelog that I think I mentioned I was doing before: Stock chutes (not radial) and Real Chute cone parts have weak built-in heat shielding as long as no chutes were deployed. (as soon as the cap comes off, they are exposed) Also interested to see if anyone noticed what else I did ...

Originally, that was in fact my intent. In spite of the increased dissipation, it is still possible in extreme conditions to destroy the shield and I'll probably leave it like that. Even so, it should be pretty hard IRL to destroy a heat shield as long as there's some ablator remaining. It's the same concept that makes it possible to boil water in a paper cup over an open flame. The paper won't go past the boiling point of water as long as water remains. But it didn't quite work as intended so it only damps the temperature rather than acting as hard clamp. It can't currently be configured but it can be turned off. On, it can be destroyed but it took me hard setting (part of the reason it came into being), FAR and RSS lunar returns

Ok, beta release time is here: Deadly Reentry version 6.3.0 beta Version 6.3.0 is mostly complete though it has some new experimental features that might break things or just not work as intended. Easy setting SHOULD be sufficiently easier for those having a tough time but needs hands on by people who might actually want such a thing. Hard might not be hard enough; it uses careful and unusual adjustment of densityExponent, temperatureExponent, heatMultiplier and the new alternate density adjustment. (be really careful altering that setting as it can nerf heating badly if other settings aren't adjusted properly) Partial changelog is here: - Chute failure message made more generic - Added unsafe chute deployment warning messages (do not deploy while warning is displayed) - Changed stock chute and Real Chute defaults to deploy at (usually) safe altitudes on Kerbin. Change at your own risk! - Experimental alternate density toggle. (intended for use with Hard setting where temperatures were ramped up greatly. Very WIP) - Some properties were made non-persistant so that existing heat shields will be properly updated if their part configs were updated. - Shields now insulate attached parts - Added version to debug window. - Reentry awareness - Added soft heat cap to heat shields. (shield dissipation rate increases tremendously as they approach max temp) - Implemented difficulty levels (Easy, Normal, Hard) on a per save game basis. - Difficulty can be changed per save game. - Debug menu changes apply only to current difficulty level. - Added toolbar button (icons courtesy of lajoswinkler) - Revamped node saving / loading to accomodate difficulty system. - Added LeadBallast resource if RealFuels is not present. (if RF is present, it has its own LeadBallast resource) - Added LeadBallast resource to the inflatable heatshield. (0 quantity by default. Increase as desired to stabilize the heatshield and prevent flipping) New Toolbar Menu: - Easy, Normal and Hard settings (still WIP; settings subject to change and open to player feedback before final release) - Easy access to Debug Menu - Legacy Aerodynamics (no per-planet gas constant. Density and heating same for all planets) - Heatshield temperature damping (as temperature approaches maxTemp, DRE will try to damp further heating) - Alternate Density (densityExponent will be ignored and density will be reduced for heating calculation: USE CAREFULLY. Intended for creation of hard settings to keep upper atmosphere from being excessively lethal and to reduce launch heating. VERY MUCH A WORK IN PROGRESS)

Drink a shot when: Player complains DRE is too hard. Player complains DRE is too easy. Player complains that parachutes keep burning up / won't deploy / destroyed. Rocket burns up during ascent. Small bits burn up during ascent. Kerbals catching fire. Kerbals dying from g-forces. Player swears that only shallow reentries are the best. Player swears that only the steepest reentries are the best. Starwaster posts picture of Cleopatra the Feral Cat.

I love weird planes like that. I'm not sure if I can use the word I'd like to use to describe it, but I like them. We don't make many like that anymore. White Knight / Spaceship 1(2) are strange like that (in a good way)...

I was a little on the fence about it but I think I just fell off....

A kraken did it.

Deploy not your parachutes into the supersonic slipstream for your Kerbals are crunchy and tasty with ketchup.

I asked a very specific question to which I have to take the answer as no. It had to do with whether you'd tried out a solution I recommended that addressed two different problems that you've posed. I have to take this to mean that you weren't really interested in a solution. Totally missing the point, the discussion is about models and not radiator implementations. RF radiators definitely have some issues (which sadly will not see a fix that was coded and pushed) but your assessment is totally wrong, especially using the solution I offered which was in the form of a Module Manager patch. Very easy to use.

Why not? Isn't it just in the part config files? You can edit those with any text editor.

Didn't someone make one for another mod? If not Interstellar, then another?

Making the fins longer won't make FAR less prone to ripping them off, but increasing the attach node size should. Did you try the config I offered you? It did in fact increase the surface attachment size (so, yes, surface attachment nodes can have their size increased)

Sent the three same Kerbals to their deaths over and over and over so I can tweak settings for the latest version of DeadlyReentry for you heathens. Lo, the power of the F9 key.

I'm going to go out on a limb here and assume that you mean that the landing gear shouldn't blow up because they have heat shields and not because they have 'deadly reentry heating'. (seriously, that part made no sense because it's the reentry heating that MAKES things blow up ) That said, several things come to mind looking at your picture. That docking adapter that you're trying to stick things in seems to me to have a convex collider. It's going to be difficult to get it to shield anything. The only thing that might (EDIT: And that's a big might. No guarantee) work is if you put it directly under the doors and if the doors can be detected by a raycast.. If you're doing it the other way around (and it looks like you are) then the raycast is originating inside the docking adapter's collider so there's no way that it will hit the adapter's collider. The landing gear has heat shielding. I have no idea how you're getting it to explode unless it's having heat transmitted to it through those robotic's parts.

Why is the download so huge? Ain't nobody got time for that.