Staredit Network

Out of all those days hearing the term "Trigger cycle", I still don't understand what it means. I've been searching the forum for some kind of definition but the best I could find was Bolt_Head's tutorial. But after reading it, I still couldn't get a faint picture
Can anyone explain the specific meaning of a "Trigger cycle" in an easy way along with some examples? And what means by "the next ending occurance"...

p.s. sorry if my grammer is a bit broken... these language barriers are somewhat painful

Every 2000 milliseconds SC reads your triggers to see if some of them need to be executed, in the order of the trigger cycle.

The reason for this is that computers can't execute more then 1 action at a time, they can do many actions fast so that it'll seem that way but infact it's only doing them 1 by 1.
The point is - triggers only execute if all conditions are true, but when if the computer checking if they're true? once in 2000 milliseconds.
It won't check every shread of second because that will totally lag-off your maps.

Althought, you can make it check the triggers 12 times in a second instead by using hyper triggers, to give your map better preformance.

Also, since the computer checks them 1 by 1, you're probably wondering what triggers are being checked first and what last.
It first checks player 1's triggers by the order they're written in the editor, than player 2's, than 3, etc.
If I'm not mistaken than it checks the 'All Players' and than the forces by their order.

You can use this for your maps, for example if you have a trigger like this:

C:
Current player brings at least 1 marine to anywhere.

A:
Kill all marine for all players.
Give 10 minerals for current player.

For players 1 and 2, and both get a marine at the same time - only player 1 will get the 10 minerals.

Are you Korean?

I think what they mean is in what order the trigger's fire. It's a mechanic with little pratical use, but if your inexperienced in UMS then it can cause lots of problems for your maps, especially the big projects.
Here is a tutorial by Dabbu, but it's a little hard to wrap your head around though.

The fundamental thing you need to remember about trigger cycles is that they execute in decending order. So first all of P1's triggers execute, then all of P2's triggers.
This gets a bit more complicated when you use all players, or forces.
Making a trigger for all players, is effectivly the same as making a tirgger for P1,P2,P3,P4,P5,P6,P7 and P8.
So lets say I make 4 triggers in the corisponding order. Trigger A is for P2, Trigger B is for P6, Trigger C is for all players, and Trigger D is for force 1 (which contains P1 and P2).

Those triggers would fire like this (the number corisponds to the player it fires for, and the letter is the trigger letter): 1C, 1D, 2A, 2C, 2D, 3C, 4C, 5C, 6B, 6C, 7C, 8C.

ADDITION:

Your mistaken. Read Dabbu's tutorial.

Did you check out the glossary? http://www.staredit.net/index.php?showtopic=13145
Also my post in the glossary (last part) http://www.staredit.net/index.php?showtopi...ndpost&p=175972

Thanks for all the help >.< I seem to get the picture now
so does it mean the trigger cycle works like this?

NEO -> Trigger cycle starts -> checks p1 first trigger conditions -> if it satifies, then executes Actions(if not satisfied, then doesn't execute actions and moves along to second trigger condition) -> checks p2 second trigger conditions -> If satisfied, executes Actions -> and so on........... -> checks p8 last trigger conditions -> executes Actions if conditions are satisfied -> NEO -> Trigger cycle starts all over again

Am I getting it right?
That means the trigger cycle will be checking every trigger conditions
in a split second and will do that over and over in every 2 seconds untill the
game ends. And hyper triggers will make the process much faster.

m.r.bob // yes I am korean. and I've read dabbu's tutorial but my head almost blew up after reading it

Bolt_Head // thanks for the posted links. After reading it though, I think it would have been better if it had some more additional explanation in it(the glossary) cause it might be hard for some newbie map makers to understand the whole thing without knowing what orders triggers work out and how they fire. but still I learned many new things

Very close, the indended definition is a little bit differant when involveing waits. By definition the trigger cycles are seperated by the Next Ending Occurance. A hyper trigger actually DELAYS the NEO. Thus the trigger cycle is extended.

Triggers can be checked again within a trigger cycle as an effect of a wait. I called this a "wait round".

So with your basic hyper trigger (with it at the end of the trigger list). You would first exicute most of your trigger cycle but it would slowdown to almost a stop at the end and just start running wait rounds checking the triggers in the same way you described above.

With the glossary you have to find a ballance between the pure definition and a report on a topic.

PS. I don't belive there is a NEO at the start of the game. I think the triggers fire first then they wait.

okay, I think I got the point Just one last thing...
Wait rounds... as mentioned in the glossory, they will start checking
triggers from the trigger after 'the trigger which contains the wait' till the trigger before 'the trigger which contains the wait'.

If we assume there's a trigger

-Trig 1 for p1-
-Trig 2 for p1-
-Trig 3 for p1-
: Contains a wait(0); in it
-Trig 1 for p2-
-Trig 2 for p2-

then does it mean it'll check the trigger like this?

p1-Trig 1 : p1-Trig 2 : p1-Trig 3(Stops cycle here) : p2-Trig 1 : p2-Trig 2
: p1-Trig 1(no NEO occured) : p1-Trig 2 : (goes back to cycle) p1-Trig 3 action
: p2-Trig 1 : p2-Trig 2 : NEO , and so on...

I have a faint feeling it might go something like this though...

p1-Trig 1 : p1-Trig 2 : p1-Trig 3(Stops cycle here) : p1-Trig 1 : p1-Trig 2 :
p2-Trig 1 : p2-Trig 2 :(goes back to cycle) p1-Trig 3 action : p2-Trig 1 : p2-Trig 2
: NEO , and so on...

I doubt it's the latter but it's still quite confusing...just willing for a clear answer to it

It goes exactly how you listed it in your first example.

Except you could be more specific when refering to the wait. The wait round 'starts' when the wait action begins to exiute. All actions before the wait will run normally. And of course the actions after the wait don't start until the wait time has been carried out.

Very interesting
Now things seem to get straight.
Thanks a bunch for all the assistance !!!