[Solved] Player Variable Question

[Dehua_Darbuya]

I'm not sure how to explain this but here goes.

Generally speaking, I know that all variables apart from integer, real, boolean and string will leak. However in the well-known leak tutorials, the player variable is never addressed. I know how to clear the leak in JASS but I cannot find a straight answer to confirm if player variables in GUI actions leak (Eg: the Unit - Create Unit actions).

Below are two triggers; the first uses a variable to store the player and which is then nulled afterwards. The second doesn't use a variable, but will it still leak a player reference?

• Reinforcements with Player Variable
  • Events
    • Unit - A unit Starts the effect of an ability
  • Conditions
    • (Ability being cast) Equal to Reinforcements
  • Actions
    • Set Caster = (Triggering unit)
    • Set User = (Owner of Caster)
    • Set Location = (Target point of ability being cast)
    • Unit - Create 3 Footman for User at Location facing (Facing of Caster) degrees
    • Custom script: set udg_Caster = null
    • Custom script: set udg_User = null
    • Custom script: set RemoveLocation(udg_Location) = null

• Reinforcements without Player Variable
  • Events
    • Unit - A unit Starts the effect of an ability
  • Conditions
    • (Ability being cast) Equal to Reinforcements
  • Actions
    • Set Location = (Target point of ability being cast)
    • Unit - Create 3 Footman for (Owner of (Triggering unit)) at Location facing (Facing of (Triggering unit)) degrees
    • Custom script: set RemoveLocation(udg_Location) = null

 

[Chaosy]

None of your triggers leak because the leak is cleared in the first one and unless you use a variable (or a function that generates an object, such as location actions) it wont leak so the second trigger is fine too.

 

[Dehua_Darbuya]

Well that was quick!

Yeah that makes sense. I also just discovered that "Owner of Triggering Unit" calls the JASS native GetOwningPlayer takes unit whichUnit returns player which I always thought was a function. Apparently, it doesn't have any internal leaks either so the 2nd trigger should perform better. Right?

 

[Anitarf]

A player object is a handle, just like locations, groups etc., that's why it's not usually included in the lists of things that don't leak. However, players are never created dynamically, functions like GetOwningPlayer always return an existing player object, unlike GetUnitPositionLoc which always creates a new location. That's why players don't leak.

 

[Dehua_Darbuya]

That makes sense as well. Okay then, problem solved.

Thanks you two! +rep!!