Witch will use less CPU ? Trigger, While, WaitUntil ?

[R34P3R 11]

Hey guys. Im working on a new mission and like to know witch of this are better for performance:

- A Trigger placed in Editor

- waitUntil{sleep 1; COMMAND};

- while{COMMAND} do {sleep 1; BLABLA};

problem is currently i have set a lot of AI units with waypoints in Editor. But now my FPS going down from 60 - 80 (Normal) to 20 - 40 FPS

so i think i only place one Unit on mission start and spawning the rest if player unit comes near then 1000m.

Thanks for help.

[jandrews 116]

I use EOS, DAC and AISSP, all depends on what your looking for.

[jshock 512]

The waitUntil and while with a sleep are essentially the same. And triggers, eh, I'm more of the scripting type, but I think it's all about the same as the while/waitUntil, the true issue comes with how "heavy" your condition code is for all of them.

[fn_Quiksilver 1634]

problem is currently i have set a lot of AI units with waypoints in Editor. But now my FPS going down from 60 - 80 (Normal) to 20 - 40 FPS

I would say the performance weight of a single AI unit is heavier than a dozen while loops/waitUntils/local triggers. To get the FPS up, focus on more efficient use of AI to get the job done, and then remove the rest. This may require shaping the scenario around the performance limitations of AI. You can reduce the performance weight of an AI unit by preventing them from going into danger/combat mode where they are doing lots of weighty terrain/object calls. This can be done with some sneaky use of setCaptive and disableAI commands or simply keeping them away from the enemy.

Also, given the same number of AI, less use of groups (and thus separate waypoints) results in less CPU loading. In short, put the AI in fewer groups = better performance.

[mr-blizzard 10]

After doing some testing with Triggers and while loops, it seems that triggers be the way to go. But that still depends on exactly what your doing.

I tested this while creating a mini insurgency, one with while loops and one with triggers, and I got a massive frame drop when I used while loops.

Hope that helps

[jshock 512]

I tested this while creating a mini insurgency, one with while loops and one with triggers, and I got a massive frame drop when I used while loops.

Then you probably didn't have the loop setup properly.

[austin_medic 109]

The performance impact of these is pretty much unnoticible unless you are running hundreds of them all at the same time and it gets backed up in the scheduler waiting for execution.

Watch that you put sleep inside a while loop otherwise its going to run thousands of times every frame and its going to swamp the scheduler.

[f2k sel 164]

Jshock what was the delay when using the while loops as triggers are only checked every 0.5 of a second so if the while is running faster it could account for time difference.

