[Crash] Slider-Based Trigger Leak

u wot m8_ · Jul 22, 2022

It's been around year since i have taken a break from working on my map, and a few days ago i've returned to working on it.
I have added new content and everything seemed to work fine... that's until i've tested the map for a while and it suddenly crashed to a memory leak.
After tracing the cause, i have found out that the slider system i have made for the map's plane units' movement is the cause to the leak, which i have found out after training a lot of planes and letting them chill with their idle slider circling movement, which has caused the game's memory consumption to constantly go up until the frame drops make it barely playable.
I have been trying to inspect the triggers as carefully as possible but to no avail, i can't seem to find the leak source.
Here are the triggers, any kind of help will be appreciated.

Here's the trigger for the idle sliding:

Slide
- Events
  - Time - Every 0.03 seconds of game time
- Conditions
- Actions
  - Unit Group - Pick every unit in Sliders and do (Actions)
    - Loop - Actions
      - Set Loc1 = (Position of (Picked unit))
      - Set Loc3 = ((Position of (Picked unit)) offset by ((Real((Custom value of (Picked unit)))) / PlaneSpeedModifier) towards ((Facing of (Picked unit)) + 3.00) degrees)
      - Unit - Make (Picked unit) face Loc3 over 0.00 seconds
      - Set Loc2 = (Loc1 offset by ((Real((Custom value of (Picked unit)))) / PlaneSpeedModifier) towards (Facing of (Picked unit)) degrees)
      - Custom script: call SetUnitX( GetEnumUnit(), GetLocationX(udg_Loc2) )
      - Custom script: call SetUnitY( GetEnumUnit(), GetLocationY(udg_Loc2) )
      - Custom script: call RemoveLocation(udg_Loc3)
      - Custom script: call RemoveLocation(udg_Loc2)
      - Custom script: call RemoveLocation(udg_Loc1)

And here's the trigger for the movement sliding:

Slide2
- Events
  - Time - Every 0.03 seconds of game time
- Conditions
- Actions
  - Unit Group - Pick every unit in Sliders2 and do (Actions)
    - Loop - Actions
      - Set Loc1 = (Position of (Picked unit))
      - Set Loc2 = (Loc1 offset by ((Real((Custom value of (Picked unit)))) / PlaneSpeedModifier) towards (Facing of (Picked unit)) degrees)
      - Custom script: call SetUnitX( GetEnumUnit(), GetLocationX(udg_Loc2) )
      - Custom script: call SetUnitY( GetEnumUnit(), GetLocationY(udg_Loc2) )
      - Custom script: call RemoveLocation(udg_Loc3)
      - Custom script: call RemoveLocation(udg_Loc2)
      - Custom script: call RemoveLocation(udg_Loc1)

Lordul Dracula · Jul 22, 2022

Well you made an event Every 0.03 also you never removed any units from that Sliders2 group

u wot m8_ · Jul 22, 2022

Lordul Dracula said:
Well you made an event Every 0.03 also you never removed any units from that Sliders2 group

it's necessary for the trigger to be fired every 0.03 seconds due to it being a sliding trigger.
Units are removed from the sliders groups in other triggers.

Slide Return Copy
- Events
  - Time - Every 0.03 seconds of game time
- Conditions
- Actions
  - Unit Group - Pick every unit in Sliders2 and do (Actions)
    - Loop - Actions
      - If (All Conditions are True) then do (Then Actions) else do (Else Actions)
        
        If - Conditions
        
        (Current order of (Picked unit)) Equal to (Order(none))
        
        Then - Actions
        
        Unit Group - Add (Picked unit) to Sliders
        
        Unit Group - Remove (Picked unit) from Sliders2
        
        Else - Actions

Slide Move
- Events
  - Unit - A unit Is issued an order targeting a point
  - Unit - A unit Is issued an order targeting an object
- Conditions
  - ((Triggering unit) is in Planes) Equal to True
- Actions
  - Unit Group - Remove (Triggering unit) from Sliders
  - Unit Group - Add (Triggering unit) to Sliders2

Basically these poorly named triggers determine whether the unit is idle or not, and based on that they change or don't change it's sliders group, which determines it's type of sliding.

Additionally, i have a trigger that removes a unit from all of it's groups upon death.

Remove From All Unit Groups After Death
- Events
  - Unit - A unit Dies
- Conditions
- Actions
  - Unit Group - Remove (Triggering unit) from Sliders
  - Unit Group - Remove (Triggering unit) from Sliders2
  - Unit Group - Remove (Triggering unit) from Airfields[((Player number of (Owner of (Triggering unit))) - 1)]

