Ahoy, long post ahead! Steer clear to avoid imminent headplosion...
sence force = mass * velocity, then force / mass tells you how much energy to add to your current velocity every second. force and velocity are both vectors and so must be handled as such. you determine your velocity by adding all force vectors (normal diretion * amount of force). then divide the total vector by the mass of the ship, then divide again by the length of the frame, and add the resulting vector to the velocity every frame. at least i think thats how it works. please correct my physics anywhere i may be off.
Replace velocity with acceleration... or, rather more accurately, replace force with momentum.
Also, energy actually has not much to do with kinetics, as surprizing as it may sound. Momentum is way more fundamental here. It's not even necessary to invoke the concepts of energy and/or acceleration if you only need to simulate movement in three spatial and one temporal dimension, but I suppose that's more of a matter of huge overhaul and the fact that after that it would be much more difficult to implement FS2-like behaviour again, unless there's two movement calculus choices in the code, perhaps another one activated via "newtonian" flag or somesuch. Anyhow...
Since
F = d
p/dt
p = momentum vector, t = time, d=delta ie. change of.
and d
p = m * d
v (
v = velocity vector)
and d
v = ds / dt (s = spatial dislocation vector)
we got ourselves here a fancy little equation that resolves like this:
F = m * d
v/dt
d
v = F/m * dt
Int d
v =
F/m Int dt
v =
F/m * t + C , where C is integration constant.. further analysis reveals that C =
v0, ie. the velocity at the time when the analysis started.
->
v =
F/m * t +
v0d
s / dt =
F/m * t +
v0d
s = (
F/m*t * +
v0) dt
Int d
s = Int (
F/m * t +
v0) dt = Int
F/m * t dt + Int
v0 dt
->
s = ½ *
F/m t^2 +
v0*t + D
again, D is an integration constant that will, for our purposes, be suitable to assume to be the "zero vector", or the starting point of the spacial dislocation vector...
->
s =
F / 2m * t^2 +
v0*t +
s0There. Gods damn that was a lot of brackets to get the vectors announced correctly with bold letters, for sake of sanity please don't quote that...
Obviously, the toughest part is to make that work in [x,y,z,t] space, which means you need to hacksaw all vectors to three dimensions, but that's trivial number crunching at this stage... for example this is one common way to do it:
i,
j and
k are unit vectors with length of 1 and they are all perpendicular to each other, defining a space co-ordinate system (there are fancy mathematical marks to say that but I can't bother to look for them...) For the sake of sanity, let's say that vector
i defines so called x-axis,
j defines y-axis and
k defines z-axis. The co-ordinate system is right-handed, which means that when X axis points to right, y axis points away from you, then z axis points upwards.
Now we can define that
s = dx
i + dy
j + dz
ks0 = x0
i + y0
j + z0
kv = |
s| / dt
x0, y0 and z0 and v0 are the x,y,z and v from the previous pass.
Note that the values that are actually fed into the program that crunches this bastard are mass, force vector, initial co-ordinates and initial velocity vector. mass is defined by table value (and quite possibly fuel and weapons on board
), force vector is defined by attitude and controls input.
Initial co-ordinates and initial velocity are translated from the previous pass - the end results of previous equation pass are simply moved to form the data basis of the next equation pass. Obviously, the first pass of the equation will need to aquire arbitrary values - location and initial velocity, given by the mission designer. From there, the simulation can proceed quite accurately.
Now, the only thing needed to define is the time change between two equation passes. Basically, the smaller the time shift, the better the accuracy. Real space likely uses Planck's time as dt, but we don't have that kind of resources now do we (no we don't). So we need to define how good accuracy we want. I truly have no idea how good the accuracy should be, but I have a vague opinion that it really definitely doesn't need to be any better than dt = 1/1000 second. That would define the ship's location thousand times a second, which is plenty much and well enough to fool human senses to think it's truly newtonian (when instead it's just a numerical approximation...).
...obviously, that's just the location part. Aquiring the thrust vector is a matter in it's own right, because you need to first define how much net thrust the ship is producing and it's direction in ship's co-ordinates, and then convert that vector to the previously defined base co-ordinate system, based on the ship's attitude vector, which needs to be handled separately by rotational dynamics, which sucks monkey **** and is for the most part much more complex to handle than simple 3D movement... still, same things apply, you need to know the moment of inertia for all three axes of the ship, and then you can handle the rotation vectors pretty much like you would handle linear movement vectors, but that's already handled pretty well enough in FS2 IMHO, you don't really need to add all the pesky things like gyroscopic effect (if you're rotating on longitudinal axis, it would be harder pitch or yaw...)
But that's basically how it would be sensible to build a 3D spaceflight simulation engine in it's very rudimentary basics, without bothering over gravitational effects and stuff. Rotation would not need to really be changed for our purposes - if someone wants to fly realistic space fighter game, go get B5:IFH, get your bone marrow surgically replaced after the blood cancer inflicted upon you by B5:IFH's atrocious difficulty level, and then get back to playing FS2...
Again, this is most likely *not* the way to go with FS2_Open code due to historical reasons'n stuff, but that's the most simple way to do it. The stupid thing is that for compatibility, in FS2 this kind of code would still need to convert old ship tables' acceleration values to available thrust based on the ship's mass, or at least check if there is are or aren't direct thrust values supported. Also, if raw thrust values were added to new ship tables, they wouldn't be compatible with older builds which doesn't make even that much sense...
