The mass determines how quickly a ship can change velocities... or at least how quickly it can change speed. When the linear drag on an engine is set lower, mass comes into much greater play to determine acceleration/deceleration. The more mass a ship has, the more linear momentum it will have, and the slower its linear acceleration/deceleration will be.

I challenge you to see how rotational inertia effects collision properties.

EDIT: Also angular drag affects both the start and finish of a turn. Angular drag / rotational inertia = how quickly a ship will accelerate into/out of a turn in radians/sec/sec. I've even tested this out by creating values that would cause a ship to reach maximum turn rate in 6 seconds, and the ship takes roughly 6 seconds to reach maximum rotation speed, and then when you stop the turn, the ship spins around for roughly 6 seconds before finally stopping. In your example with the Patriot, the ship will accelerate/decelerate at roughly 5.36 radians per second per second, and since its maximum turn rate is roughly 1.6 radians per second, it will reach full turning speed and 0 turning speed in a fraction of a second.

Edited by - Uejji on 6/13/2005 1:48:11 PM

I don't suppose you could post the formula to determine acceleration? I'd like to see how it's done.

I never really put much work into figuring it out, but since Force = mass * acceleration, you can take several readings with different mass values and see how it correlates to the engine force and linear drag values.

It may even be as simple as Engine force = ship mass * linear acceleration

Well, since you gave a "rough" number accurate to two decimal points, I figured you had a formula to work from.

That was for rotational acceleration/deceleration.

The formula for that is Angular Drag / Rotation Inertia and is in radians/sec/sec

@Uejji

Look, all I'm pointing out is that making ship physics not part of an overall approach to game-balance is probably not a very good approach to these issues, in my opinion.

It's not that my system for the Toolkit Mod is "perfect", and I provided (at great length, and at great detail) an alternative approach that combines your work with game-balancing variables, to allow everything to come together in a way that would be ultra-realistic, at least insofar as the FL engine allows "realistic", which is not terribly far I don't think that that approach would be "better" than my much simpler approach, however, and I explained my reasoning. If it's not satisfying... well, keep at this, and come up with something you like better- I'm not trying to stop you

Just don't be under the illusion that you can ever seperate the physical performance of an object in a game engine from the other game variables- performance is a very big part of what makes a game object in a 3D world "better" or "worse" than another one. FL is a game where the game design is very intimately tied to the physical behavior of game objects. So is any game that consists of steering a game object through a 3D space. First person shooters, driving games, platformers... it really doesn't matter. Any game where the primary act of players is to steer a 3D avatar and interact with the space and other avatars is a game where the accuracy of physics simulation should take a distinctly second place to gameplay.