So i don't think the problem lies within those triggers, but tell me if i have missed anything because it's possible of course.

ThompZon · Jul 22, 2022

u wot m8_ said:
Slide

Events

Time - Every 0.03 seconds of game time

Conditions

Actions

Unit Group - Pick every unit in Sliders and do (Actions)

Loop - Actions

Set Loc1 = (Position of (Picked unit))

Set Loc3 = ((Position of (Picked unit)) offset by ((Real((Custom value of (Picked unit)))) / PlaneSpeedModifier) towards ((Facing of (Picked unit)) + 3.00) degrees)

Unit - Make (Picked unit) face Loc3 over 0.00 seconds

Set Loc2 = (Loc1 offset by ((Real((Custom value of (Picked unit)))) / PlaneSpeedModifier) towards (Facing of (Picked unit)) degrees)

Custom script: call SetUnitX( GetEnumUnit(), GetLocationX(udg_Loc2) )

Custom script: call SetUnitY( GetEnumUnit(), GetLocationY(udg_Loc2) )

Custom script: call RemoveLocation(udg_Loc3)

Custom script: call RemoveLocation(udg_Loc2)

Custom script: call RemoveLocation(udg_Loc1)

In this trigger, Loc3 does not use Loc1 for its "initial position", so that's a leak per unit per 0.03 seconds.

u wot m8_ · Jul 22, 2022

ThompZon said:
In this trigger, Loc3 does not use Loc1 for its "initial position", so that's a leak per unit per 0.03 seconds.

Yeah seems like i have overlooked that.
Though despite changing it the game's memory consumption still creeps up like it did before.
Anything else i could have missed?

ThompZon · Jul 22, 2022

u wot m8_ said:
Yeah seems like i have overlooked that.
Though despite changing it the game's memory consumption still creeps up like it did before.
Anything else i could have missed?

Good question. Not that I can see in the triggers above.

I'd look for leaks in stuff that runs a lot (I.E. short timers or large groups typically), points and groups are most common and maybe excessive unit-creation (do you have a ton of dummies?).

btw, Slide2 removes Loc3 but does not use it. I don't think that should be an issue, but still... It's not needed.

u wot m8_ · Jul 22, 2022

ThompZon said:
Good question. Not that I can see in the triggers above.

I'd look for leaks in stuff that runs a lot (I.E. short timers or large groups typically), points and groups are most common and maybe excessive unit-creation (do you have a ton of dummies?).

btw, Slide2 removes Loc3 but does not use it. I don't think that should be an issue, but still... It's not needed.

Yeah i accidentally added this one, i have deleted it now.
As for other causes, i have just checked the games memory consumption while maxing my food with non-plane units.
The memory consumption remains balanced and doesn't creep up, so i am certain it has to do with the planes.
I have checked more triggers for memory leaks and fixed them, but they're not triggers that fire often, and as expected they still haven't fixed the issue.

EDIT:
I have tried disabling the slider triggers (slide and slide2) and then making lots of planes without them and the memory also didn't creep up, so something is certainly wrong with them but i can't quite tell what.

ThompZon · Jul 22, 2022

u wot m8_ said:
Yeah i accidentally added this one, i have deleted it now.
As for other causes, i have just checked the games memory consumption while maxing my food with non-plane units.
The memory consumption remains balanced and doesn't creep up, so i am certain it has to do with the planes.
I have checked more triggers for memory leaks and fixed them, but they're not triggers that fire often, and as expected they still haven't fixed the issue.

EDIT:
I have tried disabling the slider triggers (slide and slide2) and then making lots of planes without them and the memory also didn't creep up, so something is certainly wrong with them but i can't quite tell what.

Can you post the latest slide triggers? It'd make it more clear with less assumptions on my part (and assumptions can easily miss details).

u wot m8_ · Jul 22, 2022

ThompZon said:
Can you post the latest slide triggers? It'd make it more clear with less assumptions on my part (and assumptions can easily miss details).

You mean the ones i disabled? they're the triggers i have posted in the beginning.
Or did you mean something else?

ThompZon · Jul 22, 2022

u wot m8_ said:
You mean the ones i disabled? they're the triggers i have posted in the beginning.
Or did you mean something else?

The ones you disabled to confirm that they were very likely the cause of issues, (hopefully) fixed leak in Loc3 assignment and (hopefully) removed unneeded remove of Loc3 (in the other trigger).

