NathanKell

IIRC, CB's GetTemp just gets the base temperature from the temperature curve (i.e. evaluate that float curve by altitude). You want CB.GetAtmoThermalStats(). It gives the offset to the (base) temperature at altitude, given a bunch of inputs. It calculates that offset by getting the dot product between the polar axis and the sunward vector, the latitude (acos of dot(upaxis, body polar axis) ), the sun's minimum and maximum height above the horizon given the body's position in its solar year (this is obvs less meaningful for stock with its lack of axial tilt ). From that it figures out how much of a day is in sunlight and how much not. It corrects max daytime temp to ~3pm (for a 12hr day--whatever ) since IRL max daytime temp is not at noon, but later (as more energy gets absorbed). Basically all that figures out a "normalized value" between minimum daily temperature and maximum daily temperature, which is used to multiply the offset given by the latitude sun mult curve, and the seasonal variation is added in (evaluating the sun bias curve), and finally eccentricity is taken into account if that curve is defined. The function also figures out how much flux is coming from the body if you're in orbit, but that's not what you're asking about. That's all I recall.

@R-T-B Yep the EC generation is all in post. The rest of the calculation is setting the angle and determining LOS (Solar Panel also overrides the LOS step to do some raycasts, but it only establishes what the blocking part is, it doesn't generate EC). Happy to help!

@R-T-B can you subclass from solar panel and then override PostCalculateTracking. Set a flag before you call CalculateTracking, and in PostCalculateTracking() only call base() if the flag isn't set, then after your call, set the flag back to false. Hacky, but should prevent EC generation when you call CalculateTracking but still do so when the module does its own thing. (to be clear, EC generation is done in PostCalculateTracking)

@OhioBob great to see you again as well! I've been pretty much detached from all things Kerbal for the last year and a half, and mostly-detached for a couple years before that. Things are well though! Hope same for you? So...I went digging a bit and saw this in physics.cfg: solarLuminosityAtHome = 1360 // Solar flux in W/m^2 at the orbital altitude of the homeworld First, I screwed that up, it should be irradiance. But anyway, that reminded me that solar panels actually hijack the flight integrator's thermo code (which has to calculate solar flux at the vessel's current orbital altitude over the sun) and I htink *that* code uses raycasting in scaled space, which is liable to have float precision issues. So that might be the cause of your offset. (I believe I did test this that in orbit of kerbin the solar flux is reported to be 1360W/cm^2 so I don't think there's an alt/sma mixup after all.) That it lines up with alt/SMA I can't explain. But that allows me to answer your question about extinction. I think I hacked it (hah, surprise). Something like estimate the mass of air light will be traveling through (well, one scale-height's worth, IIRC), and then get a relative factor comparing atmospheric density at sea level on your current body vs on Kerbin, and multiplying the reciprocal of that with a "how much gets to ground on Earth, cough Kerbin" factor set, like solar luminosity (ehh, irradiance) in physics globals. I don't recall the specific numbers, sorry. It's all about taking straight up to the sun through Kerbin's atmosphere as a baseline and then trying to figure out how much extra air there would be based on solar angle and extra atmospheric density / higher scale height. Did find something that reminded me of what site I used to set up the temperature curves. The data points I used were: 4k 1.2x; 300k 1x; 1200k 0.134x; 1900k 0.02x; 2500+k 0.01x

@Arrowstar @OhioBob That...sounds about like what I wrote there, yes. I have no idea if it's been changed since. It's taking the dot product of the panel's up vector and the ship->Kerbol vector, dividing by (alt/ref_SMA)^2, and that's the output. If the raycast from the panel's suncatcher transform hits any collider on its way to the sun, the panel is counted as "in shadow" and provides no charge. However there's also two other aspects involved, it's coming back to me now. First, the panel's temperature. There's a floatcurve in the PART config that determines a multiplier at a given temperature in K. Evaluate it as you would any other floatcurve. EDIT: Uh, if it's not there, you probably have to empirically determine it, I might've set default values in code. Or ask a friendly current dev. Second (although IIRC stock doesn't use this, only RO) there's a multiplier based on mission time to support panel degradation. If there's no mention in the cfg file, assume it's not used in stock.

Yeah, I did some work to make the previously internal-only Kerbal Part (code-side) work like other PARTs. That is it would pull its PartModules from cfg and support adding/removing PartModules and changing PartModule values in cfg. But there was a whole lot bound up in the prefab, linking the asset and the Part, such that only the gameplay side is really easily moddable. Me and @Porkjet had a dream at one point to put real humans in, but we never got to it before we moved on. Man, takes me back.

@FreeThinker density. @Arrowstar flux is (calculated external temp - skin temp) x coefficient x the global convection constant and yields watts per square meter. That is then multiplied by exposed skin area and applied to the skin thermal mass. All constants are in Physics.cfg

@FreeThinker Nope, barking up the wrong tree. Heating is proportional to sqrt(rho) * v^3, not rho * v^2 (the latter being dynamic pressure). What's actually related to dynamic pressure is those cool swirly visual FX you see. @Arrowstar sure thing. So, in the simple case (let's assume nothing is occluded), then the hypersonic convective coefficient is: 1E-07 * MachConvectionFactor * (density ^ MachConvectionDensityExponent) * (velocity ^ MachConvectionVelocityExponent) EDIT: Oh, right, and the sqrt is ignored if density >= 1, so it's really (if density > 1, density, else sqrt(density)). Uh, since MachConvectionDensityExponent is presumably still 0.5, unless y'all changed it while I've been gone. HOWEVER. Two caveats. First, if you get too low while going too fast, we have a "pseudo-Reynolds number" that punishes you for doing so. If that gets too high, your convective coefficient spikes because you're in turbulent flow. Second, occlusion does weird things--the above math is only valid for the frontmost part, and behind that you're inside the shock cone and both area presented to the heating, and the effective shock temperature, get decreased. (And by "some work" I presume you mean "done wrote it" -- again, unless it's been rewritten since. ) If you want the entire thing all the way down, there's some general multipliers too, like the general convective constant, the part's convection multiplier, the part's exposed surface area, etc. Oh, and the above yields watts (like any sane formula would) and we convert to kW because KSP masses (and thus thermal masses) are in tonnes. ARGH, hopefully last edit: don't forget radiative heat. I've talked only about convection, above, but for fast reentries the radiation really matters too. We lerp between the full shock temperature and space background radiation based on a "density thermal lerp" calculation that involves the atmosphere's adiabatic index and the mach. That's fairly complex, and has some empirically-determined piece-wise bits.

You have perfect timing, @Bornholio! By reversed, you mean how the mission and expiration stupids are reversed? That's correct because the expiration should decrease the stupider the kerbal, and the mission training time should increase the stupider the kerbal. Both feed into lerps of (min, max, stupid) which linearly interpolate between the given min and max values based on the input stupid value (where 0 results in min and 1 results in max). Unless I misunderstand what you mean.

@linuxgurugamer hmm. @rsparkyc did the updates to 1.2. Not sure his plans for 1.3.