Let's say I'm building an income based system on the number of Pylons a player controls. Let us also say there's a hard upper bound on total Pylon limit, e.g. n = 100. For each Pylon I want to give a player M minerals every Y minutes.

What would be the most efficient way to do this, in terms of reducing load on the trigger engine / avoiding map lag (consider that this small system will be part of a much larger map with thousands of other triggers).

* Hardcode with `Commands Exactly N` Pylon or `Commands At Least N` Pylon. This would be 100 triggers, or as many triggers as total possible Pylons
* Count the Pylons. Every Y minutes, give each Pylon 1 by 1 to a neutral player, and give the owning player the income. This system would scale for infinitely many Pylons and requires no hardcoding. It's also only about 5 triggers per player.

The second approach looks more elegant, but it does involve a lot of move location, give units, and maybe even Bring actions.

Is map lag caused by lots of expensive triggers, or just overall many triggers? If it's the former, then maybe hardcoding the income is preferred.

Thoughts?

The first option would be less laggy and could be made pretty quickly with some macro or trigger duplicator or something.
Map lag is more caused by expensive triggers. There are maps with 10s of thousands of triggers with not as much lag as you might expect.
If you're open to using EUDs there are simple ways to solve these kinds of problems with minimal lag.

Is there some ranking of expensive to least expensive triggers? For example I've heard that "Bring X to location Y" is an expensive condition. Could you explain computationally what's going on the under hood?

In terms of EUDs, I've been avoiding them because I thought you could not have both extended unit limits (e.g. avoid cannot create more units) and the EUD triggers. Am I wrong? There's a checkbox when you host a Battle.net game to have Extended Unit Limits, and it appears grayed out if the map is using EUDs. Are these mutually exclusive? If so, why, and is there a workaround?

You either use EUDs or extended limits, not both, no workaround.

Binary Countoff (or generally grouping countoff) would be a good technique here - the idea is that instead of 1 trigger for every pylon you do groups instead, would look something like:

Player X Commands at least 64 Pylon
-> Give 64 minerals
-> Give 64 Pylon owned by Player X to Neutral

Player X Commands at least 32 Pylon
-> Give 32 minerals
-> Give 32 Pylon owned by Player X to Neutral

...

Player X Commands at least 2 Pylon
-> Give 2 minerals
-> Give 2 Pylon owned by Player X to Neutral


Player X Commands at least 1 Pylon
-> Give 1 minerals
-> Give 1 Pylon owned by Player X to Neutral


Player X Commands exactly 0 Pylon
-> Give all pylon owned by Neutral to Player X


In this way, you get any number between 1 and the max number of pylons, as long as the sum of your countoff (1+2+4+8+16+32+64 = 127 in this case) is greater than the max possible - say I have 69 pylons - it detects at least 64, then at least 4 (but not 32,16,or 8 since we gave 64 away), then 1 then 0. This way you might only need 7 triggers (plus 1 reset) instead of 100. Many variants of this technique exist, for example instead of exact counts using Binary you could do groups of 10, if every 10 pylons gives you something, or you can otherwise tweak this. Throw in a death count so this system only runs once every few minutes or whatever, and it will not create any noticable lag.

I don't think the performance of trigger actions/conditions is well documented but generally speaking the ones that manipulate units at locations or check for units at locations or whatever are most expensive. Probably because it does a loop of all units on the map. That and probably order/ai related things are the slowest. There are lots of micro performance saving things that become second nature like for example putting the MOST likely condition to be untrue at the top of the condition list, Replacing Bring conditions with Command condition where possible, theres others but I can't think of them right now.

Yah this helps because StarCraft is smart enough to short-circuit as soon as a single condition fails?



I'm wondering how this could be done more efficiently if you were to re-code the internals of the Bring condition from scratch to be super efficient/clever? Like every frame a unit writes its coordinates to some kind of 2-D interval tree to update its coordinates. Then at some point to check if a unit is in a region/location, do a log(n) query on the interval tree/data structure comparing the unit's coordinates to the bounds of each location. Only for locations that have registered for Bring conditions, etc.

Yes

I won't get into the details, but it's already doing something along those lines.

What you can do to optimize your use of the 'Bring' condition is to try to avoid invalidating the cached units list as much as you can: Only the initial 'Bring' condition gathers the list of units, and subsequent executions of 'Bring' are basically as inexpensive as the 'Command' condition for as long as you
1) Use the same location. (Note: Moving the location with EUDs won't have an effect until the cache is refreshed, so that's not a valid optimization trick.)
2) Don't execute a "Command" or "Command The Least/Most" condition.
3) Don't execute a "Move Location", "Move Unit", "Remove Unit", "Remove Unit At", "Kill Unit", or "Kill Unit At" action.
When invalidated, the next 'Bring' condition will refresh the cache once more.

The Commands condition is similarly optimized, where subsequent uses are faster to execute, and is invalidated by the "Bring" and "Command The Least/Most At" conditions (and the same trigger actions) but it is significantly less expensive to update since all it does is memcopy a few arrays.


This is why units created by the "Create Unit" action sometimes don't get detected later during the same trigger cycle, as that action doesn't flag the cache to be refreshed. Consider the following trigger:


A trigger immediately following it with a "Commands exactly 1 marine" condition will be false, but a similar "Bring" condition will be true. However if both of those subsequent triggers exist and the Bring one comes before the "Command exactly 1" trigger, the latter will also return true as the "Bring" condition will have invalidated the cache. Vice-versa if the initial trigger is "brings exactly 0 marine".

Executing one of the trigger actions I've listed above after the Create Unit action will allow the next trigger's condition to detect the marine. The most inexpensive way to invalidate the cache is to use the "Kill Unit" or "Remove Unit" action on a player that, preferably, has no units (probably players 9-11 for example), or if not available, has the fewest units. All of the other actions will be similarly as expensive as the Bring condition itself since they are based on finding a unit within a location. Except if you wish to invalidate a Bring condition, in which case the Command condition will be your second best option after the Kill/Remove actions. The cache is also unconditionally invalidated at the beginning of every trigger cycle.

I don't know the scale of your map, but it's worth mentioning that accidentally stumbling into the kind of trigger lag you're trying to avoid is somewhat of a trick. Of course, it's possible, but it's not a very common occurrence. Practically, I'm not sure you need to be spending as much time trying to optimize these systems as you are. There's a good chance the engine will be able to hold the load you're planning on throwing at it. I never had any issues with trigger lag until I started doing dumb stuff with the EUD editors like nesting for loops.