Pyrogasm · Jul 22, 2022

IMO you should only need one location variable here, and that's only for pathing checks to make sure you don't go somewhere unpathable. Three is unnecessary and while it wouldn't cause an issue if the unit groups are big enough it could slightly bog down. Also no reason to have two different periodic triggers, just enum through both unit groups in 1 trigger.

u wot m8_ · Jul 23, 2022

ThompZon said:
The ones you disabled to confirm that they were very likely the cause of issues, (hopefully) fixed leak in Loc3 assignment and (hopefully) removed unneeded remove of Loc3 (in the other trigger).

Ok so i did fix the loc3 assignment leak, and now i have also tried removing the unneeded loc3 remove function, which i kept forgetting about.
Interestingly after removing this one, the memory consumption started creeping up even faster.
I have no idea what's happening at this point

Anyhow, here are the triggers:

Slide
- Events
  - Time - Every 0.03 seconds of game time
- Conditions
- Actions
  - Unit Group - Pick every unit in Sliders and do (Actions)
    - Loop - Actions
      - Set Loc1 = (Position of (Picked unit))
      - Set Loc3 = (Loc1 offset by ((Real((Custom value of (Picked unit)))) / PlaneSpeedModifier) towards ((Facing of (Picked unit)) + 3.00) degrees)
      - Unit - Make (Picked unit) face Loc3 over 0.00 seconds
      - Set Loc2 = (Loc1 offset by ((Real((Custom value of (Picked unit)))) / PlaneSpeedModifier) towards (Facing of (Picked unit)) degrees)
      - Custom script: call SetUnitX( GetEnumUnit(), GetLocationX(udg_Loc2) )
      - Custom script: call SetUnitY( GetEnumUnit(), GetLocationY(udg_Loc2) )
      - Custom script: call RemoveLocation(udg_Loc2)
      - Custom script: call RemoveLocation(udg_Loc1)

Slide2
- Events
  - Time - Every 0.03 seconds of game time
- Conditions
- Actions
  - Unit Group - Pick every unit in Sliders2 and do (Actions)
    - Loop - Actions
      - Set Loc1 = (Position of (Picked unit))
      - Set Loc2 = (Loc1 offset by ((Real((Custom value of (Picked unit)))) / PlaneSpeedModifier) towards (Facing of (Picked unit)) degrees)
      - Custom script: call SetUnitX( GetEnumUnit(), GetLocationX(udg_Loc2) )
      - Custom script: call SetUnitY( GetEnumUnit(), GetLocationY(udg_Loc2) )
      - Custom script: call RemoveLocation(udg_Loc2)
      - Custom script: call RemoveLocation(udg_Loc1)

u wot m8_ · Jul 23, 2022

Pyrogasm said:
IMO you should only need one location variable here, and that's only for pathing checks to make sure you don't go somewhere unpathable. Three is unnecessary and while it wouldn't cause an issue if the unit groups are big enough it could slightly bog down. Also no reason to have two different periodic triggers, just enum through both unit groups in 1 trigger.

I don't really get why i should only use one variable, wouldn't that cause memory leak with the other locations then? Though i may have just not understood what you meant correctly. As for the different triggers, that's a good point, i have now put all of the other slide triggers in one.

Slide
- Events
  - Time - Every 0.03 seconds of game time
- Conditions
- Actions
  - Unit Group - Pick every unit in Sliders and do (Actions)
    - Loop - Actions
      - Set Loc1 = (Position of (Picked unit))
      - Set Loc3 = (Loc1 offset by ((Real((Custom value of (Picked unit)))) / PlaneSpeedModifier) towards ((Facing of (Picked unit)) + 3.00) degrees)
      - Unit - Make (Picked unit) face Loc3 over 0.00 seconds
      - Set Loc2 = (Loc1 offset by ((Real((Custom value of (Picked unit)))) / PlaneSpeedModifier) towards (Facing of (Picked unit)) degrees)
      - Custom script: call SetUnitX( GetEnumUnit(), GetLocationX(udg_Loc2) )
      - Custom script: call SetUnitY( GetEnumUnit(), GetLocationY(udg_Loc2) )
      - Custom script: call RemoveLocation(udg_Loc2)
      - Custom script: call RemoveLocation(udg_Loc1)
  - Unit Group - Pick every unit in Sliders2 and do (Actions)
    - Loop - Actions
      - If (All Conditions are True) then do (Then Actions) else do (Else Actions)
        
        If - Conditions
        
        (Current order of (Picked unit)) Equal to (Order(none))
        
        Then - Actions
        
        Unit Group - Add (Picked unit) to Sliders
        
        Unit Group - Remove (Picked unit) from Sliders2
        
        Else - Actions
      - Set Loc1 = (Position of (Picked unit))
      - Set Loc2 = (Loc1 offset by ((Real((Custom value of (Picked unit)))) / PlaneSpeedModifier) towards (Facing of (Picked unit)) degrees)
      - Custom script: call SetUnitX( GetEnumUnit(), GetLocationX(udg_Loc2) )
      - Custom script: call SetUnitY( GetEnumUnit(), GetLocationY(udg_Loc2) )
      - Custom script: call RemoveLocation(udg_Loc2)
      - Custom script: call RemoveLocation(udg_Loc1)

