Different handling despite same calculations

Durandal

Alright, so I was attempting to see if I could reduce the messiness of your average shiparch by lowering the numbers while maintaining the same ratios. For this example I used the Guardian from Discovery, which has the following stats.

steering_torque = 47000.000000, 47000.000000, 190000.000000
angular_drag = 40000.000000, 40000.000000, 141000.000000
rotation_inertia = 8400.000000, 8400.000000, 8400.000000

Changed to:

steering_torque = 47000.000000, 47000.000000, 1
angular_drag = 40000.000000, 40000.000000, 0.75
rotation_inertia = 8400.000000, 8400.000000, 0.05

As far as I was aware, the max turning speed was the torque divided by drag, and acceleration to reach said speed is torque divided by inertia, both of which nearly match up.

While the actual handling is almost identical however, ramming into an object results in the ship spinning violently out of control, leading me to believe that as least one of those stats is interacting with the game on a direct level rather than it simply being the max turning and acceleration calcs that do so.

Could somebody please explain this for me?

CK256

To get the potential max angular acceleration you have to use the net or surplus steering torque left after the angular drag has been subtracted from it.

So in your example steering torque - angular drag = net torque

47000 - 40000 = 7000

Using the equation T (net torque) = W (angular acceleration) x I (Inertia)

you can revise the equation to read

W = T/I in your example W = 7000/ 8400 = 0.833 Rads/second/second around 48 degrees/s/s

This is a measure of how fast a ship can get to it’s max rotation speed and if you compare the W between an Eagle and a Titan you can see why an Eagle is more agile in combat (I think it’s perhaps 20% higher)

If I remember correctly the three sets of numbers are the X, Z and Y axes or pitch, yaw and roll, as there’s no flight control in FL for roll (the ship rolls in the turn and self centres after the turn) the first two sets of figures are what defines the ship handling,

I’ve added a tutorial see attached zip

Durandal

I don’t think you understand what I meant, there is no issue with the X and Y axis. I changed the numbers of the Z axis while maintaining the same calculation ratios and received different handling, so evidently it does something.

CK256

Yeah you will get different handling as the Y axis defines roll so although the flight controls don’t do roll the mass of the ship causes banking.
Essentially the roll figures are there to control the amount of bank exhibited in turns.
So although the ratios between the figures are almost the same and the calculated W is too the ship has practically no roll inertia and the handling is likely to be somewhat unpredictable.
I don’t know what other effects are impacted by changes to these figures as the FL game engine has never been decoded as far as I’m aware.
I believe the trailing zeros are needed but that’s for others to comment on.

Durandal

So it defines banking. Awesome, thank you. Could you give me a clear and concise formula as to which particular Y axis numbers interact with the Z axis numbers to create the angle the ship banks at when turning?

CK256

I’m not aware of any relationship in FL coding that could output a defined bank angle, I believe it’s in place to control and damp the bank angle and re centre the ship vertically after the turn.

I think someone on Starport did create a patch for allowing roll control in the FL flight controls but I can’t remember who I’m afraid

Try this link

http://the-starport.net/modules/news/article.php?storyid=142&keywords=roll+control

If you don’t have a high enough figure the ship could topple over or oscillate about vertical, at best I’d suggest trying some different figures in Y axis (roll) and note the effect it has.
Remember mass (and also linear drag) will have an impact here too, so a heavier ship (VHF) will behave differently to an LF in that changing these figures may not have such a marked effect