Does (Triggering player) survive "Wait 60 seconds"?

[nesatauri]

I hope to take care of this problem before it actually becomes a problem

I remember reading somewhere on this forum that the Wait function causes problems, one of which was that variables like Triggering unit, Triggering player, and so on may get lost or changed if there is a Wait somewhere in the trigger. I didn't bookmark the tread, so I am unsure.

Here is the trigger I am worried about. portalopentime = 60.00

• FF dial portal 12
  • Events
    • Player - Player 1 (Red) types a chat message containing dial as A substring
    • Player - Player 2 (Blue) types a chat message containing dial as A substring
    • Player - Player 3 (Teal) types a chat message containing dial as A substring
    • Player - Player 4 (Purple) types a chat message containing dial as A substring
    • Player - Player 5 (Yellow) types a chat message containing dial as A substring
    • Player - Player 6 (Orange) types a chat message containing dial as A substring
  • Conditions
    • (Substring((Entered chat string), 1, 5)) Equal to dial
    • (Substring((Entered chat string), 6, 7)) Equal to portalcode[1]
    • (Substring((Entered chat string), 8, 9)) Equal to portalcode[2]
    • (Substring((Entered chat string), 10, 15)) Equal to <Empty String>
    • portalbusy[1] Equal to False
    • portalbusy[2] Equal to False
    • connectionopen[(Player number of (Triggering player))] Equal to False
  • Actions
    • Set portalfrom[(Player number of (Triggering player))] = 1
    • Set portalto[(Player number of (Triggering player))] = 2
    • Neutral Building - Enable portal[portalfrom[(Player number of (Triggering player))]]
    • Set portalbusy[portalfrom[(Player number of (Triggering player))]] = True
    • Neutral Building - Set portal[portalfrom[(Player number of (Triggering player))]] destination to (Center of portalregions[portalto[(Player number of (Triggering player))]])
    • Set portalbusy[portalto[(Player number of (Triggering player))]] = True
    • Set connectionopen[(Player number of (Triggering player))] = True
    • Wait portalopentime seconds
    • Neutral Building - Disable portal[portalfrom[(Player number of (Triggering player))]]
    • Set portalbusy[portalfrom[(Player number of (Triggering player))]] = False
    • Neutral Building - Disable portal[portalto[(Player number of (Triggering player))]]
    • Set portalbusy[portalto[(Player number of (Triggering player))]] = False
    • Set portalfrom[(Player number of (Triggering player))] = 0
    • Set portalto[(Player number of (Triggering player))] = 0
    • Set connectionopen[(Player number of (Triggering player))] = False

I am worried that during that 60 second wait, this or another trigger will be triggered that will change (Triggering player) to a different player than this trigger is running for.

Also could anyone point me toward the thread that listed all those nasty problems with the wait function? If it doesn't exist we could create it here or elsewhere

 

[Razorbrain]

the thing is, there can be 2 different (Triggering players) in 2 different triggers that are fired at the same time. Only becouse another trigger is fired, doesnt mean the (Triggering player) in this trigger is Nulled. Anyhow, im not that sure if the (Triggering player) function lasts through a 60 second wait(i have never tried it before, but i dont see how it shouldnt, since there can only be 1 instance of this trigger at a time)

 

[Silvenon]

Somebody told me that event responses don't work after waits, so..... I suggest you put the Triggering player in a variable before the wait (that really shouldn't be a problem, plus, it's more efficient).

 

[spiwn]

Event responses other than triggering unit. Yeah, but what about triggering player.
But putting it in a variable is recommended( a local with the name of an global).

 

[nesatauri]

the thing is, there can be 2 different (Triggering players) in 2 different triggers that are fired at the same time. Only becouse another trigger is fired, doesnt mean the (Triggering player) in this trigger is Nulled. Anyhow, im not that sure if the (Triggering player) function lasts through a 60 second wait(i have never tried it before, but i dont see how it shouldnt, since there can only be 1 instance of this trigger at a time)

Ya, a bit after posting, I realized that completely by accident, I set up the conditionals so that this particular trigger won't fire again while it is waiting. If it is true that the Triggering player from one trigger won't change the Triggering player of another, then this trigger should be fine as it is.

There are 30 other triggers that my map uses that are very similar to this one I was thinking of consolidating into one or three triggers that would do the same thing. The protection of the conditionals wouldn't be there anymore if I did so however, so if I did that, there could be 3 or 4 instances of the trigger firing during the wait.

Well, I guess I could do something like

