Starwaster

RO has builtin overrides for DRE's gforce damage. It's sort of based off real life values for humans to the extent that I could apply them to KSP / DRE game mechanics. The short of it is that humans can withstand horrendous g-forces for short periods of time. Doing 6 Gs for few minutes poses no problems if you are trained to withstand it. (assume all human and Kerbal astronauts are). I arranged it so that you could withstand 6g for ~12 minutes and 10g for 1 min. (measured as the game measures time; remember that 1 minute of real time is often going to be less than 1 minute of game so go by MET display)

No. It never shipped with an IVA

Pinging @NathanKell to make sure he sees this. Both modules have GetModuleMass(). Just a thought but together they're both shaving some mass off. If we can detect that TS is installed, maybe not factor in the base tank cost and only use the mass of the individual TANK...? Those resources exist as Oxygen and Hydrogen and are boiloff products if some sort of surge or sump tank is present. At some point in future I'd like to maybe do a virtual resource request against the ullage gas... (currently boiloff product is ONLY done on ServiceModule parts because it does deduct from the boiloff mass which is used for ullage control) I'll look at it later, going to eat now.

That's normal. Crew will be able to enter the part once it is inflated.

Who the heck knows? As @raxo2222 says, your posts are a little vague and we're not telepaths with the ability to divine the problem remotely. But I do know this: 6.4 is not RSS even if it is linked to on the first page. It's a separate distinct mod. So delete RSS entirely if you haven't already done so prior to trying to install 6.4 Then take any 6.4 related problems to the thread for 6.4 (link below)

Thanks for the feedback but two things: There's not enough information in your posts to go on. Real Fuels does not itself modify any engines by itself. That would necessarily be done by another mod / set of configs that that you have installed. If you upload your output_log.txt file or player.log (if Linux/Mac), post the link to where the files can be downloaded I'll take a look at it and tell you where that's being done. (More than likely, the person(s) responsible for the mod that applied RF configs to your engines and/or tanks would need to fix their configs) For uploading logs I recommend dropbox. No screenshots of portions of the log either. Actual log file. Thank you!

The only thing I see any point in addressing here is the clamshell issue. Easy enough to correct. @PART[*]:HAS[@MODULE[ModuleProceduralFairing]] { @MODULE[ModuleProceduralFairing] { %useClamshell = True } } As for the rest, sorry, but claiming opinions as fact is erroneous; the final sentence in your post was rather ironic in that regard.

From Nuclear Thermal Propulsion (NTP): A Proven Growth Technology for Human NEO / Mars Exploration Missions http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20120003776.pdf page 9 Material: Aluminum-Lithium (Al/Li) Tank ID/OD: ~9.8 m/10.0 m Tank L: ~19.7 m (propulsion stage) – 22.7 m (“in-line” drop tank) Geometry: cylindrical with root 2/2 ellipsoidal domes Insulation: 1” SOFI (~0.78 kg/m2 ) + 60 layers of MLI (~0.90 kg/m2 ) In LEO that resulted in ~78 W of heat flux penetrating the tank. (heatConductivity = 0.0039 would work I think...) If you need more or less insulation it gets more complicated than I have time to type out right now, so more later as needed

