Starwaster

It's simple text. But you have to have Module Manager installed

Aside from probably needing a balance pass, it should. Right now I'm only opening up 1.0 to test the new Deadly Reentry. I haven't even got to play yet

You come in here and say a thing like that and I think one of two things: Either you're just a troll or you just can't be bothered to read. Take some time and educate yourself before posting. I very CLEARLY laid out this mod's future and why it still HAS a future: http://forum.kerbalspaceprogram.com/threads/54954-0-90-Deadly-Reentry-v6-5-3-Beta-Mar-6-2015?p=1870310&viewfull=1#post1870310 READ that. My work here is not yet finished. Maybe some day Squad will update the system to something where I can retire from Deadly Reentry, but that day has very obviously not arrived. EDIT: UPDATE TO ALL: I was planning to release a lite version earlier as you all know but there's still a little bugginess that I have to work out (especially for space planes and other ablatorless shields) Additionally, this mod works by overriding certain of KSP's FlightIntegrator methods. All of that work was completed while KSP was still in Experimentals testing. However, as some of you may know, Ferram4 is getting 'nuFAR' ready for release and it too will be overriding FlightIntegrator, and in order to prevent stepping on each other's toes, we're working on a system (common dependency class) to prevent the two mods from interfering with each other. So I'm going to hold off on release for awhile while we work on that. This will be better for both mods.

In actual practice it shouldn't make much difference. If the interior heat does start to build up it will send more and more flux to the surface until the two are in equilibrium. If it gets really high, well, radiant flux gets a lot higher because it's temp^4 * surface area. If there are problem parts then it will probably pay to increase the conduction factor. And realistically, heat from NTRs is something that would need to be dealt with through radiators. If we make them Brayton radiators then they can generate electricity as they shed excess heat I can't see a fission reactor's temperature being anything but higher than other parts, regardless of respective stored heat capacity, heat will always flow from hotter parts to cooler. They're more likely to be sources of excess heat.

Currently trying to track down the source of a disgusting amount of heat whenever chutes are deployed. Literally just floating down at a sedate 5m/s from a peak altitude of 2km is enough to raise temperature by almost 1000 K....

Looks like

Real Fuels HAD some radiators and some radiator code but it was removed for 1.0 compatibility. We're talking about replacing it with a more appropriate system that works WITH the current heat model. As to whether it will be in the next update for RF I do not know yet. And, yes, I would say for cryogenics it will probably be important if you want to keep your fuels in the tanks instead of watching it float by as frozen crystals. And excess internal heat could be important in other areas that we've talked about, so yeah radiators will be 'a thing'.

