Now, another ugly drawing: the center of the ship is the X, the force getting applied to the ship has a magnitude of F, and the distance between the center of the ship and the point where the force is applied is D. For simplicity we will assume that the force is being applied at a right angle.

F
/
/
V
<=== D ===>X<=== D ===>

Such a case would occur when one ship hits somewhere off-center on another ship (i.e. a fighter collides with the side of a battleship). Now, as you know this will create a torque around the centerpoint; we will label this torque T, which in this case has a magnitude of F*D. This will cause the ship getting hit to rotate around its centerpoint. In addition, the centerpoint of the ship getting hit will move linearly in close to the same direction of the applied force, just as if the incoming ship hit square in the middle (it won't be exact since both ships will actually deflect off to the side somewhat, but this will only be significant if the ship is hit way off center; we'll just pretend it's strictly linear for now). Keep in mind that although momentum and energy are conserved, force is not; the same force can cause both linear and rotational acceleration.

So, let's assume that the ship getting hit starts out with no linear velocity (v) or angular velocity (w). It doesn't particularly matter (yet) how fast the incoming ship is going, so long as it provides a force of impact when it hits. In addition to the symbols defined above, the letter i will represent the rotational inertia of the ship getting hit (around the axis in question) and m will represent the mass of the ship.

1: T = F * D
. this is what we start with
2: T = i * (dw/dt)
. the definition of torque; dw/dt == angular acceleration
3: F = m * (dv/dt)
. the definition of force; dv/dt == linear acceleration
4: i * (dw/dt) = m * D * (dv/dt)
. substitution back into step 1
5: (dw/dt) = (m * D / i) * (dv/dt)
. moved i to the other side
6: w = (m * D / i) * v + C, where C is some constant
. integrated both sides with respect to t
7: C = 0
. at time 0, we assumed that v will equal 0. Thus, in order for w to equal 0 as well, C must equal 0
8: w = (m * D / i) * v

If we assume that the force F is applied only for a short period of time (as would occur during a collision), then this means that after the collision the angular velocity of the ship getting hit is related to its linear velocity by step 8. This is a very useful result, as it provides a definite (if clunky) way of deciding how a ship should behave when it gets hit; just choose the ship's mass and rotational inertia to suit what you want. So easy, right? Of course not. In practice it's a pain in the butt to get right, but this is a good starting point.

(continued in next post)

Finally, we have to consider that a ship doesn't drift or spin on its axis forever... as you know it slows down over time. I derived the equation describing ship velocity as a function of time time in another thread, but that was for acceleration and now we're dealing with deceleration (though it turns out that the results are virtually the same). But it doesn't hurt to derive stuff again, so:

m == mass; a == acceleration; D = drag coefficient; v == velocity; v0 == initial velocity; t == time; ln = natural log, or log base e

1: m * a = -DRAG
. drag is the only thing acting on the ship, since the engines aren't active.
. drag can be rewritten as D * v
. also, acceleration can be rewritten as dv/dt, as was done previously
2: m * (dv / dt) = D * v
3: dv / v = (-D / m) * dt
4: integral(dv / v) = integral ((-D / m) * dt)
5: ln(v) = (-D / m) * t + C
. C is some constant that we must solve for
. note that when t = 0, v = v0, as this is the definition of initial velocity
6: C = ln(v0)
7: ln(v) = (-D / m) * t + ln(v0)
8: v = e^((-D / m) * t + ln(v0)
. raised both sides to their power of e, elminating the ln on the left side.
9: v = (e^ln(v0)) * (e ^ ((-D / m) * t))
. e^(a + b) = (e^a)*(e^b); it's a useful little trick
10: v = v0 * e^((-D / m) * t)
. e^ln(a) = a, which was also used in step 8

So, we have a way of relating the velocity of the ship at any positive time t to its initial velocity. The case for rotational behavior is entirely parallel to the linear case above, i.e. you end up with w = w0 * e^((-D / i) * t). To get a nice, easy-to-use number out of this, consider the time it takes for a ship to slow down to 10% of its initial velocity.

1: v = .1 * v0
2: .1 * v0 = v0 * e^((-D / m) * t)
3: ln(.1) = (-D / m) * t
. took the ln of both sides after elminating v0
4: -(m / D) * ln(.1) = t
5: (m / D) * ln(10) = t
. ln(.1) = -ln(10)

Again, for the rotational case, this becomes t = (i / D) * ln(10).

So, you've got three things to take into consideration when considering collision behavior:
1. The linear velocity of the ship that gets hit.
2. How much that linear velocity will translate into angular velocity.
3. How long it will take the ship to stop drifting and spinning once it gets going.

These are more or less governed by these equations:
(for explanations of what the variables mean, go read the rest of the post, you lazy bum! )
1. v2 = (m1 / m2) * (v0 + v1)
2. w = (m * D / i) * v
3. linear:: t = (m / D) * ln(10)
angular:: t = (i / D) * ln(10)


Ok, so that's all I've got right now. From what I've observed in-game, my derivations are pretty much dead on, but if you happen to find something that isn't as it should be, by all means say something.

Wow, Dev... good stuff here. Do you have any experimental setups available?

Not really... for the most obvious results, I prefer to take away the thrust of transport engines (so they can't move) and then alter their ship stats to suit my purposes. They're pretty common in Manhattan space and furthermore they are of suitable length to try ramming at various points. All in all, excellent test subjects.


Oh, another point I should probably make regarding collisions with stations:

Because stations simply cannot move, they can be treated as having infinite mass (the mass defined for them in solararch.ini is for determining collision damage rather than movement behavior). Thus, when you collide with a station, your final velocity will exactly equal your initial velocity, just in the opposite direction (this is if you crashed head-on; not surprisingly if you hit at an angle then you bounce off at the expected angle with the same magnitude of velocity). This is pretty easy to verify; just hit engine kill and smash right into a station, you will bounce off as described. If you don't hit square, you will spin; as I derived before, how much you spin around an axis is given by:

w = (m * D / i) * v

where v is the velocity you had before the collision. Note that with drag and force in the picture you will obviously not drift and spin this fast for long, but this is to be expected and would apply to any study of collision behavior.

Edit: Let me go on to say that you bounce off with your incoming velocity provided you only spin a little... it is possible that if you spin fast enough the energy that is sunk into rotating your ship will reduce your linear velocity quite a bit. It's kind of difficult to determine, but since momentum is out I figure that they must still use conservation of energy on its own to determine ship behavior, hence why it would matter.

Edited by - Dev on 12/5/2004 2:51:42 AM

Not to put a damper on things...
To what end would this information be useful?

What I mean is, Yeah, information for information's sake is fun, but, as this is the editing forum, how can the data be translated into a useful adaptation that would matter in a mod of this game?

There are variables for modifying mass, velocity, collision damage, etcetera.
Angular trajectories would only be useful, IMHO, if one were planning to set up a "gauntlet" of sorts.
IE: To traverse a given path, "bouncing" off obstacles would be required/undesirable or dire circumstances would occur.
However, setting up such a scenario, so that it was both unavoidable, and hazardous, would be a daunting task.
And, IMHO, if such a scenario were actually created, few, if any, players would actually enjoy it, or appreciate the calculations that were require to accomplish it.
After all...
How many actually enjoy the Hovis race in FL?


Watch your 6!

I dunno about you, Warzog... but I've applied almost everything I've learned from research threads like this one to the development of game physics in Warriors of the Sky

Seriously... learning more about what causes object interactions in FL's physics engine is very useful theory... that we can apply if we're working on new game types, using the FL game engine. I think it's very valuable to know the true properties of a thing... otherwise, you're just acting like a mechanic who only vaguely understands a toolset, rather than as a game designer with the full knowledge of what you're applying. Just my 2 cents...

Here... lemme make this more concrete.

Collisions could be used in various ways:

1. You could make a game of "space destruction derby", using the FL engine, where running into people was an important part of the game design.

2. You could make a mod where missiles didn't do much damage, but made ships spin like crazy... making missiles a specialized tactical tool.

3. You could make capships that were rock-solid, and never, ever spun out.

4. You could make a racing game, where the objective was to go through a number of Systems/Checkpoints, from A to Z, and bumping into things was very carefully calibrated so that the effects were fun, as opposed to sucky. Think F-Zero, with the FL engine... it might be pretty cool.

Those are just off the top of my head... the FL engine can do a ton of things that people just haven't quite gotten around to yet... mainly because they aren't aware that the engine has a lot of possibilities that haven't been explored yet

Edited by - Argh on 12/5/2004 5:07:04 AM

a few notes: (btw, nice posting dev)

mass of solar objects affects their spin (if they have it).
i had a problem when creating a "radar dish" - ramming it made it spin just like ships - but it remained stationary, so it didnt move - but spinned like crazy.
increasing the mass of it helped with this.
(that solar panel thingie makes up for a nice rotating radar dish on big bases - aaah, excelcia memories coming up )

@argh:
#1: a very long time ago, Khaosprime had a seriously increased collision damage.
turn on cruise in badlands was sure death (with the increased cruise speed and engines). it was all fine till the NPCs came into play. they ignore collision damage, and it was frustrating to see that you got rammed to death by a couple of stupid starcrappers who kept bumping into you - and you didnt damage them at all by ramming them.

#2: see [explosion - impulse = ... lines

#3: its been done - would need to dig out the old stuff to post it. meanwhile most mods that feature capships have their physics right (i.e. they dont spin like crazy when getting rammed)

#4: would be fun, yeah problems see #1.

Fjord

Sorry to be a "grave digger" on this....

but

What is the fix to eliminate Large & Capital ship spin due to collisions with npc's?
I'd like to see hard numbers and formulas.

i cant remember, maybe uping the mass? xD

other than that editing the sur's inertia (thanks LS) would sort it

youll have to hex edit tho, and finding the values is a pain >.<

Universal Modding Forums

I'm looking for formulas.
Once I have the formula's, I can plug in the necessary numbers and get the answers I'm seeking.

Did I already direct you to this topic bud?...

Big ships spinning and bouncing on collisions

I already tried fixing the inertias in the .SUR files - all 150+ of them - no change. But this topic gives my findings which did improve matters dramatically.


Roleplay: - the art of self-deceipt!

Well, I'm looking for information on item #3 under Argh's post.
Making capships "rock solid" .

here is the deal.
What I had them set to, worked like a charm in Open Single Player.
Capships were as solid as The Rock Of Gibraltar.
BUT
when I put the very same ship in Multiplayer...those figures went OUT THE WINDOW and the ships spun badly during collisions with npc's.

What is even more infuriating, is even though those massive ships have shields, those blasted npc's seem to ignore and and pass through it. So, when the hit the center mass of the ship...everything goes HAYWIRE. Not just in that way though. They can "glance" off the shield (at times) and send the ship into a bad spin.
So far, I've got some of the spin limited to about 1 compete circle by readjusting the mass figures, but when the npc's are "riding" my back...the ship goes crazy.

It really baffles me.

Edited by - Rankor on 9/24/2007 5:34:22 PM

Rankor, seems apparent to me that SP and MP work virtually the same except in who handles what process - in SP, collision events are under stricter control because the server and client processes are operating as one, in MP collision events are based on predictions and certain sacrifices, like coding obstacle avoidance into NPCs but no realtime collision detection for them. the result i guess is that the server can easily get the calculations wrong, and apparently does, as when you fly out of control from NPCs entering your ship. fyi the numbers i use based on Arghs toolkit notes and stats will produce a very damped spin symptom, with ships only responding to NPC invasion by spinning slowly and more importantly without lag. no magic formulas or anything, i basically just used factors of 10 to get the ratios correct and did my testing by smashing into asteroids at every angle, camping in front of NPC paths in engine kill/engine on, fighting npcs and taking explosion-impulse hits from flak cannons, in my experience it is not complicated - you need to kill the amount of force available to NPCs as well as increase the proportions of capship's stats..

i don't have my mod files in front of me atm or i would share some exact numbers, i may report back later tho



Edited by - Cold_Void on 9/24/2007 6:13:04 PM