Starwaster

No, if MODEL nodes are going to be used then rescaleFactor should only be set to 1: There is a long standing bug with rescaleFactor. If the vessel's root part uses MODEL nodes then rescaleFactor is applied twice when the ship is loaded in, aside from the initial launch. That is to say, when you first launch everything will look fine. If the ship is reloaded, the root part will be scaled incorrectly. Additionally, scale (outside of the MODEL node) should be left at 1 unless the part was originally modeled to a scale other than 1 unit = 1 meter. (or leave it at whatever it was set to in the original part file) (scale doesn't affect the part's actual size in the game at all. The only thing that does is rescaleFactor and the scale setting in MODEL)

I posted updates in the ADEPT thread and Deadly Reentry also patches it for compatibility. It could be rescaled easily enough to cover a larger area if someone took the time to do it properly There was a parts pack with a larger shield that would probably be suitable for braking a large ship but it's badly in need of an update. http://forum.kerbalspaceprogram.com/threads/12106-0-25-Lionhead-Aerospace-Inc-Icarus-v0-4-updated

This is pretty easy to implement. Samples are handled by a PartModule and PartModules can make use of an interface to add mass. I'm not sure how much impact it would actually have though given the scale of the universe and engine power and delta V requirements needed for orbit. (that is to say, for example, how much sample mass can you get away with adding to a Mun lander before its ability to reach orbit is threatened given the low thrust and low delta V requirement needed to leave) Edit: Oops I missed the part where you actually were dealing with specifics of mass in kg in what you're already doing.

They have too much mass per sq meter compared to real life fairings. I forget how much more but when the problem is corrected, they become much more valuable aerodynamically speaking.

Did you measure it? What are its dimensions? Is it 1 - 4 - 9?

No moreso than any other animated part.

That's not a reliability issue. That's a 'I don't feel like having to update every time this other mod I depend on updates' Welcome to the world of dependencies. Maybe using reflection would have served your needs better.

Try lowering Conduction Factor. From somwhere between 1.0 - 3.3

