Zuthal

There appears to be an issue with the Rapier's plume. In vacuum, it clips through the vessel, and has weird visual artefacts. This is on a fresh install of KSP, with only Waterfall-Core, ModuleManager and Stock Waterfall Effects installed, running on macOS 10.14.6 with a Radeon Pro 560X. All other Waterfall plumes work perfectly fine.

I made a small modulemanager patch to, if CryoTanks is installed, add the option to switch the bipropellant internal RCS to hydrolox or methalox. This patch does not change the plumes, only changes the stats, by the same ratio as the switch from LFO to methalox/hydrolox for Near Future Launch Vehicles' heavy bipropellant RCS. I thought some other people might find it useful as well.

Thanks!

Given that Procedural Parts has now been updated to 1.8, are you planning to update this mod to 1.8 as well?

There is SMURFF, which adjusts parts to have a more realistic performance mainly regarding the propellant mass fraction of tanks and the thrust to weight ratio of engines. The full adjustments are to realistic values, and would definitely be OP in a 2.5x scale game, but you can set how much it adjusts in the config of the mod.

Problem is, IR parts don't work with FAR either - I have tried to make variable geometry planes with them, and they also do not behave nearly as you'd expect.

I use RCS build aid, and while the torques from engine thrust/engine gimbles/RCS it displays, as well as the dry and average CoM, are useful, it doesn't quite display the info I am looking for. But I found that FAR actually displays those values, so that's fine.

I would like to know if there is a mod to both a) display the vessel's moment of inertia tensor along the axes it will be controlled about when in flight (or along the axes of the root part), and to b) visually indicate these axes in the editor, to help with aligning the control component with the principal axes.

One question that is kinda tangential to this mod: Does anyone here know of a mod that works for 1.6.1 that adds small-diameter SRBs and probe parts that would go into the starting tech node? Because starting out with a Flea and a Stayputnik just feels kinda ehhhh to me, from a realism POV.

One thing you should I think definitely do is keep separate records for stock aero and FAR - since FAR seriously changes the aerodynamics model, and especially can make taking those tight turns a lot harder at high speed, due to your plane potentially just being torn apart by the aerodynamic stresses.

I have a question about the part variant switcher: Can it only switch part models and textures, or also other aspects of parts? If the second is true, then this addition might have just obsoleted all of the various fuel switcher/part switcher mods.

You have disabled Oxidiser, Liquidfuel, Monoprop, Equipment and Researchkits from being included in the calculation. Click the buttons next to the name of the resource to enable it again.

L4/L5, at least the exact positions (same orbit, but 60° in front and behind) work perfectly fine in normal KSP, however, if you do not get the exact same orbital period, they will eventually drift. It is L1 through L3 that do not work and absolutely require n-body gravity.

How would I go about putting together a profile to use with Sigma Dimensions rescale factor of 6.4? My main concerns are signal distance (as all distances will be 6.4x larger than in stock KSP) and anything time-related (as larger distances translate to much longer transit times). Additionally, I am not sure, but there might be issues with the magnetospheres, if their sizes are hardcoded and not based on the planet's size. Also, one thing I noticed without the rescale: On a Mac, with Intel integrated graphics, the magnetospheres/radiation belts do not render until you are quite far out (Kerbin's outer radiation belt, by the time it becomes visible in map view, covers about a fifth or so of the width of my 1280x800 screen).

Could you make the ECLSS maybe more granular (so one "unit" can support one Kerbal) and simply give any pod enough slots to support its full crew capacity? Since to me it would seem kind of silly to design a pod with an ECLSS that cannot support the full capacity.

I think it will just always tweak them if you remove the RealSolarSytem part - then it will just do the tweak if the Signal feature is enabled.

Is it possible at all to do swing-wings currently, and if yes, how to do so? Because the way I tried it (hinge or joint, with a wing attached to it) the wing would not rotate with the joint/hinge when I actuate it, and yes, the joint itself is moving.

Thanks! I was looking at MOLE as well, but that one has a dearth of 1.875 m engines - which is really what I am after, since just Tweakscaling 1.25 m engines feels a bit cheap.

Does anyone have a mirror for the download? I want to use this mod with the community patches, but both of the download links from the OP are dead.

What would be the proper way of determining what lever is the right one for a certain system scale? I was assuming that the mass ratio multiplier relative to stock is proportional to the lever, and that levers=1 is balanced for RSS. Then, the lever for a certain scale, I would htink, to maintain roughly the same difficulty, should I think be proportional to the ratio of the mass ratios you need to LKO in the different scales, which would give ~0.56 for the levers for 64k if you use engines with an exhaust velocity of 3500 m/s. Is that anywhere close to sensible?

My general rule of thumb for delta-V to a circular low orbit is ([low orbit velocity]+1000 m/s)*1.1. For stock with 2300 m/s, this yields 3630 m/s, and for RSS, with 7900 m/s, this yields 9790 m/s - a bit over what is strictly necessary, but gives a buffer for deorbiting and less-than-ideal ascents, and seems to hold for all reasonably feasible rescales. I wonder if that works for other planets (mainly Eve, Duna and Laythe) as well, and what the "loss constants" for them are.

I think the scaling between the terrain colliders and the terrain model, at least on Kerbin, is very slightly wonky - for example, at least in some places landed craft sink in a little bit (close to KSC, but not on the actual KSC territory, a Kerbal sinks in about up to the lower edge of his helmet). This seems to be visual only, but does anyone know how to fix it?

Hmm... I think those loss figures aren't accurate anymore. Using the GravityTurn mod, I can, with stock scale, get a rocket into a circular 100 km prograde orbit with only ~3500 m/s, so it seems the losses are only ~1000 m/s. Will test how much delta-V it takes to orbit now in 64k scale, with atmo scaled to go away more gradually and end at 100 km, for a 150 km orbit. My science has a result: Using a four-booster pairwise two-stage asparagus launcher (3000 m/s second stage, 3500 m/s first stage, 3500 m/s in the boosters), I achieved, using the config posted earlier, a circular orbit of 153 km, with a total burn of 6942.1 m/s plus 24.7 m/s circularisation, with a total loss of 1492.76 m/s. Conclusion: In 6.4x scale, you will be on the safe side (if you fly an efficient ascent) if you use 7.5 km/s in your launcher.

Okay, so then the difference in launch delta-V should just be the difference in low-orbit velocities. That simplifies things quite a bit

That would be awesome, even if it would have to be limited to transfers and takeoffs from nonatmospheric bodies - since atmosphere losses will be quite difficult to predict. For simple orbital maneuvers (escape and going to synchronous orbit) you should be able to just use Kepler's Laws, and for transfers, https://alexmoon.github.io/ksp this tool allows you to define your own bodies, though it of course isn't automagic. But you could maybe take a look at the source on github and implement some automagic from that.