Starwaster

I could maybe treat them as having mass for thermal purposes... Can override thermalMass to have a minimum value SHOULD be a non issue. The matter is decided and the discussion is over, especially if trolls are going to come in issuing ad hominem attacks. Deal with it. Replace the copy of DeadlyReentry.cfg in your DeadlyReentry folder with this file: https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry/DeadlyReentry.cfg

People are obsessing about the Ablator vs AblativeShielding a bit too much Deadly Reentry has ALWAYS had a resource called AblativeShielding. I'm not changing that just because Squad finally got off their rocket nozzles and decided to do something about reentry heating. I'm also not going to tamper with the new stock resource they made to go along with it. There's just no reason to and it hurts nothing for it to sit there quietly doing nothing. I still don't even get what problem people think there is to be solved with the two resources. Just ignore it and pretend it doesn't exist. They will quite literally accomplish the same thing as whatever it is they think would be accomplished by 'unifying' the two. It's a non-issue Now, thermalMass: The skin stuff that you can assign is: skinThicknessFactor (defaults to 0.1) skinThermalMassModifier (defaults to 1.0) skinHeatConductivity (defaults to 0.12) skinMaxTemp (defaults to part.maxTemp) So: skinThermalMass = part.mass * skinThicknessFactor * skinThermalMassModifier * PhysicsGlobal.standardSpecificHeatCapacity (value of 800) Resources have a specific heat: It's called hsp in the resource node Parts don't have a separate specific heat, they just use the global specific heat default of 800. That's what thermalMassModifier is for. Should the part have a specific heat of 400? Set thermalMassModifier to 0.5 Should it be 1000? Set thermalMassModifier to 1.25 Accomplishes pretty much the same thing as if parts had a separate specific heat setting. skinHeatConductivity controls how fast the skin will conduct heat to the interior. The largest of skinHeatConductivity and part.heatConductivity will be used. (they default to the same thing)

It's not really massless though, it's just very low-mass. Let's run through the math and see what's happening here mass = 0.005 (5 kg, that's a heavy barometer) mass * specificHeat of 800 = thermal mass 4 skinThermalMass = (thermalMass * 0.1) = 0.4 now, this part here isn't terribly realistic, but when skinMaxTemp is reached the entire part explodes. That's not very realistic and it's going to change in a future update. I think probably I will have it take damage like when parts caught fire in earlier versions of DRE. You know, as hot plasma enters through the breach. But for now, the barometer has an effective thermalMass of 0.4, a maxTemp of 1200 and it will explode when it absorbs 480 kW of heat. So I think what I'll do here is give it a skinThicknessFactor of 1. That way it will take 10x as much incoming flux to destroy it. (assuming that it's convection that's getting it) Thanks man!

Because it's a stock resource that I don't control. Squad could change something about it in the next update, or the one after that or the one after that. Secondly, there's no reason to. WHAT??? You say WHAT to me? YOU SAY SEE-KAN?!?? I KILL YOU! I KILL YOU FILTHY! No, just kidding. I'm sort of aware of the CKAN situation but I have no idea why that is... I think it might be because it's looking at the DeadlyReentry.version file and when I first pushed the update, the version file change didn't get picked up. (there was a problem merging branches and I had to do it by hand) SO maybe it needs time for the new change to propagate. I'll ask the CKAN folks if they know what's up and how to fix it. Thanks Yes, she was my girl and she passed away a few days after Valentine's day after being ill for awhile. So this update is dedicated to her. You can *mostly* ignore those errors. I think I know what those are and I updated the file. If you go a page or two back you can find the link to it on the github site. Uhm... I have no idea how you're burning ANYTHING up because you also happen to have 3192 errors in UpdateConvection. I think that's a problem I'm already looking into; I encountered it myself and I thought it was fixed. I'll also look into the proc fairing problem. It might have been a conduction issue... I don't think any of those mods will currently work (properly) with DRE because it's the skin damage that will kill you first and they won't even see that unless they use reflection to look at ModuleAeroReentry and lookup skinTemperature. That's not too hard to do.

You can probably get away with deleting them if you want. DRE certainly has no dependency on them. Any ill effects are on you though! I have no idea what 'unifying' them entails. I'm inclined to leave the stock resource alone however unless there's some compelling reason otherwise. (deleting a resource that could potentially exist in someone's save file is a very BAD thing. We're talking 'cross the streams' bad) Yes, that does sound like a problem. I'd looked briefly at the maxTemp value but doing anything about it slipped under the radar. FYI, it's only 400 degrees hotter than Apollo heatshields got so the value itself isn't a problem. What is a problem is whether it's possible in a stock environment to reach that temperature. Even with Deadly Reentry. So I will be looking into that. Yes, I might try to do something like that but it's not a priority ATM. What you're probably thinking of was a proposal by B9 to assign differing levels of protection to a part depending on what side of it was oriented into the airflow. It was an interesting proposal and I had intended to do something about working it in, but basically ended up freezing the beta development where I left it and there wasn't time to implement his suggestion. If it turns out that there are still a significant number of hangers on to KSP 0.90 / DRE 6.5 then I'll probably go back and put the last beta into an official 0.90 release and possibly look into implementing B9's suggestion for that version. But that assumes a lot more free time than I have right now. (though it wouldn't be a huge stretch to do so after having implemented it for DRE 7.0 as the code would be universal) EDIT: Those concerned about having two ablative resources: On the subject of heat shield resources, that's not hard coded you know. Anyone could put out a parts pack with heat shields configured for their own custom resource. You could conceivably use ElectricCharge as a resource, though that's probably harder now than it was pre DRE 7.0 (because the new heat shield looks at resource density, which EC doesn't have so you'd basically end up with zero pyrolysis)

