SSTU - Shadow Space Technologies Unlimited

SSTU - Shadow Space Technologies Unlimited

98.5k Downloads

MUS produces almost no RCS thrust at small diameters

blowfishpro opened this issue · 4 comments

commented

Seems pretty reproducable.

I took a look at the code and I think there's an issue with this line?

float scale = currentHorizontalScale * currentHorizontalScale * currentVerticalScale;

Looking at updateEngineModuleThrust above it I think that should be Mathf.Sqrt(currentHorizontalScale*currentVerticalScale). Not sure what the layout.modelScalarAverage() multiplier is.

commented

The layout.modelScalarAverage is in place because you can also supply an additional 'scale' factor in the layout used (e.g. Quad, Double, etc).

From the snippet you posted, it looks like I was trying to do standard 'cubic' scaling for thrust... which works well when 'upscaling' engines, but results in very poor thrust when scaling down.

I think what you are proposing (using sqrt of horiz*vert) would result in linear scaling of the thrust, which may result in extremely large thrust values when scaling models down.

Lets see... Cubic, Square, Linear scaling of an RCS port, using 2.5m as its 'base scale' (parent parts scale), and 1kn of thrust at that scale --

Def Parent Size = 2.5m
Def Thrust = 1kn

Parent Size scale % Linear Square Cubic
10 400.00% 4 16 64
7.5 300.00% 3 9 27
5 200.00% 2 4 8
3.75 150.00% 1.5 2.25 3.375
2.5 100.00% 1 1 1
1.875 75.00% 0.75 0.5625 0.421875
1.25 50.00% 0.5 0.25 0.125
0.625 25.00% 0.25 0.0625 0.015625

Figuring out proper thrust scaling for engines/etc has always been 'tricky'. Perhaps I need to handle RCS different than other engines, merely because of how they are used...

Any preferences/insight on the above numbers?

commented

The reason that looks wrong to me is you’re already exponentiating the scale a few lines down (I think the exponent ends up being 3 by default)

commented

Doh... you are absolutely correct. The 'scale' value here is being fed in as the % scale factor, and not as the exponent scalar.

So yes, in this case sqrt(hScale*vScale) is more correct.

commented

Fixed in dev, available with the next release (hopefully in a few hours).