The objective of this article is to expand our current knowledge of the FL flight models for ships, and to gain a better understanding of what variables do and do not come into play.

After a lot of experimentation (and several severely-mistaken variable setups early on), here is what I've learned:

1. The only variables effecting acceleration/deceleration of ships are the following:

A. Linear_Drag (Ship). This is set to 1.0 on all ships, and should remain so.
B. Linear_Drag (Engine). This is probably the most important physics variable in FL.
C. Max_Force (Engine). This, divided by the Linear_Drag (Engine) plus Linear_Drag(Ship) results in the top speed of the ship.
D. Mass (Ship). This is the Mass of the ship, in whatever conversion units Digital Anvil used. I'm not sure what their conversion units were- it's not really obvious. Ships that probably wouldn't weigh more than 5 tons IRL are frequently listed as being from 100-175 units in Mass. The important thing is to understand what Mass does in the game engine.

And that's it. Whether you're designing a slow-as-molasses freighter or a speedy interceptor, changing these four values can make a huge difference in a ship's behavior in the game.

Since we're going to be talking a lot about turning (since that's one of things people are really concerned with, from a game-design perspective) later on, it's important to note that there are three variables that come into play:

A. Steering_Torque (Ship)
B. Angular_Drag (Ship)
C. Rotation_Inertia (Ship)

Lastly, I will talk about docking behavior and AI problems at the end of this article. To understand how this works, you'll need to be aware of one more variable:

A. Nudge_Force (Ship)

Edited by - Argh on 10/29/2004 6:05:10 AM

Edited by - Argh on 10/29/2004 6:08:58 AM

Acceleration explained

Ships accelerate by applying their Engine's Max_Force against the Linear_Drag and Mass variables. They decelerate by applying the Linear_Drag variable against the current speed and Mass.

Top speed = Max_Force / [ Linear_Drag (Engine) + Linear_Drag (Ship)
Acceleration/Deceleration, in seconds, to/from top speed = Mass / Linear_Drag

Linear_Drag, which shows up in every equation, is the most important physics variable in Freelancer. It basically is at the heart of every important flight behavior: acceleration, deceleration, and turning (more on this later).

For those of you who find a visual diagram more useful than writing (and I am certainly in your camp)... here's an illustration which explains these concepts:

Linear_Drag... the king of variables

Why is Linear_Drag so important? Because, in short, it controls almost every aspect of flight in Freelancer. Without it, Freelancer's ships would drift through space without stopping.

To find out what it'd be like to have Freelancer ships that act more like spacecraft in the "real world", simply download this file, and activate it using FLMM. In this mini-mod, I have set the Linear_Drag of the Engine to zero, and set the Mass of the ship to 3. The Max_Thrust is set to 150, giving us a top speed to 150 (Linear_Drag of the ship is left at 1, which gives us a 150:1 ratio, or top speed).

Difficult to fly, eh? And almost impossible to land, too. Not to mention that it takes quite awhile to get your speed to zero.

In fact, it never reaches zero... it'll always stay at 1, so long as you don't turn. Why is that?

Well, it's very simple, folks: when Freelancer was designed, it was programmed so that the Linear_Drag of the ship (which is set at 1.0) would exactly cancel out the lowest possible forward speed... which is 1. So a speed of 1 is really a speed of zero. This also explains why it seems like you never quite get to a true speed of 80 in the game- that Linear_Drag entry is there, eating away that last bit of speed... constantly. The game's designers could've made this less obvious by making all top speeds really be 81 (so it'd look like 80) but they didn't bother.

This also explains why setting the Linear_Drag of a ship to anything but 1.0 is a terrible idea- don't do this! It screws up whatever code is responsible for getting a ship to a relative velocity of zero... and this leads to all kinds of weird behavior. If you're messing with Linear_Drag... do it with the Engine, not the Ship.

So, let's say that we don't want our ships to drift willy-nilly. We want them to turn and manuever very crisply, with "arcade-like" physics. We can achieve that through the opposite approach: make Linear_Drag (Engine) much higher than the Mass.

Download this mod to try it out in the game. Here, I've left the Mass at 3, but increased the Linear Drag (Engine) to 299, and the Max_Thrust to 45000. So the ratio of Mass to Linear_Drag is now 1:100... it takes 1/100th of a second for Linear_Drag to cancel out the effects of Mass... wowzers!

Now the ship accelerates and decelerates very rapidly, and turns on a dime. Just a few small changes have a HUGE impact on the behavior of the ship.

