Starwaster

that's exactly what I mean. the resource trick was just the only way of doing it without going into the underlying code.

Didn't the NASA mod add that but scaled down?

You have two toolbar DLL's installed. I say delete the entire toolbar mod, download the very latest one from the toolbar mod thread (sorry, don't have the link handy) and install that. Don't ever allow a duplicate to be made and don't allow it to be overwritten unless you know 100% for sure that the one you want to overwrite with is the very latest. Non platform assembly: E:\Backup\personal\John\Software\KSP_win\GameData\000_Toolbar\Toolbar(1).dll (this message is harmless) Non platform assembly: E:\Backup\personal\John\Software\KSP_win\GameData\000_Toolbar\Toolbar.dll (this message is harmless)

If what I said was thought to be rude... O just you wait until the next time when I channel my inner John Larroquette.....

Yeah, I was practically tearing my hair out at the roots trying to get the KSO down intact without burning up. At one point it occurred to me that there was no way in real life those parts would be reaching those temperatures behind thermal tiles and if they did, they would be dangerously close to failure. (Columbia ) So this was a way to track tile temperatures vs part temperatures. Exact values need to be fine tuned still. I've been meaning to talk to you actually about maybe integrating that into the plugin itself and only when the shield reaches certain levels does some of it begin to bleed through to the part. Been to busy to do more than think about it though. (see first link in signature) Edit: Something else I've been thinking about is optionally using a value curve in conjunction with the direction vector so it wouldn't be so linear. And the heat protection could then extend past 90 degrees to configurable levels. (after all, Apollo's heat shield did provide some coverage to its upper surface)

Each shield has a direction vector which is compared with its velocity vector as a dot product. The dot product is multiplied by the reflection value and I think is also used with dissipation and loss. So if your direction vector is exactly lined up with your velocity vector then you have 100% of your reflection rating and ablation/dissipation values. If you're hitting it at a 45 degree angle then you're cutting those things by half. That's especially important for space plane type shields which instead of having ablative materials rely in increased reflection ratings. Typically that's 25% for non-ablative and 5% for ablative shields. BTW, that works ok mostly for ablative shields in Real Solar System, but not for 25% reflection only shields, at least not for heavy planes. I've gone as high as 98% and still had the shuttle burn up. That's why.... Oh, oops, actually that one says 180% which might seem extreme but I was expecting to get a 45 degree reentry pitch which means half protection which means 98% and it was still burning up. It's still a work in progress when it comes to RSS. (shuttle tiles btw supposedly reflect over 90% of incoming heat...) RESOURCE_DEFINITION:NEEDS[RealSolarSystem] { name = HeatCapacity density = 0.0 flowMode = NO_FLOW transfer = NONE isTweakable = False } @PART[super25rudderkso]:BEFORE[DeadlyReentry]:NEEDS[DeadlyReentry] { @maxTemp = 1500 MODULE { name = ModuleHeatShield ablative = HeatCapacity direction:NEEDS[!RealSolarSystem] = 0, 0, 0 // omnidirectional light shielding direction:NEEDS[RealSolarSystem] = 0, 1, 0 // forward standard shielding (only when playing Real Solar System mod) reflective:NEEDS[RealSolarSystem] = 1.8 // 180% of heat is ignored at correct angle (no, seriously. You have NO idea until you've attempted this in RSS with FAR) reflective:NEEDS[!RealSolarSystem] = 0.05 // 5% of heat is ignored at correct angle //adjustCollider = -0.015 loss:NEEDS[RealSolarSystem] { key = 650 0 0 0 // start ablating at 650 degrees C key = 2000 1000 0 0 // peak ablation at 2000 degrees C key = 6000 2000 0 0 // max ablation at 6000 degrees C } dissipation:NEEDS[RealSolarSystem] { // dissipation is based on the part's current temperature key = 300 0 0 0 // begin dissipating at 300 degrees C key = 800 250 0 0 // maximum dissipation at 500 degrees C } } RESOURCE:NEEDS[RealSolarSystem] { name = HeatCapacity amount = 3000 maxAmount = 3000 } MODULE:NEEDS[RealSolarSystem] { name = ModuleGenerator isAlwaysActive = true OUTPUT_RESOURCE { name = HeatCapacity rate = 0.2 } } }

If you want to save your maneuver nodes then get Kerbal Alarm Clock

Looks like the file in my dropbox didn't sync up. Try downloading it again. Starwaster's Deadly Reentry Config for KSO25 HOWEVER It's odd to me that you singled out the gear as not having AblativeShielding because none of the DREC configs that I've put out for the KSO25 use AblativeShielding. So either you're looking at a pre-existing shuttle or you didn't follow directions and have more than one DREC config for the KSO25. Read the following carefully: The DREC configs that I put out Must overwrite /GameData/KSO/FX/KSO25_dre.cfg Use only reflection when playing normal sized Kerbin (at 25% reflection value; 5% for the rudders) Provide maximum protection at 45 degree pitch up. (rudders receive their full 5% at any angle) Use 98% reflection when playing Real Solar System Also use a resource named 'HeatCapacity' which is massless and regenerates slowly over time when playing Real Solar System. Pre-existing shuttles will not see most of these changes because they use persistent data. Only newly launched shuttles will see the full effect of a new DREC config. That's outside of my control Edit: Also, about the s-curve's, what you're doing is rolling your shuttle 60 degrees to the side (I also combine it with 45 heading change to make I still have my optimal reentry angle lined up as close as possible to my velocity vector) so that lift from your wings isn't causing you to gain unwanted altitude or carry you past your landing site. Yes, I know it can be hard, especially when you're approaching max-Q and it insists on going nose down. At least try to keep your nose up above the horizon as much as possible. That sounds more like you're seeing malware advertising disguised as a legitimate warning of some kind.

