FreeSpace Releases > Scripting Releases

atomspheric flight

<< < (4/4)

WMCoolmon:
The physics in the freespace engine bear little resemblance to reality. Basically, forces etc. are done away with in ship movement and instead there's a 'desired velocity' vector. The ship "accelerates" to the desired velocity from the current velocity based on a dampening value that keeps the ship from instantly changing velocity.

You can probably do things like rotation from a collision based on momentum, but it pretty much invalidates a lot of 'proper' physics.

Herra Tohtori:
Yeah. Aerodynamics can be modelled in a complex or more complex way. In a relative perspective, the "merely complex" way could be described as "simple". :p

I am also quite sure that most of FS2 players would be content with the crudest of atmo models, if it can just be made playable and accurate enough to not be completely out of intuitional range of any human...


On the topic of lateral pitch... actually you can get almost as much lateral AOA out of afighter-sized airplane as pitch AOA, but it just doesn't change the aircraft's vector much at all, it just makes it fly slightly sideways. Actual degrees of AOA are almost same in both pitch and lateral regard, but their consequences are vastly different. Increasing pitch AOA increases the AOA of wings, which increases the lift a lot, while increasing the yaw AOA doesn't really make that much of a difference in the forces generated by the body sideways. In the pitch case, the wings start rapidly changing the vector of the airplane towards the direction of the changed pitch, while the body of the aircraft doesn't do that. That's why vertical stabilizer doesn't turn the airplane as fast as roll-pitch turn does.


If the airplane had symmetric aerofoils vertically installed at the same place as the main wings, changing the lateral AOA would have a lot more effect on the plane's vector...

Nuke:

--- Quote from: WMCoolmon on December 18, 2007, 04:12:48 pm ---The physics in the freespace engine bear little resemblance to reality. Basically, forces etc. are done away with in ship movement and instead there's a 'desired velocity' vector. The ship "accelerates" to the desired velocity from the current velocity based on a dampening value that keeps the ship from instantly changing velocity.

You can probably do things like rotation from a collision based on momentum, but it pretty much invalidates a lot of 'proper' physics.

--- End quote ---

that said how much you figure changing orientation every frame is going to hurt colision detection?

WMCoolmon:
A lot, probably.

Really what you're supposed to do with scripting stuff is set things up so that the engine can handle all of the interframe movement, while scripting comes in only when something changes. That's very difficult to do with Freespace 2, especially in cases like this, where the physics system is so damn specific.

The camera system is pretty much the best model of how things are supposed to be scripted that I can think of, but even that's a rather basic example.

I've been meaning to add in some kind of hardcoded frame-limit feature, so you could for instance have a hook run only every 4 frames or every eighth of a second or something. This would be good for HUD stuff, although there's the issue of making it so that not _everything_ falls on the same frame; possibly adding an additional field that lets you increment it so it's the 2/8th second, and then you could use other fields (eg update radar at 1/8, left hand gauges at 2/8, right hand gauges at 3/8, do some AI at 4/8, and so on)

Nuke:
that could always be done by


--- Code: ---
if counter == nil then
  counter = 0
elseif counter == 4 then
  doStuff()
  counter = 0
else
  counter = counter + 1
end

--- End code ---

which is about how i intend to to rtt stuff, probibly precomputing all the data to be drawn in the previous frame. id rather frame limiting not be forced since its really easy to set it up in lua. that would also throw off timing too. id rather it be something i can explicitly define. unless of course i could tell the feature how frequently to run. probibly add a +frame_skip: x field after the lua block. ba.getFrametime would need to be aware of the extra time that passed so as not to hurt timing.

still there might be script i want to run every frame say if i calculate the gauge data every 4 frames, is still want to have the draw functions run every frame, so as not to get an annoying flicker. perhaps multiple code blocks per hook, where each could have their on frameskip parameter.

Navigation

[0] Message Index

[*] Previous page