Important Message

You are browsing the archived Lancers Reactor forums. You cannot register or login.
The content may be outdated and links may not be functional.


To get the latest in Freelancer news, mods, modding and downloads, go to
The-Starport

flight stats explained

The general place to discuss MOD''ing Freelancer!

Post Thu Sep 16, 2004 10:45 am

Volume is compleatly different from mass. Volume is the area an object takes up while mass is the total amount of matter an object has. Two objects could be the same mass but different volumes. Volume determins weather it can fit in your ship and that limit is set in the shiparch.ini as the cargo_hold constant.

Post Thu Sep 16, 2004 7:20 pm

There is a volume entry in all [engine entries and changing this affects the above calculations. Most are set at 0 but many capital ships are set to 400.

Post Fri Sep 17, 2004 12:33 am

yep, and they do take up cargo hold space, I dont believe they effect the ship manevourability tho

Edited by - bane42 on 9/17/2004 1:32:59 AM

Post Mon Sep 20, 2004 8:58 am

Ok here's question from somebody who takes off his shoes to count to 11;
how much of a difference in game play does it make to set the various details according to your equasions as opposed to leaving those details at stock(i.e. mass=150 for fighters and whatever it is for small freighters etc.)? I mean while this is a space based game and all you guys are talking about rocket science LITERALY! If i'm out of line a apologize but going into this much detail over performance seems a little much. Or are you planning to set up senarios based off of the Hovis race where that extra bit of performance means that much? The reason I ask is that I don't believe MS/DA put that much thought into those details otherwise FL would be a different game(not to mention the cost would be much higher and interest in the game much lower).

I guess what I'm getting at is getting too far into details can turn off as many people as it interests others, hence the public stigma and derision over "trekkies" who argue over ST details.

Post Mon Sep 20, 2004 11:18 am

Ahoy junior1210, thats a fair comment, the difference can be huge in the game
I am finalising a shipmod which drastically changes the way the ships fly.

The main thing about this is it gives you the tools to know what your ships will be like before you even test them in the game.

I set up a spreadsheet , put in all the formulas and used that along with my own basis for recalculating mass, drag etc based on the ships size and other factors

The end result is way more exciting dogfighting and flying, a better balance between heavy and light fighters. I know what to change and how it will affect a ship. A lot of effort goes into making ships, but if they fly like the std ones, its a bit wasted in my opinion. From testing changes with other ppl, they are amazed at the difference, if you do it properly, and the only way to do that was to work all this stuff out

I personally now find the std game stats to be pretty awful, it boils down to a sabre or eagle and that is boring. It is a lot of detail but ultimately worth it I think.

Post Mon Sep 20, 2004 2:46 pm

You're probably right as far as the actual performace goes. I really never put that much thought into it as my fighting style is shoot 'em fast so they can't shoot you. As to the differences between the fighter classes, I figured that was more defined by armor and weapon classes than by performance. Although what they could have done in defining the ship classes and levels is that instead of just mounting higher level weapons and such, they could have made it so the lower level ships were slower and poorer performance than the higher level ships. Like say a class 2 ship could mount class 10 weapons but it would turn like a pregant whale and slower than molassas(say 65kps), while a class 9 ship could turn on a dime and rather fast(120kps). I know that's off topic but worth saying, I think. What it comes down to I guess is that I generaly take the actual game mechanics at face value and just work with them. The number of things in FL that you're expected to swallow without going "WTF!?!" is enough to keep me from delving too deeply into the basic rules of the FL universe. Either that or It might be my limited knowledge of physics and higher math to anything more complicated than that it's not the fall that kills you, it's the landing, and that the speed of the fall is just sufficent to get you to the site of said landing.

"we wish for one last landing on the globe that gave us birth, to rest our eyes on the fleecey skies, and the cool green hills of earth" - 'Noisy' Rhysling

Dev

Post Wed Sep 22, 2004 4:46 pm

I'm definitely with bane42 on this one; knowing the how and why behind what makes your ship handle the way it does is very important for providing a true variety of ships to fly. Consider, for example, that you want to rebalance the existing ships in the game. Say you want the Drake to be super-responsive in any maneuver you put it through. What do you do? Well, since you know that the variable controlling its angular acceleration is the rotational inertial (initial acceleration from zero being F/I), you know that by decreasing the rotational inertia you will accomplish your goal. Now, perhaps you think that the Humpback turns a 180 so slowly that it's simply painful. To fix this, you know that the maximum angular velocity is F/D, so by simply decreasing the drag you will cause it to rotate faster in the long turns. However, note that it will still respond like a lead brick when you try and change directions, since the F/I ratio remains unchanged; if you would rather have both the angular velocity and the angular acceleration increase, it might be better just to increase the force (though you could lower both the drag and the inertia and get the same result).

Long story short, knowing how these numbers correspond to in-game flight dynamics is a whole lot better than just shooting in the dark when you're trying to build a ship that flies exactly how you want it to. This is pretty much what bane42 said already, but no harm in saying it again.

Post Tue Nov 09, 2004 12:14 pm

Please correct this article, so that the information contained in it reflects the experimental results obtained (and replicatable by others, as I've made mini-mods to demonstrate my points) in the following article:

Click here to view my Physics article.

Basically, this tutorial, while correct in some places, is still quite wrong in others. Sorry to be controversial, but the facts demonstrated in my article are quite clear.

Post Tue Nov 09, 2004 9:36 pm

hey Argh,
send me an email explaining which parts you think are wrong and why.
thks
Bane

Post Tue Nov 09, 2004 10:47 pm

The whole section about turning is wrong. Proof? Make the steering_torque 20K, 20K, 20K and the angular_drag 30K, 30K, 30K. By your calculations, the ship could not turn. But in truth, the ship does turn (although slowly).

Post Tue Nov 09, 2004 11:23 pm

@Wasabe: yes, it'll still turn, according to my current theory, which I explained in my article. Basically what follows below is a quick rehash:

Steering_Torque / Angular_Drag using your numbers produces 20/30, or 2/3, which inversed results in a turning speed of about 1.5 seconds for a 180, assuming that rotation_inertia is set to 1 (setting it to 0 is not recommended, for obvious reasons). Try it, my calculation basically works. But it's still rough- I haven't been able to empirically demonstrate this, although when I use this calculation in my mod, it's been about right on the mark for vector changes. Now, turning as described in my article (vector change + position change) is quite a bit more complicated, since it involves so many factors.

In short, I don't think that what I've got is science yet, and I'd like to spend time making another mini-mod and demonstrate some sort of useful proof on that concept, but I've been rather busy working on my mod.

Setting a value of 0 for Steering_Torque will produce a net turning speed of zero, though... you can try that out yourself, or wait until my mod gets to Beta (I'm working on putting ocean-going ships into the game, and they obviously cannot fly, so I made them unable to turn in the X axis).

Edited by - Argh on 11/9/2004 11:42:21 PM

Edited by - Argh on 11/9/2004 11:44:04 PM

Edited by - Argh on 11/10/2004 12:02:52 AM

Post Wed Nov 10, 2004 12:45 am

hullo argh and wasabe

if we can take torque/drag as the max turning velocity or speed (which although not stated above is assumed nonetheless), being that torque replaces force, and linear drag goes to angular drag.
then we have a max turning velocity of 0.67 in this case (20/30).
Now this is probably radians per second so that translates to a speed of 38 degrees per second.

now for the angular acceleration we have in this thread,
angular accelaration = excess torque/rotational inertia

assume the inertia is 3800 so as pointed out we have a negative angular acceleration

(20000-30000)/3800 =-2.63 radians

so I'm not saying that the ship cant turn, becos' it has a maximum velocity thats positive. What I am saying (I think ) is that it slows down to the turn velocity when theres a negative acceleration figure, and speeds up to reach the turn velocity when its positive.

I did a test with the same steering torque and drag values (30k each)
This gives an angualar acceleration of zero and a max velocity of 1 radian which is 57 degrees. To do a 360 should take (360/57 degrees) =6.3 seconds. I timed it and give or take a half a second for a slow sever/pc, It was bang on.

I cant say for sure if this is rubbish or not, but it seems pretty solid.
any thoughts would be good

Post Wed Nov 10, 2004 12:50 am

Okie doke, so what you're saying that what I'm saying and what you're saying match up, roughly- I'm calling a 20/30 split a 3-second 360, assuming that one takes the inertia out of the picture (I try to eliminate mass/inertia as a variable whenever I'm trying to figure out what the others do here).

Lemme put together a quick mini-mod to describe what we're talking about, and test in the game engine... I'll put it up here in a second, along with my results

Post Wed Nov 10, 2004 1:14 am

Click here to download my experimental setup.

What I discovered is that:

1. Setting rotation_inertia to a very low fraction of the other two variables causes the same sorts of instant-acceleration problems seen in my other mods when mass:linear drag had a relationship of more than 1:15. IOW, you accelerate into a turn at incredible speeds, and then spin like crazy. Hmmph.

2. Once I set rotation_intertia to 1000, and then set up turning on one axis only with a 2:3 ratio, the recorded time was roughly right. BUT BUT BUT... the acceleration curve of angular_drag vs. rotation _inertia is NOT the same relationship that one sees in the linear acceleration equations- angular_drag is not acting in the same way at all. At 1000, you can really see the acceleration as the ship begins its turn.

3. Looking at my prediction, where I predicted that rotation_inertia played the same role as Mass... well, obviously that ain't right. At 30:1, the rotation_inertia should've been overcome so quickly that the acceleration should've been instant, but it wasn't. Knocking rotation_inertia down to 100 resulted in a much sharper acceleration curve, but did not increase top speed.

I think we're both wrong here- your equation is based on a model that's not very clean (iow, you based your equation on what seemed to fit existing ships), and mine's wrong because I'm not factoring in rotation_inertia correctly- it's obviously not cancelled out the way that Mass is cancelled by Linear_Drag. I wish I had time for more detailed experiments, but I really need to get some sleep

In short, I think that the acceleration time is a huge factor in the timed speed for a 360-degree turn. And unfortunately... as I described above, if you make that acceleration time approach zero (to the get the most accurate measurement possible of true turn speed) then the game engine goes crazy... yikes!

Edited by - Argh on 11/10/2004 1:17:56 AM

Dev

Post Wed Nov 10, 2004 3:04 am

If I had to guess about the off-the-charts acceleration problems, I'd say that FL takes a statistical approach to solving for how your ships accelerates (linearly or angularly, the approach is likely the same). At any moment in time, it takes your current velocity as well as the force, linear drag, and mass constants to obtain the new velocity, then multiplies that by a small amount of time to get the ship's new position. Thus, after some amount of time the current and new velocities will become approximately the same, meaning the ship has hit its maximum velocity of F/D. However, if mass is set very low, all hell breaks loose since the initial acceleration (and therefore the first value for velocity) will be far beyond the theoretical maximum velocity; it's a standard problem of linear approximations, eventually you'll run into a situation where the distance between steps becomes so large that the approximation becomes quite poor.

Anyway, that's my take on the situation; I didn't write the code, I don't know for sure. However, it would be a good explanation for why you must provide force, linear drag and mass rather than a maximum velocity and acceleration (as is the case for missiles).

In response to this:
"Looking at my prediction, where I predicted that rotation_inertia played the same role as Mass... well, obviously that ain't right. At 30:1, the rotation_inertia should've been overcome so quickly that the acceleration should've been instant, but it wasn't. Knocking rotation_inertia down to 100 resulted in a much sharper acceleration curve, but did not increase top speed."

I maintain that you were right originally; I see no reason why the guys who made the game would adopt two physics standards for handling in-flight movement. However, FL does have its share of its oddities, so consider this as well: the ratio of engine force to ship mass is usually on the order of 300 or 400. When you give all the linear drag to the ship's hull rather than the engine, get moving at top speed and then hit engine kill, you will decelerate to zero quite rapidly, as in a half second or less. If you increase the ship's mass by a factor of ten (making the force/mass ratio 30 or 40), it will take quite a bit longer to grind to a halt. Now, when you give the ship 20000 torque and 1000 rotational inertia, you have a ratio of 20; this means that it SHOULD take a little while to get close to its maximum turning velocity. When you decrease the rotational inertia to 100 (making the ratio 200), it will of course have a much steeper acceleration curve, closer to that coventionally observed in linear ship movement. So, I don't think there's anything anomalous about your findings at all.

Finally, perhaps I am misunderstanding this statement:
"it's obviously not cancelled out the way that Mass is cancelled by Linear_Drag."

I don't know if this is a fair thing to say. If FL physics are based of off reality (which seems likely at this point), mass and linear drag do not compete against one another so much as they both compete against force. We all seem to agree that the maximum velocity is F/D (if you'd like to see the derivation of this for whatever reason, it's on the previous page of this topic). The acceleration of the ship at time zero is F/m (F = m*a initially, as there is no drag component). If you trust my derivations (as I obviously do), the time for the ship to reach P% of its maximum velocity is (m/D)ln(100/(100 - P))

Now, judging from this last equation, it might seem that as drag is increased, the ship will (rather counterintuitively) accerelate more quickly. However, do not forget that as the drag increases, the maximum velocity also decreases. So, I wouldn't say that mass is cancelled by drag anywhere.

Return to Freelancer General Editing Forum