Free Allegiance Forums

/me runs and hides in fear of what could happen if someone integrated that code into Allegiance

If there was strong interest in this we could give it a go (as in a trial), provided someone wanted to code it up.

But my 'gut' feeling is it would detract, significantly, not add to the game or game feel. This is not 'bumper cars' /tongue.gif" style="vertical-align:middle" emoid=":P" border="0" alt="tongue.gif" /> Just like there is 'drag' in the game, not realistic at all, but makes for a much better 'feel' and thus more fun. Now being tossed a little and shaken up some from an impact is good, but spinning, not so good. Just my two cents.

Lets just say ships have 'inertial dampeners' that minimize the effects of collisions. /wink.gif" style="vertical-align:middle" emoid=";)" border="0" alt="wink.gif" />

I'm with Dogbones on this one. This isn't just a game, it's a science fiction game. You're shooting an energy disruptor at a shielded transport with electro-magnetic pulse missiles.

Don't worry so much about how a ram should affect the target. /mrgreen.gif" style="vertical-align:middle" emoid=":D" border="0" alt="mrgreen.gif" />

In the FWIW category, we considered adding more rotational effects to collisions (the math -- while painful -- isn't that difficult), but decided not to. The main problems were that the modelers would have needed to provide moments of inertia (or I would have had to figure them out), the effects of a collision would become even more sensitive to position errors between clients, and we were behind schedule /doh.gif" style="vertical-align:middle" emoid=":doh:" border="0" alt="doh.gif" />.

Even when ignoring things like the shape of the ships this would be a hassle to code. I will stick it in the folder for "What to do on a rainy day when I should study for exams". Perhaps it will show up as a patch at some point /wink.gif" style="vertical-align:middle" emoid=";)" border="0" alt="wink.gif" />

Is it possible to do it only for AI craft? Rotation only applies to miners and constructors? Perhaps making coding a bit easier and making game a little more fun (would love to ram a constructor and get it to spin a bit right as it tries to plant).

I am NOT so sure I want to get spun around in my bbr run by some noobie who can't line up on his push run.

Avalanche wrote:QUOTE (Avalanche @ Oct 29 2006, 10:55 AM) If I rember correctly the collision code will not calculate any changes in heading, so you will never be turned in another direction by being hit. You simply calculate a combination of a strict ellastic and strict inellastic collision between two point bodies and update the momentum of ths ships. The reason for this is rather simple. It is several, rather complicated additional calcuations to do correctly.

You would have to calculate the center of mass for both ships, find the contact area between them, figure out where the impulse is transfered, the direction of the impulse and then calculate the momentum in the 3 roll axises along with the momentum in XYZ.

If somebody feels like doing the linear algebra and mecanics I can look into implementing it, but I don't really have time to do all these physics calcuations at the moment, even if I probably could.

I can't see any easy way to fudge these calculations and make it work reasonably. Any suggestions are obviously welcome. But, please, grab your physics book before you begin /wink.gif" style="vertical-align:middle" emoid=";)" border="0" alt="wink.gif" />

I actually think that "realistic ramming" could be achieved by ignoring the center of mass of the rammer, since, for all practical purposes, its center of mass lies within it's flightpath. Therefore the only factors are the mass and speed of the rammer, and the distance from the target's center of mass, and the mass and rotational speed of the target (which might serve to slow down or speed up rotation). The problem that I see with this is that constructors and cap ships are going to mass much more than rammers in most cases, and the angular momenum of the more massive object is not going to change that much. Realistically, you would have a great deal more deformation (damage) of the target (and the rammer) than you would a transfer of momentum (think of a VW bug hitting an 18 wheeler in a T-BONE collision...).


Anything smaller than a cap ship or a constructor will have a roughly spherical shape and less mass. For targets of lesser mass (bombers and htt) it "should" be difficult to strike them a glancing blow that would change their angular momentum. (Or else you wouldn't be able to push them successfully with scouts, etc. )


Since there are no real "shields," it is hard to say how they should affect collisions, but we might logically assume that a shield is spherical in shape and frictionless. Shield to shield contact between object of reasonably equal size would then be handled like billiard balls (which I am guessing is the way the game handles collisions at this point). The amount of angular momentum transferred is insignifigant compared to the linear momentum. Good pool players can do "english" tricks with cue balls (by using angular momentum and friction) but generally not after striking a target ball. [Unlike billiard balls, the game does "deform" the shields by sapping thier energy and lessening the amount of energy that deforms the ship and the pilot ("crumple zone").]


So, IMHO the game already handles shield to shield contact correctly. And without shields, the amount of energy that would remain after deformation of ram and target and the transfer of linear momentum is a small fraction of the whole [realistically, it should be mostly suicidal to ram (at any appreciable speed)another spaceship (of almost any size) without shields].


As far as calculations running during the program, I think that is a mistake. There can only be a degradation of game performance by adding more math. However, a lot of game programs use pre-calculated tables that approximate math, because it is a lot faster to look up an approximate figure than compute an exact one. So give us a .dll with values and not a subroutine with math.