Let me also add that gimbals are way too gimbally in 1.0.* I invariably reduce mine to 15% - 30% And if I have boosters then the core stage has the lowest amount of gimbal. (I'd lock that gimbal if I thought I could remember to unlock it when staging all the boosters away) One of these days I have to make myself a MM patch to just globally patch them all

Ah I see where that's coming from. That will affect stock shields. Not sure what the exact effect is; probably they won't burn as much shielding as they should Replace your DeadlyReentry.cfg file if you use them. (link: DeadlyReentry.cfg) It patches the stock shields so that they work properly with DRE. Grab the latest version from the link in my reply to Enceos No idea, I'll leave it to them to do.

Well I messaged Planetshine's developer to ask him about it since he had that problem.

I can't reproduce that. Does it only do it sometimes? Are you using Windows, Mac or Linux? Log files too and repro directions as to what you're doing when it happens

Mainly that only a portion of a part's mass is used when applying heat. That's the skin. (or hull if you prefer that term) If one thing has more mass than another (and all other factors are equal) then the more massive thing will heat up more slowly. This is a large part of why stock reentries feel weak. The other reasons are Slower reentry speed over Kerbin than over Earth. Less time spent in reentry To correct these two problems, convectiveFactor was increased to 50. This means things are subject to convective heating 50x faster. (you could also think of it as 50x the heat, but in practice, part temperature and skin temperature act to limit this so that things will heat up only until they reach equilibrium or explode) Also, the amount of heat produced in reentry has been increased so that it is comparable to an Earth reentry radiationFactor was also increased to 50 so that it's still possible to reach thermal equilibrium after convectiveFactor was increased. Also: OP was updated to remove any confusion as to what to do with ModularFlightIntegrator.

Ok, I pushed a patch release and updated the version number to 7.0.1 Also corrected links in OP and my 7.0 post. This fixes the problems with the stack nodes. the nullref error I'm not sure about why that's still happening as I put code in place to prevent that. (pretty sure it's the cached FlightIntegrator as nothing else in there should even be capable of causing that error and I haven't seen it myself since I put that code in place)

Shock compression temperature in Kelvin = your velocity in meters per second, yes. That is how you find the temperature of the shockwave. Strange but true. Ambient air temperature is mainly relevant in determining atmospheric density which is used in determining how much of the heat generated actually makes it through. Air temperature doesn't really play a part in determining reentry heating. If you slam into a mass of air at 11 km/s, the result is largely going to be the same regardless of whether it's cold air or hot air: You're compressing the air and that heats it up. It's that compression that causes the heating and at 11,000 meters per second a few tens or even hundreds of degrees air temperature won't make a difference. Crap, that sounds like I missed the stack nodes if you can't attach. I'll get that fixed ASAP. Module Manager errors: You can probably ignore them. The most likely cause is that some conditional clauses in the config file couldn't be met. Submit an output_log.txt or player.log (if on Mac or Linux) and I'll take a look at them.

If external temperature is lower than the skin of the ship then heat will be transferred convectively away, yes. No. Without knowing what your complaint is about air temperature, all I can really respond to that with is that air temperature is not the primary contributor to the temperatures you will experience during reentry. The contribution of air temperature is useful mainly in knowing what the precise density of the air is at a given altitude so we know how much heat to transfer to your ship during reentry. Wow, ok, quite a few of those are Deadly Reentry related and I've a pretty good idea where from. I'll have to reevaluate how I'm caching a certain item. What happens if you revert to VAB and then try again? And does it do it every time you launch a rocket? What if you restart the game? Thanks! I'll take a look at them and see if we use them.

Deadly Reentry updated for KSP 1.0 There are far too many changes to list. This is a near total rewrite from the ground up to take advantage of KSP 1.0 new thermal system. The major difference is that only fraction of a part's mass (thermal mass) is used when applying convection heating. (convection is the main means by which reentry heating occurs) This concept was used to track 'skin' temperature separately. Skin can have different max temp properties, different thermal mass, etc. Skin temperature will eventually propagate into the interior (what was previously 'part.temperature' is now a part's interior. Chute damage is currently not implemented. Both stock and Real Chutes have had canopy destruction built into them if you open them up when it's either too hot or you are going too fast. Crew and part stress damage due to G forces is in. Go too steep and you could kill the crew even if the craft survived reentry heating. To Do: * Switch 'on fire' damage to skin temperature. * Switch from an instant destruction to gradually applying damage over time. (this is how previous versions worked. * Reimplement mod settings. (currently, if you want to change mod's settings, do so in the stock KSP debug menu: alt-F12->Physics->Thermal) Deadly Reentry version 7.0 - The Melificent Edition

