Triggers, Scripts and
addAction in MultiPlayer v1.10
by Baddo
Recom
This piece of old, but still interesting (and for so
http://kyllikki.tiimipeli.net/cgi/ib/ikonboard.cgi?s=47362bd75f91a11e1451959d6cd4ce42;act=ST;f=7;t=9
It was originally written in Finnish by Kegetys. With
the permission of Kegetys, Baddo has modified and translated the most
interesting parts of the text into English to be readable by a wider audience. Many thanks to Kegetys for the grassroots
level research he has done and for giving permission to submit this to OFPEC.
TRIGGERS
Triggers work in a multiplayer environ
Example scenario:
Trigger with Condition: East Present
Let player X be a west soldier and player Y be an east
soldier. When player Y walks into the
zone of the trigger, his computer doesn’t send any particular information about
the trigger event to player X’s computer. But in a normal situation the trigger
also executes on player X’s computer because player Y’s character is also standing
in the trigger zone on X’s computer.
But what if there is a lag peak, or player X’s / player Y’s connection lags
slightly behind the other players’ connections just at the mo
To ensure this will not beco
1st Trigger:
- Condition: East Present
- OnActivation: trig1Fired = True;
publicVariable "trig1Fired"
2nd Trigger:
- Condition: trig1Fired
- OnActivation: hint "This is a more secure
way to get things done in OFP."; [] exec "bringintheWOMD.sqs"
How this works:
1. Player Y walks into the 1st trigger’s zone and the trigger executes at least (but not necessarily only) on player Y’s computer, setting the trig1Fired variable to True and sending a publicVariable
2. On all computers in the session the 2nd trigger notices that the trig1Fired variable has
beco
This
SCRIPTS
Scripts (started with exec,
addAction) are also executed
locally. This isn’t usually a problem but there are issues that must be taken
into account when designing MP missions, especially when using the addAction command.
Lag and different speeds of client computers causes scripts to rarely start and
end at the exact sa
Baddo’s thoughts: You could
try to reduce this effect with a waiting loop at the end of your intro. Every
client could tell the server that they have reached the end of the intro and
after all clients have reported to be finished with the intro, the server would
tell all clients to start the mission. This would increase the waiting ti
ADDACTION / PLAYER
A script started from addAction is only executed locally i.e. only on the computer of the player who uses the action. You must use the publicVariable command and a True/False variable to activate a trigger if you want your script to run on all computers in the session. Example:
this
addAction ["Bring in the WOMD","activateWOMD.sqs"]
Script: activateWOMD.sqs
trigWOMDFire
= True
publicVariable
"trigWOMDFire"
exit
Trigger:
- Condition: trigWOMDFire
- OnActivation: hint "This is a more secure
way to get things done in OFP."; [] exec "bringintheWOMD.sqs"
The player
command can be very useful when using the addAction command. If you want to add an action to
all players, you might be tempted to put this in Init field of each playable unit:
this addaction["Eat
dust","eatdust.sqs"]
But this is not a good way to do it. All
client computers in the session will execute this line of code for each
playable unit. This leads to a situation
where players will see the added actions of other playable units in their
action
A way to fix this problem is to execute this line of code at the start of the
mission:
player addAction["Eat
dust","eatdust.sqs"]
This code should go into the init.sqs
file or an equivalent place where it will only be executed once for each
player. Do not put this line in the Init
fields of the units because then all players will add the action to themselves
multiple ti
In a playable unit’s Init field:
this exec
"initunit.sqs"
Script initunit.sqs:
if
not(local _this) then {exit}
_this addAction["Eat dust","eatdust.sqs"]
exit
Happy editing.
Revision History
v1.10 - 2006/09/29 - edits, bonus examples and reformat to html - Mr.Peanut