Report, edit, etc...Posted by LegacyWeapon on 2005-10-27 at 22:58:09
Triggers process one at a time too. Waits (and center locations in Single Player) are a special occasion where triggers run some of their actions, halts and runs any other triggers, and then finishes their actions.
Wait blocks are a perfect example of triggers running one at a time. During a wait block, none of other triggers run because trigger checking is halted due to the wait block. A wait block is also a super long wait.
So if you did a spawning marine trigger + preserve and then a wait 10,000 trigger. It would spawn 2 marines, wait 10 seconds, and then continue spawning marines as usual (assuming you aren't using hypers).
Spawns the first Marine upon checking triggers normally.
Spawns the second Marine upon checking triggers before waiting.
Halts trigger checking for 10 seconds (from the wait).
Spawns next Marine from checking triggers normally.
Wait blocks are a perfect example of triggers running one at a time. During a wait block, none of other triggers run because trigger checking is halted due to the wait block. A wait block is also a super long wait.
So if you did a spawning marine trigger + preserve and then a wait 10,000 trigger. It would spawn 2 marines, wait 10 seconds, and then continue spawning marines as usual (assuming you aren't using hypers).
Spawns the first Marine upon checking triggers normally.
Spawns the second Marine upon checking triggers before waiting.
Halts trigger checking for 10 seconds (from the wait).
Spawns next Marine from checking triggers normally.
Report, edit, etc...Posted by in_a_biskit on 2005-10-28 at 04:39:18
*makes LW's proposed map*
[attachmentid=14867]
*plays map*
Legacy, you aren't completely correct in your prediction.
What actually happens:
So it seems like the wait action didn't in fact force the first trigger to be checked again immediately. But, as the addition of a single hypertrigger can quickly verify, wait actions can and do force other triggers to be checked when the wait actions are run.
In this case, I suspect that the prediction failed because there were no triggers that were not yet checked by the time the second trigger (the wait trigger) ran - it found the end of the trigger list and decided that every trigger had run once already this trigger cycle, so didn't force the checking of triggers again.
As to whether actions from other triggers can run through wait actions, I think that this test clearly demonstrates that it is in fact possible. The first trigger continued to be checked every two game seconds whilst the wait action was running.
I would propose that there is a rule that StarCraft must check its trigger list at least once every two game seconds. Of course, it is possible for triggers to be checked faster.
Wait actions, transmissions, and centering view in single player are all "blocking actions", which makes them a little different from other actions.
Other actions, I'm pretty sure, can only be processed one at a time, even if they are in different triggers, or if they are for different players.
To see what I mean, consider that you could run two actions 'simultaneously'. But suppose that the two actions that I want to run simultaneously are "Create 1 marine for player 1" and "Kill all marine for player 1". After they both run, what do you see?
In this case, one of the actions must take priority, because what you see in the game depends on which one comes first. If you see a marine at the end, then you can conclude that the killing trigger was processed first. If you see a marine corpse, then you can conclude that the creating trigger was processed first.
For other examples, consider trying to move a marine left and right simultaneously, or creating two buildings at the same spot at the same time.
Whilst Veritaserum's examples are valid, they all involve 'blocking actions', which are a special case (albeit a fairly common special case). Everything must still be processed in some order, even if the "execution time" for each order can be rounded down to 0 milliseconds. Normally, entire triggers are processed one at a time, so that the actions of one trigger finish before those of the next one start.
As to the lag, look for repeated "complex" processes - a complex system like fishgold's "Micro Scan" or Tux's "Gunnner System" running many times a second, or an AI script running (especially if on preserve trigger), or ordering hundreds of units around at a time - all the things that others have said before already.
[attachmentid=14867]
*plays map* Legacy, you aren't completely correct in your prediction.What actually happens:
- Marines are created one by one at regular intervals. Two marines don't appear simultaneously at the beginning, nor does the production of marines stop after the first or second.
- The wait action finishes at around the seventh marine produced.
- The marines continue to be created at regular intervals. The wait action seems to have done nothing at all.
So it seems like the wait action didn't in fact force the first trigger to be checked again immediately. But, as the addition of a single hypertrigger can quickly verify, wait actions can and do force other triggers to be checked when the wait actions are run.
In this case, I suspect that the prediction failed because there were no triggers that were not yet checked by the time the second trigger (the wait trigger) ran - it found the end of the trigger list and decided that every trigger had run once already this trigger cycle, so didn't force the checking of triggers again.
As to whether actions from other triggers can run through wait actions, I think that this test clearly demonstrates that it is in fact possible. The first trigger continued to be checked every two game seconds whilst the wait action was running.
I would propose that there is a rule that StarCraft must check its trigger list at least once every two game seconds. Of course, it is possible for triggers to be checked faster.
Wait actions, transmissions, and centering view in single player are all "blocking actions", which makes them a little different from other actions.
Other actions, I'm pretty sure, can only be processed one at a time, even if they are in different triggers, or if they are for different players.
To see what I mean, consider that you could run two actions 'simultaneously'. But suppose that the two actions that I want to run simultaneously are "Create 1 marine for player 1" and "Kill all marine for player 1". After they both run, what do you see?
In this case, one of the actions must take priority, because what you see in the game depends on which one comes first. If you see a marine at the end, then you can conclude that the killing trigger was processed first. If you see a marine corpse, then you can conclude that the creating trigger was processed first.
For other examples, consider trying to move a marine left and right simultaneously, or creating two buildings at the same spot at the same time.
Whilst Veritaserum's examples are valid, they all involve 'blocking actions', which are a special case (albeit a fairly common special case). Everything must still be processed in some order, even if the "execution time" for each order can be rounded down to 0 milliseconds. Normally, entire triggers are processed one at a time, so that the actions of one trigger finish before those of the next one start.
As to the lag, look for repeated "complex" processes - a complex system like fishgold's "Micro Scan" or Tux's "Gunnner System" running many times a second, or an AI script running (especially if on preserve trigger), or ordering hundreds of units around at a time - all the things that others have said before already.