[Herra Tohtori]

I just hope I didn't make any stupid mistake there...

The notation might not be extra-accurate since vectors and deltas are not actually the same thing, but for all intents and purposes and avoiding even more breckets and formatting I simplified things a bit there. It shouldn't affect the maths in any way however. Also note that the equation for dislocation vector that pops out can also be formatted like this:

s = ½*a*t^2 + v0*t + s0


which is the standard "learn-by-heart" equation that is first taught in school physics to calculate the location of an accelerating object, without any use of differential calculus... which IMHO sucks ass and is the exact wrong way to learn physics because you don't really know where all the equations pop up, you just need to memorize them mindlessly. Only way, way later in high school when the differential calculations were presented to us it became clear why and where that equation comes from... obviously I consequently tried to make a 2D orbital simulation (with a big object on origo) on TI-86 but it never worked out as it should have. Perhaps it's time to brush that up again...

[Flaser]

its sorta like that but the box subdivides and then checks which divided section the projectile is in, and it repeates untill the box is so small that its position is pretty much spot on with the projectile. but if you have a situation where you, your target, or your shot is moving about a hundred meters every frame, then that meathod doesnt work so well. this can be fixed with extra math of course, draw a line between the current position and the last position, and check every point along that line for a colision. this is actually of math. especially considering all those points have to be transformed into model space (or is it world space) to see if they hit any bounding boxes.

No force to mass conversions... just an arbitrary value I settled on after much testing.  Yeah I know, but I figured in "semi-realistic" Freespace terms the ships would have the right engines that had the proper thrust to propel them... so that's what $Forward accel is for.  Whatever that means
The arbitrary value happens to be 0.16 * 1+(the acceleration time constant, whether forward or side or afterburner) if you must know.  I'm open to suggestions to how to make it better, but last time I posted the math people ran screaming from the thread

im not gonna really make any suggestions. the freespace engine isnt really cut out for newtonian physics at this time. not that i dont want them, i do, it just seems we need a bunch of other things for it to work. if collisions dont kill you the edge of the mission will. then again the math for newtonian is much simpler than what freespace uses. it starts getting confusing to mod when none of the values in the tables work anymore. you have to know 2 things to determine how fast you can accelerate, how much mass your ship has, and the force output of your engine.

since 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. each force vector is essentially your engine normals backwards, times the amount of force that engine is producing at the time. 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. i need to have this nailed for a little something im working on.

Hmm...what if we had an "in-between frame", that doesn't actually get rendered but is only used for collision detection?

Namely do a whole frame collision calculation as if "time was doubled"/"velocities halved".
This should only be done if there are models present with sufficiently high velocities, and during the "in-between frame" only the high speed objects should be checked for collisions.

If the velocity is so extraordinary we can halve it again and do 4 successive in-between frames.
Fine tuning the velocity limit (the point where a sinle frame transition creates a noticable error) could also depend on the model size.

[Unknown Target]

Is this working with BtRL yet?

Because it would be great if it did...

[jr2]

Hmm, wikify this stuff, anyone?  Or not?

[Backslash]

Ok now you guys with the math almost scared ME off

Update:
http://files.fringespace.org/bs/build20070509.rar

I fixed a bug with ships slowing down faster-than-usual when not gliding.  Also added the negative value idea for $Max Glide Speed, let me know if it works how you like.

Known issue: engine trails are not always working.  Bug since April 13 or so.  Working on it.

jr2, good idea.  I'll add it to the wiki once I'm sure things are working right.

UT - um, yes it works with BtRL, but BtRL is not working with it    If you want to try it, make the temporary changes I showed in the other thread    Remember, HEAD is where stuff gets put to test... if it works well THEN it gets added to 3.6.9 branch.