# NathanKell

Members

13,276

1. ## How does KSP compute aerodynamic heating?

@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
2. ## How does KSP compute aerodynamic heating?

@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.
3. ## [1.2.2] Realistic Progression Zero (RP-0) - Lightweight RealismOverhaul career v0.54 June 15

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.
4. ## Realism Overhaul Discussion Thread

@linuxgurugamer hmm. @rsparkyc did the updates to 1.2. Not sure his plans for 1.3.
5. ## [1.6.1] Realism Overhaul v12.7.2 [17 July 2019]

@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.
6. ## [1.6.1] Realism Overhaul v12.7.2 [17 July 2019]

@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.
7. ## RO/RP-0 Development Branch testing

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?
8. ## [WIP][1.5.1, 1.6.1, 1.7.x] Principia—version Fibonacci, released 2019-09-28—n-Body and Extended Body Gravitation, axial tilt

Guilty as charged, yes.
9. ## [1.6.1] Realism Overhaul v12.7.2 [17 July 2019]

There is indeed a catastrophic bug with RealFuels right now.

11. ## [1.2.x] [1.4 in Development] Real KSC in KSP Dev Continued

@Tristonwilson12 do I understand correctly that right now RealKSC uses a mesh terrain item? Or do you have a mapdecal? If your terrain is from a mesh, I highly recommend replacing the mapdecal's blank heightmap with an actual Canaveral heightmap to let PQS handle all the terrain natively. MapDecal is notionally for having local heightmaps that override the global heightmap, but all it's used for on Earth right now (and Kerbin one presumes) is to flatten things.
12. ## No longer maintaining

@Crzyrndm sorry to see that but I get how life goes. Bestest best wishes! As to pwings, DYJ let me update the license when I took over, and I believe it was to CC-BY-NC (and possibly -SA as well).
13. ## [1.2.2] E.T. - Extreme Textures (RSS)

@ufindbatman ah I can help there! KSP *always* runs in DX9 mode in Windows unless you force DX11 mode. You can also force OpenGL mode. On Mac and Linux of course you can only ever run OpenGL mode no matter what arguments you pass to the executable. Best wishes to you!
14. ## [1.2.x] [1.4 in Development] Real KSC in KSP Dev Continued

So, finally trying this out. However, it looks like the default KSC position is well clear of anything interesting and, worse yet, for me it looks like the main heightmap is interfering with the RealKSC terrain. Has anyone tried replacing the heightmap that the MapDecal uses with a real Canaveral heightmap?
15. ## [1.2.2] E.T. - Extreme Textures (RSS)

Hadn't heard of this until now, which is bad. I'm wondering--why is there a DX11 requirement? Just to lower system RAM usage, or does something actually depend on it?
16. ## [1.3] RealEnginesPack v1.8 OMS and Apollo engine release. 22/07/2017

@Alcentar awesome!
17. ## [1.7.3-2 + Backports] Kopernicus & KittopiaTech

@Sigma88 for some reason, sometimes it creates the log in %appdata% ( search under that for output_log.txt ). @OhioBob hit windows+R and type in %appdata% and hit enter. Then hit ctrl-F and type output_log.txt and hit enter. That should find it. I hope. (In particular, it's in the Kerbal Space Program folder in Roaming appdata. I *think*. It's been a while since I've seen that happen.)
18. ## [KSP 1.3.1] Stock Size Real Solar System [0.0.3.1]

@Tyko as of 1.1 you can write your own date/time formatter, so as I said if mods are smart and use KSP's own date/time formatting, then you can have whatever days you like. RSS takes advantage of this to add months and have proper (1951+) year display. https://github.com/KSP-RO/RSSTimeFormatter
19. ## [1.3] RealEnginesPack v1.8 OMS and Apollo engine release. 22/07/2017

@Alcentar the NK-33 and RD-275 are fixed! Awesome! But there's still an issue: while the actual vernier models on the RD-108 move correctly, the thrust transforms don't seem to be parented to the right verniers at all. Do test it ingame and try to roll, and see what happens: the exhausts don't move correctly in sync with the verniers, and no roll control is provided--the exhausts splay in and out instead of going side-to-side.
20. ## [KSP 1.3.1] Stock Size Real Solar System [0.0.3.1]

@Tyko I'm confused. KSP itself supports either 6h or 24h time, and RSS just sets the gamesetting during load. There isn't some way to set KSP to allow arbitrary time formats that way, unless (a) you replace DateTimeFormatter, and (b) all the mods you care about properly use it to format dates.
21. ## [KSP 1.3.1] Stock Size Real Solar System [0.0.3.1]

@TykoI have no idea about USI. But I can tell you RSS forces the time format itself in KSP to be in 24 hour days because, well, the days are 24 hours.
22. ## Analysis of the buoyancy of parts and how to improve things

My improvements were one of the parts of 1.0.5, yes.
23. ## Analysis of the buoyancy of parts and how to improve things

@Azimech did that, then scaled up water density by something like 50%. Because floating. If you (or @nhnifong ) want to play with that, there's a very obvious water density scalar in Physics.cfg (RO obviously sets it to 1.0). EDIT ok actually there was a reason--KSP parts can be *insanely* heavy for their volume. Part of the whole scaled-down universe thing. Not as dense as the planets, but denser than real life for sure. You can make a plane that looks like it would mass 5 tonnes in real life and it could easily be 25 in KSP. People just don't realize it. So in order to make water landings non-sinking affairs, we scaled up water density.
24. ## [1.3] RealEnginesPack v1.8 OMS and Apollo engine release. 22/07/2017

@Alcentar On the RD-108 the verniers 'splay out' during flight. I would say, just for every gimbal transform you have, align them with +Z down, and +X to the right (so -Z is aligned with the part's +Y, gimbal +Z is aligned with the part's -Y, and +X and -X on the gimbal are aligned with the part's +X and -X). That should solve all problems.
25. ## [1.6.1] Realism Overhaul v12.7.2 [17 July 2019]

@Galile-Ho the bug exists only in the editor. It does not occur in flight. So you're safe there. Your best bet is to remove all astronauts in the VAB/SPH during design and instead add 100kg lead ballast tanks surface-attached to the pod as mass simulators. That will give you accurate delta V readouts in the editor. Then at the end remove them and put the astronauts back. Their weights are fine in flight. I tend to prefer to use MJ all the time; KER has some weird staging issues and some issues with RO/RF and the changes it makes, so I prefer MJ, although the part tooltips are very cool. Yeah, were I redoing RF from scratch, I'd make two core changes: 1. No binary distinction between pfed and non, instead each engine would have a required tank pressure and you could set the tank pressure on a scale-bar and that would either work-or-not for pump-fed engines, or cap your chamber pressure for pfed engines. 2. Make ullage tank-side not engine-side, as you folks say. And thanks!