So sad. a year later and still having to explain this......

Winner of the challenge has to do it again.... with Real Solar System and FAR installed!

Oops I forgot this part; that needs to overwrite the original file; it's not a patch for the original. Put it in /GameData/KSO/FX/

I dont think so. Or, if it does, it has no effect on docked craft.

Here is a Deadly Reentry config for KSO25 It is a multi-purpose config and requires Module Manager 2.1.5 as the one file contains contingencies for Real Solar System and stock Kerbin. https://www.dropbox.com/s/4j4r99yb1bjp8wz/kso25_dre.cfg needs to overwrite the original file; it's not a patch for the original. Put it in /GameData/KSO/FX/ Please provide feedback! Or I will resort to typing in italics! Using Comic Sans!

Ayana's is a few pages back; I'll look for it in a bit. Edit: That's what happens when you don't refresh page often enough. Or maybe I was composing that as she was pasting her link... The current DREC config is ablative shield based. It also has a typo that leaves the left wing unshielded. Mine is entirely reflective. It also has special configurations depending on if you're playing stock Kerbin or RSS sized Kerbin. The latter is very challenging especially combined with FAR. Even combined with 98% reflection I lost that shuttle several dozen times. I had to stick resource based shielding back in when using RSS. (not technically ablative since it's massless and represents the shield heating up. the resource regenerates slowly to represent cooling) All in all, a FAR+RSS is dangerous and leaves no room for errror. s-curve mastery is a must.

Fun trivia fact: Did you know that video games in Germany are not allowed to use ragdoll technology for corpses? Corpses must be static so that players cannot perpetrate violence upon them. Because of the laws pertaining to this, Crytek's Cryengine deactivates ragdoll on corpses after 2 seconds. (basically giving the corpse some time to settle into position and then lock it into place)

I've used Ayana's FAR configs and find them satisfactory except for the problem that center of mass is way too far forward of center of lift but there's no satisfactory solutions to that (when using FAR) except to move CoM backwards a few meters and downwards by (I think) a quarter of a meter. NOW then. On the subject of DREC, what of the configs I provided you? I'm still waiting on feedback on those. I use them myself and consider them acceptable. If you don't find them so, I'd have appreciated knowing that and knowing why. No feedback, no improvement.

I just suggested something similar in the Real Fuels thread..... if dangerous propellants (or MORE dangerous propellants as the case may be) are detected then random accidents are triggered.... ranging from simple sound effects to Kerbals animated to run around on fire. Yes, obvious wishful thinking is obvious. But if we could pull that off then it's not too much of a stretch to have Kerbals wielding firehoses and being whipped around by the high pressure.... it would be like the Keystone Fire Department!

I just had a thought of pure awesomeness. Let's make the VAB propellant aware. If you start building rockets with nasty propellants (chlorine trifluoride anyone?) then Kerbals in the VAB will randomly experience accidents. Sounds of explosion... panic.... if we can figure out how to control Kerbal animation we can have one running around in circles in the background with flame and smoke particles attached!

A bug definitely but not a Deadly Reentry bug. DREC does not affect aerodynamics at all.

Sky_Walker, do you actually understand what he just said before contradicting him? Fairings exist to reduce drag on a rocket. They would be useless in KSP unless the existing drag model is changed because they would only add weight and not reduce drag. It's not currently possible, under the existing stock aerodynamics model for nosecones or fairings to reduce drag.

Here's a tip I saw someone post recently for RT2: Put antenna and command pods on your lower stages. They can act as relays to Mission Control. It'll especially help in the early stages of a new RT2 game before you have adequate relays in place.

No you don't. the FAR file only gets applied if The FAR mod is installed. Unless you have an outdated version of Module Manager. MM is up to 2.1.5 - anyone who doesnt have it should upgrade.

I dont cant think of any, I dont usually use them. I dont have patience for tutorials. I've made them and I use a plugin from Nvidia for Photoshop. it takes an image and makes the normal map out of that. dark colors are low areas and bright colors are high areas

As others have said, you've been deploying too early. However, you also need to do something about your reentry vector. I typically do drogue pre-deploy at about 12km (give or take a few km). You have to have come in at an angle shallow enough to do a lot of aerobraking but not so shallow that you overheat. In your case it sounds like you need to be more shallow than you've been coming in. Also, @stupid_chris, perhaps some more robust presets for DREC use? (or a warning in the preset description that DREC reentries may require alteration of the presets). Maybe also some MM 2.1.5 style :NEEDS to provide alternate configurations if DREC is installed. (if needed, I could help with that)

Call me biased, but I'm liking that reflective tank. Can I suggest some normal mapping for it? Not something too extreme, but reflective textures really benefit from it visually.