NathanKell

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.

@coolguy8445 There can't be a standalone because we just use models and then rescale and repurpose them. What you probably should do is (either yourself or with others) make a mod that sanifies KSP electrics. For the parts with their KSP purposes, not "this little piggie is now a Surveyor probe core, and this little piggie is Mariner" and so forth. @Wallygator I...have no idea what you mean. They're fine in RO, that's what I mean. If you have a problem with stock, you might want to talk about it somewhere other than the thread for the not-stockiest of mods.

@coolguy8445 the issue isn't the solar panels (they're sane for their mass, albeit not their size), or the batteries (I mean, they have hilariously low capacity but whatever)--the issue is the consumers. They're all over the map. Pods use *no* EC, for example, unless they're torqueing, but probes use a lot...but then so do lightbulbs! You'll need to handle that, which has to be done on a part-by-part basis, for EC to make sense.

Yep, happily @soundnfury is working on a UI for maintenance. For retirements...what do you suggest? Should we just not have the retirement popups? Certainly you'd want one when you hire a crew member, I'd think, unless you want to manually look at the tooltip, and certainly you'd want one when someone retires?

Guilty as charged, yes.