Ok, here's what I'm saying... let me make this as clear as I can.

You can download a number of mini-mods I've developed right here, that cover all of the work I've done on this issue, so that you can check to make sure that I haven't made any mathematical errors.

1. Linear_Drag does not counter force. Instead, it counters velocity on a given vector. This is a very important distinction here. When you're applying force on a new vector, Linear_Drag is countering your velocity on the previous vector, for all practical purposes- it's what allows FL ships to turn (defined as change of vector and position) without using thrust to directly counter the previous velocity to the degree you need to IRL in space, where any velocity you build on a given vector is only countered by force applied in the precisely inverse vector (classic newtonian physics here). In FL, you don't need to do this, and Linear_Drag is what makes it work. That's why it's such a vital variable.

2. FL's physics don't have real-world equivalents. We need to be very, very careful about our assumptions, and figure out ways to test things with mini-mod builds, instead of assuming that we know anything- thus far, what I've seen is that when I assume something's true, then I get smacked by the way the engine actually does things In the real world, aircraft (which is what the FL ships are very roughly approximating) have to deal with two different forms of "linear_drag"- friction, which is a roughly linear constant at a given altitude/barometer level, and air resistance, which changes every time the vector of the aircraft changes. In a true flight sim, this is modeled in various mind-bogglingly complex ways, with custom "envelopes" developed for each aircraft. In FL, they made one shoe fit every ship in the game. This is a problematic, and some of the mini-mods I built demonstrate some of the hazards.

