Lets' do
- action
- animate
- animationPhase
shall we?
Command: action - makes a unit perform an action
Syntax:
actor action [
actionstring,
target ]
Scope/results: Use it where actor is local. Results/effects seen on all nodes
Example: dude
action ["EJECT",somehelo]
Common misuse, giving issues in MP:
* players in MP and his AI loonies not getting ejected from planes. Likely reason: ejection script runs on one machine only. >Bzzzt!<
Best practiceThe fix? Make sure that 1) it runs on all machines and 2) enclose the eject action call with
? local _dude: _dude action ["EJECT",_transport]
or similar locality check.
Command: animate - runs animated parts of a model
Syntax:
object animate [
animation,
phase ]
Scope/results: one call affects all nodes in MP
Example: myplane
animate ["cargodoor", 0.5]
Common misuse, giving issues in MP:
Animated part controlled by the same script running on all machines, each one having a go at calling
animate at different times. This leads to the affected vehicle doing some really funky stuff in MP. I recently witnessed a certain radar tower dish do this... while the indended effect was to have it rotate nice and slowly, the multiple
animate calls from different players' machines had it jittering and not knowing if it was coming or going... ;D
Best practiceMake sure only one machine (not necessarily the server, mind you) does the
animate for a certain animated part at a time. Again, this can be done by a simple locality check, should the object to be animated have a script running on many machines.
Command: animationPhase - return the current phase of an animation. Value returned is a number between 0 and 1.
Syntax: object
animationPhase animationScope/results: phase returned might differ between machines. See below for dedicated server gotcha!
Example: _doorPhase = myplane
animationPhase "cargodoor"
Common misuse, giving issues in MP:
OFP feature/bug: sadly, animationPhase ALWAYS returns 0 on dedicated serversMay addons have lots of nifty functionality that uses invisible animations internal to the model as state variables to coordinate these extra features. (cargo loading, towing, rappelling, CAS support feature...the list goes on). In what must be one of the top showstopper bugs/features of OFP,
animationState is useless on dedicated servers. In actuality, this breaks a lot of otherwise fantastic functionality in addons out there, rendering them if not useless but at least shaky for MP useage.
Normal OFP clients, arent't affected - the state of an animation is transferred just fine from machine A to all others if/should a script on machine A issue
animate on a part. All other machines except the dedicated server can then read the current state of the animation just fine.
Take the example of the jittery radar dish I exemplified above. The rotation of that dish is governed by a script that checks the state of the radar animation in order to keep it spinning. In the current version of the addon with that radar, the rotation script runs on all machines, including the dedicated server, if available. The result is that the rotation monitor script on the deddy basically doesn't do anything since it's waiting in vain for the animation state to change from 0. All player clients, however, have scripts that ever so often detects that the dish has turned one whole revolution and issues another
animate call. The end result? A very jittery/shaky radar dish that doesn't really work in MP.
Side note: on camCreateA
camCreated LGB (bomb) on player A:s machine will not be
seen on player B's machine. However, the resulting explosion on A's machine will most certainly kill player B should he be unfortunate enough to stand where the bomb lands. ;D