Note, also, how the ship is now "jittering" quite a bit, whenever you're flying in a straight line at the top speed. This is because normally the FL engine uses some sort of smoothing behavior at the top/bottom speeds of a ship, using Linear_Drag (Ship) and the ratio of Mass to Max_Thrust seems to play a role, here. In short, Linear_Drag(Engine) is "dragging" the ship forward just a tiny bit (to make the ship's position "true" to what the engine expects to be happening, and it's happening so fast that the ship's position is changing quite a bit between screen refreshes!

If you've ever downloaded a ship or mod and seen ships with this odd-looking flight behavior... now you know- the modders weren't aware of this relationship, and didn't lower the ratio between Max_Thrust and Mass to appropriate levels. This is a really extreme example, of course, but I've seen it in several of the larger and more popular mods.

Turning: how it really works, and what to do about it

Altering turning dynamics in Freelancer is probably the area that's least well-understood. This is because most of us are used to the way that things turn in the real world, or in flight simulators, which try their best to act like the real world.

Freelancer ain't the real world. In Freelancer, there is no air resistance or friction to contend with, other than that imposed by Linear_Drag. And unlike the real world, where these things are constantly being altered by circumstances (for example, when a plane lowers its flaps, it gains more lift, and thus better turning/climbing behavior, at the expense of speed), in Freelancer, it's a battle between three constants- Linear_Drag, Mass, and Max_Thrust.

In the real world, with aircraft in an atmosphere, the tighter you turn the aircraft, the more velocity you're going to lose, in all directions. This means that if you keep circling the aircraft, you'll lose velocity and eventually stall, but before you stall, your turn will get tighter and tighter.

In Freelancer, this doesn't happen. Instead, once you've hit your maximum rate of turn, your velocity will stay constant. You can't turn any tighter, because your velocity won't go any lower, and neither will you see your POV turning any faster- it's limited by the Steering_Torque.

In the real world, the more mass and length a thing has, the more force has to be applied to turn it. Real-world examples, like aircraft carriers, are great examples- they turn so poorly that they can only dock in the best harbor facilities on the planet, where they have room enough to get to their moorages.

In Freelancer, the Mass of a ship has very little effect on a turn, other than to make a ship continue to drift in the direction you were last traveling, until overcome by Linear_Drag. You can turn your ship instantly, but it will take some time for this to be translated into motion in the direction you now desire to go.

In short, if you want things to turn in ways that are appropriate to your mod, then there are a lot of things to consider. In the following, I'm referring to "spin" where I'm talking about changing the heading of the ship, and "turning" where I'm talking about a change of heading AND change of position (which is what most people think of, when they think of turning).

