I didn't want to revive old threads, so here is a new one with the specific question. Then again, I know similar things been discussed several times before, but there is a particular question which I haven't got a satisfactory answer yet.

It's known conditions introduce lag to the map. Regarding lag, conditions fall into 2 groups: Bring-alike and Deaths-alike. Conditions of the first group populate cache with units, when the second group conditions mostly just check a value, or two, or up to around ten values in the worst case.

Group 1: Bring-alike conditions.
Bring, Command The Most At, Command The Least At.

Group 2: Deaths-alike conditions.
Never, Always, Switch, Accumulate, Least Resources, Most Resources, Deaths, Kills, Least Kills, Most Kills, Score, Highest Score, Lowest Score, Elapsed Time, Timer, Opponents.

As you've noticed there are 3 conditions I haven't put into any group, they are: Command, Command The Most, Command The Least. The question is where should I put them? Are they really closer to the second group than to the first one in terms of the amount of required processing power?

As far as I understand, somemost people suppose in this topic that Command conditions are almost as effective as Deaths. I have doubts, because Command still populates cache with units (pass one) and then it is going through cache couting occurencies of a unit or group of units (pass two). Of course pass one is simpler in comparance to Bring because units aren't checked for collision with location, but there are still two passes through a pretty large units array.

I'll try to make some numbers. Let's say an average map may include around 500 units, but I believe the first pass must be done over the whole units node array which has 1700 entries. That way there are roughly 2200 comparance/assignment operations for Command condtions. With Bring we have 4 comparance operations more (to check locations bounds) for each unit on the map on the first pass: we add 500*4 operations and get 4200 total.

So, I'm personally putting Command-alike conditions into the first group regarding the amount of processing power they take, but what can you say? Do you think they are really closer to Death-alike conditions than to Brings? I'm not familiar with low SC code myself, but I really want to know an opinion of people who know it well. Am I right with my assumptions and calculations? Probably I have missed something significant?

Relevant topics:
Map trigger lag?
Bring/Command Updating Discussion
Map lagging conditions.

Thanks for your attention!

Post has been edited 2 time(s), last time on Aug 4 2013, 9:23 pm by Wormer. Reason: Reformatted paragraphs and fixed typos

The reason I rank the non-location based command conditions near deaths is because they should be able to use numbers from these tables, which are well maintained, rather than having to check through all the units.

Brings is in its own league as far as potential lag is concerned. It does something more intensive, regarding memory allocation and physically scanning the map, which Commands doesn't do. This being the case, I believe saying Commands is "Bring-alike" would be extremely misleading.

Keep in mind that, while Brings is on another level, the other conditions still have varying levels of intensiveness. Commands would contribute more to lag than Switch, for example.

You'd need more classifications if you wanted to make it especially accurate, but even if you're just using two categories, Brings and Commands shouldn't be grouped together.

I remember you told about memory leaks before. I was very suprised then. But you haven't been more specific than that.

I'm saying those 2 other conditions (Command The Most At, Command The Least At) are Bring-alike because they're also checking for each unit if it is on the location while populating cache.

I always believed that this location checking for each unit is the stumbling block of all brings.

EDIT:jjf28, according to what I heared earlier and from my own experience it is not the case, because Command condition still repopulates cache when it's invalidated. It's logical to suppose that it then uses this cache to get numbers.

Post has been edited 1 time(s), last time on Aug 5 2013, 8:51 pm by NudeRaider. Reason: merged 2 posts

hmm... I find it hard to believe that they would cycle through all the units to update a list in the middle of a trigger cycle when they could go:

array[unitID] -= 1;

in the, say, remove unit trigger, unless they absolutely had to do a full update (for something like brings after remove unit).

Anyway, i'm just speculating, we'd need Heinermann or someone to have hard evidence.

I believe the reason SC doesn't use these tables is because Command may check for units owned by Foes or Allies that still requires to compare this data with players alliance statuses. It's not something you can just take from a table.

Yes, we need Heinermann! But, I believe Fyrinite is pretty good at this knowledge. He looks like a man who really knows the stuff and I have confidence in his words.

deaths can also use foes and allies