Thanks, but can you please submit an output_log.txt instead of ksp.log? ksp.log isn't as informative. (if you're on Mac or Linux versions then it's player.log)

Is there a staged engine with sufficient fuel to do the burn? Or any fuel at all? Is it an unmanned rocket and if so did it run out of electricity?

No version of DRE ever caused any parts to not slow down (enough, or otherwise). It didn't touch drag. Any beta there would be for KSP 0.90 and not KSP 1.0 I am aiming more for a release sometime tonight, unless I find some glaring bug that requires immediate attention. The only tasks are to tweak space plane shielding which is tricky because passive heat shields no longer use a dedicated heat shield module. Instead they require tweaking of the part's various thermal related parameters. Interestingly I've found that drastically REDUCING thermal mass of the skin causes significantly less heating. I've never been able to actually get that to work so there's clearly a sweet spot in there where thermal equilibrium can occur. (this is actually how the shuttle tiles worked. They really couldn't hold very much heat, so they reached their maximum temperature very quickly very high up which meant that they basically could hold no more and would reject the rest. In KSP that actually tends to cause things to blow up but I accidentally achieved that when testing the SDHI heat shield trying to find the best configuration for Sumghai) So long story short, things are mostly fallen into place and I just need to finish things up enough for a basic release. (the settings screen is going away for awhile; the stock thermal debugging screen controls DRE's parameters so it's there for tweaking if anyone wants it) BTW, I tried the drogue test at very high up at atm 0.001 and it survived.... YMMV depending on starting altitude and speed....

And, I *think* that stupid_chris is doing checks for both heating and stress damage on the canopy. Regarding heating, here's what governs which way heat flows: From hotter temperature to cooler temperature. How MUCH heat depends on the densities of the respective. At higher altitudes, sure the air is thin but so is the canopy. And the larger it is the more heat it can collect. So it can heat up fairly quickly. My guess is that it will fail from melting (or decomposition; Kevlar doesn't melt. It just weakens at higher temperatures and then comes apart) And his code isn't even dependent on Deadly Reentry anyway. So you can definitely give it a try right now. Actually I'm going to try it right now myself and see what happens. My guess is that it's going to be pretty ugly.