I know what error you're talking about and no, it's not crashing your game. It's just a message posted to the log by Module Manager saying it couldn't apply that part of the patch. (and later it will also report that it didn't write out the cache because of that error) If you tried what they said and it didn't work then either you applied the fix incorrectly or something else is wrong besides what you reported earlier. It's impossible to say which without knowing exactly what the error is this time.

Hurrah for you. I don't have that issue either. That doesn't change the fact that there's people who for whatever reason effectively can't use the mod. Also the periodic pleas for help from people who still don't understand how PFs interstage works because they don't know what to do about the two top node system or because they think they have to use two base parts to do an interstage. (A situation not helped by otherwise knowledgeable and experienced veterans telling them you do need two base parts)

Making interstages is easy. I can do it consistently every time. Though I can definitely see the attraction in making fairings that are ridiculously huge, Squad apparently decided to put reasonable limits on fairing sizes. That's not hard coded though, it's a question of configuration. in the part's cfg file. On the downside for the PF mod, have you checked that thread lately? There's quite a few complaints about buggy behavior with fairing stability, especially when using (but not limited to) the autostrutting feature which has been bugged for quite awhile with no fix in sight. Sorry, request denied The remains must now be re-burned back down to ash and the ash burned again with chlorine trifluoride. (a chemical that has been described as being able to burn even things you would normally consider burned to hell and gone - Also being able to set fire to glass, asbestos and test engineers)

FYI, Deadly Reentry doesn't handle that sort of thing anymore. Stock handles the application of all reentry heating and determines whether or not a part is shielded by another part, unless you're using FAR. For stock, it doesn't look like the drag data changes when RC parts are resized, just going by the physics data available in-game. (referring to drag cubes here) FAR has its own way of doing things... I think it recalculates for size changes though.

No, if you defined a custom drag cube, it uses that cube as is regardless of rescaling. Yes, rescale factor causes cubes to be rescaled (except for customd drag cubes)

It uses the cube you created for it

Depends. If you cloned the part then yes it will create new drag cubes for it. If you're modifying an existing part (including new parts that KSP has previously rendered cubes for) then the part database might not be updated to reflect the new change and I'm not clear on what circumstances that can happen under. Sometimes PartDatabase.cfg needs to be deleted so it can rebuilt. (declaring a part as having procedural cubes definitely seems to force an update...)

It ties into the method used for simulating axial tilt. Due to KSP limitations, we can't give each planet its own custom axial tilt. In fact if you look at Mars you will notice it has no axial tilt. Its equator is in the wrong place That's the case with all of the other planets, so axial tilt is simulated by playing with orbital inclinations. Individually, you will find many such cases (all of them really) where the individual inclinations look wrong but are actually simulating axial tilt with Earth as the primary reference point. Compare their relative inclinations to THAT and what the relative tilts would have been and you'll find it makes more sense.

Not surprising you never heard back on your problem. You alluded to the existence of a log file that might have helped someone to troubleshoot the problem and craft files that when loaded resulted in the problem occurring. But you didn't provide any access to any of those things.

You're travelling at Mach 5.5, faster than an SR71 Blackbird. Convection heating is normal. Even if you are 10km higher than the Blackbird. Fast enough to blow you up? I dunno. Maybe. I assume that's why you mentioned turning on the max temp cheat. What part fails first? And at what temperature?

Going sequentially.... key 10 becomes the 2nd key after you delete 2nd key.... not sure how MM handles that. Try reversing the order of deletion.

I think the actual resource originally asked about was AF-M315E which is a liquid. (HAN is only one of its components)

Why not this?

You CAN turn off the limited ignition system but... it provides some added challenge. With every burn it becomes important to make sure you get it right and also to make sure that it's what you wanted before you start the burn too. Some engines allow for alot more burns than others, like OMS engines. Nuclear engine allow effectively unlimited starts requiring only that you be able to pump your propellant into the engine. Ion engines I think are also unaffected

Basically it's a flat boiloff rate independent of actual heat flux. With a flat electric charge rate to counter it. RF has boiloff based on actual incoming heat flux with rate being affected by the insulation on eac tank type. Final penetrating heat flux is then applied to the resource's heat of vaporization. Boiled off resource carries heat away with it. Next update, the boiloff byproduct can be stored as a gas if you have a tank to receive it.

Sorry, I thought you were talking about Real Fuels. What I said only applies if you have RF installed alongside of PF. Cryo Engines has its own boiloff code and LH2 resource. I have no idea how it interacts with RF.

It's as simple as changing the type on the tank. Just right click the tank (in the VAB or SPH) and there is an option to change its type.