LAG factor, trigger v.s sqf

[laggy]

Hi all,

Haven't tested this or anything, but got curious about this subject as I was designing missions.

Does anyone know if there is a performance difference between a trigger:

Code: [Select]

BLUFOR detected by OPFOR, once
Radius: 500
Cond.: guy in thislist
onAct.: spotted = true

and this script that incorporates a game logic called "sectorLogic":

Code: [Select]

_finders =  nearestObjects [sectorLogic, ["ALL"], 500];

while {! spotted AND isServer} do
 {
      {
        if (side _x == east AND _x knowsAbout guy > 0) then
        {
            spotted = true, publicVariable "spotted";
        };
      } forEach _finders;
sleep 0.5;
 };

Variable "spotted" first initialized as false of course.
Sleep 0.5 is afaik a triggers standard "check loop intensity".

Maybe this was not the ideal example, but I think you get an idea of my thoughts.
What's your input, are triggers needed at all concerning performance, or just more user friendly?
Maybe it's better (performance wise) to have a shorter range "detected" script attached to a unit than a huge trigger covering a whole island.

Laggy

[Spooner]

Well, a trigger checks its condition exactly every 0.5s so on the face of it it is equivalent to a script that loops every 0.5s.

However, in this case, a trigger will be significantly faster since:
* triggers find things vastly quicker than any near(est)Object(s) type functions.
* You are manually iterating through a large number of iterations, especially since you have to use a nested loop (so 100 OPFOR looking for 10 BLUFOR has to check 1000 relationships).

You also can't assume that a trigger's DETECTED BY functionality acts exactly the same as what you are doing manually.

However, I suspect a trigger which has condition like "x > 5" and action "frog = 12"
would run slower than the equivalent SQF script: "while { x <= 5 } do { sleep 0.5 }; frog = 12"
That is, triggers are probably more efficient when they are doing trigger-like things, such as when the PRESENT or DETECT is the important part of what they are doing, rather than a "scriptish" thing which is what I'm considering in these latter examples.

[Worldeater]

Just two comments:

1. To make the while-loop work like a trigger the line containing nearestObjects should be inside the loop not outside.

2. If possible try to avoid using nearestObjects with "ALL". Be as specific as possible. This won't speed up the nearestObject command but it will speed up the processing of the returned list!

For example, using [...,["ALL"], 500] on an empty map in downtown Paraiso returns more than 700 objects (like road signs, insects, trees, park benches, walls, etc) and all of them would have to be checked for being opfor. Whereas using a slightly more sophisticated "filter" like [...,["AllVehicles"], 500] reduces this number to one here (the player's unit since the map is still empty).

[laggy]

Thanks a lot both, that's what I expected, it makes sense.

Laggy