trigger VS waituntil question?

[demonized 20]

I was wondering:

If i have a trigger size 50 with bluefor present, and i have a script with a

waituntil {(player distance) _object < 50 }

Wich one uses most resources of the CPU? Edit: player is on bluefor side.

Is it same?

And what if script is big, but skips down to waituntil part, will it use more because of size even when it doesnt read the whole script but just skips to the waituntil part.

Also, what do i use in script instead of player distance to get

bluefor/side distance object < 50

?

Tried with iskindof, typeof, but no go, probably wrong usage by me or something, can this be done simple or do i need to use loops with nearestobjects or something similar?

Edited January 1, 2011 by Demonized

[bhaz 0]

Don't think you could pull something like that off without a forEach to test every unit on the side - forEach can be very CPU hungry in large doses - so the trigger is likely the way to go for performance in this case.

For your average check though, a waitUntil would be the better option unless you need a response right away, since the 0.3ms delay doesn't apply to triggers.

Reference: Code Optimisation

[demonized 20]

tnx for reply.

[Muzzleflash 111]

Don't think you could pull something like that off without a forEach to test every unit on the side - forEach can be very CPU hungry in large doses - so the trigger is likely the way to go for performance in this case.

For your average check though, a waitUntil would be the better option unless you need a response right away, since the 0.3ms delay doesn't apply to triggers.

Reference: Code Optimisation

Your right the 0.3ms delay doesn't apply to triggers, even though strangely commands such as sleeps doesn't function properly there.

However, triggers are only checked twice per second! So they are not good when you need a response right away. Thats why you can drive through those trigger-based IED's easily by going fast enough.

If you need to check whether BLUFOR is within 50m of an object use a trigger unless the object is moving.

To check if bluefor is within 50m of the object moving or not I would put the following in a trigger which the right settings, not a script:

CONDITION: {side _x == west} count thisList > 0

However, if you really want to have it in a script you will need to a way to find the people in the area. Something like this then:

waitUntil {{side _x == west} count (nearestObjects [MyCenterObject, ["LAND", "AIR"], 50])};

If you don't want air units triggering it remove the AIR from the array. You can introduce a sleep like this (for performance):

waitUntil {sleep 0.5; {side _x == west} count (nearestObjects [MyCenterObject, ["LAND", "AIR"], 50])};

I would not worry about performance even if nearestObjects returned 100 objects within those 50meters that were checked constantly. From my experience the typical reason for bad fps is due to too much AI or "stuff", and not loops that iterate a 1000 times a second.

[shuko 59]

IMO the biggest difference between trigger and waituntil is that you can make the script run on only on the server (excluding dynamically creating triggers just on server). Pointless to me all machines run same check if it can be only be done on the server.

Edited January 1, 2011 by Shuko

[Muzzleflash 111]

Yes agree, however, he has not provided a context so I saw no reason not to prefer a trigger, eg. I can't tell whether he wants to hints something to all or create a vehicle,

[Two Dogs 12]

Yes agree, however, he has not provided a context so I saw no reason not to prefer a trigger, eg. I can't tell whether he wants to hints something to all or create a vehicle,

Can you provide a good example for the rest of us? When to use an editor placed trigger vs. a script running server side.

This is a question I run into alot.

Edited January 1, 2011 by Two Dogs

[demonized 20]

@Muzzleflash - thank you for very useful info and examples.

shk

IMO the biggest difference between trigger and waituntil is that you can make the script run on only on the server (excluding dynamically creating triggers just on server). Pointless to me all machines run same check if it can be only be done on the server.

I totally agree.

I didnt provide a context since i didnt have any, was just generally wondering if i should use triggers more actively or stick with my waituntil commands in scripts as i tend to do now.

---------- Post added at 08:14 PM ---------- Previous post was at 08:07 PM ----------

I would think that when in a single player game you can just use a bluefor present trigger, and for a MP game use a script with waituntil run only on server like this:

if (isServer) then {
waituntil {waitUntil {sleep 0.5; {side _x == west} count (nearestObjects [MyCenterObject, ["LAND", "AIR"], 50])};};
};

This way only the server runs the check using its CPU and no players will notice any usage on their end.

I belive triggers are created across the board, even when created ingame, meaning they will run on every players machine using their CPU.

Now for a small mission you would not notice anything, but for say Domination or other BIG MP missions i would think performance will be noticable when there are alot going on.

Someone correct me if i explaineed something wrong.

[Muzzleflash 111]

The reason for only running something on the server is not because of performance, but because you only want something to run once!

Let's say you want to hint something to all. Hint is a local command meaning if I run the command 'hint' on machine A and not on machine B only the player at A will see the hint.

Triggers placed in the editor are present to all machines. Therefore hint placed in a trigger will hint for everybody when the condition is true. An exception might be if you use the player variable since that is different for each player (eg. you hint when !alive player, however, because you are dead doesn't mean your buddy is!).

The reason you scripts with if (!isServer) exitWith {}; is because you only want to run something on the server. You might want to create a tank. Imagine if you used a trigger with condition time > 30 and then used createVehicle. Since the trigger is with every machine you would get (NumberOfPlayers + OneServer) amount of tanks. However, if you tell the script to quit if you are not the server then only the server will make a tank.

You can do the same with triggers by, for example:

Condition: time > 30
On Act: if (isServer) then {"T72" createVehicle (getPos player)};

Hopefully that clears the issue up. Basically it boils down to locality. Some commands you want to run everywhere, some you don't. If you run a hint command on the server only then nobody will see it.

[bhaz 0]

Note that the createTrigger command is local - so you can create triggers that are only present server side.

(excluding dynamically creating triggers just on server)

Then I read this after posting.

+1 pointless post. :D

[galzohar 31]

You can always just add isServer && ... to the trigger's condition to make it server-only, or create the trigger with a script only on the server. createTrigger is a local command in Arma 2, trigger will only exist on the machine that created it, unlike triggers that were created in the editor which are global - This is especially useful for creating radio triggers that only run on the machine that activated it, since there is no other way to check who activated a radio trigger.

Therefore, the only real difference between trigger and waitUntil is how the condition is checked. waitUntil is checked (or at least tries to be checked) every frame, while triggers are checked every 0.5 seconds. Also, code executed inside a trigger's onAct/Deact field will be guaranteed to finish running on the same frame the trigger is activated (other scripts will be delayed, and also your FPS would drop if you run too much non-interruptable code in there). In most cases (aka when you don't run a huge amount of code when the condition is true and you don't have a ridiculously extremely high amount of scripts running in the background) waitUntil will react faster and a trigger will be more efficient. Of course if you have ridicules script lag (which you should honestly avoid like the plague, if you have this your mission is most likely bugged or at least way too script heavy, again this is an extreme situation), then a trigger will react faster and take up a bit more (because it forces all the already lagging scripts to stop for a bit).

Most of the time it simply doesn't matter and you should just use what you think will be easier for you to keep bug-free.