[Nuke]

lets just put it this way, i could do it if i really wanted to, but i dont. id be much more intrested in an atmospheric/gravitational flight engine.

[Mobius]

I was refering to me, I know you're good

[Nuke]

im not that good.

[Mobius]

You came out with this idea, you must be good.

[Herra Tohtori]

(...) atmospheric/gravitational flight engine.

What's the difficult part in that if you have working newtonian flight model? You just add gravitational acceleration component towards a certain point to all ships in the area. Then you add drag as function of ship's drag coefficient, airspeed velocity and altitude (or actually, static pressure, but that translates from altitude...).

Finally - and this is obviously the most difficult part as it affects not only position but attitude - you need to add lift and control surface forces. These are easy enough to determine - lift is the function of angle of attack, airspeed, lift coefficient and altitude, control surface forces are similar but the lift coefficient can change depending on control input.

Cake!


...not. Most likely the problem would be to make the control surfaces work according to the controls input, and meanwhile disabling the code built-in attitude control. You have already described problems that sound like the engine mkes the ships want to be in different place than the script makes them to go... imagine if the same problem would also appear on the attitude controls. ==unplayable as such.

But honestly, I'm eagerly anticipating the introduction of alternative physics models for FS2_Open, including atmospheric flight. Especially because it will enable the Adama Maneuver in BtRL...

[Nuke]

the main problem i see with the engine is that theres not enough space. youre not gonna have enough of it to make the space>atmoshpere interface.youre gonna have in atmosphere missions and youre gonna have in space missions. sorta the way nebulas work. there is just no means of transition between environments other than going to the next mission.

also the feel will be wrong. people arent comfortable with the newtonian in space flight, and going from freespace style spaceflight to newtonian style atmospheric flight will just feel kinda wierd. i havent really been able to get newtonian to work through scripting. maybe backslash will add an option to force glide mode on all ships, which would spare us the hassel of coding newtonian physics in script. this makes adding gravity and lift easyer.

id mainly use an atmosphere gradient and a gravitational gradient to go calculate drag, lift, and gravitational forces. theese forces will all take the form of vectors and will be summed up for each object, along with that object's induced forces, like thrust. seeing as not many ships in the fs universe posess aerodynamic traits, i want to have support for vtol based lift systems as well (as in strong vertical thrusters). the gradients are based on a 1-0 scale of ground level to the altitude of max attenuation. so using earth as an example. on the ground you have 1 atmosphere and 1 g. at 100km you have the edge of space and tharefore youd be at 0 on the atmo gradient (im not sure how gravity attenuates).

ships with lift surfaces will have a lift profile, which will be a rough approximation of lift producing parts of the ship, mainly wings and lifting bodys. essentially a list of very basic flat polygons discribing the shape, area, and position of the wings. the face normal representing the direction of the lift force, and its position representing the point on the hull upon which force is applied. each lift surface will have other attributes as well, such as lift per square meter (at sea level, and attenuating to zero based on the atmosphere gradient), as well as positive and negative varience range to simulate control surfaces (theese are added to the l/m^2 value). a control axis by which the amount of user induced varience can be shifted, based on control imput (through abstraction of Physics.RotationalVelocityDesired). 2 more vars for min and max angle of attack. the force is calculated for each one of theese surface objects can be calculated and added to the vector sum of all forces applied on the ship. its at best a very rough approximation.

[WMCoolmon]

What you need is a proper physics hook. The only reason I didn't implement that before my last build is 'cause the physics code is fairly complex at a certain level. I didn't know where, exactly, to put the hook to do the most good. (After all, if you override physics, do you also want to override collisions? How will the player's controls be translated into physics values, since right now it's done directly from control_info to physics_info? And many other questions I forgot about.)

[Nuke]

i really dont understand the inner workings of the game physics as it stands. reading physics.cpp usually gives me a headache. so its difficult to name exactly what needs to be changed. idealy we shouldnt have to reinvent the wheel when it comes to collision detection. now i have a rough understanding of how that works and im assuming all you need is a position and a velocity vector (as well as some model data, but that isnt changed buy script).

take the way my newtonian script works. for some reason i was unable to get the proper effect by changing Physics.Velocity. i had assumed all i needed to do was to take the velocity vector, and add an acceleration vector (scaled by frametime) to it. but no matter how i did it it behaved erratically. either i didnt understand how the velocity vector worked (i had always assumed it was where i was gonna be in one second time from the current state), or the game was doing further modification to it, or now that i understand how games work better, that physics was operating in another space (even though world space makes the most sence and is what i assumed in the first place). anyway i still dont understand why that didnt work.

