Let's say both p1 and p2, bring 1 CIV to the same location at the exact same time. And the next thing that's supposed to happen is, they are to get a unit from another location (this location has a cache of a lot of burrowed drones owned by p9). The next thing that is supposed to happen is, the unit they received is given from p9 to the person who brought the unit the location.

The triggers are separately owned by both p1 and p2.

Is it possible that p2 will somehow hijack the drone that p1 is supposed to get or vice versa?

It's very possible that p1 would get the drone p2's supposed to get, but not vice versa... p1's triggers always fire before player 2's, it wouldn't necessarily matter who brought the civ to the location first, as long as both of their civs were in the location when the next trigger cycle fired.


you can get some more details on trigger ordering here http://www.staredit.net/starcraft/Trigger


Now you can drastically reduce the chances of this happening with Hyper Triggers, which will run about 11.9 times per second rather than every 2 seconds, so unless they both got there within the same .084 seconds (approx), it would run accurately.

Post has been edited 2 time(s), last time on Apr 16 2012, 9:21 pm by jjf28. Reason: blizzards false info :/

Triggers are executed player by player. That means first ALL of P1's trigger fire, then all of P2's and so on. And if you have triggers owned by forces or All Players Starcraft splits them up and makes a copy for each player, also resulting in a trigger owned by All Players being executed by P1 first.

So what exactly happens depends on what your trigger says. When it says give 1 of P9's units to Current Player then P1 receives 1 units. And when it's P2's turn he also grabs (another) unit from P9. This is probably how you want to do it.

However if you mistakenly let the trigger give 1 unit from All Players to Current Player then P1 will receive a unit from P9 (this step stays the same) and P2 will grab the exact same unit that P1 just received. So P1 ends up with none and P2 with one unit.
This is because StarCraft has a certain algorithm for which unit will be chosen when there's multiple candidates in a location. First it checks the x coordinate of the units (leftmost) and if there are multiple units with the same coordinate it picks the one with the highest unit ID (created last).



EDIT:
This is false. During the runtime of a map (aka while playing, not in the editor) there are no triggers owned by All Players or forces. As I explained sc makes copies for each player seperately.

Still a tad confused, but it's my own fault. The triggers are for the players, individually, not forces/all/etc. I forgot my own triggers while I was writing the thread. The triggers still have the possibility of having the conditions satisfied at the same time, but the actions will move 1 Zerg Drone owned by P11 to a location owned by the specified played.

From what I've gathered (skimmed through), it's impossible for them to fire at the exact same moment and screw up. Since p1 goes first even if both conditions were satisfied at the same time?

Nothing is ever happening the same time in triggering. Triggers always fire one after another. As I said, first the first trigger of P1 is fired, then P1's second trigger, etc. until all of P1's triggers are done. Only then P2 gets to work on his trigger queue. Then P3, etc.
Because of this sequential nature it is possible that P2 "undo's" P1's trigger by grabbing the same unit. But when P1 already moves a drone out of the cache location for himself then P2 can't affect the same unit because it's not there anymore.

What about multiple triggers that have exactly the same conditions?

I remember some "odd" behaviour around them. I suspect that maybe SC checks the conditions all at the same time and then executes the triggers in order, even if the 1st trigger had actions that would invalidate the conditions for the 2nd trigger, the 2nd trigger would still fire?

No.

There's a problem however that certain actions are not forcing updates for certain conditions fast enough:
http://www.staredit.net/topic/2754/
So the condition gives a wrong result.

Hmm, ok, I'll have to check it out when I get home. I do know that this map here has many triggers with the same conditions, and it has an extra condition in there to prevent the switches from firing at the same time: http://www.staredit.net/files/1730/ Then again it was a long time ago when I looked at that and I was new to mapping, so perhaps I was just wrong.

Also the bring command not being updated is explained here: http://www.staredit.net/307127/

"Give" doesn't update the "bring" data as seen in NudeRaider's first post (-> the wiki link -> bottom of the page).

That's not what I'm talking about Ahli, read my last post.

Edit: I've checked the map now, the thing I'm talking about is the System State DC that gets incremented. It's used for adding 100's, 10's and 1's to the result value. If you get rid of the system state variable then the whole thing screws up.

Post has been edited 1 time(s), last time on Apr 17 2012, 9:47 am by Lanthanide.