Trigger queue, what is it good for?

I can find pratically no information on the trigger queue, I know of one use that is ensuring triggers run in correct order and one after the other (ie how it's done in the campiagn maps). Good if you dont want to "chain" multiple triggers in a sequence.

Is there any other compelling reason to use the trigger queue? Prehaps reducing server splits by ensuring triggers run in a well defined order or something?

I never use TQueue... It's just a trigger array and Blizzard.j contains several functions allow you to manipulate triggers in that queue. I use the same thing - global-defined trigger array which contains handle to every trigger in my script. So I always know which trigger is running and can manage that "queue" if it's necessary :) I guess TQueue was declared for using with editor GUI and it is not necessary for people writing on JASS.

P.S. This is just my modest opinion...

In RoC times when I didn't know anything about JASS I had to use the trigger queue to make computers select from a range of 12 heroes without chosing one twice.

But when you know about JASS and loop it is kinda innecesary

Does anyone know if war3 uses 1 thread internally for trigger execution? In other words: can 2 triggers be executing at the exact same time?

I'm almost certain war3 uses only 1 thread, because otherwise usage of globals in callback functions would cause serious errors.

Anyway, this means that only the code of 1 trigger (conditions and actions) is run at a time. War3 doesn't start execution of another trigger until the currently executing trigger yields (runs to completion, calls a wait function like TriggerSleepAction, or executes a lot of instruction).

The purpose of the TQueue seems to be to prevent 2 triggers from executing at the same time. Then why would you need it anyway? Sleeps are easily controlled, and a trigger rarely hits the maximum # of instructions.

Okay the best use I know of for trigger queue is getting the timing right in cinematics and stuff:

Lets say you want 3 triggers to run in some order - these triggers have wait actions.

In your master trigger you could then just add these:
Add triggerA to trigger queue
Add triggerB to trigger queue
Add triggerC to trigger queue

This way you dont need to "chain" them (ie have run triggerB at the end of triggerA). I bet this could be really useful if for some reason you had a number of triggers that you wanted to run in random order (random cinematic?).

As far as I can tell theres never a NEED to use the trigger queue, in some cases it's just a bit cleaner than other possible solutions. (that means dont say "but you could do that this way instead!...")

2 jmoritz:

Yes, Warcraft supports several "copies" of one trigger running at same time. But they don't interact among themselves in memory, each one using its own object handles f.e. GetTriggerUnit(), GetTriggerPlayer() etc.

Simple example:

Create simple trigger, which fires when unit enters region. When some units will enter that region, trigger will be executed several times. And GetTriggerUnit() in every "copy" of that trigger will refferer to unit caused trigger to fire.

That doesn't mean they are separate threads. They could simply have their own part of memory allocated. Any way, if they do are threads they do not swap whenever they want. One trigger runs fully until it reaches the end of the tirgger or a wait statement is reached.

A simple trigger like that runs lightning fast. Ik could complete execution before the next unit enters the region. You'd have to make 2 triggers that fire on the same event, and then have them both do a loop (without waits), that reads and writes a variable. I'm too lazy to test this, because I'm almost certain I'm right :)

I once had a trigger and every copy of the trigger running at the same time incremented a global variable...
it proves jmoritz right

Just submitting some stuff to the conversation, although most of you know this already, but i believe there are still many that don't. But with this knowledge you will have a easier time debugging complex scripts, and you'll know wether too choose between functions, or triggers. (if you did know this already, just dismiss it)

But basicly, As you already said, a trigger has solo-focus from the run-time until it meets a TriggerSleepAction, or when it finishes (not counting the limit). But you still have to watch out for function-calls. If you call a function, the runtime will focus on it, and it will "not" return to the calling trigger when the called function meets a "TriggerSleepAction". So f.ex. that's why if you want to keep track of some event, it's not good to have called functions wait for it. F.ex. you call your custom function which creates a special effect, and you want the function to wait it's duration and destroy it at the end, it will, but the calling trigger/function will not continue untill it has. That's why the submitted SFX-functions in our vault automatically create triggers that do the sleeping.

So if you want another code to be run parallel to the running code (ofcourse not at the exact same time, and this would be using sleeps), you'll have to create a new trigger and "execute" it. But the obvious flaws of this is that it's harder to give parameters to the new trigger. Well, you can do the simple method and just have a few temporary globals that you use to "pass" stuff into the new trigger (instantly replaced by locals (resetting the globals if needed)). There are also some other methods though.

But this knowledge is very important when coding in jass, as f.ex. I have needed it alot in my reasent coding in TKoD, f.ex. handling scripted Hero Deaths, handling Special Effects, handling Victory-related stuff and i could go on and on.

Anyways (but as i said, most of us here know this already, considering the quality in the already submitted functions in the vault)

Cubasis