You are technically correct (the best kind of correct) but what I'm saying is that it's not helpful. He doesn't explain it in a way that someone can use to understand the concept, if they don't already know what's going on.
What makes this worse is the many inconsistencies: No clear distinction between actions and conditions, confusing information mixed in (see red parts below), and putting 2 of the same and one different thing in 1 list (see yellow, green and blue groups below).
Each time any one of those actions occurs it compares the stored variable [...]
Just take this part. An action does something. Indiscriminately. It does not check a variable before that. Now that I know what is going on, I understand what you actually meant with it, (grouping actions and conditions because both affect the variable) but it's not suited as a first sentence explain it to someone.
[...]it compares the stored variable value to the value assigned to the condition. If the value matches then the unit counts are not updated before the condition is checked. If the value is different then the unit counts are updated, the variable set to the new value and the condition is checked.
See this is better. Here you state that I only should look for conditions (so I can infer to ignore the 3rd list item for now) to understand it. But if you already confused people with the beginnging of the sentence it's hard to find the middle part that makes sense.
Alright... so please don't take all of this as an offense, I'm glad you took the time to clear it up for me. I just wanted to explain in detail what I had trouble with, and why I think just linking to Heinermann's snippet is not enough to
really explain the issue to someone. It's not even suited as a "HowTo" avoid the issue, because it's doesn't clearly state what you're supposed to do to avoid it without understanding it.
In any case, I think I got (most of) it now. Here's what I got out of this:
(Feel free to skip to the conclusions and notes part, I think those are worthy of further discussion. the inbetween is just my thought process.)
Raw data (colored for easier referencing in the analysis)
There is a variable involved. It is first set to 0 as the trigger cycle begins. If this value is different than the value assigned by certain conditions then the count is updated.
Command, Command the Most, Command the Least leaderboard sorting ---- Value is set to 1.
Bring, Command the Most At, Command the Least At, leaderboard sorting ---- Value is set to 2. Reset if location is different than previous call.
Move Location, Remove Unit, Remove Unit At, Kill Unit, Kill Unit At, Move Unit ---- Value is reset to 0.
AnalysisThe first sentence refers to a procedure that is run before each condition check. SC first checks a variable and the outcome decides whether or not SC updates the unit counts *[1]. Below are the rules for this precheck-variable.
So
initially the variable is 0. And whenever I run any of those
blue actions it's
reset (to 0) again.
(Variable 0) When a
yellow condition is encountered, the variable is checked against
1 and returns FALSE, so the count is updated and the condition will behave correctly. It now sets the variable to
1 and the condition is checked
(Variable 1) If the next condition is a
yellow one again, the precheck returns TRUE, so the count is NOT updated. So if any
not blue action changed something, it will use an outdated game state
! The variable is set to
1 again and the condition checked.
(Variable 1) But if the next condition is a
green one instead, it will update the count, because it matches 1 vs 2 which is FALSE. Now it normally sets the variable to
2, but there's also a case where it
resets the variable: If a different location was checked than by the previous condition. *[2]
(Variable 2) The result of going from
green to
yellow should be obvious by now: The count is updated and the variable is set to
1.
Conclusions- Conditions from different groups following each other are always "safe" (guaranteed to be up to date)
- Conditions that follow blue actions, are also safe. *[3]
- Green conditions following each other are "a bit safer" because they have fewer cases that lead to outdated game state, compared to yellow conditions.
- Bring is in the green group, so it can be considered a bit safer than Commands.
- Looking at the blue action list, it's notable that Create Unit is missing, like with the Bring anomaly DoA described in 2008. And Give Unit, which was where you (Lanth) stumbled over it.
- WTF is red? And how can it appear in 2 different behavior groups at once?
Notes*[1] "What unit counts?", you may ask. Good question! SC keeps track of the units inside a location with an array that is populated at the beginning of each trigger cycle. To reduce the performance impact this list is not updated after each trigger, but only under certain circumstances. Unfortunately they forgot to include some possible circumstances, which makes conditions checking against this array unreliable, which is why we're talking about it here in the first place.
*[2] Am I correct in assuming this includes conditions within the same trigger?
*[3] This one is probably the biggest take-away because we can formulate a clear instruction with it to avoid running into conditions checking an outdated unit count inside a location:
In triggers, that rely on each other and being correctly executed within the same trigger loop, always include a dummy action from the blue list in the predecessor trigger. Heinermann recommends Move Unit to keep performance impact low.
The map you've come up with that shows that Command is somehow affected by Give in this situation is weird though and isn't explained by Heinermann's description, unless there's some other modifier like it depending on the player the action is affecting and the owner of the trigger somehow, since you see there's a clause in the second bullet point where a different location will also reset the variable value.
Theory says that using Bring after Commands (or vice versa) should always force an update. It must be the part where it says "Reset if location is different than previous call." - which is only valid for Brings, but not Commands.
But this also means that conditions would not set the variable, but then the whole concept makes no sense, because what would set it to 1 or 2 then?
At this point I'd like to mention
this post (part of the discussion that DoA resolved) that seems to draw the same conclusion about switching Commands and Brings up being safe.