Depending on exactly what you're doing, this means it is definitely the one to put first!

Lets say you have 5 characters, and each character has 100 triggers of this type. If you put that condition first, it means for any particular player, 400 triggers will return false on their first condition, and only 100 triggers will return true on their first condition. That is much better than waiting until the 2nd, 3rd or 4th condition to wipe out 4/5 of triggers.

The way you need to think about it is highest cull rate, and cost. You want to order by cost and then cull rate, so out of all of the cheapest conditions you want to have the conditions with the highest cull rate first. Then out of all of the expensive options (bring, basically), you want to have the conditions with the highest cull rate first - eg if you have multiple 'bring' conditions in a particular trigger, put the bring that it least likely to be satisfied first.

Woot, a memory leak?!
Disagree. Accumulate only accesses a single variable, when Command iterates through the units array.
Haven't understood about O(1) thing (the bold part). Could you please elaborate more why you think it's O(1) but not O(n)?
Actually it operates a bit differently. There is a cache which is filled with all units on a given location. Bring fills the cache with units and then iterates through this cache. If the cache wasn't invalidated and if the next Bring runs on the same location, SC won't reiterate through all units performing "narrowing" (when it checks whether a unit is in the location), it uses the cache instead. Some actions doesn't invalidate the cache (like CreateUnit) which is a well known bug when a unit appears to be invisible for the Bring condition.

Moral: always group multiple Brings working on the same location.

Right. Norm wasn't very clear and I read it literary that all 2500 Deaths conditions are always true.

Post has been edited 4 time(s), last time on Jul 1 2010, 6:12 am by Wormer.

This whole thread has me baffled... How many thousands of triggers do people make now days where you are debating the computational complexity of starcraft's conditions? I've been out of SC1 mapping for quite some time now but I had never saw reason to suspect anything other than actions that resulted in a graphical change would cause negligible lag. Even on the computers of the past...

So what am I missing? Is everyone taking theoretical lag reduction to the next level of crazy or there been some serious changes in the last 5 or 6 years?

Suffice to say, the trigger limit has been found at 64k triggers.
Trigger duplicators have become really popular.

I believe this is dictated more by practical limits than theoretical craziness. You see, people try to emulate computations on triggers engine. SC triggers aren't intended for such things, which leads to a huge amount of triggers. SC isn't suited to have that much, and isn't optimized to handle large amounts of them. I found my personal practical top triggers limit at about 16k trigger checks every second frame. I believe 16k trigger checks is where you must optimize triggers for conditions. However the lag may already be noticeable to a trained eye at about 12k trigger checks, however exact values of course vary from map to map. Up to date computers are fast, but most of their computational power is spent by the trigger engine in vain...

Post has been edited 1 time(s), last time on Jul 1 2010, 10:09 am by Wormer.

65536 or more triggers will disable your save ability causing a crash. I don't know what the actual limit for running a map is (maybe trigger section size, maybe map file size, ...). Everything else works with that many triggers (tested with 71k triggers).

btw, I guess we don't really know how SC checks the location cache because centering the location on itself will revert the order of the units with the same x coordinate (-> it doesn't only scan the unitnode for units within the location because that would result in a static order).

Only certain events can cause the unit count to change (created unit either with triggers or through buildings, killed unit through triggers or combat, and removed units through triggers or unplaceable errors. It is simple to allocate space for each unit (variables like "dragoonCount" or w/e), and modify its value with a few extra ASM statements. Accessing it then becomes O(1).

I wasn't aware of the exact mechanism of Bring so I thought of a simple optimized system, but I realized that it's not how SC checks it (see my last statement in the same post). Thanks for clearing that up; it helps =).

I've had a 230k trigger map run smoothly; it depends more on the trigger contents than the count.

I didn't say they were identical Command doesn't access a location, which makes it far more efficient than Brings.

I can make a map that lags the living fuck out of your computer with only conditions, and easily has less than 1000 triggers.

Actually, I will do that when I have time anyways and post it in this thread, because I think it would be a good visual aid.

As has been stated, you can make a map with tens of thousands of triggers and have it run well. Alternatively, you can make a map with a few hundred triggers and have it run like shit. It's not how many triggers there are, but the content of them.

Post has been edited 4 time(s), last time on Nov 18 2012, 7:31 pm by Azrael.

I wonder how long you waited for that map to load and how long you waited the final score screen to close...
Must have been minimum several minutes.

Of course you may put all blank preserve triggers or only death conditions, but the point is that in a real map you can't do anything interesting only with deaths, you necessary need to interact with units.

For everyone interested in exact SC mechanisms concerning bring/command conditions strongly recommend the following thread: http://www.staredit.net/54441/.

About few seconds. Nothing really noticeable.

Could that map be created using standard StarEdit? I have no idea if 'new' triggers have been discovered, I remember having Player 9-12 triggers and being able to use them. I do know however that I had created some really trigger intensive things in my day. (at least action intensive, such as centering a location and performing actions on 100+ of different spots every hypered trigger cycle)
So Aside from editing the standard input for the parameters are there new triggers?. Has there been ways to run triggers for non standard (1-8) players? Has the location limit been broken?

So a theoretical idea/question of mine is. Have people used things like a Location grid to create simulated locations? So for an example... You want to check if a unit is within the bounds of (X1,Y1)(X2,Y2). And then it is achieved by moving a series of locations (or one) to those coordinates and checking it with simulated OR conditions?

And speaking of OR conditions. Are there tools now that greatly simplify the creation of OR condition triggers without going though the hassle of coping the trigger for each OR and disabling them all when any one executes?

(sorry for my newbism)

Are you sure? We can use P9-12 units, but they still can't run triggers.

No. We can read certain things in memory now, so in a sense there are new conditions, but not new triggers.

No and no.

Yes, I think so. Sorta.

Yes and No. There is nothing which simplifies the "OR" problem itself, but people like Wormer have made tools like Macrotriggers which can greatly simplify the mass production of triggers in a loop-like fashion.

As for some idea of how many triggers maps nowadays have, Ahli probably has the largest amount in an actual map, (idk if aristocrat's 230k was just fooling around or what), but Kaias & Lethal's Nightfall had around 11k, my own map is approaching 6k, Norm had 3k or so? So yeah, little things like condition order start to matter.