3. I agree with Wasabe about the idea that the two equations are probably similar, but use a different scalar relationship (and just like with speed, I strongly suspect that there's some sort of bell curve involved). Let's look at the numbers here:


Now, I've done some experiments.... and the results were NOT what I expected. Please tell me that I've made an error in the last mini-mod, because it more-or-less invalidates both of our previous assumptions about turning. Here was how the sequence went:

1. In my first setup, here are the figures for a two-dimensional turn:

steering_torque = 20000
angular_drag = 30000
rotation_inertia = 1000

So, using the previous math... we have a 30:1 relationship between angular_drag and rotation_inertia here... IOW, it's much HIGHER than in the stock Starflier. Yet turning acceleration is quite horrible. And what works so well for calculating the way that linear acceleration is handled (mass / linear_drag = no. of seconds to nearly top speed)... doesn't work here, because if we applied that, we'd assume that acceleration to a top turning speed would be 1:30th of a second.

Does this make things clear? Fly my mini-mod (erm, OK, don't actually fly, just sit at 0 velocity and spin... not very exciting, but hey this is backyard science at its finest). Try different values for rotation_inertia. Note that, just like with Mass, if you lower it to 0 or near... the game will break. And in no way does the initial setup result in the acceleration curve I predicted. Which sucks for me, I guess

I'm not sure if I agree with your interpretation about how what's happening in the math translates to what we see on-screen, Dev, but I don't have a better theory... just a hunch that what's happening here is more messy than with linear acceleration, where the "shivering" you can see in ships where Linear_Drag is set too high for the Mass is due to the ship accelerating so fast that the game engine draws it considerably ahead of where we "expect" it to be. If that were right, we'd see "angular shivers" as the ship seemed to get drawn a little farther into a turn than we expected, resulting in a ship that seemed to twitch. The wild spinning (not for the faint of heart) is not the same thing.


2. So, I've built another experiment. This time, I've kept steering_torque and angular_drag at exactly the same amount, and I've set up a 1:10000 ratio between rotation_inertia and the other two, by setting it to 10 and the others to 100000.

Download the mod here, to try this out yourselves...

Basically, that didn't work very well... the results were... ah... rather ugly.

3. So, I quickly built a third experiment... this time I set the ratio between them to a much lower value: 1:1. The result was a game crash, every time. Apparantly "FL don't like dat" :-/

4. Next, I decided to make it 1:2. This made the game crash, too. I was surprised by this, but I guess there had to be some sort of threshold at which the turning speed wouldn't convert into a meaningful float for the radians, and this must be there. I'll look at the math later, if I care.

5. Finally, I set it closer to what was used in the game: 1:100. This caused a crash, until I unlocked all three axis, by making the figures the same for all three directions. Feeling that maybe I'd finally gotten somewhere in terms of understanding what was causing the crashes in the first place, I went back and tried the 1:2 ratio. This didn't cause a crash this time, but the results were surprising: you'd think it would've taken a veeeeeery long time to reach maximum turning speed, at that ratio... but it doesn't

6. So, now knowing that setting all the axis figures the same could prevent crashes, I set them all to 1:1000, for my final experiment (I assumed that 1:10000 would just crash again).

The results were so... amazingly not like what our theories have predicted (please note that almost all of my experimental results above have not met predictions, either) that I strongly advise you to not trust my experiment, but set one up yourselves... maybe I messed something up here. When I put in the following settings:

steering_torque = 100000, 100000, 100000
angular_drag = 100000, 100000, 100000
rotation_inertia = 100, 100, 100

The ship's turn through 360 degrees was absolutely faster than previous experimental setups. I don't mean that it accelerated to top speed faster... it was faster, period.

I'm going to go think about that and eat some lunch now Have fun trying out my mini-mods... and if you find any serious setup errors or can't duplicate my results, it'll make me happy, not annoyed- if that last experiment was right, then all of our theories are trashed.

As for point 1, if you were commenting about what I wrote, I do not disagree with what you said; my statement was that there will be no net acceleration in a given direction if the linear drag and force in that direction are exactly opposite in magnitude. I think there may perhaps be some communication difficulties because drag as a force is equal to the drag coefficient times the velocity in a given direction (it's not like it couldn't be some other function of the velocity, it's just that experimentally this seems to be what we observe in FL). However, it is not the drag force itself but rather the drag coefficient that is defined in FL's .ini files, so explaining what we're talking about has the potential to get considerably misintrepreted. Anyway...

Point 2, I disagree entirely. I'm 95% certain that the guys who wrote the code built it around plain and simple Newtonian physics, which is exemplified in many walks of life. My previous derivations are based entirely off of traditional physics, and so far I have not seen them fail, EXCEPT in the magical case that was brought up at the end of the post, the one with 100k torque and drag and 100 inertia. However, I believe I can give a possible solution for that, starting now.

First, this comment got me to thinking:
"...just a hunch that what's happening here is more messy than with linear acceleration, where the "shivering" you can see in ships where Linear_Drag is set too high for the Mass is due to the ship accelerating so fast that the game engine draws it considerably ahead of where we "expect" it to be. If that were right, we'd see "angular shivers" as the ship seemed to get drawn a little farther into a turn than we expected, resulting in a ship that seemed to twitch. The wild spinning (not for the faint of heart) is not the same thing."

And you're right, the ships don't noticably oscillate around a certain angular velocity, they just spin like ewoks on crack. So, I messed around with the infamous starflier some, and I discovered some things that were most intriguing.

For starters, I set the torque and angular drag to 100k each in order to have a nice theoretical max velocity of 1; I set the rotational inertia to 10k as a starting point and did the classic spin test in front of Manhattan's docking ring. After a few revolutions to make sure velocity was close to max I timed myself and got just over six seconds, which is awfully close to 2*pi (meaning the velocity is likely in radians/second, a handy thing). Anyway, as I said, this was nothing special, just the starting point.

Next, I kicked up the inertia to 100k and did the same 360 spin timing after giving myself perhaps 20 revolutions to build up speed. Again, just over six seconds, as expected. Moved the inertia up to 1 million, same deal. All consistent with what I derived.

Going the other direction was a little more interesting. Starting at 10k, I decreased the rotational inertia by 1k at a time and did the spin test. The results: just over six seconds UNTIL I hit 4k... at that point, the times started to increase. And I thought, "well, crap, my derivations were off." However, if that were the case, there would be no way to explain how the maximum velocity is the same for inertia values of 10k and 1 million.

At that point I noticed that the ship did not turn smoothly whenever the inertia was less than 5k (you can even sort of notice it at higher values if you look closely). Every second or so, and sometimes even more often, the ship would "jump" ahead by several degrees. Just watch the contrails and your forward velocity, there's no way you can miss it. This is strong evidence in favor of a numerical approach to calculating ship motion.


::Entirely speculative conclusion::

This is what I think is going on in the code. The guys who were working on the problem realized that with very high acceleration it was quite possible to overshoot the intended maximum velocity. Now, if you do something like this, as I originally suggested:

dv = ((T - (D * current_vel)) / I) * interval_size
new_vel = current_vel + dv

the values for new_vel will be self-correcting; if the current velocity ever gets too high, (T - D*current_vel) will be negative, meaning that new_vel will be less than current_vel. Thus, you would get an oscillatory effect. My guess is that the guys who designed the system realized that having your current velocity going from very high to very low every small fraction of a second would drive people insane, so they decided to do something different: rather than directly adding dv to current_vel to get new_vel and letting the thing correct itself, they opted for something more like this:

if (dv < 0) new_vel = current_vel - damping_amount
else new_vel = current_vel + dv

where damping_amount is perhaps some fraction of current_vel or maybe a more complicated function, but in any event is less in magnitude than dv. Furthermore, damping_amount would take into account whether the new_vel has already been damped, and would equal zero if this was true; the result of that would be that new_vel would remain constant (barring external influences). Every second or so, the whole thing would refresh, so new_vel would be calculated as though no damping was in effect; thus, periodically you would see spikes in the angular velocity, as observed. However, most of the time you would see pretty much constant angular velocity, though it may not be the theoretical maximum velocity if the first value of dv is large enough (as it would be for small inertia).


Anyway, that's is the conclusion I have drawn from my observations. Regardless of whether that's how the code actually works, my advice is to keep away from small inertia/torque ratios (as in, greater than 1/20) lest you want to deal with unexpected results.

Well, at least now I know that my results were verifiable. I think that your formula is probably right, so long as you don't go below that magic threshold where bad things start happening. I'm going to do some more experiments on slowing acceleration down, though- I saw a couple of things in my early stabs at this that were ... funny... and I'm very interested in slow turn dynamics (remember, I'm planning to have ocean-going ships in my mod), so I might was well do the experiments and document anything weird that comes up.

When it comes to point no. 2... yes, I will happily concede that the programmers started with real-world examples... but the way that things are handled is very much unlike the real world, so I'm mainly just cautioning to look at the experimental results, and not be prejudiced towards a given theory until we can prove it. I think that that figure of 6 seconds for the 360 is probably the most useful thing we've learned thus far- it does appear that the engine (under normal circumstances) does revolve things by figuring the radians.

As for the weird results at the low end... if we can figure out how to tame that beast, there could be some useful things to do with it. Bear in mind that I already have one pretty extreme example of manueverability in my mod (the Bloodhound), so if I can keep this in check (just as I worked with Linear_Drag, Mass and Max_Force to get valid docking solutions) then I might find some ways to make use of this. For example, I've been looking at what might be required to make something that acts more like a helicopter than a traditional aircraft...

Aargh... I tried your experiment and changed archtype.ini.

steering_torque = 100000, 100000, 100000
angular_drag = 100000, 100000, 100000
rotation_inertia = 100, 100, 100

You were right....it made my head spin. The computer could not dock my ship with planets or trading lanes. Each revolution was easily under a sec. So I'll need to modify this to something flyable.

Have you come up with a ratio that works for you?

Thanks for all your hard work.

From what I've observed, the critical ratio is that of angular drag to rotational inertia, as this will determine how long it takes to approach your maximum angular velocity. I usually try to keep it 20:1 or less; for example, if your angular drag is 100000, then your rotational inertia should be greater than about 5000.

you maniacs... what about just play and enjoy ?!

Titus, please don't be digging up 2 year old dead threads.