Trigger lag is something I've spoken about before, but I never really got any set-in-stone answers. The aim of this post is to determine the following things:
1. Assuming all 8 players are in use, what would be the recommended limit of triggers being activated per trigger-cycle per player?
2. What is a healthy total trigger count vs. a dangerous trigger amount in a map?
3. What are the risky conditions/actions that may cause lag?
4. Knowing that the 'bring' condition creates lag, is it a bad idea to constantly track a particular unit for each player?
5. Do switches cause considerable lag if randomizing them?

Furthermore, here's a dilemma I can't answer. Recently I've been playing my latest map (Fury of Immortal Heroes) and the game lag is minimal up until the game reaches 12 minutes game-play. It seems strange Starcraft would suddenly start lagging at a particular point in the game each time. I was told the apm was over 9k, I'm not sure if that has anything to do with it...

Does anyone know how to resolve these questions, and if not, direct me to a good source that will?

Thanks

http://www.staredit.net/topic/11648/

1. Depends on what the triggers are doing. If the triggers are Always () with Comment for an action, you can have as many as you want. If the triggers have lots of Bring conditions with Create or Kill actions, then fewer. It also depends on how fast your computer is - slower computers will suffer 'lag' compared to faster computers when running the same triggers. Remember that triggers in SC were designed to be run every 2 seconds, and with hyper-triggers we instead run them 12 times a second, which is significantly more workload.
2. Depends on what the triggers are doing, as above.
3. There is a map somewhere that has various different conditions/actions examples showing which ones lag the most. Generally Bring conditions are quite costly, and anything that involves changing units on the map (creating, killing, setting health) will be more computationally intensive than a Show Text action, for example.
4. This in and of itself is not "bad", it depends what other triggers you have. If you have lots and lots of bring conditions, removing 1 single lot of bring triggers won't change your lag situation much at all. Likewise adding another won't be a huge problem as well. It's like rain - a few rain drops don't hurt anyone, but a flood does.
5. I believe not.

In general, if you need to use bring conditions, it's best to place them at the bottom of the conditions list. You should generally order your conditions with the one most likely to fail to be met top-most. For example if you only need to do the Bring condition when the player has a DC of 3 for Zealot, then you would check the DC before checking the bring, because DC operations don't involve units on the field and so they're quicker to execute. On the other hand, if you have a switch that is almost always Set, then putting "is switch unset" as your first condition isn't ideal because you'd be better off putting one of the later conditions before the switch check because the switch check will almost always pass and the idea of ordering your conditions is to produce the least work possible so you want a failure condition detected as early as possible.

Edit: Sacrieur's link covers a lot of this, and you'll note I even replied to that thread talking about cull count vs cost. My above summary is slightly misleading: really what we want is for each trigger to do the least amount of work possible when checking conditions. SC checks conditions from top to bottom and then exits the trigger as soon as it finds something false. This means we want to put the least costly conditions highest in the list, and the most costly conditions last. When two (or more) conditions have exactly the same costliness, we want to put the condition(s) that is most likely to fail first in front of the other condition, because it's better to check 1 condition and exit than it is to check 3 conditions and exit.

Post has been edited 1 time(s), last time on Nov 6 2011, 8:24 pm by Lanthanide.

1. trigger count can be ignored. It's more important to have a look at every condition that involves living units like "bring". If you have death count or switch conditions, put these above them. I'm not sure, but I think that that might help. I didn't test that, but in theory it should work like that [I would implement it like that])
Else you should check the "bring" once and save the result in a variable that is used for the rest.
2. see 1
3. everything that deals with alive units and/or scanning stuff on the map like bring, orders, kill, move, give, ai script, ...
4. not really
5. it should cause a very tiny amount of lag. I just guess that you randomize only a few switches per trigger run. In the end these are only a few calculations. Math can be considered fast, comparing much stuff (searching) is slow.

My 71k trigger map (Diablo for sc1) can be handled in singleplayer on modern machines without lag (except the lag of a new operation system that didn't receive the necessary settings to run the game without lags).

How many triggers do you have? Are bring conditions on top of the list?

The worst lag source I experienced myself:
Move a group of ground units to a region that is already crowded with many ground units. It will pick each unit and check the whole 10x10 area to find a place where it can place the unit. With enough units and enough repetition (every trigger cycle), it comes close to freeze the game. ;D

well that's helpful so far. however, incidentally i've always used death counters as first in the list, and bring conditions always after the dc's. so i'm still confused as to why my map is lagging. also, i have another question. i understand that death counter conditions are minimal to process, but what about death counter actions? i use a hell of a lot of death counter timers that activate every trigger cycle. could this be a problem?

also, i have a DDS system with 8 reaver lanes that is constantly detecting/moving scarabs and detecting/removing/creating reavers every 3 cycles. will this inflict lag?

by the way, if anyone gets a chance to look, i have attached my latest map. it has severe lag issues

Death count actions are simply changing a single variable to a certain value, or adding or subtracting to it. This is very simple compared to an action that creates a unit or moves a unit, etc. But sure, if you had 64k triggers each with 63 actions (+ preserve) that were modifying DCs then it could potentially be problematic - it wouldn't be much of a map, either. The problem with all of this is that it's very much based on context and even guidelines like "put lowest cost conditions first" may not be the best approach in specific situations.

Actually it would be nice if we had some real cost understandings for trigger conditions and actions. It doesn't need to be an actual time to execute or anything, just a relative measure of complexity. You'd say that Always or Never had a cost of 1, and a DC increment might have a cost of 2, a command condition would have a cost of say 20 and a bring condition might have a base cost of 50 -> the bring would be more or less expensive depending on the size of the location and the actual units inside that location when the trigger was fired.

I guess Heinermann would be the best placed person to come up with such a list, if he was willing?

i just remembered that in my map, a computer player has to run through a series of 'bring' conditions every trigger cycle. this as well as the DDS could be causing big lag issues. what do you guys think is the maximum number of bring conditions each cycle?

Again, you're asking for hard and fast numbers for things.

There is no "maximum number". It depends on:
1. The computer running the game
2. The size of the location involved
3. The number of units in the location at the time the trigger is run
4. What other triggers are being checked and run in that same cycle

Because 3 and 4 can potentially change throughout the course of the game, there's really no way for us to tell you the "maximum number".

Also lag related to triggers is on a gradual gradient. There's not really a case where it goes from "no lag at all" to "unbearably crushing lag you can't possibly play with" when you just add a single trigger.

Post has been edited 1 time(s), last time on Nov 7 2011, 12:20 am by Lanthanide.

One thing that I know causes tons of lag is tracking multiple units with burrowed units.
I recently made a zombie map where each zombie was tracked with a location and burrowed zerglings to slow them down.
It started lagging at about 20 tracked zombies.
but yes, it does depend on the computer number of triggers etc.

well thanks for the help guys, you've certainly clarified things for me. i'm going to start working on my next map