Can two separate triggers fire at the same time for the same player?

Nope.

Thanks for that confirmation.

But I still have a mystery. I set up a test in which there was an Overmind building for P1 at the center of location "test1". I had 2 triggers:

P:
Player 1
C:
Player 1 commands exactly 1 Overmind
A:
Create 1 Marine for Player 1 at test1
Remove all Overmind for Player 1

P:
Player 1
C:
Player 1 commands exactly 1 Overmind
A:
Create 1 Medic at test1

In that order on the list. However, when I loaded the map, it created the marine off to the side, like it would if the Overmind were there and then created the medic in the center of the location, as if there were not overmind there. When I replace Command with Bring in the medic trigger, it didnt create the Medic. Why did it create the medic with cmd(there are no more Overminds on the map)?

Hmm, maybe it took a longer time to remove the value for the cmd and with bring it just checks if it's there or not. So, with bring it might take less time to check? I'm really not sure about this, just a theory.

Well Elvang is right in that computers in general can only do one calculation at a time (save dual and quad cores, but this isnt relevant for a game as old as sc).

But regarding trigger logic while in the game there's no game time passing during triggers are processed.
So all effects of triggers take place the same time, after triggers have been checked.
Nevertheless triggers have a specific order in which they are run. And ALL triggers will be checked if their conditions are true. And ALL triggers with true conditions will be executed, even if they have contradicting actions.

Okay, so much the theory, now about your problem:
Commands takes 2 full trigger loops to update. So if you remove the overmind, it will still be detected in the current AND the next trigger loop.
This is not the case with bring. Bring is updated when you execute either of these actions
Kill Unit
Kill Unit at Location
Remove Unit
Remove Unit At Location
Move Location
Move Unit
or at the latest in the next trigger cycle. Thus trigger order* can be important.
So to avoid bugs, never use commands, except you know exactly what you're doing.

*Triggers are checked player by player. SC will create copies for each player if the triggers are under forces or All Players. So first Player 1 checks ALL his triggers (even the triggers that are under his force and All Players), then Player 2, etc.
Warning: ScmDraft doesn't recognize this rule, so the order in ScmDraft can be (and is most of the time) different from the order during game time.

So was I right or wrong?

Yes, your theory was correct.
I just explained what exactly happens and how the 2 actions work.

Is there some sort of cached data starcraft uses when checking trigger conditions to increase speed or something? I can't imagine why a command taken the previous loop wouldn't be detected the next loop, I was under the impression that during the trigger logic phase of the game loop something similar to this happened:

Check trigger 1 conditions... False
Check trigger 2 conditions... True
Check trigger 3 conditions... True
Check trigger 4 conditions... False
Execute trigger 2 actions...
Execute trigger 3 actions...

There is indeed a cache of some sort, according to this.

And no, the triggers are dependent on another. So it is possible, that Trigger 2 has actions that make Trigger 3's conditions false, thus preventing it from running. This is a common source of bugs. Especially with cross player triggers, because of the order discrepancys I mentioned above.

Interesting, thanks for the link to that post. Raised a few questions, will edit this if further research doesn't yield answers.

EDIT: I cannot seem to find info on how often the block of data is repopulated, aside from when the actions listed are performed. Normally I'd assume the data would be repopulated at the start of every cycle (as that is how I'd do it), but you said it takes 2 full trigger loops for Commands to update (the data I'm assuming), so is the block of data repopulated every 2 cycles of the trigger list? Would be somewhat understandable seeing as how it could save cpu cycles and memory for an older game.

Post has been edited 3 time(s), last time on Dec 14 2008, 6:52 pm by Elvang.

Oh and just to clarify:
With commands I meant the "Commands x units" condition (as opposed to the bring condition), not actions/conditions in general.
And not the old state of the condition is what "lags behind" but the information about what unit is where.
Meaning the triggers DO check the condition every loop and calculate the result, but in case of bring or command could calculate it from old unit information (for example detecting a unit that was removed in the trigger above).

The deaths or minerals condition for example are always returning accurate results. Actually I wouldn't know of any other condition that could "lag behind".

EDIT:
For bring the data block is repopulated at least every trigger cycle. Plus everytime an important action (listed above) is executed. Why Blizzard didn't deem create or give important escapes my knowledge.

But I cannot tell you what exactly happens with the data block commands takes its information from, I never looked deeper into that matter. All I can tell you is the relevant effects for mappers (is updated ever other cycle). And the CPU load is probably the reason for this condition's existence, since bring can basically do the same.

Post has been edited 1 time(s), last time on Dec 14 2008, 7:01 pm by NudeRaider.

Ok, here is my current understanding of the trigger phase of the game loop, correct me if I'm wrong:

>Check trigger conditions
>>If conditions true then execute actions
>>>If actions invalidate related 'cache' then repopulate said cache
Repeat while not at end of trigger list

Just to clarify, there are several such 'caches', one for each location (including anywhere or entire map), with each 'cache' containing information on how many units are in said location, along with possibly other useful information.

One of my questions was wouldn't it be possible to create a trigger list that will never repopulate the cache by never using any of the listed actions, but I realized that I was only thinking about the trigger phase. Any unit movement or creation/deletion during the logic phase will probably repopulate any 'caches' the units are valid for.

EDIT: Also, apologies to the creator of the topic for going off on a tangent.

I trigger list is a set of triggers I assume?

What is the logic phase, if not the trigger phase?

And yes, it is indeed possible to create triggers that do not update bring (don't know for command). This had led to numerous unexplainable bugs, before this was found out.
BUT as already mentioned the cache for bring is updated at the start of every trigger cycle no matter what.

Yes, not sure how starcraft represents it. The triggers might all be in a single list and the editor naturally saves them sorted by player, or there might be a separate list for each player (would cut down on memory by not even loading the list for absent players).

Sorry, shouldn't have said logic phase, as I suppose traditionally in game design everything that doesn't have to do with updating the screen should be in the logic phase I think. Not sure what its considered (I think AI), but I think of it as a phase where Starcraft handles unit orders, such as attacking/building/movement.

EDIT: I think one of the caches not being updated explains one of the bugs I had in a map previously... Never did figure out how I got rid of the bug, was just rearranging/add extra move triggers until it disappeared.

So the logic pahse = phase where game time is passing. Alright.

SC reads the trigger section and creates the necessary triggers. This does obviously not include absent players.
Triggers of leavers will be removed from memory.
If SC sorts them in any way is not relevant. They will be checked player by player and then in the order they have in your map.

I think that about answers all the questions I had... Oh yea, not sure about the inner workings of AI scripts, but I assume they check the locations of units when need be. Do these checks rely on the 'caches', and if so do they repopulate them first?

I have no idea.

Whenever something is done that would cause a problem with an AI script if it wasn't updated, they are updated, so it shouldn't be a problem.

some related, easier guidelines: http://www.staredit.net/wiki/Bring

This seems to come up every once in a while, I should bookmark the topic.. Anyway, here's the topic that the bring/command updating was originally discussed in, it's a good idea to know how it works, as it sometimes causes some odd errors that aren't easily troubleshot: http://www.staredit.net/topic/2754/