• FF dial portal 12
  • Events
    • Player - Player 1 (Red) types a chat message containing dial as A substring
    • Player - Player 2 (Blue) types a chat message containing dial as A substring
    • Player - Player 3 (Teal) types a chat message containing dial as A substring
    • Player - Player 4 (Purple) types a chat message containing dial as A substring
    • Player - Player 5 (Yellow) types a chat message containing dial as A substring
    • Player - Player 6 (Orange) types a chat message containing dial as A substring
  • Conditions
    • (Substring((Entered chat string), 1, 5)) Equal to dial
    • (Substring((Entered chat string), 6, 7)) Equal to portalcode[1]
    • (Substring((Entered chat string), 8, 9)) Equal to portalcode[2]
    • (Substring((Entered chat string), 10, 15)) Equal to <Empty String>
    • portalbusy[1] Equal to False
    • portalbusy[2] Equal to False
    • connectionopen[(Player number of (Triggering player))] Equal to False
  • Actions
    • Set portalfrom[(Player number of (Triggering player))] = 1
    • Set portalto[(Player number of (Triggering player))] = 2
    • Trigger - Run portalopen <gen> (ignoring conditions)
    • Wait portalopentime seconds
    • Trigger - Run portalclose <gen> (ignoring conditions)

with portalopen and portalclose being the parts of the previous trigger before and after the wait. It will cut down on the clutter and make the portal triggers easier to edit, at least.

Edit: Found something useful in the related posts. I'm going to use a variable just to be on the safe side.

 

[PurplePoot]

@Everyone: Some event responses work after waits, some don't. It seems rather arbitrary, but there may be a pattern.

 

[spiwn]

Some events responses are local and some are not.
If it is the only trigger in the map all event responses seem to work most of the time after waits.
But it seem we are too lazy to test this one

• FF dial portal 12
  • Events
    • Player - Player 1 (Red) types a chat message containing dial as A substring
    • Player - Player 2 (Blue) types a chat message containing dial as A substring
    • Player - Player 3 (Teal) types a chat message containing dial as A substring
    • Player - Player 4 (Purple) types a chat message containing dial as A substring
    • Player - Player 5 (Yellow) types a chat message containing dial as A substring
    • Player - Player 6 (Orange) types a chat message containing dial as A substring
  • Conditions
    • (Substring((Entered chat string), 1, 5)) Equal to dial
    • (Substring((Entered chat string), 6, 7)) Equal to portalcode[1]
    • (Substring((Entered chat string), 8, 9)) Equal to portalcode[2]
    • (Substring((Entered chat string), 10, 15)) Equal to <Empty String>
    • portalbusy[1] Equal to False
    • portalbusy[2] Equal to False
    • connectionopen[(Player number of (Triggering player))] Equal to False
  • Actions
    • Custom script: local udg_temp_player=Player number of (Triggering Player())
    • Set portalfrom[temp_player] = 1
    • Set portalto[temp_player] = 2
    • Neutral Building - Enable portal[portalfrom[temp_player]]
    • Set portalbusy[portalfrom[temp_player]] = True
    • Neutral Building - Set portal[portalfrom[temp_player]] destination to (Center of portalregions[portalto[temp_player]])
    • Set portalbusy[portalto[temp_player]] = True
    • Set connectionopen[temp_player] = True
    • Wait portalopentime seconds
    • Neutral Building - Disable portal[portalfrom[temp_player]]
    • Set portalbusy[portalfrom[temp_player]] = False
    • Neutral Building - Disable portal[portalto[temp_player]]
    • Set portalbusy[portalto[temp_player]] = False
    • Set portalfrom[temp_player] = 0
    • Set portalto[temp_player] = 0
    • Set connectionopen[temp_player] = False

But you will have to make a global variable of type integer with name temp_player

 

[Captain Griffen]

Triggering player is fine, 99% sure. And ffs don't tell people how to use the local global trick without explaining it properly.

On a different point, at least use polled wait (gametime wait).

 

[spiwn]

Triggering player is fine, 99% sure. And ffs don't tell people how to use the local global trick without explaining it properly.

On a different point, at least use polled wait (gametime wait).

You are right, I should have explained it.
Here:
In GUI you can make/create/initialize one local variable with the same name as a global variable.
As it is GUI, each time you want to refer to a variable you have to select it from a list, so no local variables should work. But if the local variable has the same name as a global one and you refer to the global one, warcraft 3 will actually refer to the local one.
Polled wait is just more accurate. I doubt a difference of 0.3-0.4 seconds(those numbers are a bit high) would make the difference.
P.s. I also think that Triggering Player works but am too lazy to check.

 

[GhostWolf]

Triggering Unit is a trigger member, so I would think that Triggering Player is the same (meaning its fully MUI).

 

[UreDe4D]

you could simply copy the trigger 6 times and have a different player on every trigger, so every trigger has only one triggering player

 

[spiwn]

you could simply copy the trigger 6 times and have a different player on every trigger, so every trigger has only one triggering player

Er, no : D

 

[nesatauri]

you could simply copy the trigger 6 times and have a different player on every trigger, so every trigger has only one triggering player

There were already 30 copies of this trigger, and I recently added 6 more copies.

