Teleporting Trigger Not Working

[Theory]

I've been working on a map and was made aware by my testers that one of the big issues in it was travel time. For forward-travelling, I had way gates set up that become enabled when certain objectives are completed; no, that wasn't the issue.
The issue was travelling BACK. I have a system set up where the 'heroes' have a base at the start of the map, that occasionally (every 30 minutes) is assaulted by a very powerful mob. However, the map is very large, and while it isn't an issue to walk back in the early stages, it becomes much more troublesome when you're 3/4 of the way through and it takes a fierce 5 to 10 minutes *just* to walk back to the start. In response to this, I made a simple trigger that allows players to recall their units back to their starting base -- starting base which has a way gate to later points in the game, hence why travelling forward is not an issue.

This is the trigger.
Now, here is the issue I face; when I try recalling a unit (selecting the unit, typing '-Recall' in the chat), it does the first part. It pauses the unit.
And then it waits 10 seconds.
And 10 more seconds.
And 10 more.
Actually, it doesn't stop waiting, it just pauses the unit. I could understand if the trigger constantly checked for the unit to remain selected, but if I keep the unit selected it doesn't change the fact that it is now paused permanently. And if I change my unit selection, it doesn't pause the newly selected unit.
Anyone know what could be causing this?

 

[Swatosj]

The problem you are facing is a reference problem, after the 10 seconds wait, the value of (picked unit) is unsure and may reference something else as it is a global variable you don't control.

I'd suggest you to use either a timer, either a periodic manual count (decrease by 1 every 1s) for each unit in your loop so you can have safe reference to the unit you paused.

You may check this previous answer I gave about using timers and arrays to store units for later use : here

 

[Theory]

Would it work to add the selected unit to a unit group at the start of the trigger, use that as the variable, and remove the unit at the end of the trigger?
Thank you for the reply!

 

[FUJI]

Yes, you shouldn't use waits inside the 'Unit Groups'.
However, you can insert those units into another group then wait for 10, unpause and remove them to that group.

• Test
  • Events
    • Player - Player 1 (Red) types a chat message containing -recall as A substring
  • Conditions
  • Actions
    • Custom script: set bj_wantDestroyGroup = true
    • Unit Group - Pick every unit in (Units currently selected by (Triggering player)) and do (Actions)
      • Loop - Actions
        • Unit - Pause (Picked unit)
        • Unit Group - Add (Picked unit) to Paused_Group
    • Wait 10.00 seconds
    • Unit Group - Pick every unit in Paused_Group and do (Actions)
      • Loop - Actions
        • Unit - Unpause (Picked unit)
        • Unit Group - Remove (Picked unit) from Paused_Group

The custom script is there for destroying the selection group to prevent a leak.
Paused_Group is our constant group variable.

Note that this is the most basic but inaccurate way on your case.

If you prefer accuracy and less abusive way, you can do that with indexing and timers.

 

[Deserted]

Would it work to add the selected unit to a unit group at the start of the trigger, use that as the variable, and remove the unit at the end of the trigger?

Yes, it would work okay if the unit group is a local variable.
If that's a global variable, one request would be able to interfere with another.

Also there are Things That Leak so one should destroy groups that are no longer necessary.

@JAKEZINC
I recall 1 footman
Wait 5 sec
Recall another
In 5 sec both are recalled, cause both are in Paused_Group

 

[Uncle]

This trigger will pause selected units and teleport them 10 seconds later. If a unit is already paused (recalling already) then it won't get recalled again.

• Recall Type
  • Events
    • Player - Player 1 (Red) types a chat message containing -Recall as An exact match
  • Conditions
  • Actions
    • Set VariableSet RecallGroup = (Units currently selected by (Triggering player))
    • Unit Group - Pick every unit in RecallGroup and do (Actions)
      • Loop - Actions
        • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
          • If - Conditions
            • (Owner of (Picked unit)) Equal to (Triggering player)
            • ((Picked unit) is paused) Equal to False
          • Then - Actions
            • Trigger - Run Recall Pause <gen> (ignoring conditions)
          • Else - Actions
    • Custom script: call DestroyGroup (udg_RecallGroup)

This trigger uses global variable shadowing (local udg_) to keep track of our recalled units even after the Wait. I run this trigger once for each of the Recalled units. GetEnumUnit() = Picked Unit.

• Recall Pause
  • Events
  • Conditions
  • Actions
    • Custom script: local unit udg_RecallUnit = GetEnumUnit()
    • Unit - Pause (Picked unit)
    • Wait 10.00 seconds
    • Set VariableSet RecallPoint = (Center of (Playable map area))
    • Unit - Move RecallUnit instantly to RecallPoint
    • Unit - Unpause RecallUnit
    • Custom script: call RemoveLocation (udg_RecallPoint)
    • Custom script: set udg_RecallUnit = null

The DestroyGroup/RemoveLocation stuff is used to clean up Memory Leaks. This will help keep your map performing well.

Edit: I forgot to null udg_RecallUnit in the 2nd trigger.

 

[Swatosj]

@Uncle Omg, what a trick... If I had heard about global variable shadowing before....

 

[FUJI]

@Deserted

Note that this is the most basic but inaccurate way on your case.

If you prefer accuracy and less abusive way, you can do that with indexing and timers.

Yes, it would work okay if the unit group is a local variable.

I'm also not expecting to work with local groups in this case,
ForGroup already splits the code for callback which makes the local groups inaccessible anyway.

Uncle's way should work in accurate with the help of shadowing the reference. Brilliant.

 

[Uncle]

Yeah, it's pretty useful for GUI. Note that I edited my previous post as I had forgotten an important step, nulling the local variable when we're done using it.

 

[Deserted]

ForGroup already splits the code for callback which makes the local groups inaccessible anyway.

Yeah, local group itself isn't accessible, but (Picked unit) is.