Though as probably expected, the leak is still happening and i have yet to find a solution.

u wot m8_ · Jul 23, 2022

UPDATE

i can't believe i have overlooked that, i removed the wrong loc3... no wonder why the leak accelerated

EDIT: just to clarify, the leak still happens, just slower like it was in the beginning.

Pyrogasm · Jul 23, 2022

u wot m8_ said:
i can't believe i have overlooked that, i removed the wrong loc3... no wonder why the leak accelerated

EDIT: just to clarify, the leak still happens, just slower like it was in the beginning.

If it's not what you meant you caught here, you've forgotten to remove Loc3 in the first Group Pick. You removed Loc1 and Loc2, and in the second Group Pick you don't use Loc3 so it's not needed there.

Set Loc3 = (Loc1 offset by ((Real((Custom value of (Picked unit)))) / PlaneSpeedModifier) towards ((Facing of (Picked unit)) + 3.00) degrees)

That line is weird. Why are you moving it towards the facing +3 degrees, but then two lines later you move it along the facing angle directly anyway? Since the direction that the plane is being moved in is its facing direction then this line is actually useless and does nothing since it makes it face the angle it's already facing. I've left this line in my example trigger below but I'm not convinced it does anything for you.

u wot m8_ said:
I don't really get why i should only use one variable, wouldn't that cause memory leak with the other locations then?

You're already using SetUnitX and SetUnitY, so you might as well use GetUnitX and GetUnitY and cut out the locations entirely. The only time you would need a location would be for checking the pathability of the point you are about to move units to... if that matters. Sounds like they're flying units so it's likely it wouldn't matter at all where you moved them to, which means you would "need" to use 0 locations. What goes on behind the scenes in Polar Projection ("point with polar offset" in GUI) is very simple when working with coordinates directly. Removing locations from the equation also means performance savings that might matter if lots of units are being moved by these triggers.

Code:

(x1,y1)
project R distance along angle F (facing angle of the unit)
x2 = x1 + R*Cos(F)
y2 = y1 + R*Sin(F)

(x1 + R*Cos(F), y1 + R*Sin(F))

Slide
- Events
  - Time - Every 0.03 seconds of game time
- Conditions
- Actions
  - Unit Group - Pick every unit in Sliders and do (Actions)
    - Loop - Actions
      - Set Slide_U = (Picked Unit) //saving this into a variable saves a function call every time you have to refer to "picked unit" now!
      - Custom script: set udg_Slide_X = GetUnitX(udg_Slide_U)
      - Custom script: set udg_Slide_Y = GetUnitY(udg_Slide_U)
      - Set Slide_F = (Facing of Slide_U)
      - Set Slide_R = ((Real((Custom value of Slide_U))) / PlaneSpeedModifier)
      - Set Slide_X = (Slide_X + (Slide_R * Cos(Slide_F))) //I'm assuming all GUI functions treat angles in degrees, not radians. Pretty sure it's the case but it might not so if you get unexpected movement look to convert F to radians for these lines
      - Set Slide_Y = (Slide_Y + (Slide_R * Sin(Slide_F)))
      - Unit - Make Slide_U face (Slide_F + 3.00) over 0.00 seconds
      - Custom script: call SetUnitX(udg_Slide_U, udg_Slide_X)
      - Custom script: call SetUnitY(udg_Slide_U, udg_Slide_Y)
  - Unit Group - Pick every unit in Sliders2 and do (Actions)
    - Loop - Actions
      - Set Slide_U = (Picked Unit)
      - If (All Conditions are True) then do (Then Actions) else do (Else Actions)
        
        If - Conditions
        
        (Current order of Slide_U) Equal to (Order(none))
        
        Then - Actions
        
        Unit Group - Add Slide_U to Sliders
        
        Unit Group - Remove Slide_U from Sliders2
        
        Else - Actions
      - Custom script: set udg_Slide_X = GetUnitX(udg_Slide_U)
      - Custom script: set udg_Slide_Y = GetUnitY(udg_Slide_U)
      - Set Slide_F = (Facing of Slide_U)
      - Set Slide_R = ((Real((Custom value of Slide_U))) / PlaneSpeedModifier)
      - Set Slide_X = (Slide_X + (Slide_R * Cos(Slide_F))) //I'm assuming all GUI functions treat angles in degrees, not radians. Pretty sure it's the case but it might not so if you get unexpected movement look to convert F to radians for these lines
      - Set Slide_Y = (Slide_Y + (Slide_R * Sin(Slide_F)))
      - Custom script: call SetUnitX(udg_Slide_U, udg_Slide_X)
      - Custom script: call SetUnitY(udg_Slide_U, udg_Slide_Y)