so i then hacked in my own physics, and told the ship exacly where it should be. and it worked. this killed collision detection, but it worked. the reason colision detection no longer worked was (i think) because freespace would move the velocity vector all over the place based on the game physics and the ship position went where i told it to go, and you no longer draw a line between you and where you were going. my way of implementing those physics was rather cheap and hackish.

there are of parts of physics to deal with. linear physics and rotational physics to name a couple. and even if the colision detection is handeled internally, what do you do with the data it generates. for the colision you could have a Physics.ColisionForce and Physics.ColisionTorque. theese would be 0'0'0 unless something colided with the object in question, and if a collision occured in the last frame, they would be abstracted down to an acceleration vector and a rotational acceleration. theese could be added to Physics.Velocity and Physics.RotationalVelocity as desired, or modified as needed to do other things.

now with colisions taken care of, i think 2 overrides are in order. a linear override and a rotational override. theese overrides would disable anything in c that tries to change an object's physics vars, mainly your velocities (linear or rotational). your position and collision would be delt with by the engine. so then all the scripter and the lua interpreter has to do is tally up acceleration vectors, scale them by various vars and build a new velocity vector based on the data. this makes both newtonian and non-newtonian physics models easy to create, as well as other cool things like atmospheric flight.

there are a few things i dont like about some of the existing vars. one thing i noticed which is a real pita is the way Physics.VelocityDesired and Physics.RotationalVelocityDesired seem to be pre damped by the time they reach scripting. when i think see those var names i think "what im telling the ship to do" as in where my controls are positioned, rather than "as close as i can get to what i want to do based on what the ship can do". but the purpose of scripting in alternate physics is to decide what the ship can do, and do do that i need clean, unmodified control imput (though it can be scaled and sensitivity increased as per the options in the control panel). but pass the damp and rotdamp vars to use in a manor decidable by the scripter. pass all relevant physics data from the tables to supply us with tweak factors.

somewhere along the line after the controls update that, iirc, taylor has planned, and when we get things like axial control over lateral and vertical thrusters, id like lateral velocity desired and vertical velocity desired. make them work in the same way as the main thrust. i never really understood the current implementation of Physics.LateralThrust and Physics.VerticalThrust. the script output.html file gave them a value from 0-1 and i never got why it wasnt a -1 to 1 setup. at some point i want to do an engine accurate flight model that uses engine positions, normals and radii to determine what acceleration vectors should be applied to what parts of the hull. theese give ships with things such as vectored thrust some rather intresting flight characteristics.

[WMCoolmon]

LateralThrust and VerticalThrust might be -1 to 1. I felt the same way about some of the :V: comments (They said 0 to 1 where -1 to 1 would make more sense).

Depending on where you're applying the scripting stuff, you might be making your changes after the physics code has run for that frame. If you're using $Simulation that's certainly true. +Override, on the other hand, will run before the default code or hook. You could put your code in it like so:

Code: [Select]

$Simulation: [
   --la de da
]
+Override: [
   --doo bee doo clean the droids
   --(Physics code)
   return false
]
That would keep the behavior of just $Simulation, as you would always be setting override to false, but you could set desired_* values and they would automatically be fed into the physics code for that frame. OTOH they might be overriden by something else in that frame, which may be what the problem was in the first place.

[Talon 1024]

I know a bit of lua, but I don't know the math behind newtonian physics.  Wing Commander had a physics model like this, but the only difference was that your speed was limited to your set speed and you were not able to pass that limit.  (If you ever played WC1, 2, or WCP you'll know what I mean) and I want to do the same with this script.  Can I have some help, please?

[Nuke]

newtonian physics is mathematically very easy, at least the lateral part. im still not totally clear on how to deal with torque. ive taken the idea as far as it can go. the atmospheric flight script has a better newtonian system, but theres still some issues with collision detection that break the whole thing. i may have an idea to get around it but it is untested.

[WMCoolmon]

If you have questions about Newtonian physics, ask away. There's never going to be a better time for me to be able to answer them than in the next few months, as most of the stuff I'm dealing with classes is on the level that you'd want for this, and there are people that live and breathe physics that I see on a semidaily basis.