If I have Trigger A, in which I can refer to "TRIGGERING PLAYER", and from that make a call to run Trigger B, will Trigger B have the same "TRIGGERING PLAYER"?
Also is it reliable?
If not, is there any way to pass a variable to a trigger you are calling, or do you just use functions in those cases?
you can use it, you just can't be certain it's the same value as at the start of the trigger.
The event variables (like triggering player, created unit, etc.) can be reset if you use a wait in your trigger because an other trigger ran while this trigger was waiting.
As mentioned, they are global, so you are prone to race conditions regardless, but if you are doing a wait you are pretty much guaranteed a race condition will occur.
Add this to an empty map, then move around some units. The units die in the correct order. Triggering Unit does not overwrite itself. It can be used just like a local variable.
Even more interesting, even this works:
MeleeInitializationEventsUnit-AnyUnitisissuedanordertoMoveActionsTrigger-RunMeleeInitialization2(CheckConditions,Don't Wait until it finishes)MeleeInitialization2EventsActionsGeneral-Wait2.0GameTimesecondsUnit-Kill(Triggeringunit)
As you see, the trigger with the actual event calls a different trigger which then uses triggering unit after a wait. That works flawless, even when moving a dozen units at once.
Even adding an additional wait before running Melee Init 2 works.
Looks like all event responses are saved in a list, stack or whatever and can be called from there (probably with a time stamp or an ID). The triggers will always get the event responses that were created at the time the event fired. Triggers that were run from within these triggers seem to inherit their "parent's" event responses.
There's nothing there that would cause a race condition,
which is why triggering unit (EventUnit) still points to the previous value because it has yet to be overwritten.
If Triggering Unit was a global, how would I be able to run the above triggers mutliple times at the same time without causing a race condition?
I can move a dozen units at once or quickly after each other and after the 5 seconds delay every unit dies in the right order.
Yeah tried it, figured it would fail with multiple units, but turns out it works.
However have been cases where EventUnit has returned null after a thread sleep, not sure what this leaves us at, is it thread local, undefined behaviour in certain events, etc.
maybe blizzard fixed it without mentioning it. At beta it was so that those trigging player, etc. event stuff wasn't localized.
could be that it got fixed at release.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
If I have Trigger A, in which I can refer to "TRIGGERING PLAYER", and from that make a call to run Trigger B, will Trigger B have the same "TRIGGERING PLAYER"?
Also is it reliable?
If not, is there any way to pass a variable to a trigger you are calling, or do you just use functions in those cases?
Yes, UNTIL a Wait call is made from anywhere within the execution context. After that, all bets are off.
And no you can't pass arguments to triggers via Run Trigger, so you need to use global variables.
In fact, that's all the (Triggering player)-type functions are - getters for global variables.
Okay thanks.
@RileyStarcraft: Go
Are you sure they are global? How come you can use triggering player inside its original trigger even after a wait.
@Vexal: Go
you can use it, you just can't be certain it's the same value as at the start of the trigger.
The event variables (like triggering player, created unit, etc.) can be reset if you use a wait in your trigger because an other trigger ran while this trigger was waiting.
@Vexal: Go
As mentioned, they are global, so you are prone to race conditions regardless, but if you are doing a wait you are pretty much guaranteed a race condition will occur.
That is untrue. EventUnit (Triggering Unit) is not just a getter for a global.
Add this to an empty map, then move around some units. The units die in the correct order. Triggering Unit does not overwrite itself. It can be used just like a local variable.
Even more interesting, even this works:
As you see, the trigger with the actual event calls a different trigger which then uses triggering unit after a wait. That works flawless, even when moving a dozen units at once. Even adding an additional wait before running Melee Init 2 works.
Looks like all event responses are saved in a list, stack or whatever and can be called from there (probably with a time stamp or an ID). The triggers will always get the event responses that were created at the time the event fired. Triggers that were run from within these triggers seem to inherit their "parent's" event responses.
There's nothing there that would cause a race condition, which is why triggering unit (EventUnit) still points to the previous value because it has yet to be overwritten.
@caspersc: Go
If Triggering Unit was a global, how would I be able to run the above triggers mutliple times at the same time without causing a race condition?
I can move a dozen units at once or quickly after each other and after the 5 seconds delay every unit dies in the right order.
Yeah tried it, figured it would fail with multiple units, but turns out it works. However have been cases where EventUnit has returned null after a thread sleep, not sure what this leaves us at, is it thread local, undefined behaviour in certain events, etc.
@caspersc: Go
maybe blizzard fixed it without mentioning it. At beta it was so that those trigging player, etc. event stuff wasn't localized.
could be that it got fixed at release.