PakledHostage

It should work although I haven't tested it. The module calculates the re-entry effects based on the atmospheric properties of the celestial body that you're landing on. It will already behave differently depending on the temperature and density profile of each atmosphere. My plan is to eventually define a couple of constants for each atmosphere that will change how the re-entry heating behaves. That way we could make it more or less difficult to land on certain planets and moons. (i.e. Conditions during entry into Mars' atmosphere are more extreme, for a given entry speed, than for Earth because of differing radiation heat transfer effects.) It may turn out to be pointless though, and for the time being the gas specific constants in the model are the same for every atmosphere.

Thanks! Check to make sure that you've got the latest version of the mod installed. I posted version 1.0.17.03 to Kerbal.net yesterday. Among other things, I fixed an oversight where I left the little debugging GUI window turned on in the MK1-1pod heat shield's part.cfg file. You shouldn't need that window. Copy the new MK1-1 HeatShield and MK1-2 HeatShield directories into your KSP->Parts directory when you install the latest version. That should get rid of the window. If you really want to turn the little debugging GUI window, set the "DisplayHeatShieldUI" parameter in the part.cfg file to "True" (i.e. DisplayHeatShieldUI = True). The red "Integrity" bar in the icon stack should be all you need to gauge how closely you're cutting it. It is displayed when the heat shield is activated. The spacecraft will be destroyed if the red bar reaches "empty". It will also be destroyed if the g-meter needle on the navball stays in the red for too long. If your spacecraft are burning up during re-entry, enter a little steeper. If they are breaking up due to high g-s, enter using a shallower trajectory. But beware that the width of the survivable re-entry corridor gets narrower as your re-entry speed gets higher! I will make a plot showing the survivable re-entry corridor in the next week or so.

I'm hoping for another round of optimization... In v0.17, frame rates are almost as low on my computer as they were in 0.12.

Update: I have just posted a new version of the re-entry heat plugin to Kerbal.net. Version 1.0.17.03 changes: 1. Improved logic controlling when plasma trail effects are displayed. 2. Improved "explodieness" of re-entering debris. 3. Fixed a bug that prevented plasma trail effects from being displayed in some circumstances. 4. A few other minor bug fixes. @Subcidal: The "auto-steer thing" is supposed to simulate the inherent stability of the command pod. Re-entry vehicles like the MK1-1 and MK1-2 command pods are designed to naturally orient themselves blunt end forward due to aerodynamic effects. These aerodynamic effects don't kick in until the aerodynamic forces are high enough, however

IMUs are pretty accurate... They accumulate error in the longer term, but this can be corrected with things like radar, celestial navigation, etc. Data from an IMU can be used to calculate velocity in any reference frame you like.

Cricket, cricket, cricket... Is this thing on?

@ddavis425: I owe you an apology... I thought the problem that you were having was specific to your machine but I was able to duplicate it on mine this evening. The upside is that I think I have fixed it. While I was at it, I also tweaked the logic that controls when and how intensely the plasma trail is displayed, plus I've tweaked how I destroy parachutes that are opened too early and how I destroy nearby re-entering debris. I think I also fixed a bug where a jettisoned heat shield explodes due to excessive g-forces caused by the decoupler. I still have some testing to do, but I'll post up the new revision (v1.0.17.03) in the next day or so. And Moach? I haven't heard from you in a few days. Did you still have some changes that you wanted to incorporate?

This might be interesting for some of my fellow Kerbal fans/space geeks: Comet ISON

The configurations in the two threads that I linked to above were designed for "hand-flyability", rather than peak efficiency of design. That way, the challenges were more about testing ascent profiles and less about testing people's flying ability. Prior to v0.16, it was possible to reach orbit and even parachute safely back down using just 1.5 tanks of fuel.

Thanks for the tip, but the problem with that suggestion is that I have no idea what the Unity physics engine is doing in the background. From what I've seen by logging temperature data in a little home-brew data recorder module that I made, Unity's heat transfer calculations are very erratic (at least in how they are used by KSP's game engine). I don't feel that I can trust it enough to rely on it. That GUI was actually only intended as a debugging window. It wasn't supposed to be turned on in the release version. It should be turned off in the part.cfg file by setting "DisplayHeatShieldUI" to "False".

RoboRay's suggestion is good, but you can avoid having to make many such adjustments (and save a lot of fuel) if you start from a circular orbit then bump up/down as appropriate when you pass your target's Pe or Ap. In your case, I would start with either 104 km or 268 km circular orbit, depending on whether I want to speed up or slow down to rendezvous. I would then bump my orbit up or down as needed at the instant I passed my target's Pe or Ap.

So the flames show up the first time you run it, but then don't the next time? That makes me wonder if your experience is related to the memory leak issue that some people are reporting with KSP v0.17? Maybe the game is running low on resources by the second time you re-enter? I'll try to run some tests. Another thing you might try in the interim (admittedly a bit of a long shot) is to check your video settings in the game's settings menu. Dani-Sang sent me a PM saying: "For everyone that doesn’t see the glow effects on the parts, try turning off fallback part shaders in the game settings menu (it needs a game restart to take effect)."

I want to tweak the logic for when it displays the plasma trail, but I haven't finished it yet. It is a compromise between what "looks cool" and "physical accuracy". The reason the little UI window displays when you use the small shield and not the big one is that the "DisplayHeatShieldUI = True" option is turned on in the MK1-1 pod shield's part.cfg file. This was unintentional. Both heat shields are otherwise identical. The only difference between them is the part.cfg file (the larger one's rescale factor is set to 2.0, rather than 1.0). They both run the same plugin module. Not necessarily. Think of it like fried ice cream or waving your hand through a flame. You can expose objects to very high heat for short periods without appreciable heating. When you do a very steep re-entry, the spacecraft slows down so fast due to atmospheric drag that it doesn't have time to heat up. In that case, the spacecraft is destroyed by g-forces, rather than heating. I regard this effect as another piece of evidence that the re-entry heating physics model is actually working the way it should.

Unfortunately, 3D modelling is outside my area of expertise... It is its own specialty. I just make the programs that "make things go"... The 3D models have to be drawn and textured by people far more artistic than I am. They then compile their models into a format that can be used by KSP. The emissive animations that I mentioned above are compiled into the model at the same time.

That would be great! But he can actually already do it if he wants... All he'd have to do is create an emissive animation for his aeroshell model. He can set it up so that the animation "plays" from cold to hot. He then just needs to set the "HeatShieldHeatAnimation" parameter in the aeroshell's part.cfg file to the name of his animation. The current value "Heat" is the name of the animation in Dani-Sang's heat shield part that is supplied with my module. My module looks for an emissive animation with the name specified in the "HeatShieldHeatAnimation" parameter. It then figures out how long it is and scales that length to the temperature range. It then just displays the animation, frame by frame, depending on the temperature.

@Olsson: Can you post an image of your spacecraft? Or maybe even the .craft file? It sounds like you're using the re-entry plugin in another heat shield model. The logic currently expects the shield to stay attached to the command pod. I might need to change that if more people are installing it on parts that drop away (I can think of how to do it, but I'd need to try it). @Sbowyer28: I did a bit more work on the module last night (I exposed an "AllowableHeatDamage" parameter so that it can be set in the part.cfg file), but there's nothing to test yet. I am waiting to see Moach's changes before I release another version.

Check out Closette's Mini-challenge: max altitude with this supplied spacecraft. The conclusion there seemed to be that climbing at terminal velocity is about optimal. Achieving this profile requires a fair bit of throttle modulation during the climb. Also, check out the Optimal Ascent Profile for this spacecraft challenge. Both of these challenges pre-date v0.16 so the stacks won't perform the same way anymore, but the conclusions are still valid.

I like role playing. I have yet to fly to any of the new planets because I am trying to learn as much about their orbits as I can before I launch any missions there (thanks, but I don't need any tips). I want to reach them the most economical way that I can, the first time I try. Public support for my space program would dry up if there were too many tragedies, mission failures, or if the program were to become too expensive.

Thanks for trying! The flame effect is just an instance of the game's built-in particle emitter. I am surprised that it isn't visible for you. Could it be something about your installation, video card or maybe even operating system?

Hmmm... What warp were you using? What did you set your periapsis altitude at? What if you try, say, starting from a LKO in the 80km to 100 km range and lower your periapsis to somewhere in the 25-35 km range? It shouldn't make a difference if you enter in real time, but what if you re-enter at 1x time warp? Does that make a difference? You should see a plasma trail comparable to that of the video on the first page of this thread if you re-enter this way. If you still don't see any re-entry effects, then there must be some game setting or video card issue that is preventing the smoke effects from being displayed?...

I noticed that when I was developing the re-entry heat physics model. It is one of the facts that I used to check my work. It gave me some comfort that the values calculated by the current re-entry heat physics model that is used in the module already agree quite well with this. You can set the "DisplayHeatShieldUI" parameter to "True" in the heat shield's part.cfg file if you want to view the shock temperature all throughout the re-entry. Also, you may want to have a look at the the Re-entry Heating Model thread, over in the General Discussion section. This explains the current re-entry heat physics model in detail. I guess the question then becomes, do we use a physics model that has at least some physical significance and basis in aerodynamics & thermodynamics, or do we just fudge it? I prefer to stay with the physics model currently used in the module because it isn't just based on a rough rule-of-thumb. This allows re-entry effects to be varied somewhat realistically for different planets, merely by changing one or two constants in the model. The model will then respond according to the properties of the atmosphere that exists on that planet. That is the way it works right now, with the exception that gamma and the simplified heat transfer coefficient are the same for every planet/moon with an atmosphere. And as for making this module work with other heat shield/aeroshell parts, maybe the best way to do that would be to expose the HEAT_DAMAGE_LIMITS constant as a parameter that can be set in the part.cfg file. Heat shields and aeroshells that are designed for higher speed re-entries could have higher heat damage tolerance, maybe with a corresponding weight penalty to maintain some play balance and challenge.

I am happy to hear that my bug fixes have improved things! I was aiming to deal with the "show stoppers" so that people newly downloading the mod would have a more positive first impression. This will buy time to work on polish and solving some of the remaining nuisance items... @Moach: Sounds like a good idea. I look forward to seeing what you come up with. @DasPenuin85: The module is structured so that it can be used with any heat shield part that has a built-in heat animation. Just develop your 3D model and include an emissive animation. There are tutorials on this forum for how to do KSP compatible models and animations in Unity3D. Configure your animation model so that it "plays" from coldest to hottest. I just display the animation frame by frame, depending on the temperature that I calculate for the heat shield. Use my module’s "HeatShieldHeatAnimation" parameter in the part.cfg file to set the name of your heat animation. Also, MrPwner is working on a transparent texture for emissive animations. It is an impressive bit of work because, as far as I know, it has never been done before with any other mods in KSP. When he gets it working, he will add a transparent detached shock effect to the plugin. @Tommygun: I like your suggestion but I think the way to deal with parachute damage is in the parachute module itself. Parachute parts could have a parameter in the part.cfg file that sets the rated opening speed. Open it above that speed and it takes damage. If this were handled in the parachute module, then I wouldn't have to apply my cludge to destroy parachutes that open in the middle of the plasma trail... @Subsidal: I will add this to the list of bugs. I suspect that there's an additional function that I need to call to end the mission when I destroy the spacecraft.

Updates: 1. I've posted a new version of the plugin (v1.0.17.02) over on Kerbal.net. 2. I have posted a video in the first page of this thread, showing this re-entry module in action. 3. I've updated the Q&A section in the first page of this thread. Hopefully these will, collectively, help solve some of the issues people have been experiencing.

I expect it will be more efficient. I am happy to have Moach's input on this project. His obvious expertise and his direct connection with HarvestR make him an invaluable resource. I am sure he can improve it in ways that I couldn't do on my own.

Can you please run your changes by me before you post a new version of the module? Feel free to ask HarvestR to get you my e-mail address from the forum member's database if you don't want to enable PMs on your account. I am happy to work together with you on improving this part module. Some of the changes that you are thinking about are already on my list (i.e. making the heat shield work as a decoupler) while other "problems" with the module are probably just issues of tweaking play balance. I expected that some changes would be required before the module was finalised. In fact, that is why I haven't made the plot showing the survivable re-entry corridor vs. re-entry speed yet.