1. Steering_Torque / Angular_Drag = speed, in degrees, of spin per time unit (I have not yet pinned down the exact amount of time, but it's somewhere around one tenth of a second).

2. Ships stop spinning as the Rotation_Inertia is overcome by the Angular_Drag. Again, this relationship is much like the effects of Linear_Drag vs. Mass, in ship flight models. Setting the Rotation_Inertia too high will result in a ship that keeps spinning and spinning, and setting it low will lead to a ship that has very "crisp" turning behavior. For those of you with "spinning battleship" problems... this is one of the key relationships.

3. True turning behavior is the combined results of 1 and 2, plus the accelerations and velocity changes generated using the formulas discussed earlier.

Thus, if all you change is the top speed, then you'll see a relationship between turning and all of the other variables like this:



In short, it doesn't really matter how fast your ship is going. What matters, for turning, is how quickly you can change your ship's heading, and then how quickly that heading change is translated into a change of position towards the desired coordinates.

A ship with an incredibly fast spinning speed and poor Mass:Linear_Drag ratio will spin around, and find that its velocity is "negative"... it's still drifting towards the previous vector, until Linear_Drag fixes this little problem. So it'll get to a desired location much more slowly than a ship with a lower spinning speed but better Mass:Linear_Drag ratio.

This may not matter in combat, but it might- it depends on whether getting back into weapon range quickly is the primary problem, or whether getting your guns angled to hit the target is the problem. In a mod, designers need to think about this a LOT, if they're building the mod for PvP combat. After all, if there is very little practical disadvantage to keeping your ship at low velocities and simply spinning and using strafe, then players will do that. If players can win a combat by getting behind an opponant, however, and defeat them by superior manuever and by making sure that by the time an opponant can face them, they're out of range... that's another thing entirely, isn't it? I have yet to see a mod that really understands these concepts very well, but hopefully this will help.

AI and Docking problems.

The AI is stupid, but not nearly as stupid as I once thought. So long as the AI is dealing with ships with "tight" handling parameters, it's actually able to successfully fly ships that are traveling at speeds in excess of 300.

If you "loosen" the flight characteristics of ships, though... the AI becomes less and less able to handle the ensuing problems, especially in asteroid zones, where it needs to dodge things. Human players are able to plan their manuevers in advance, often planning several steps ahead. The AI, on the other hand, is pretty reactive in nature, and will crash into asteroids that a human would dodge easily. This is because a human "gets" the idea that with a ship that "drifts" a lot, sometimes you're going to have to take a vector that's counter-productive (i.e., it puts you into the firing cone of the enemy) in order to dodge an asteroid.... the AI isn't that smart. So, dear modders... if you want to build a "realistic space combat" mod... better leave it far more empty than Freelancer's world.

Docking problems are easier to handle. If you're working with a funky flight model for your ships, where ships drift more than the default ones do, then change the following: go into you SOLARS, and change the docking_sphere entries from 40 to something larger, like 400 or whatever. And remove all but the last docking hardponits, so that ships don't have to move on a path- they simply get within the sphere's radius and dock. It's not pretty- ships will get dragged into the object at high speed, if you don't move the hardpoints out of the object- but it works just fine.

Nudge_Force is the final part of the puzzle. Like Max_Force, Nudge_Force is divided by Linear_Drag, to produce a top speed. This top speed and the acceleration curve created by the relationships between Nudge_Force, Mass and Linear_Drag is used solely by ships when flying on autopilot.

Whether you're docking, getting into formation, or using "Go To", this variable has an effect on the way that the ship is able to steer and manuever. Make sure that if you've used a non-traditional Mass and Linear_Drag that you set this variable (and Strafe, for the same reasons) to a value that sets the speed at something fairly low. 30-50 seems to be a good number for the resulting speed, unless the Mass:Linear_Drag ratio is really low, in which case, keep it around 10 or so (or hitting Strafe will send people waaaaay off course).

Edited by - Argh on 10/28/2004 1:01:51 PM

Very very good. However I would have to disagree with you on this:

---

A. Linear_Drag (Ship). This is set to 1.0 on all ships, and should remain so.
B. Linear_Drag (Engine). This is probably the most important physics variable in FL.
C. Max_Force (Engine). This, divided by the Linear_Drag (Engine) results in the top speed of the ship.
D. Mass (Ship). This is the Mass of the ship, in whatever conversion units Digital Anvil used. I'm not sure what their conversion units were- it's not really obvious. Ships that probably wouldn't weigh more than 5 tons IRL are frequently listed as being from 100-175 units in Mass. The important thing is to understand what Mass does in the game engine.

---

A: You can change this to anything you want, FL Fifth Gear changes it to anything.
B: I agree, but FFG turns it off.
C: Divide this by both of the linear drags
D: This changes the damage collisions do and bounce physics

@Blazeme:

First off, glad you liked it. At least this time, it doesn't contain a flawed experimental setup hehe...

---

A: You can change this to anything you want, FL Fifth Gear changes it to anything.
B: I agree, but FFG turns it off.
C: Divide this by both of the linear drags
D: This changes the damage collisions do and bounce physics

---

1. I strongly suggest that people don't change it to anything other than 1.0, because test results indicated that this can have some unwanted results, especially in "arcade-like" physics models. But hey, you can ignore me here. It won't make the game crash. I just don't think it's as stable.

2. Yes, you can turn it off, just like I did in one of the two downloadable mini-mods. Again, it won't break anything.

3. I'll go up there and edit that... I said that explicitly farther downwards, where I got talking about acceleration in more detail... it more or less explains why the standard ships' Linear Drags are all 599, instead of 600.

4. I'm going to run some explicit tests with that, under good experimental conditions. I think that that's actually not correct (i.e., collision damage is the same, no matter what Mass is involved... it's just a function of speed), but I will be the first to admit that I haven't tried this with a ship without a shield on, so my results are preliminary. I'll put up another mini-mod for y'all to duplicate my setup this evening... I have a super-busy day today, so this is it for awhile.

Edited by - Argh on 10/29/2004 6:08:15 AM

Impact Damage: Does Mass play a role?

The short answer is... "yes, but the answer isn't what you expect it to be".

Very simply, higher-mass objects take LESS damage than lower-mass objects, when your ship runs into something.

I've put up two mini-mods to demonstrate these counter-intuitive findings:

Download 1- Super Heavy
Download 2- Super-Light

In the SUPERHEAVY mod, I've set the mass of the Starflier at 1,000,000. Yup, a million Mass. Ramming stationary objects will cause no damage whatsoever.

In the SUPER-LIGHT mod, the mass is now 1, and you actually take more damage when ramming things at the same velocity.

If anybody in the community would like to dispute this claim, which I personally found very counter-intuitive and not what I expected... please, give it a go. My mini-mods should contain all of the relevant data you'll need.

One of the things I did expect, that was confirmed by my experiments, was that the heavier the ship is, the more it wants to spin upon an impact event. This is counter-intuitive, but it's a widely-reported phenomenon in the FL modding community, so I expected it. To prevent this spinning from occuring, you simply have to raise the ANGULAR_DRAG entries... resulting in a lower turning speed.

The net result of these experiments, imho, is that there simply isn't any real reason to have ships with a Mass of larger or smaller amounts. This is probably a controversial statement, since it flies in the face of earlier modder's attempts to work with Freelancer's physics. But if you're trying to get a ship to have slow acceleration/deceleration and generally "heavy" performance... you don't need to do it with mass, and it's actually counter-productive to do so. Instead, use Linear_Drag and Max_Thrust.

The damage incurred from collision is at least somewhat due to the ratio of mass between the crasher and the crashee (if that's even a word) in addition to the relative velocity of the two. In solararch.ini, stations are always assigned a value for mass, and it is often quite high. Setting that value much higher really didn't seem to make the ship suddenly disintegrate when it touched Manhattan's docking ring; however, setting it to 1 made my little starflier take negligible damage from such collisions.

Hmm, I'll have to mess with that, as well as messing with the physical constants, to see what weird things can be done with this. Among other things, it might be fun to try to convince the AI to intentionally ram...

I'm interested in the bounce properties of object collisions... one of the things I'm (slooowly) working on for my mod is some specialized movement types, and I'd like to figure out how to tune collisions so that different classes of objects have different results for collisions with certain objects (i.e., some things die instantly, some just take damage).

I also need to figure out how to either prevent or remove "sliding" between objects that collide, at least under certain circumstances. Haven't really had a chance to figure all of that out yet.

'Arcade like'! Pha! Download Freelancer Fifth Gear and see how much fun it is!
This is what I did:
1. I turned off the linear drag in the engine (to 0) and lowered the actual power of the engine to 18000.
2. I made the linear drag of the ships equal to their mass (although I changed that). So a Starflier was 80 while a Sabre was 150 and a freighter was around 300. The Starflier could reach 225 (1800/80) and this mass carried on to the thrusters so I changed the speed of the thrusters to fit the game.

I actaully got this new flying system accidentily while trying to make the ships have different speeds while using only one comman engine.

So, basically 5th Gear uses pretty "loose" steering. The default ratio in the original game is about 6:1 (600 total Linear_Drag for engines/ships for typical fighters, at a mass range of 100 to 200), which makes for very "arcade-like" steering, as it takes about 1/6th of a second for Linear_Drag to cancel out Mass.

I've decreased this ratio to 1:3 without the game's docking AI giving up in frustration... this produces pretty nice acceleration curves, very "loose" steering, and makes for some much more interesting combat. I think it's cool that your mod makes use of 1:1... that makes Steering_Torque that much more important, in terms of how things actually fly.

So everybody should try out BlazeMe's work on 5th Gear to see what a looser flight model can look like, and enjoy some of the other experiments in game design

Oh, and... I'm definately not implying that "arcade-like" physics are a bad thing. I always put "realistic" and "arcade-like" in quotes, because both are perfectly valid models for game-designers to use when building their mods, and I'm not trying to push people towards a particular model- it wouldn't be fun if every mod used the same physics

Edited by - Argh on 11/1/2004 9:15:14 AM

Reading the beginning of this, I guess you have already figured out how to create infinite velocity. I have two engines I use for this, very nice.
I do not mean infinite force while running. One of the engines has a force of 150000, which will obviously not create infinite velocity.

It takes a lot of messing around with the mass to get it to work (sometimes it just won't work on a ship, and you need to change its properties).

In case you haven't figured it out, I mean cutting engines and having your speed increase indefinitely. (The speed at which you approach infinity is determined by the initial velocity at engine kill)

This is so useful for quickly zooming through a system, and not having an impossible to handle ship.

Yes, you can do that. From a modder's perspective... ah, assuming that the modder wants the game to work in a well-balanced way... this is actually a problem. Engine-kill speed increases can actually be set off in a number of scenarios, which I'm not going to get into, as cheaters will no doubt read this just like everybody else. It's basically a game bug more than anything else. The good news is that it's a preventable one- modding a ship's physics in the correct way can prevent players from ever doing it, and thus anybody who's seen doing it in a mod... is obviously cheating