Currently, these cannot have anything attached to their bottom nodes and the heat shield code is no longer valid. (going forward, Deadly Reentry will use a heat shield module based on the stock module as Deadly Reentry is using the stock heating code heavily) Additionally, these parts can't have anything attached to their bottom nodes because the bottom nodes don't point the right way. (it was only possible before due to a bug which is now fixed) The following patch for Module Manager will allow parts to attach to their bottom nodes and should allow them to function as shields in KSP 1.0 (no actual heat shield code yet but they will have a high emission factor combined with a large radiative area) (there will be a Deadly Reentry update soon; if you use that, don't use the patch as it will be incorporated into DRE) create a text file with an extension of .cfg (ADEPT.cfg for example) Edit the text file you created and copy then paste the following code into that file @PART[NASAaeroShield_A] { @node_stack_bottom = 0.0, -0.95, 0.0, 0.0, -1.0, 0.0, 1 //thermalMassModifier = 4.0 maxTemp = 1800 heatConductivity = 0.06 // half default emissiveConstant = 0.95 !MODULE[ModuleAnimation2Value],*{} !MODULE[ModuleHeatShield]{} } @PART[NASAaeroShield_B] { @node_stack_bottom = 0.0, -1.9, 0.0, 0.0, -1.0, 0.0, 2 //thermalMassModifier = 4.0 maxTemp = 1800 heatConductivity = 0.06 // half default emissiveConstant = 0.95 !MODULE[ModuleAnimation2Value],*{} !MODULE[ModuleHeatShield]{} } DennyTX, feel free to incorporate this if you want. I'll add a heat shield section to it later, but as is it should be pretty effective with the stock heat system. When it animates it will automatically have both its drag and radiative area increased and the emissiveConstant of 0.95 means it will be very effective at radiating excess heat away.

Ok, if anyone wants to give Ioncross a try in 1.0, install the mod as usual but replace IoncrossCrewSupport.dll with this file https://www.dropbox.com/s/hrecj1t6lkzb5gj/IoncrossCrewSupport.dll?dl=1 It's compiled against the KSP 1.0 binaries so there shouldnt be any errors... I'll get to a proper release after I've gone over the parts files and made sure that any necessary 1.0 specific fields are added and tested it all.

Even I haven't had a chance to check it out; I'm still working my way through the mods that I administer. I have however tried compiling the source and got some errors when linking to the new KSP 1.0 binaries. The nature of which lead me to believe that it will throw exceptions. The specific errors dealt only with a contract module that wasn't completed and is currently disabled. The exceptions generated in-game would be upon accepting a contract, and since the contract is disabled, it should be ok. No other compile time errors occurred in any life support functions. So it will probably run in KSP 1.0 HOWEVER. No guarantees on that. If you want to try it anyway please do so on a save game specifically created for testing Ioncross. Or backup any saves you care about if you want to try. If you do decide to try it, please inform me about any errors you get

That's our call to make; edog's as to whether he wants to continue and ours as to whether to support him.. You don't want to use it then don't use it. But nobody here cares what you think. Way to make me hungry

Ablation rate has been using part temperature in DRE for awhile now. I forget how long. But yes, now it will use skin temperature. And yes, reentry increases the background thermal radiation.

One option: Radiators. Use them to cool off your tank Option 2: If LH2+LOX is your only option on that engine then you need to use the one that can use methane or ammonia. It should be in there somewhere. Ammonia has the highest boiling point of the available cryogenic fuels. Per kilogram of propellant it has the lowest performance though that's offset by its compact tanks. (I use methane for tooling around Kerbin and its moons. It would probably also do well on a Duna mission. For real long distance, like Jool, consider ammonia)

The future of Deadly Reentry: http://forum.kerbalspaceprogram.com/threads/54954-0-90-Deadly-Reentry-v6-5-3-Beta-Mar-6-2015?p=1870310&viewfull=1#post1870310 In summary, stock heating is tame enough that Deadly Reentry is going to be around for awhile; there will be a series of updates with the first being tonight. (think of it as Deadly Reentry Lite)

So once that's done, Procedural Fairings works ok with KSP 1.0?

By default that's based on the part's temperature. Skin is tracked via a PartModule and it will be possible to set things like that independently of part temperature. That means it will be possible to go through and change part maxTemp values to saner values but the skin would have higher values. For instance, shuttle parts could have their maxTemp set to 933.45 (the melting point of aluminum in Kelvin - all temperatures are now Kelvin) while the skin would have something like 1800 to represent something like shuttle tiles. It would have high emission values so it would radiate more heat. Since it's supposed to be shuttle tiles it will have a low specific heat capacity. (lowered thermal mass) and it will conduct slowly. The way the system is currently set up, if the skinMaxTemp is exceeded it will just destroy the part, which is in keeping with the current system but I'm going to shift that to a damage based system and as the skin becomes more damaged, it will leak more heat through (higher conductance) and/or other dire consequences. Tonight's version will probably just explode the part. Uhm yes to skin conducting to internal (skinTemperature to part.temperature) outgoing radiant energy is attenuated by background radiation and nothing else. (though obviously if it's subject to convective heating, one will offset the other) Parts can occlude one another from convective heating. That uses a cone based system instead of the raytraced system that DRE used in earlier versions. It's probably quite a bit faster than raytracing. On the other hand it also means that if you separated a part from your ship, you can't ride in its wake like you used to be able to do (you did know you could do that... right?)

Check the first post. It's right above the download link I think; says 'links to third party shields' or some such. I can't speak as to their KSP 1.0 readiness state. If they use ablative at all then they won't ablate at all because they are configured for KSP 0.90 versions of DRE. On the other hand, if their animations were done properly then KSP will automagically update drag area and radiative area so it's possible they might perform adequately as is. (i.e. they will increase drag and radiate more heat). They still will need tweaking to increase emission values and possibly thermal mass. When I push through the update tonight, there will be patches to make sure those shields function properly in 1.0

One caveat though: I'm probably going to ditch the inflatable shield that DRE has always had. It has an issue with its animation that is even worse in KSP 1.0 In the new aerodynamics / thermodynamics, parts automatically have their drag and radiative area changed when they animate. But it doesn't seem to recognize that inflatable shield has changed unless I quicksave / quickload in flight. (exiting to space center would do it too). It's not a new problem either. FAR didn't like that shield though nobody ever seemed to notice that there was an issue. (same issue really. It wouldn't update the shield's drag on the fly. Had to save/load) So, unless there's some huge outcry to keep the shield (in which case I'd try to find a workaround using ModuleAnimation2Value) it's time for it to go away. There are other animated deployable shields out there that work properly with KSP 1.0 instead of sticking with one that 1) won't increase its drag level as it inflates and 2) won't increase it's radiative area as it inflates. (either of those is bad for a reentry. Together is not fun and not survivable)