[Heeeere's johnny! 51]

The main difference between a trigger and a waitUntil is that a waitUntil checks its condition roughly on each frame, depending on the complexity of the condition. A trigger checks its condition roughly every 0.5 seconds.

Depending on how critical timing is, a while loop with a custom sleep may obviously be most performant as you could set the sleep to e.g. 5 seconds which would mean less CPU usage than a trigger and way less than a waitUntil.

BUT another difference between an while loop and a trigger is that the while loop is 100% SQF while a trigger is partly C++ as all the logic around it, including the sleep, is C++ driven. There may be a major difference in performance when you compare plain SQF scripts to scripting commands doing the same work.

For instance, if you had an array and wanted to delete a single element from that array, it takes by far more time iterating through that array, checking each element to fit a condition and at the same time creating a new array without that respective element, than doing the very same thing using the command deleteAt.

In the end, I'd allways recommend to use loops carefully and reasonably. For time critical area dependent events bound to AI and player movement, I use a script which checks a units presence with a trigger and when a unit is close to the respective area, the trigger spawns a waitUntil on that unit and removes it again when that unit is out of range. That way, I minimize CPU load and this can be driven even more performant using a well scripted while loop.

Edited March 1, 2015 by Heeeere's Johnny!

[R34P3R 11]

I would say the performance weight of a single AI unit is heavier than a dozen while loops/waitUntils/local triggers. To get the FPS up, focus on more efficient use of AI to get the job done, and then remove the rest. This may require shaping the scenario around the performance limitations of AI. You can reduce the performance weight of an AI unit by preventing them from going into danger/combat mode where they are doing lots of weighty terrain/object calls. This can be done with some sneaky use of setCaptive and disableAI commands or simply keeping them away from the enemy.

Also, given the same number of AI, less use of groups (and thus separate waypoints) results in less CPU loading. In short, put the AI in fewer groups = better performance.

Hmmm the AI units are 2000m away from my spawn position and dont have any enemy contact at this time.

[guy123 10]

As has already been said - but to confirm. Triggers are far less intensive but check their conditions only every 0.5 seconds. Whereas a waitUntil checks every frame.

The main performance consideration for the waitUntil is the code it runs before it hits it's condition (last line). If it is being asked to perform cpu intensive tasks such as a config lookup every frame then it will cause massive lag. If this must be done it would be much better to put it in a trigger.

When it comes to checking AI, make sure you aren't performing a loop within a loop forEach AllUnits, this is almost always avoidable and can cause big performance issues.

[R34P3R 11]

ok thanks now i grouped a lot of Units together and using waitUntil{sleep3; player distance < 1000} now my FPS are mutch better.

[Heeeere's johnny! 51]

ok thanks now i grouped a lot of Units together and using waitUntil{sleep3; player distance < 1000} now my FPS are mutch better.

I guess you just didn't copy-paste the code as "player distance < 1000" will not really work. ;)

[R34P3R 11]

I guess you just didn't copy-paste the code as "player distance < 1000" will not really work. ;)

No :D .. (player distance _unit) < 1000

[R3vo 2652]

Hmmm the AI units are 2000m away from my spawn position and dont have any enemy contact at this time.

Use the Simulation Manager module. Or http://www.armaholic.com/page.php?id=26093

There are tons of options to optimize missions. Bohemia should start to make those more obvious for beginners. Would solve many "performance issues" in my opinion.

[barbolani 198]

EOS COS Etc rely on triggers not for performance, I asked the author for the spawning system I use in Antistasi, which is own made, and has a total different approach than EOC / COS.

If you are building a spawn /despawn system, having a trigger for each zone may consume a lot more than a single script which checks distance for each zone under certain conditions.

My system (unpbo Antistasi, the script is distancias3.sqf) is not perfect and may have improvements, but works. It takes about 0.0x seconds to make the check to the whole island with all the units involved, which may be around 200 hundered at a time. It does not involve all the units because I wanted to be selective on which unit can make a zone to spawn or not (generally speaking, player controlled, players and attack units of each side).

Fully MP compatible (took me a lot of work on this, and that's why EOS uses triggers, because of MP issues).

With this, I have been able to populate the whole Altis. Now what consume more or less CPU will be your spawning system and how "special" it will be (if you will use lots of building detection, lot's of units etc..).

So: if you are planning to put just one trigger, my suggestion is not to mess up with scripting if the condition checking can have about 1 second. If the condition needs to be checked on each frame or, lets say every 0.1 seconds, then use a script.

Ad if you are planning to use a lot of triggers, then yes, build a script to do in one single instance all the checkings.

Hope this helps.

[zapat 55]

"Triggers are far less intensive but check their conditions only every 0.5 seconds. Whereas a waitUntil checks every frame."

Waituntil {sleep 0.5; CONDITION};

It checks the condition every 0.5 secs as well.

For spawners, despawners the best solution is to have ONE loop handling all units. You'll have a lot more control than having 50 triggers all over the place.

And it is enough to run a distance check (or most other checks) like every 1-2 seconds or even 5. Unless the player travels 1000km/h it is impossible to spot when the actual spawns happen.

[Imperator[TFD] 444]

Use the Simulation Manager module. Or http://www.armaholic.com/page.php?id=26093

There are tons of options to optimize missions. Bohemia should start to make those more obvious for beginners. Would solve many "performance issues" in my opinion.

Unless the OP is trying to do something fancy I don't see why he cannot just use the vanilla Simulation Module in the editor that allows a user to define radious and exceptions for air vehicles?

This will fully disable the AI simulation until a unit enters the defined radious.

I utilise a method of hiding/showing the AI I've placed in some of my missions to help with performance loading with the number of AI in my missions as the Hide/Show module also disables simulation.