Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Droid803 on January 10, 2011, 04:31:56 pm
-
Kinda want to read an object's x/y/z speed for something (mostly to use in combination of set-object-speed-x/y/z). It'd be nice it if could have the option to both be absolute (in terms of universe) and relative (in terms of the ship).
Or...could this technically be done already?
-
If the game uses a vector setup for the speed indicator, then it should be possible to get the x-y-z speeds after some math.
Assuming the the ship speed is a vector with magnitude M and has angles represented by θx, θy and θz,
Mx = M · cos( θx )
My = M · cos( θy )
Mz = M · cos( θz )
The magnitudes for each direction are Mx, My, and Mz.
-
get-object-speed-x, get-object-speed-y, and get-object-speed-z are in trunk and will be included in the next nightly. Because of limitations of the sexp system the returned values are ints, which I don't think is a big deal because set-object-speed-* only takes integer speeds anyway.
If the game uses a vector setup for the speed indicator, then it should be possible to get the x-y-z speeds after some math.
Assuming the the ship speed is a vector with magnitude M and has angles represented by θx, θy and θz,
Mx = M · cos( θx )
My = M · cos( θy )
Mz = M · cos( θz )
The magnitudes for each direction are Mx, My, and Mz.
Huh? What does this request have to do with the speed indicator?
Anyway, internally FSO represents the velocity of all objects using a 3vec of floats (x,y,z) stored with respect to the "grid".
-
If the game uses a vector setup for the speed indicator, then it should be possible to get the x-y-z speeds after some math.
Assuming the the ship speed is a vector with magnitude M and has angles represented by θx, θy and θz,
Mx = M · cos( θx )
My = M · cos( θy )
Mz = M · cos( θz )
The magnitudes for each direction are Mx, My, and Mz.
Huh? What does this request have to do with the speed indicator?
Think I added a word there... omit "indicator" and it might make more sense.
Pretty much boils down to me not knowing what type of system the game uses for speeds, position, etc. :nervous:
-
The nightly that contains the new sexps is here: http://www.hard-light.net/forums/index.php?topic=74091
If the game uses a vector setup for the speed indicator, then it should be possible to get the x-y-z speeds after some math.
Assuming the the ship speed is a vector with magnitude M and has angles represented by θx, θy and θz,
Mx = M · cos( θx )
My = M · cos( θy )
Mz = M · cos( θz )
The magnitudes for each direction are Mx, My, and Mz.
Huh? What does this request have to do with the speed indicator?
Think I added a word there... omit "indicator" and it might make more sense.
Pretty much boils down to me not knowing what type of system the game uses for speeds, position, etc. :nervous:
Okay. The engine stores all physics information (velocity, position, etc) in a vec3d (a vector of three floats (x,y,z)) with respect to the 'grid'.
-
YAY! <3 's
-
Okay. The engine stores all physics information (velocity, position, etc) in a vec3d (a vector of three floats (x,y,z)) with respect to the 'grid'.
Ok, thanks for clearing that up with me.
Out of curiosity, is acceleration included?
-
Okay. The engine stores all physics information (velocity, position, etc) in a vec3d (a vector of three floats (x,y,z)) with respect to the 'grid'.
Ok, thanks for clearing that up with me.
Out of curiosity, is acceleration included?
Sort of. There is a desired speed as a vec3d and also a float for 'how long' (in seconds iirc) it takes the object to accelerate/decelerate in each various directions. See the definition of the 'struct object' in object.h and the definition of 'struct physics_info' in physics.h. Obviously there are exceptions to this as well depending on what is going on, for example the warping process uses different rules.
-
Huh, that's a bit odd from an physicist's viewpoint. I wonder if :v: made it like that to get around making a drag coefficient?
-
Why would there be a drag coefficient in space? :P
Ok, aside from the whole "space is a fluid" thing...
-
Why would there be a drag coefficient in space? :P
Ok, aside from the whole "space is a fluid" thing...
It's mainly to limit the speeds of craft in the game, as well as affect its handling during sharp turns.
Real-life space does indeed have a sort of drag coefficient, but it's very dependent on how much matter (a.k.a. junk) that's in the area the craft is trying to pass. The more matter, the greater the drag, the less matter, the less the drag.
There's also this theory out there that says a space craft can't go faster than what they eject out of their engines. This has a direct effect on the acceleration of the craft as it reaches its maximum velocity. This can be modeled as a drag coefficient
-
Why would there be a drag coefficient in space? :P
Ok, aside from the whole "space is a fluid" thing...
It's mainly to limit the speeds of craft in the game, as well as affect its handling during sharp turns.
Real-life space does indeed have a sort of drag coefficient, but it's very dependent on how much matter (a.k.a. junk) that's in the area the craft is trying to pass. The more matter, the greater the drag, the less matter, the less the drag.
There's also this theory out there that says a space craft can't go faster than what they eject out of their engines. This has a direct effect on the acceleration of the craft as it reaches its maximum velocity. This can be modeled as a drag coefficient
Drag would cause triple the math to be done for all moving objects on every tick (acceleration, drag, and movement), whereas :v:'s method only adds load when stuff is changing speed or direction.
-
It's mainly to limit the speeds of craft in the game, as well as affect its handling during sharp turns.
Real-life space does indeed have a sort of drag coefficient, but it's very dependent on how much matter (a.k.a. junk) that's in the area the craft is trying to pass. The more matter, the greater the drag, the less matter, the less the drag.
There's also this theory out there that says a space craft can't go faster than what they eject out of their engines. This has a direct effect on the acceleration of the craft as it reaches its maximum velocity. This can be modeled as a drag coefficient
Drag would cause triple the math to be done for all moving objects on every tick (acceleration, drag, and movement), whereas :v:'s method only adds load when stuff is changing speed or direction.
Hmm, yes...
For simplification purposes, the space drag would be omitted, and only the terminal velocity drag would be used. (the space drag could be put in for a later date if needed)
Terminal velocity drag would only be applied to the craft when the player is change their speed or heading. (During glide, the calc's would be omitted.)
My whole point of asking about the acceleration is related to what the multiplayer code transmits.
I'm assuming, that the multiplayer code would transmit the coordinates, velocity vectors, desired velocity vectors, and time to achieve desired velocity over the net.
If the drag coefficients where to be a linear function of the ship's velocity, you could store them in a .tbl somewhere. You could then send over the position, velocity, and acceleration (9 values) and have the receiving computer interpolate the craft's movement until the next packet is received.
The question then would be, if the added math costs would be worth the bandwidth saved...
-
Drag would cause triple the math to be done for all moving objects on every tick (acceleration, drag, and movement), whereas :v:'s method only adds load when stuff is changing speed or direction.
Yeah, but now that we're trying to mess with the physics, we're paying for that decision. A proper force-object model would be so much easier to work with. :(