Yikes, that does not look like a place I want to send manned ships to!

Status Report Re: KSP 1.0 To summarize what you may (or may not) already know: KSP 1.0 has had a major overhaul in how thermodynamics are handled and Deadly Reentry is having a major overhaul to take advantage of these new systems. Previous thermodynamics in the game were limited to an extremely simplistic system that handled temperature changes without any concept of heat. (as temperature and heat are two very different things) The new thermodynamics system takes into account heat flux from four sources. Radiant heating (incoming: from solar and background; outgoing: based on part temperature) Conductive heating (from part to part until temperatures are equalized) Convective heating (Based on a part's velocity through an atmosphere and somewhat on the atmospheric temperature itself) Internal heating from other sources such as engines or drills, or any time heat needs to be shunted around where it doesn't fall under the first three categories. That last one is where reentry heating comes from and doesn't really get started until you're supersonic and doesn't get really serious until you're hypersonic. All in all this is a fairly realistic system but is lacking in stock due to two factors: Low velocity at reentry interface (this is an old issue that anyone who has been with DRE for awhile is familiar with: Velocities of incoming craft over Kerbin are approx 2-3 km/s which is low hypersonic and deceleration to subsonic occurs quickly and easily) The concept of thermal mass has been introduced. This is a more realistic concept than what we had before: In order to raise temperature by 1 degree, an amount of incoming heat flux is required equal to the part's mass * thermal mass modifier * specific heat constant. (this also includes resource mass) Thermal mass is a good and necessary addition but there's one problem with it: In Real Life, you shouldn't have to overcome the enter thermal mass before the skin is breached. Localized heating occurs swiftly and stays local because heat conduction throughout the entire mass occurs too slowly. If it weren't for this, I'm not even sure Deadly Reentry would still be necessary. So what I've done is introduce the concept of skin temperature. Radiant and convective heating are now shifted to part's skin temperature. The amount of thermal mass in the skin is 10% of the part by default. (10% might actually be a little too high but lower than that might have been too deadly). These values are subject to change as the system becomes more robust. (specifically I'd like to introduce heating by location in the future but this requires some thought before implementation. The current system I've devised is more in keeping with with stock. It would have been easier to just do a config based system where part's thermal mass was reduced across the board or convective heating was increased enough to make stock Kerbin reentries lethal, but that would have affected internal heating out of proportion to what it should be to the point of making things too difficult and the introduction of skin temperature is more natural. This way we can restrict part temperature to being internal heat with different consequences for parts based on function. (i.e. parts with fuel tanks might explode at lower temperatures due to their contents boiling off too quickly, or Kerbals dying or being incapacitated because their quarters overheated, etc etc) The bulk of what needed to be done is already complete but had to be built from the ground up rather than being integrated with existing code. The old DRE code will require wholesale chunks ripped out of it because they're now obsolete. What I currently have could be dubbed 'Deadly Reentry Lite' and aside from some config file work and parts editing (for existing DRE parts). I expect to do a basic release of this tonight with a more complete version later in the week. (deceleration damage, handling of animated parts like landing gear which is shielded when closed; unshielded when open. Etc etc)

As I understand it, the stock app tray changed how icons are accessed. So without Blizzy's toolbar or until Alarm Clock is updated, there's no way to open the Alarm Clock menu. (and I assume that Blizzy's toolbar needs updating as well though I haven't tried it in 1.0 but there were a lot of big changes this time around)

This is working in 1.0 pretty well.

I could live with them if they at least broke into 1 piece per section And if they had actual physical pieces that I could strut things to. (and it also seems like the point of drag is at the fairing base instead of high up where the actual fairing nose is.... not 100% sure of that though) All in all, I think if the first two conditions were true that they would really appeal to people who have never tried edog's Procedural Fairings Regarding the nodes, 1.0 is a LOT stricter about node direction than pre-1.0 versions were. For example: The bottom node in the below example can't be attached to from below any longer. The fifth digit would need to be -1 (Y pointing down) for you to attach from underneath node_stack_top = 0.0, 1.0, 0.0, 0.0, 1.0, 0.0, 1 node_stack_bottom = 0.0, -0.95, 0.0, 0.0, 1.0, 0.0, 1

For ascent I typically use a profile where: turn start = 0.25 turn end = 60 turn end angle = 5 degrees turn shape = 40 Obviously YMMV according to your TWR at the launch pad. If you have low TWR then you'll want to start your turn higher. Typically you'll want to start when you reach 100m/s though I like to flirt with lower speeds starting. The lower your velocity when starting your turn, the greater the value of turn shape should be. Worst thing you can do is have your nose drop too low and too soon before you've really gotten up to speed.

Indeed!