Triggers or scripts? (Performance-wise)

[Dash5]

In a mission I'm currently working on, when the gunner of a static Dushka is killed, a replacement gunner takes his place. If the replacement is killed, someone replaces him. Right now I'm using triggers to accomplish this. That's 2 triggers x 6 gun emplacements. All the triggers do is check if the previous guy(s) is (are) dead and if the gun is still alive.

Would it be worth it to replace these triggers with scripts that do a check, say every two seconds instead of however often triggers check (how often is that?) or would the difference in performance would be negligible?

[LCD]

scripts r better dan trigers...... if u wanna help preformance on a laggy comp... i think dat functions r even better dan scripts... but its only worth it if da mision goes laggy... else do what is easy 4 u

LCD OUT

[firecontrol]

Right.

They check their conditions once every 0.5 seconds, by the way. I believe all at the same time (for editor placed ones.)
If you notice some jerkiness, or stuttering every half second... there are too many active triggers.

[johnnyboy]

I'm currently using General Barron's ManMG1.sqs script for this in ARMA.  I believe you can find it under scripts in the Editors Depot portion of this site.  (I was going to provide the link, but it appears the Editors Depot is not working at this moment.)

[macguba]

I speak now for OFP, not ArmA, but I suspect it's much the same.

Triggers poll (check themselves) every 0.5 seconds or so if the condition field is "this".   Otherwise, they poll every frame.   Triggers themselves cause very little lag:  in other words it is possible to have a mission with a very large number of triggers.   What causes the problem is loons and wagons interacting with triggers, particularly if they are near the trigger boundary.   

Triggers are very powerful and sometimes wrongfully neglected by mission makers who are coders by hobby and therefore used to scripts.   In general you should start with triggers.

The thing to watch for in scripts is loops.   Fast loops eat resources.   I can't remember the fastest possible loop but there's no point in writing ~0.000001, it will still check every 0.05 or whatever the limit is.

The place where you can really get a benefit is when you really need something to be checked only every 5s, say.  In that case you're much better off with a script.   In this particular case, I'd leave it with the triggers  unless you have a large mission, in which case use the script.   

[Mandoble]

Well, there where I can, I try to avoid the usage of triggers, unless they are mandatory to check the presence of something inside an area. The reason is quite simple, following what many triggers do from the editor is a total mess, it is much easier to follow what scripts do from the "old" Notead 

About performance, ArmA seems to be QUITE efficient with SQF scripts.

[LeeHunt]

hey Dash5,

Event handlers might work well if you are trying to check if a gunner or soldier in the game is killed. There's no script running in the background even at 5 second intervals or trigger running at 0.5 second intervals-- the script only runs if the guy is killed. 
Check this out from the COMREF: http://www.ofpec.com/COMREF/index.php?action=list&game=All&letter=a#addEventHandler

object addEventHandler handler
Operand types:
object: Object
handler: Array
Type of returned value:
Number or Nothing
Description:
Format of handler is [type,command].
Check scripting topic Event handlers for more information.
Index of currently added handler is returned.
Used In:
ArmA/OFP
Example:
player addEventHandler ["killed",{_this exec "playerKilled.sqs"}]

[Dash5]

Hm. Event handlers seem like the best way to do this. Is there any trouble using 'killed' in an MP map?

[LeeHunt]

I don't know for multiplayer to be honest, maybe someone else does? 

[T_D]

EH "killed" is local. So textoutput could be tricky.

[Dash5]

Okay. Thanks for the advice all! I think I'll end up using a script in conjunction with EH.

where's that solved button???