And yes, I'm talking about precession. A ship spinning on its center of mass in zero-g is subject to precession, just like a weight at the end of a string that you're spinning around your head is- it will resist changes to the angle of rotation once it's rotating, and the moment of greatest stress upon the structural elements is when you're accelerating it (which is what you're referring to- polar moment of inertia, I believe). At any rate, I was just trying to sketch the IRL issues out, not get into a debate about mechanical engineering principles- in the end, you can make up whatever you want, and totally ignore reality, like FL's game designers did.

nudge_force is used for docking, auto-dodging asteriods, joining Formation,and anywhere else where the game engine wants to move the ship in a fairly subtle fashion without player input. Making its ratio too high/low in relation to linear_drag will result in ships that cannot dock correctly- the game engine's expecting performance in a fairly narrow range here.

Turning behavior does effect collision dynamics, but not in terms of damage. Damage is mass and speed of the two objects. Basically, the higher the numbers (not the ratios) used for steering_torque, etc. are (no matter what their ratios), the "stiffer" the ship's collision behaviors will be, and the less the ship will turn when impacting another game object. If you look at Shiparch.ini entries for all of the giant warships, you'll see some ridiculously large number of zeroes after every entry.

My working theory is that the FL game engine subtracts the values for one ship from the other, and then determines how many radians the ship will turn on the three axis. All I know for sure is that if you put ten zeroes after every number for the values for spin and then ram somebody, then you'll keep going straight ahead, while they'll spin

I like the mission value as far as rebalancing the ships themselves. We could probably start another thread about that.

But what I'm trying to say is that none of that really matters for what I'm trying to get across in this thread. Someone can come up with their own arbitrary figures for everything else via their own methods (be it Freelancer's default values, made up on the spot or a comprehensive balancing system like you suggested) and then just plug a couple of values from that in and put in the numbers that get spit out the other end for the torque, angular drag and rotation inertia.

I can't be the only one who feels a sense of awesomeness when their giant freighter responds somewhat sluggishly compared to a Starflier. I think big ships should behave like big ships and small ships should behave like small ships. I can employ a system not based in physics and get the same effect, but this allows me to say, "Okay, it works on the Starflier and it works on the Humpback, so I know it's going to work on everything else." I've grabbed ships at random and applied these formulas to their agility, and I like what I am getting in-game. Drop the drag coefficient down to 150, and ships oversteer like crazy and take a long time to speed and slow down, and I think "Wow, this is interesting. I wonder what it would be like to dogfight when all the ships behave like this." Or I can set the drag coefficient up to 600 and get a system that behaves very similarly to Digital Anvil's default system.

That's the purpose of this system. Not to say, "I have the most realistic Freelancer space model," but to say, "I have a system that scales easily and, although it takes more calculation work, the end result can be however realistic you want it to be."

For as much as the Freelancer physics system gets trounced, I don't think it is so bad... they just went the wrong way about collecting the variables. Had there been internal calculations to determine all these things and we just put in drag, mass, volume and turn rate, agility would be a lot easier to figure out and work with. Instead, I can make a ship that has a low mass, but a ton of rotational inertia, and that, realistcally or game-wise, just does not make sense.

By all means... playing with some of the "looser" models is lots of fun. If you haven't already, you should go download Warriors of the Sky, Beta One, which is where a lot've my thinking about all of this came from. There you'll see very distorted physics, and you can also see the various tricks I used to deal with the problems they created (among other things, docking behaviors quit working pretty darn fast).

Version 1.2 of the Toolkit Mod features much "tighter" physics than 1.1. This was just a bit of whimsy on my part- demonstrating to modders how scalar changes in the releationships can have big impacts on the way that the game feels. At any rate, while I'd agree that your approach works, it's going to encounter issues with scale- there's that little problem of negative ratios as you get to the high end. If there's anywhere where I felt like my approach was utterly heavy-handed, it was when I felt the need to set a floor value. But I didn't see much choice- if you make the steering too "loose", they simply cannot complete normal FL docking procedures, and will forever circle the DockMounts, unless you raise the size of the Docking Spheres to ridiculous levels (which is the approach I used in WOS, to hide the fact that none of the "ships" could dock worth a darn).

There are other issues, of course. Among them... the AI waits a fairly long time before deciding to dodge an impact with another object, because it's been programmed to "expect" that it can change vector/velocity within a fairly short timeframe, and that impacts won't be very deadly. This is too darn bad, because it means that making an uber-realistic physics sim, including realistic collision damage (basically meaning "run into something and die" simply isn't very practical, unless you used a very carefully designed custom universe (with, say, much more sparse asteroid fields, among other tweaks).

At any rate, there are floors that shouldn't be dropped below. See my warships in version 1.2 to get a rough idea of how to deal with practicalities of massive objects that we want to be truely massive, yet able to function within FL's rather narrow range of designed behavior. With a TC mod, this isn't so much of an issue, of course- nobody thought "insta-dock" was lame in WOS... but with stock FL, it proved a rather large challenge to solve all of the issues, and included wholesale modifications of CMPs, physics tweaks and testing, and a host of other little things.