Okay so let's say I have triggers that fire when the player commands them to do so.

Trigger1

Conditions.
1. Bring X to X
2. Commands X
3. Has exactly X deaths of X
4. Accumulates at least X gas.

Actions.
1. Spell happens.

Trigger2

Conditions
1. Commands X
2. Has exatly X deaths of X
3. Brings X to X
4. Accumulates at least X gas.

Actions
1. Spell happens.


Let's say that I must reproduce either Trigger 1 or Trigger 2 500 times with only the X's changing. Which causes more map lag?

The best way to do this would be:


Conditions

1. Has exactly X deaths of X
2. Accumulates at least X gas.
3. Commands X
4. Brings X to X

Actions
1. Spell happens.

Assuming that the Bring condition uses a fairly large location.

Locations lag the most out of all conditions.
Command:number, player, unit
Deaths:number, player, unit
Bring:number, player, unit, location
Accumulate:number, player, type.

Theoretically accumulate should be fastest, then deaths, then command, then bring. So you want them in that order for the minimum lag. However, it is extremely likely that all but bring are exactly the same speed. How do you even test for lag?

Once a condition returns false, it stops checking other conditions, so the slower conditions should be last.

Actions are the source of most lag.

I disagree with some of that, here is my reasoning:

1. X Deaths of X remains constant for the entire game based on which character is selected. This condition is always true.
2. Accumulates at least X gas is also easily met, especially with weaker spells having a low gas requirement (gas regens constantly)

The Command / Bring would be the conditions met the least frequently (rarely met).

This is an ideal order. The idea is to order your conditions from 'easiest to check' to the most difficult. Switches should always go first, followed by numerical checks (accumulates, death counts), and lastly physical checks. The last condition in your list should always be Brings, since StarCraft reserves memory to actually physically scan the location for the unit, it is the most likely lag-inducing condition and can even cause a memory leak.

Note that regarding the location size for Brings, that checking many smaller locations can induce more lag than checking a single one of the same total area.

Edit: Ninja'd by rockz Dx
It doesn't matter if they are met or not, placing them at the top means they are being checked 100% of the time. Brings conditions still generate just as much lag when they are false as when they are true, if not more. It's not like StarCraft says, "let's skip this because it's false." It doesn't know if it's false until after it's been checked.

Post has been edited 2 time(s), last time on Oct 12 2010, 12:07 pm by DevliN. Reason: Mineral abuse.

Okay well, is "command" more or less lag inducing than "bring"?

Command produces less lag than Brings. Brings is the biggest offender of all conditions, and should always be listed last.

Post has been edited 2 time(s), last time on Oct 12 2010, 12:06 pm by DevliN. Reason: Mineral abuse.

Okay, I just wanted someone to verify this because I had roughly 500 triggers in my map with a leading 'bring' that I am inserting a command in front of in an attempt to reduce lag. I just wanted to be sure I wasn't wasting time.

Whenever the Command condition is false, it will reduce the lag generated by the conditions, though it'll remain the same when it's true.

If you optimize the map's conditions and still experience trigger lag, chances are good the problem's in the actions. Most times that's the cause anyways, though it doesn't hurt to reorder the conditions to reduce their impact on the map's performance.

Post has been edited 2 time(s), last time on Oct 12 2010, 12:05 pm by DevliN. Reason: Mineral abuse.

Deaths checks the numerical value of a 4-byte number; since it's an equals condition it will terminate as soon as bitwise XOR returns true. Locating the address of the deaths variable is O(1). Extremely fast and trivial to compute.

Accumulates, similarly, checks a 4-byte number, and is equally as expensive as "deaths".

AFAIK Command scans the array of units and checks for the number of units with the same ID, but it is possible that a variable is assigned to the number of units owned by the player and is modified on creation/removal/death. In the first case it would be O(n) but in the second case it would be O(1) like the death and accumulate conditions.

Bring, however, functions like this: (as far as I know)
-Iterates through all units.
-Once a unit of the type is found, It locates the center of the unit and uses arithmetic to find the four corners of the unit.
-Then, it performs four comparisons for each corner, to check to see if they lie within the location.
-If so, then the unit is in the location and 1 is added to the "bring count".
-When all units have been scanned it checks that number.

Therefore, it is beneficial to place the computationally inexpensive conditions first, even if a more expensive condition is likely to be false.

(Actually, on second thought, if "bring" becomes more laggy with bigger locations, then that's not how this works.)

I got it under control, thanks guys.

Well, it's more laggy checking 225 8x8 locations covering a 120x120 area than it is to check a single 120x120 location, if that helps.
Good luck

Post has been edited 2 time(s), last time on Oct 12 2010, 12:05 pm by DevliN. Reason: Mineral abuse.

I actually had "scans 8x8 tiles and flags units" typed out =o. But then I thought about inverted and 1x1 locations and realized that location scanning would break if that's how it worked.

Ugh, a little over 150 triggers re-conditioned so far, I can almost see the half way point. This better be worth it ><.

http://en.wikipedia.org/wiki/Regular_expression

http://en.wikipedia.org/wiki/Notepad++

:3

I am.. what they would call an old-school mapper. Proving to nerds everywhere that SCMdraft is all you need to make the best maps.

Completely agree, but people who posted above you haven't known this additional info.

I personally don't distinct deaths/accumulate from each other, neither do I distinct command/bring much (yes I know they may have little lag distinctions but I found it impractical).

A good idea which none have pointed out so far is to precache the bring/command conditions. The basic idea is the following. I don't know, but let's say all these triggers have to check Brings X to Y where X and Y are constant in a given trigger block (which contains 500 triggers in your case). Then you do like this:


Believe me, this method applied consistently to all trigger-consuming subsystems will save you much lag.

EDIT:
Also,
1. Always try to store the game state info in a switch or a death counter. Let's say the Command condition in your trigger checks whether hero is alive or dead. If this condition is checked in many triggers it's probably not very wise to check the condition in it's pristine form. What you do is
Then you obviously check the deaths condition everywhere. As you can see, this is another variant of precaching technique. You store a game environment state in a DC state machine and specify all the transitions between it's states, then you check the state of the machine fast instead checking all the hard-weight "environmental" conditions. In the example the state machine got only two states, but obviously you can accommodate the idea to something more complex.

2. Don't miss the opportunity to add additional light-weight conditions (switches/deaths/accumulate/score and such) above to eliminate the necessity of checking a hard-weight condition. For example, if you can add something like
which eliminates half of the cases then do it! Combine this with the first method. When you have enough "environmental" conditions precached in DCs this allows to guard all the bring conditions with lightweight ones in most cases.

EDIT2:
No doubt in small maps this is yes. In large maps however conditions start to become a big problem.

Post has been edited 4 time(s), last time on Jun 30 2010, 8:02 pm by Wormer.

Wormer, Norm specified that the "X"s will change in these triggers, so each Bring would still need to be individually checked when possible.

The transfer of bring condition states to a death counter is good triggering etiquette. Do so when possible.

Alright, probably not in this case, but I'm just giving an advice which can push norm to an idea which we can't get to, because we don't know all the info about his map.

Bring can cause a memory leak, Command can't. Just because they appear to be doing the same thing doesn't mean they are, they operate in completely different ways. As outlined by rockz above, Command is much more similar to Accumulate than it is to Bring.

The difference is pretty substantial, especially when you have a massive number of triggers being checked 12 times a second.

Post has been edited 2 time(s), last time on Oct 12 2010, 12:05 pm by DevliN. Reason: Mineral abuse.