Starwaster

No it's not a bug, but you're free to do whatever you want to your own installation.

Except that it is loss because the system doesn't produce a gaseous version of the resource and fuel cell consumption is going to outstrip boiloff loss anyway.

Nope, still missing. if you see it, please tell it to come home and all is forgiven.

It won't??? oh dear. I wish someone had told me so that I wouldn't have used it with 1.0.5 for the past month and a half I guess now I have to uninstall it. That's a crying shame because this whole time I thought it was working.

I don't agree. There's no need for separate modeling and it can be approximated just fine in the existing system. I only need to know the Q between tank surface to interior.

Since the ablation rate itself has been questioned repeatedly, @lajoswinkler, and you also question everyone else's knowledge in the face of some perfectly reasonable answers, I have to ask: how much do YOU really know about shields? You seem to think the rate itself should be much higher but do you know how much they really ablate? I thought I did until @NathanKell and others pointed me at some literature on Apollo that indicated that the actual amount of shield that was ablated away was less than 1/100th of what I thought it should be. That's why the stock shields have such low ablation rates. If you want higher ablation rates, install Deadly Reentry. I intentionally (and extremely unrealistically) increased the ablation rates in order to keep players on their toes and sweating into their keyboards.

Heat shields have maximum heating rate that they are qualified for. That's in real life that I'm talking about; in KSP that's not something that's hard coded into the shield or exposed to the player. But if it heats up faster than the ablator can keep up with then it can fail. Again, in real life, that's the sort of thing that has to be taken into consideration when planning a mission and deciding how to design the shield and what kind of reentry profile it will fly. Not sure what you're trying to say there above. Do you think the shield shouldn't heat above the point at which it starts sublimating? If so that is WRONG. It starts sublimating at 400 and continues increasing. Apollo's shield peaked at about 2750 C. You also say it still had all its ablator on it? That's not even plausible unless you're hitting a bug that causes the shield to not ablate at all. Or you're exaggerating and think that the amount of ablation you're seeing isn't enough. If it's the former and you really are seeing no ablation at all then you need to move this to the support threads (modded or unmodded as appropriate). If it's the latter then I'm sorry but your expectations need adjusting.

As mentioned previously, scale is an issue as well as balance. The more balanced a shield is for Earth, the more overpowered it would be for Kerbin. That said, looking at the config for stock shields, 3300 K is a pretty reasonable temperature for an ablating, charring heat shield. Bottom line is that it is your expectations that need resolving. If you can't survive an Eve reentry then you're doing it wrong. Modify your approach until you find a solution that works. Venera might have been steep but it was still enough of an angle for aerobraking to come into play so decrease your reentry angle.

Or how it's even possible...

Yes, it is a magic material called 'vapor cooled shielding' which is (more or less) a high tech version of a thermos bottle. That's essentially what they used on Apollo in the service module for the LOX and H2 tanks. The conductivity is expressed as W/(m K) btw. (watts per meter thickness per degree Kelvin).

Use service module tanks for the parts making the actual trip to the moon. That's what you should store fuel cell LH2/LOX in. (There are currently no technical limitations on using that tank type anywhere for any amount but realistically it's only suitable for smaller tanks)

That's because you right clicked it. If I want a right click I'll say that Behold! You do it like this. Hover the mouse controller over the hatch. This works for every part that has a proper hatch (and the FLAT does) When you're in the right place it will say on the screen 'Crew Hatch' Left click while it says 'Crew Hatch'. A menu will appear that has the part's name + Crew (so the FLAT will say Inflato Storage Container F.L.A.T Crew) The menu will list each crew in the part and the buttons EVA and Transfer. If you want to put the crew member on EVA then click the EVA button. If you want to move him/her to another habitable part then click Transfer and then when prompted, click the part you want him transferred to. (valid destinations are highlighted in blue) The reason you must do it like this is because the FLAT does not have an IVA. No IVA means no internal camera and no seats so no crew manifest in the lower right. This has always been true for every habitable part that lacks an IVA. It is known.

Has anyone encountered issues when using this mod with Dynamic Deflection mod? (consistently and that aren't present unless Dynamic Deflection is installed) (Dynamic Deflection dynamically scales deflection based on dynamic pressure. The greater dynamic pressure is, the less controls are allowed to deflect) Also, does anyone have any effective PID settings they might want to share? (for preventing unwanted rolling, yawing or pitching or that work well with engines that have long spool up times)

BTW folks, a good example of 'jinkiness' here would be having your radial thrusters on backwards... and directing against the hull of the ship. That seriously impairs the thrust. I think it even cancels it out entirely. Should be based on angle, not sure it is but whatever; if you have the impellers pointing against your ship then they aren't gonna work. (that's always been the case with engines in KSP)(except RCS)

He didn't disappear. If you want to extract him: click on the hatch and then click EVA on the menu that appears.

Don't exit to space center if the ship is about to begin reentry. It goes 'on rails' and does not have physics applied therefore drag / aerobraking does not occur. Since reentry heating is partially dependent on atmospheric density, if you wait until the ship is low in the atmosphere it is natural and to be expected that it will be traveling at unsafe velocities. Your reentry angle has to be like Goldilocks and the Three Bears. Just right. If you're coming in to steep your heating rate may be too great resulting in explosion. If it gets even steeper the opposite occurs where although the heating rate is extreme it doesn't last long enough to be a problem. However, then you have a new problem where you are coming in too fast and don't have sufficient aerobraking to arrive at a safe speed. A shallower reentry is needed. HOWEVER, if you go TOO shallow then you burn up your shield before braking enough to drop into the lower atmosphere. ~20-30km is a good target periapsis in most cases. Your 'minor' problem: Not enough information!!! Read this thread: http://forum.kerbalspaceprogram.com/index.php?/topic/83212-how-to-get-support-read-first/

But you are gravely mistaken. The engine is NOT stowed. Build that configuration as depicted and you can activate the engine to your heart's content.

Possibly a long standing stock bug that I coded a work around for and then removed thinking it was no longer necessary. Or actually, the code is still there but disabled.

Something something CKAN version (an unsupported release) something something.

Ok, going over the Animated Decouplers code and I think when I put in the wait for animation delay that I coded the logic in such a way that it won't play the animation if waitForAnimation is False. I'm doing a small overhaul, probably have a release out tomorrow or the day after.

Having trouble drafting a reply... grrrr. Have you verified that animations are actually happening and not just decoupling? Please double check that

Correct, Alt+DR was removed awhile back.

I don't know then. Something else must be interfering because it does work. Doesn't matter though because you're not missing anything right now as the button only goes to a placeholder menu. Nothing there except a really cool picture. Edit: Also, you're not looking at the Blizzy toolbar are you? That's never been supported.

No not related. Everyone using the last few versions gets that error; it doesn't actually affect the button because other code ends up initializing it. Delete your entire DeadlyReentry folder (from GameData) and redownload: https://github.com/Starwaster/DeadlyReentry/releases/latest Install and try again.

Yes, it's because of the menu code that I need to update. The error hasn't been seen to be harmful and once I get around to fixing the menu (putting a real menu back in) then the error will go away.