However bad things were, you just made them worse. Do not EVER delete physics.cfg Especially not ever. Download this replacement and copy it over your existing physics.cfg and do not ever delete it ever again. (maybe in KSP 1.1 a certain physics.cfg munging bug will be fixed but until then DON'T DELETE) https://www.dropbox.com/s/0qrtkf9altzb8r4/Physics.cfg?dl=1 After that, DO delete ModuleManager.ConfigCache in your GameData folder. Then run KSP. Feel free to test if you still have the problem but I may not have told you anything that definitively fixes your problem so next, you probably need to post your ModuleManager.ConfigCache file here. (host it somewhere like Dropbox and post the link)

ok, I think I get it now. The node is still hanging around in the database as some unrecognized malformed thing.

The context menu for each part will tell you how much convection heating a part is taking. (both the total amount of energy in joules and the maximum heating rate in watts) Right click each part immediately after hitting atmosphere and see what the different parts are taking. (if the heat is coming from somewhere other than convection heating then you'll need to enable the thermal debugging using alt-F12 for the stock thermal data) Edit: And about non-physical parts: Those receive reentry heating the same as anything else in the same manner as anything else. That's stock behavior. (the only time non-physical parts didn't receive reentry heating was in the early days of DRE)

As I understand it, the problem was in subnode NEEDS being treated as met that were actually unmet? As in: The following should fail for the RESOURCE? @PART[crewCabin]:NEEDS[Squad] { RESOURCE:NEEDS[asdfasdfasdf] { name = LiquidFuel amount = 32000 maxAmount = 32000 } } Because that's what I just tested out, and as expected, the RESOURCE did not get added and the log reveals the following when processing it: Looks to me like it's failing where it should fail.

Ok, what sounds strange here is that you shouldn't be getting convection heating on the capsule itself unless it's exposed. Are you able to keep the entire ship between it and the shockwave? And it's still getting heating?

Ok, I don't see anything abnormally wrong there, and the Base parts look about the way they do on my install. Though, like I said earlier (I don't know if you saw it) I do think the stock conductivity factor of 20 is way way too high, at least in light of the stock reheating issues. I think you ought to be dropping it down to 3 or so.

Be aware that lowering conductivity may solve this issue but it will also cause other overheating issues such as during reentry. Lowering conductivity is part of how the current incarnation of Deadly Reentry works. (by preventing heat from escaping the part) - - - Updated - - - Would you mind posting your ModuleManager.ConfigCache please? It will show all changes made by other mods (except for ones that make changes by plugin instead of MM config) as well as showing the state of your physics settings.

Instead of ablative shielding I'd suggest either doing it the way the stock game does it and increase thermal mass (using thermalMassModifier) combined with high emissiveConstant or do it the way Deadly Reentry does it with very low skin thermal mass + high emissive + low skin-internal conduction. (the DRE way emphasizes a very shallow shuttle style reentry that is punishing on reentries that are too steep) Either method avoids adding extra mass which is unnecessary in a space plane. However, if you still do want to do it as an ablative shield, I don't see anything wrong in your syntax above. That should be adding a shield and resource. So there's something else wrong in the config and I'd need to see the entire config to know what. Are you adding it to the actual part's config file or via Module Manager patch? If MM then make sure that you specified the correct name.

@Sashan, @Nils227 There is a stock heating bug that affects low mass parts. The exact mass is probably variable with surface area maybe being a factor as well. Certain build configurations with stock struts (okto, girders, etc) are prone to overheating. The issue is indeed linked to conduction and and the actual cause is probably math float errors. What happens is that that as heat is conducted between parts, the errors build up with temperature rising in the low mass parts as the heat oscillates back and forth. Masses of 1kg or less are at risk. Installations with Deadly Reentry should be mostly immune because the conduction factor is lowered to 3.3 (from a stock value of 20), so anyone having problems with overheating should lower conduction.

Do not delete your physics.cfg file, especially not ever. If you see other people suggest this in other threads, smack them and correct them. As to lack of reentry FX, I don't know, unless you've edited the DeadlyReentry.cfg file. I get reentry FX very shortly after the capsule hits atmo. FAR is another mod that affects physics so try updating to the latest dev version. Keep in mind that the Mk1-2 has no shield itself beyond what you added to the bottom, so make sure that shield is between you and reentry. You can get away with a pitch of no more than 14deg (if you go for a lifting reentry for example). More than that and the pod risks being exposed.

Moho having an atmosphere isn't realistic because the sun would blast it away. Which is probably why any atmosphere it had was removed in the first place. Laythe on the other hand.... what's wrong with that? Some of Jupiter's moons have atmospheres.

Well, these were my early days of KSP. I didn't have many mods yet. I think I had MechJeb but I might not have.... I'd found ModularFuelTanks (Real Fuels was just a set of configs for it back then) and a bunch of parts packs like KWR and some Bobcat parts. Real Chute didn't even exist back then, which really caused me problems with my Laythe rescue ship because after having a Kerbal clamber around the outside of this really tall tail lander perched on a 5% slope repacking chutes, loading up the refugees and then lifting off.... I discovered a bug in the stock chutes where launching the ship caused all the repacked chutes to immediately deploy. Hilarity ensued. And of course I had SAVED the game so they were all now saved in a repacked state ready to go off the instant I launched. Only the action group mod saved me by assigning each chute a 'cut' group so I could immediately cut them all.

Ahhh, the proverbial 'good landing'! Reminds me of my first big mission to Jool and using Laythe for aero braking. I botched it badly and even though I wasn't yet using Deadly Reentry my ship broke apart from stress. Barely got the crew into their escape vehicle so they could make a safe landing on one of Laythe's islands. Spent 3 real life days devising a ship that could land, rescue the crew then take off and reach orbit. Eleven parachutes to land an ungainly tail lander with 6 solid boosters. Good times...

2. They should cool down in space but they'd do it more slowly because in a vacuum, heat rejection is entirely through radiation. (no cool air to help) 3. As long as you burn up without the shields then you don't have a problem. Apparently (IRL) heat shields don't lose alot of their material in reentry, at least not Earth, Apollo style reentries.

The source already has code to emit fire and smoke when a part is on fire. He probably modified that code. (the current version does not have fire damage in; It's on my TODO list to add it back)

https://www.dropbox.com/s/u1lsj0byrtrllx3/KSO_25_livery_edition.dds.zip?dl=1

I don't know; I haven't used KSO much in awhile and haven't verified any change in functionality of those configs since sometime between KSP 0.90 and 1.0. So... probably it worked at least as late as 2.5.6 I'll make up some new test configs and watch the logs and see if anything turns up as well as verifying that there is an issue. But not until after I've had some bed and comatose time. (on a related note, I've been up all night with MJ2 and RCSFX and found a control input issue in RCSFX that definitely will hamper MJ2 no matter how much torque calculation you do. Tell you more later)