Logically, command works identical to deaths.

12 * 228 = 2736

SC keeps track of all 12 players' command counts in the all unit counts table, so you you're looking for player 1 commands exactly 1 terran marine, it will be the first 4 bytes of the all unit counts table. Presumably player 13 (12) commands exactly 1 terran marine will look at ghosts.

Bring likely checks the unit table and matches unitID with an X and Y orientation within the limits of the specified location. It has to look at 1700*4*4*2 bytes, but it might have some builtin indexing somewhere which organize which unit slots of the 1700 are actually in use.

rockz, like I said, according to this SC doesn't use this table to check units count, but checks the whole unit table instead. The only difference is that it doesn't match X and Y positions of the unit each time.

It seems like the posts there were only describing location based commands/brings.

I think the fact that we have a table of the same size as, and at the same location as the death table, that has no significant purpose other than use in count-based conditions, constitutes strong enough evidence that they are using this table, but I wouldn't regard it as crazy if you didn't rest till you saw some dissasembled assembly code

Use a memory modifier and change the All Unit Counts Table so that terran marine is 1 for player 1, then run a trigger that runs when you command exactly 1 terran marine, and another when you bring 1 terran marine to anywhere.

That is a good idea. I tested this and figured out command doesn't read or write to All Unit Counts Table (AUCT). I repeated the same test with Completed Unit Counts Table (CUCT) and it looks like Command really reads data from there.

Also, the difference between AUCT and CUCT is that first includes units that started production in a factory (not queued but only the one that produces), but the latter only contains completed units. Maybe there are other differencies though.

Post has been edited 4 time(s), last time on Aug 11 2013, 7:07 am by Wormer.

Which modifier were you using? I'm pretty sure that matters.
The "at most" modifier should be checking the All Units Count Table, whereas "at least" and "exactly" should be checking the Completed Unit Counts Table.

I've used exactly in my tests. As far as I remember (been long time) command condition doesn't suffer from these bugsfeatures with modifiers.

You're joking. This must be cut from some context.

I also remember similar mess with bring condition and units in transports, but it's inside out: "exactly" and "at most" work just fine when "at least" doesn't count those units (if I'm still remembering right).

Honestly I don't remember anything about units in production with this regard, but still I believe a structure under construction is counted as a completed unit in CUCT. This is calling for more tests!

One thing I can't understand: what the heck command condition invalidates cache when it just reads values from a table?

You aren't; "at most" is the one that works differently.

Growing old

EDIT1:
Still I'm remembering right that it's not the same mess, but inside out in a different fashion: "at most" doesn't detect units in transport when it does detect buildings under construction.

EDIT2:
I'm wrong here. Command condition does suffer from the same modifiers problems with buildings under construction, but doesn't suffer with units in transports.

EDIT3:
I've made a test. You're right! Exactly like this.

Post has been edited 6 time(s), last time on Aug 11 2013, 8:19 pm by Wormer.

You're right, Roy was quoting it out of context. It's from this wiki page: http://www.staredit.net/?p=oldwiki&s=142

I wrote it after my experience with the Blood Pressure Marathon map I was making. The context here is about Powerups: "at most" + "bring" doesn't work for powerups. It would probably work the way you expect for all other units, though.

The problem with "at most" is that it only detects visible units; that's an easy way to summarize it. It does detect unfinished buildings, and does not detect units inside of other units. This is applicable to powerups as well, "at most" cannot detect them when they are being held by a worker unit (for all intents and purposes, the powerup is inside the worker unit).

However, it does detect them the rest of the time. The "at most" + "bring" combination works for powerups, like any other unit. It's when they're held by a worker that it becomes problematic.

I believe you were aware of this when you wrote it, as the line before that one specifically mentions the powerup being picked up by a worker, and the lines after that continue the "being picked up by a worker" theme. However, it wasn't mentioned in this line, so the critical fact that the powerup must be held by a worker is easily missed.

Yeah, you're probably right that the 'picked up by worker' applies to this specific line as well, judging by the content around it.

The way powerups are handled is really quite kooky; it explains why I was having so much difficulty with them giving random results, until l sat down and really experimented to work it out.