NathanKell

I've been super busy recently, I'll try to take a look ASAP and make any RP-0 related whinging without delay.

FlowerChild et al, there's an interesting setting in ModuleAblator, reentryConductivity. I'm guessing the heat shield can determine when it's in use and switch its conductivity to that instead of the original conductivity. Might want to poke around and see when that comes into play, say making a module that on right-click displays the part's heatConductivity and see when it changes? Also, in Physics.cfg, it looks like the convection exponent is exposed for the "mach heating"--you might try a higher exponent than 3 (and a lower convectionFactor) if you want to try to tune up reentry heat. Thing is, though, recall that (a) spaceplanes are only 500m/s lower than reentry on ascent, and ascent takes way longer, and ( interplanetary trajectories can be in excess of 5km/sec, so if you make Kerbin dangerous via that exponent, better test 2.5x the reentry velocity too.

Yes! Also if they reentered at night, no solar flux. Also at higher latitudes, where it's colder. Keribn's equator is no longer 15C, it's 40C now during the day. Up north (or down south) however, it can get down to 0C (273K) or lower.

The number after the // appears to be the old maxTemp (0.90). // means to start a comment, in cfg (as it does in C-derived languages like C#) so everything after // is ignored.

Good stuff! Here's a bit more. Copied from other things I said recently: heatProduction is now scaled by the part's thermal mass (as well as the internal generation factor). So assuming the latter is 1 (it's not, it's something like 0.03) then heatProduction=1 literally means "this engine produces enough heat per second to raise its temperature 1 K per second". Yet increasing 0.02t of mass 1K means waaaaay less energy than increasing 6t of Mainsail. And that heat (the energy, not the temperature) conducts outward. emissiveConstant is the emissivity factor in the black-body radiation equation (flux in W = Stefan-Boltzmann constant * emissivity * area * temperatureK^4). It most certainly cannot be >1 (1 is a perfect black body). .95 is the "poor man's heat shield"--non-ablatively shielded parts, like spaceplane wings, have that, that means they radiate away heat very fast, comparatively. Default is 0.4, which is gray. Note that solar absorption appears to equal emissivity (this is why solar panels take in lots of heat from the topside as well as radiating from the underside). heatConductivity is per unit area of connection (connection area = the minimum of the facing area of the two parts). There's also a heatConvectiveConstant (in Part) although I don't think anything uses it yet. It defaults to 1.0. You can raise it to increase that part's convection rate, or lower it to lower it.

Nope, it's by entirely by mesh, does nothing with bounding box or colliders. What panzer1b's screenshot shows is a bug in the occlusion logic. The mesh seems to be broken down into six faces (it is called DragCubes after all) and the area of the mesh (vs a full face) in that direction is kept, as well as how rounded/tapered the mesh is in that orientation.

It appears to only be used by camera shake (to determine engine vibrations).

It's the latter, although not the best approximation of the latter. (It uses the "1 m/s = 1K" hack that DRE used to).

Yes. Mu made all GameVariables 's methods virtual, so you can create a child class, overload them all, and replace the existing instance.

heatProduction is now scaled by the part's thermal mass (as well as the internal generation factor). So assuming the latter is 1 (it's not, it's something like 0.03) then heatProduction=1 literally means "this engine produces enough heat per second to raise its temperature 1 K per second". Yet increasing 0.02t of mass 1K means waaaaay less energy than increasing 6t of Mainsail. And that heat (the energy, not the temperature) conducts outward.

emissiveConstant is the emissivity factor in the black-body radiation equation (flux in W = Stefan-Boltzmann constant * emissivity * area * temperatureK^4). It most certainly cannot be >1 (1 is a perfect black body). thermalMassModifier is a modifier applied to the standard specific heat capacity (as defined in Physics.cfg, default = 800kJ/tonne-K). Part thermal mass = part.mass * standardSpecHeat * thermalMassModifier * sum[for each resource](resource amount * resource density * resource hsp). heatConductivity is per unit area of connection, and does indeed default to 0.12. If you want to make a radiatior, you want high emissivity (although be warned, absorption = emissivity, so it will also be very good at absorbing solar radiation etc), high(ish) conductivity, probably higher than normal, and perhaps a higher than normal thermal mass (or perhaps not, because as you can see by the T^4 above, it's good to keep your radiator at high temperature to maximize outflux).

Perhaps silly question, but did you go to the Alt-F12 menu (Debug Toolbar) then Physics then Thermal and click "Show Thermal Data" ? That's how you turn in on.

Brotoro, while I 100% agree with you on NTR design, the same could be said of liquid engines. And yet they generate lots of heat in KSP too. At this point I'd say it's dev choice regarding using overheat as a mechanic, although re: the strength of the NTR's overheat, well, we'll have to see.

A thermometer's "temperature" is the temperature of that part. That temperature is based off convection with the atmosphere (if there is one), outgoing blackbody radiation, and incoming radiation (background radiation from space/the atmosphere, blackbody radiation from the body under you, solar flux, and reflected solar flux from the body under you). If the thermometer is attached to another part, that temperature is also modified by conduction. Note that a lot of factors go into that--radiative area, area exposed to the sun, area exposed to the body under you (and that body's radiative temperature and emissivity, and albedo), distance from the sun and the sun's angle, etc. All this means that any two parts, let alone a part and a kerbal, will have different resting temperatures even at the same instant in the same environment. The "external temperature" reported is the mean temperature of the atmosphere at that location. It is not part-specific. It is 4K (background radiation temperature) when there is no atmosphere. And yes, are in Kelvin, and they do vary by latitude and sun angle.

Ah. Then you might want to fix the craft before trying to reenter.

Depending on their area ratio and chamber pressure, bell nozzles 'lose' Isp at different rates. So the engines optimized for vacuum, well, their Isp falls off very fast. Sea-level-optimized engines with low area ratios (LV-T30) and with high chamber pressure (Mammoth) fall off slower. The aerospike has an altitude-compensating nozzle; it performs nearly-optimally (but not quite optimally) in all regimes, and so has the slowest falloff to near-zero thrust/Isp.

Pretty sure there was a thread about this about a week ago, actually. You're free to reuse and make derivative works using the assets in the GameData folder. With the power of MM, you don't even need to distribute the files (though if you want to distribute modified models/textures, that's ok too).

Like the real shuttle, reenter belly first, not nose first.

The jet engines most certainly were totally and completely unbalanced. They currently have, in 1.0, like 1/3 the Isp they used to and it's still nearly 10x what they have in real life. They also still have insanely high TWRs, even though that, too, has come down in 1.0.

As you can tell from Physics.cfg, and some ingame experimentation, KSP uses two convection models: 1. a Newtonian model, where convection is based on the temperature delta between part and enviroment and a heat transfer coefficient. The external temperature for this is calculated as the ship's velocity (which is true, ish, for Earthlike atmospheres between 300m/s and ~7000m/s). 2. a mach model (might call it hypersonic heating) where convection is based on velocity and density, and does not care about external temperature (indeed, it seems external temperature under this model is not computed, since it's still computed the "old" way). Instead, convective flux is directly calcutaed, going by the exponents in Physics.cfg as k * density^1 * velocity^3 * convectionFactor (40). Model 1 has a multiplier of 1.0 to heating. Model 2, by Physics.cfg, has a multiplier of 40. The bug here seems to be that a 'fake' external temperature for model 2 isn't calculated for you.

Doesn't respect decouplers. So it'll drain all your fuel

Kelvin. 10char.

Kelvin. 10char.

Click "edit" on the OP's post, then "go advanced". You can then change prefix.

Nope, top-heavy is good. When's the last time you saw a bottom-heavy dart or arrow?