splitting them up further would give me 216 triggers!

Here's what I've done with it in the meanwhile as an update:

• portal open
  • Events
  • Conditions
  • Actions
    • Neutral Building - Enable portal[portalfrom[(Player number of (Triggering player))]]
    • Set portalbusy[portalfrom[(Player number of (Triggering player))]] = True
    • Neutral Building - Set portal[portalfrom[(Player number of (Triggering player))]] destination to (Center of portalregions[portalto[(Player number of (Triggering player))]])
    • Set portalbusy[portalto[(Player number of (Triggering player))]] = True
    • Set connectionopen[(Player number of (Triggering player))] = True
    • Environment - Create at portalregions[portalto[(Player number of (Triggering player))]] the weather effect Rays Of Light
    • Set portalweather[(Player number of (Triggering player))] = (Last created weather effect)

• portal close
  • Events
  • Conditions
  • Actions
    • Neutral Building - Disable portal[portalfrom[(Player number of Bsing)]]
    • Set portalbusy[portalfrom[(Player number of Bsing)]] = False
    • Neutral Building - Disable portal[portalto[(Player number of Bsing)]]
    • Set portalbusy[portalto[(Player number of Bsing)]] = False
    • Set portalfrom[(Player number of Bsing)] = 0
    • Set portalto[(Player number of Bsing)] = 0
    • Set connectionopen[(Player number of Bsing)] = False
    • Environment - Remove portalweather[(Player number of Bsing)]

• FF dial portal 12
  • Events
    • Player - Player 1 (Red) types a chat message containing dial as A substring
    • Player - Player 2 (Blue) types a chat message containing dial as A substring
    • Player - Player 3 (Teal) types a chat message containing dial as A substring
    • Player - Player 4 (Purple) types a chat message containing dial as A substring
    • Player - Player 5 (Yellow) types a chat message containing dial as A substring
    • Player - Player 6 (Orange) types a chat message containing dial as A substring
  • Conditions
    • (Substring((Entered chat string), 1, 5)) Equal to dial
    • (Substring((Entered chat string), 6, 7)) Equal to portalcode[1]
    • (Substring((Entered chat string), 8, 9)) Equal to portalcode[2]
    • (Substring((Entered chat string), 10, 15)) Equal to <Empty String>
    • portalbusy[1] Equal to False
    • portalbusy[2] Equal to False
    • connectionopen[(Player number of (Triggering player))] Equal to False
  • Actions
    • Set portalfrom[(Player number of (Triggering player))] = 1
    • Set portalto[(Player number of (Triggering player))] = 2
    • Trigger - Run portal open <gen> (ignoring conditions)
    • Set B[12] = (Triggering player)
    • Wait portalopentime seconds
    • Set Bsing = B[12]
    • Trigger - Run portal close <gen> (ignoring conditions)

• FF dial portal 46
  • Events
    • Player - Player 1 (Red) types a chat message containing dial as A substring
    • Player - Player 2 (Blue) types a chat message containing dial as A substring
    • Player - Player 3 (Teal) types a chat message containing dial as A substring
    • Player - Player 4 (Purple) types a chat message containing dial as A substring
    • Player - Player 5 (Yellow) types a chat message containing dial as A substring
    • Player - Player 6 (Orange) types a chat message containing dial as A substring
  • Conditions
    • (Substring((Entered chat string), 1, 5)) Equal to dial
    • (Substring((Entered chat string), 6, 7)) Equal to portalcode[4]
    • (Substring((Entered chat string), 8, 9)) Equal to portalcode[6]
    • (Substring((Entered chat string), 10, 15)) Equal to <Empty String>
    • portalbusy[4] Equal to False
    • portalbusy[6] Equal to False
    • connectionopen[(Player number of (Triggering player))] Equal to False
  • Actions
    • Set portalfrom[(Player number of (Triggering player))] = 4
    • Set portalto[(Player number of (Triggering player))] = 6
    • Trigger - Run portal open <gen> (ignoring conditions)
    • Set B[46] = (Triggering player)
    • Wait portalopentime seconds
    • Set Bsing = B[46]
    • Trigger - Run portal close <gen> (ignoring conditions)

That should ensure the Triggering player makes it through the wait.

Do Players and Weather Effects leak? These triggers could turn into a leak fest if the players aren't first timers. I could easily change the variables B and Bsing into integer variables if its a problem. The weather effect isn't necessary so I could just get rid of it.

Before someone picks on me for (Center of portalregions[portalto[(Player number of (Triggering player))]]), I know its leaky and I intend on fixing it soon.

Edit: Since Triggering player probably won't cause problems, but global variables B and Bsing will, I'm going to go back to using Triggering player.

Edit 3:Just tested things out. Player doesn't leak, Weather effects do (duh, its a handle) but remove weather effect takes care of it just fine. Yay!