NathanKell

Just an FYI--Vernor is what Squad is calling the thruster because it's not a vernier thruster; a vernier is a type of thruster, Vernor is like Rockomax (a KSP name). Drooling after that JT8D.

Welcome to the forums! Not aware of one, sorry. Maybe someone else might know?

Optimally!? Good luck, people write doctoral dissertations on it. It's not a solved (let alone easy!) thing to do. For MJ ascents under FAR, however, see here.

Apologies that this release is so minor; I have been busy on other fronts recently. Changelog v7.4 \/ *Upgrade to ModuleManager 2.4.5. *metaphor: add pressure/temperature curves for Jupiter. *eggrobin: improve curves for solar panel power, Earth pressure and temperature. *Use compatibility info, now. Another public request: would someone(s) like to volunteer to help get the various launch sites fixed? They will need their height and angle changed to avoid the terrain problems that affect many of them.

Uh....no. The ingame memory textures in the Squad folder take up is *less* than the disk space they use, since on disk they are uncompressed MBMs and ingame they are compressed to DXT1 or DXT5. The reason the game takes up 2GB of memory is because of all the *non* part related textures the game has, which are stored in KSP_Data not GameData--try finding planet textures in the Squad folder, for example. See this page for information on how KSP handles textures. There may be leaks such that textures take up more memory than their DXT-compressed selves, but certainly not 4x as far as I know, and *certainly* not directly related to disk usage.

It does it based on what says it's targeting, not the direction it's actually pointing (since maintaining orientation in KSP is tough due to timewarp and everything orbiting.)

Note: the current release of DRE is...a bit too hard. For now, lower the heating multiplier to taste, until RealHeat is done.

Well, sounds like the heat multiplier needs to be turned down some. I'll let that be Starwaster's call, as I have no sense of stock balance at all these days.

The vast majority of memory usage comes from textures. Even an array of a thousand floats is only 4 kilobytes, whereas a 1024x1024 texture is 512 kilobytes (or 1 megabyte if it has an alpha channel...or 3 (!) if it's a normal map and uncompressed ingame).

RT2 doesn't actually do that. Original-RT2 did, but for RT2lite (which became the RT2 we know) it was removed. I think you should check the UP of the transform for the antenna, and do a dot product between that and (CB.position - vessel.position). Which might need the signs flipped, dunno.

It's worth noting that if you implement reentry heat *without* mach effects (although as ferram points out they are the same thing) you will have much *harder* reentries than you should. I mean, reentry is *already* harder than it should be, because parts generally only have 40% of the surface area they should for their mass (consider the Mk1 pod: masses what Mercury does, but 64% of the width, height, and depth, so .64*.64 the surface area). If you then don't consider increased drag from Mach effects, you're going to get a "double whammie" worth of increased heating.

That...geez, this is just so amazing.

Ferram doesn't update the version number until official release. There's been like *two months* of commits, don't think you're getting some old version from git

That's very awesome indeed!

Folks, folks, folks. If you need to report something, use the report button. Moved to addon general. Stone Blue, please don't spam/bump posts; doing so is forbidden by the Community Rules. As others have said, and as is true for me as well, GitHub seems fine; I would suggest the issue is on your end, then.

On the contrary, some of this stuff *is* fixed, which is one reason why it'd be nice to have a release of this newer than a year old.

Hah, thanks folks! Sorry it took such a squirrely path. And to be clear--thank Starwaster too. He found pretty much all the sources for the problems.

I will eventually, but it takes doing some fancy footwork, and I'll have to integrate support into ModuleEngineConfigs for it, since we don't want it and TweakScale fighting.

Changelog: v5.3.2 *Revert to prior adjustCollider functionality; small parts should be shielded again. *No longer ignore heating on physics-disabled parts. Note: Unable to reproduce the tumbling problem with one (and only one) MM 2.4.5 (as shipped with DRE). I did, however, notice it when I had an old (2.2.0) MM lying around. Note that with low density air there is *very* little righting moment to the pods, so you need to manually align first (with SAS on to stop the quivering) and *then* you can turn SAS off.

Deadly Reentry has nothing to do with aerodynamics. Please try the same descent without DRE installed; if the problem *does* go away, then I'm doing something very odd; if not, it's not a DRE issue. :]

Oh, right. I think the default density exponent was lowered, which should increase heating some in the upper atmosphere.

Changelog: v5.3.1 *Fixed stupid typos (thanks Starwaster). Apologies, folks.

For the record, some of the spawning (the timewarp-related stuff) is a stock issues, in case you weren't aware.

No, it's correct, but only if static pressure is in pascals, rather than atmospheres. Dangit. Expect fix shortly. Again. And yes, for *this* howler I'll bump the version number. EDIT: testing shows fixed (I just blowed up my parachute! Oh noes!)

Sure! Yeah, it stinks that we're floored at 500mW, but...them's the breaks. However, is there anything other than antennas that have such low power usage? We could ask RT2 to use TaranisElsu's TACLS Resource request code, since that doesn't have the 1e-5 limit (which is not going to be fixed, since it was an *addition*). The reasoning is this: jet flameout behavior was changed from "whenever there's less IntakeAir than your current throttle setting, flameout" to "thrust scales with IntakeAir available." However, if that's the case, and there's no floor for the resource request, then jets would *never* flame out until >70km, since there would always be an infinitesimal amount of air left, and jets would produce 0.00001% thrust. There are other, better ways to handle it IMO (for example, modeling jets as jets ) but that's what we have, and I don't think they'll use a different method. It's still better than it was, too teal'c: right-click on the pod and select "Reentry CoM" when in flight, and the CoM will be offset. This is so that under normal conditions the CoM can be left un-offset, since people were having a hard time balancing their service modules with the pod with an offset CoM...