Okay so now you see the method I suggest? There is one final thing to improve. Why are there two groups to begin with? They both do the same things to the unit, except that in Sliders the unit is forced to face its facing angle +3 degrees (which would make it slowly orbit, maybe that's what you want) and in the other group it isn't. They could easily be combined.

Since the second group pick might potentially put units from Sliders2 into Sliders (because of the if block at the start), you should probably actually pick the units in Sliders2 first before picking the units in Sliders. Also when a unit is removed from Sliders2 it's actually still moved according to Sliders2 on that iteration of the trigger, so to avoid that you would do something like this:

If (All Conditions are True) then do (Then Actions) else do (Else Actions)
- If - Conditions
  - (Current order of Slide_U) Equal to (Order(none))
- Then - Actions
  - Unit Group - Add Slide_U to Sliders
  - Unit Group - Remove Slide_U from Sliders2
  - Skip Remaining Actions //This only skips the rest of the 'scope' that you are in, so in this case it would only skip the remaining actions in the "Pick" for THIS SPECIFIC UNIT ONLY
- Else - Actions

u wot m8_ · Jul 23, 2022

Pyrogasm said:
If it's not what you meant you caught here, you've forgotten to remove Loc3 in the first Group Pick. You removed Loc1 and Loc2, and in the second Group Pick you don't use Loc3 so it's not needed there.

Set Loc3 = (Loc1 offset by ((Real((Custom value of (Picked unit)))) / PlaneSpeedModifier) towards ((Facing of (Picked unit)) + 3.00) degrees)
That line is weird. Why are you moving it towards the facing +3 degrees, but then two lines later you move it along the facing angle directly anyway? Since the direction that the plane is being moved in is its facing direction then this line is actually useless and does nothing since it makes it face the angle it's already facing. I've left this line in my example trigger below but I'm not convinced it does anything for you.

You're already using SetUnitX and SetUnitY, so you might as well use GetUnitX and GetUnitY and cut out the locations entirely. The only time you would need a location would be for checking the pathability of the point you are about to move units to... if that matters. Sounds like they're flying units so it's likely it wouldn't matter at all where you moved them to, which means you would "need" to use 0 locations. What goes on behind the scenes in Polar Projection ("point with polar offset" in GUI) is very simple when working with coordinates directly. Removing locations from the equation also means performance savings that might matter if lots of units are being moved by these triggers.

Code:

(x1,y1) project R distance along angle F (facing angle of the unit) x2 = x1 + R*Cos(F) y2 = y1 + R*Sin(F) (x1 + R*Cos(F), y1 + R*Sin(F))

Slide

Events

Time - Every 0.03 seconds of game time

Conditions

Actions

Unit Group - Pick every unit in Sliders and do (Actions)

Loop - Actions

Set Slide_U = (Picked Unit) //saving this into a variable saves a function call every time you have to refer to "picked unit" now!

Custom script: set udg_Slide_X = GetUnitX(udg_Slide_U)

Custom script: set udg_Slide_Y = GetUnitY(udg_Slide_U)

Set Slide_F = (Facing of Slide_U)

Set Slide_R = ((Real((Custom value of Slide_U))) / PlaneSpeedModifier)

Set Slide_X = (Slide_X + (Slide_R * Cos(Slide_F))) //I'm assuming all GUI functions treat angles in degrees, not radians. Pretty sure it's the case but it might not so if you get unexpected movement look to convert F to radians for these lines

Set Slide_Y = (Slide_Y + (Slide_R * Sin(Slide_F)))

Unit - Make Slide_U face (Slide_F + 3.00) over 0.00 seconds

Custom script: call SetUnitX(udg_Slide_U, udg_Slide_X)

Custom script: call SetUnitY(udg_Slide_U, udg_Slide_Y)

Unit Group - Pick every unit in Sliders2 and do (Actions)

Loop - Actions

Set Slide_U = (Picked Unit)

If (All Conditions are True) then do (Then Actions) else do (Else Actions)

If - Conditions

(Current order of Slide_U) Equal to (Order(none))

Then - Actions

Unit Group - Add Slide_U to Sliders

Unit Group - Remove Slide_U from Sliders2

Else - Actions

Custom script: set udg_Slide_X = GetUnitX(udg_Slide_U)

Custom script: set udg_Slide_Y = GetUnitY(udg_Slide_U)

Set Slide_F = (Facing of Slide_U)

Set Slide_R = ((Real((Custom value of Slide_U))) / PlaneSpeedModifier)

Set Slide_X = (Slide_X + (Slide_R * Cos(Slide_F))) //I'm assuming all GUI functions treat angles in degrees, not radians. Pretty sure it's the case but it might not so if you get unexpected movement look to convert F to radians for these lines

Set Slide_Y = (Slide_Y + (Slide_R * Sin(Slide_F)))

Custom script: call SetUnitX(udg_Slide_U, udg_Slide_X)

Custom script: call SetUnitY(udg_Slide_U, udg_Slide_Y)

Okay so now you see the method I suggest? There is one final thing to improve. Why are there two groups to begin with? They both do the same things to the unit, except that in Sliders the unit is forced to face its facing angle +3 degrees (which would make it slowly orbit, maybe that's what you want) and in the other group it isn't. They could easily be combined.

Since the second group pick might potentially put units from Sliders2 into Sliders (because of the if block at the start), you should probably actually pick the units in Sliders2 first before picking the units in Sliders. Also when a unit is removed from Sliders2 it's actually still moved according to Sliders2 on that iteration of the trigger, so to avoid that you would do something like this:

If (All Conditions are True) then do (Then Actions) else do (Else Actions)

If - Conditions

(Current order of Slide_U) Equal to (Order(none))

Then - Actions

Unit Group - Add Slide_U to Sliders

Unit Group - Remove Slide_U from Sliders2

Skip Remaining Actions //This only skips the rest of the 'scope' that you are in, so in this case it would only skip the remaining actions in the "Pick" for THIS SPECIFIC UNIT ONLY

Else - Actions

I have taken your suggestions and remade my trigger like your example.
It has slowed down the memory leak, but still hasn't removed it, the memory consumption still seems to slowly creep only upwards.
Additionally, i know that it's not very important, but i have noticed the plane movement feels less smooth now and when there are many planes it gives the illusion of a frame drop.

About the second part, i didn't understand why do the skp remaining actions, do they run despite them being only in the "else" part?

Pyrogasm · Jul 23, 2022

As new units get added to one of the two groups memory usage will rise because the groups collectively contain more units. You should remove it from both when a unit dies.

u wot m8_ said:
i have noticed the plane movement feels less smooth now and when there are many planes it gives the illusion of a frame drop.

I don't know why that would be. All I did is what you did with fewer steps. Literally the exact same math with fewer objects and operations and function calls. If you did the Skip Remaining Actions but didn't swap the order of the group loops then it would lead to there being 1 frame where the units are not moving when transitioning between the two groups.

u wot m8_ said:
i didn't understand why do the skp remaining actions, do they run despite them being only in the "else" part?

Under the hood "skip remaining actions" is a raw return. It will work to 'end' the function you are currently inside of as if it was actually returning something. Any function can return even if it doesn't normally give a return value, and it can return at any point it its execution wherever it encounters and executes a return. GUI trigger actions take place within one such function that can be ended early with a return. When you do a "unit group - pick" or "player group - pick" the stuff inside the "loop - actions" all takes place within its own sub-function. This sub function runs once for every unit in the group, so telling it to end just tells one specific instance of that function to end early. If blocks use a separate function for their conditions but the then/else are not separate functions so returning inside just one of those would end the trigger.

The reason you want to do it there is because if a unit should be moved from Sliders2 to Sliders, it shouldn't be moved as if it was in Sliders2, which it is about to be when that if block is executed. We move it to the other group and then when the other group gets iterated over it will move according to the proper rules.

[Crash] Slider-Based Trigger Leak

Similar threads