I have no idea if that will still work. Deadly Reentry will no longer inflict damage on chutes. At least, not on Real Chutes because SC has implemented chute damage himself. I think stock chutes also have deployment limitations now too but I might have imagined that. (in which case, I'll reimpliment damage for stock chutes. I have to check that out) so in short, try it out first but make sure you have backup chute or your Kerbals may DIE. And then I'll jeer at you mockingly while posting in Comic Sans. It's looking good. I finished some preliminary testing of spaceplanes but not as much as I would have liked, but it will have to do because I don't do space planes very well, so you guys will get to tell me if they burn up too much or something. I'm finalizing some other things and going over configurations and Deadly Reentry 7.0 should be up sometime in the next day or two.

That's the reality of the situation. The compressed shockwave in front of the vehicle (where front = the direction in which it is travelling regardless of orientation) has a temperature value in Kelvin equal to its velocity in m/s. That is half of why reentry heating feels so weak. How often are you travelling even as fast as 3 km/s during reentry? Over Earth you'll be doing 7.8 km/s from orbit. Less when starting from suborbital. A Mun return... is what, 9 km/s? 10? A Minmus return doesn't provide the peak temperature of even 1/3rd of a Moon return to Earth. Coupled with the fact that you're spending 1/5th the time doing any really intense heating as you would be over Earth. That's half of the problem. The other half is (because that's actually still quite a bit of heat) that in order to raise your temperature one degree, you have to absorb your mass * specific heat *thermal mass multiplier. And by mass, I mean the mass for the entire part. In reality, only a fraction of that mass would matter: The mass of the skin of the spacecraft in the area actually undergoing convection heating. (for a capsule, the bottom area) The skin issue is the only real oversight that I consider to exist in the new model. The rest of it (peak heating / heat load) is an unfortunate and unavoidable problem stemming from doing a reentry over such a small planet. To mitigate it means dealing with multipliers and exponents and there's no way around that part. (except to have real solar system sized planets, and that's not for everyone)

They're probably hidden off screen now, if you used 452 or an earlier version. It might have corrupted the settings. If that's the case, you have two choices Look in GameData/MechJeb2/Plugins/PluginData/MechJeb2/ - then find mechjeb_settings_global.cfg and delete it. You will lose all custom windows you created. Do this when NOT in flight mode or when exited out of the program. (I do all this sort of stuff when still in the game because I'm a 1337 b@d@$$ h@><04 and I know what I'm doing - don't do it if you're not me) If you don't want to lose any custom settings and windows then keep reading. If you followed step 1 then don't read any further. If you're still reading: edit mechjeb_settings_global.cfg and delete the very first section that says MechJebModuleMenu { buncha stuff } Replace that section with this: MechJebModuleMenu { windowStat = NORMAL windowProgr = 1 windowVPos = -403.593 hideButton = True useAppLauncher = True windowVector = 1720,303.593,200,530 windowVectorEditor = 1910,1070,0,0 showInFlight = True showInEditor = True enabled = True } Your other windows should come back too but they will likely be crammed into a corner but you'll be able to move them. Good luck

Your problem must be different than what I thought. It's probably something besides Limit to TV Duplicate that again, and have your MJ Utilities window open. At 2km altitude take a screenshot and post it here. (use imgur to host it; you dont even need an account) NOW then your throttle limit issues aside... WHY are you launching straight up to 10km before turning? Is it for a career mode altitude record or something? Because if you're trying to get to orbit and waiting to start your turn until 10km, you don't have to do that anymore (if the first one was it and it's a record thing then forget I said anything about it)

Only the vertical component of your velocity vector is considered when limiting to terminal velocity. Horizontal is not considered and it's by design. MJ is working as intended.

Control from here isn't a toggle per individual pod or cockpit. It just changes which reference transform you're controlling from and switches from one to another. There's no way to control from multiple pods. I haven't looked at the MJ source in a few months and not sure how the KE files were integrated. This: should work for you though. Instructions are for MonoDevelop. (please be using MonoDevelop...) Open your MechJeb2 solution file. In the explorer on the left, right click the MechJeb2 project and click Add->Add Existing Folder Browse for the KerbalEngineer folder. Do the same for any other folders or files you might be missing or get errors on

There's a community patch for it. I don't know what it needed; it's just a parts parts pack with no plugin. With the possible exception of its bottom stack nodes, everything else should work fine with defaults. (the stack node issue is that a lot of older stuff needs a sign reversal because the bottom node is pointing up instead of down on a lot of parts, and KSP used to ignore that, but not anymore)