Does this leak?

[Proxym8]

Hello, Hive members, I would to know from some experts if this GUI trigger snippet leaks in any way. I am aware locations (using regions) leak, so I wondered if assigning them to variables would 'fix' the problem (without the need for the call RemoveLocation script). The locations/points are intended to be static for the entirety of the gameplay.

• Lane Spawns Trigger
  • Events
    • Map initialization
  • Conditions
  • Actions
    • Countdown Timer - Start Lane_Spawn_Timer as a Repeating timer that will expire in 35.00 seconds
    • Set VariableSet Razormane_Bot_Corner = (Center of Razormane Bot Corner <gen>)
    • Set VariableSet Razormane_Top_Corner = (Center of Razormane Top Corner <gen>)
    • Set VariableSet Hooktusk_Bot_Corner = (Center of Hooktusk Bot Corner <gen>)
    • Set VariableSet Hooktusk_Top_Corner = (Center of Hooktusk Top Corner <gen>)
    • Set VariableSet Razormane_Top_Spawn_Location = (Center of Razormane Top Spawn <gen>)
    • Set VariableSet Razormane_Bot_Spawn_Location = (Center of Razormane Bot Spawn <gen>)
    • Set VariableSet Hooktusk_Bot_Spawn_Location = (Center of Hooktusk Bot Spawn <gen>)
    • Set VariableSet Hooktusk_Top_Spawn_Location = (Center of Hooktusk Top Spawn <gen>)

• Lane Spawns
  • Events
    • Time - Lane_Spawn_Timer expires
  • Conditions
  • Actions
    • Unit - Create 4 Razormane Soldier (Custom) for Player 1 (Red) at Razormane_Top_Spawn_Location facing 90.00 degrees
    • Unit - Create 4 Razormane Soldier (Custom) for Player 1 (Red) at Razormane_Bot_Spawn_Location facing 0.00 degrees
    • Unit - Create 4 Hooktusk Soldier (Custom) for Player 2 (Blue) at Hooktusk_Top_Spawn_Location facing 180.00 degrees
    • Unit - Create 4 Hooktusk Soldier (Custom) for Player 2 (Blue) at Hooktusk_Bot_Spawn_Location facing 270.00 degrees

There are several more triggers that use these points/locations for the purpose of giving orders to lane creeps, but I don't think there should exist any leaks in them that are not apparent in these.

 

[GIMLI_2]

It does not leak.

 

[Duckfarter]

A location leak is when a location becomes unable to be referenced so that it cant be removed or used. Any time a location is used it leaks, UNLESS its a variable. If the location is set to a variable it can be used as much as one likes as long as its not overwritten.

One can imagine that there are no locations at the start of a game and the default functions ALWAYS creates new locations without any way to reference them. By setting locations to a point variable at their creation it ensures a way to reference the locations and if we want to use the point variable then the game doesnt need to create a new location since the location already exists in the point variable.

It goes without saying that the location in the point variable has to be removed before setting a new location to the point variable, otherwise it will be overwritten and the reference is lost.

 

[Daffa]

Looks okay to me

 

[Uncle]

One thing that helped me understand what was really going on was learning to understand the code behind it:

Here's a GUI action creating a Point (location) at the center of "some region":

• Set Variable MyPointVar = (Center of some_region)

And here it is converted to Jass:

set udg_MyPointVar = Location(GetRectCenterX(some_region), GetRectCenterY(some_region))

Maybe a little confusing to understand at first, but it's pretty simple once you break it down step by step.

First, we know that you can't just point at your screen and tell the game to create a Footman there. The game uses Points (aka Locations) to know where we want things to happen. But if we go a layer deeper, the game actually uses a grid of x/y/z coordinates which these Points exist on top of. You can see this grid in the World Editor if you press G. You can also see in the bottom left corner of the editor that it literally says "Point: x, y, z" and tells you the exact coordinates of where your mouse is currently positioned. For example, X: 0 and Y: 0 are the center of the map assuming you haven't screwed with the map settings. The Z coordinate will depend on the Cliff Level, one cliff level is equal to 128.00 units (aka Wc3 distance, whatever that means).

So with that in mind, let's look back at the code. Location() is a function that takes an X coordinate and a Y coordinate and creates a Location object at those given coordinates. If the user provides a variable when calling this function, like I'm doing with MyPointVar, the newly created Location will be tracked by that variable as well. This is useful since that's our only way to interact with the Location object that we just created.

Now you might be wondering, what is GetRectCenterX() and GetRectCenterY()? So Rect is just another word for Region just like Location is another word for Point. These GetRectCenter() functions return an X and a Y coordinate, and go figure, Location() requires an X and a Y coordinate, so we've now combined these functions together to reach our goal --> Creating a Point at the center of a Region.

With that in mind, let's think about memory leaks. It all starts to make sense when you realize that the act of setting MyPointVar in the above code was not actually necessary. That was a step taken by me, the user, to ensure that I could track the Location (Point) that was created. If I delete that variable the code would still run perfectly fine and the game would simply create a Location object that I could never interact with (not a very smart thing to do). But that's the important thing to note here, the ability of the user to interact with the Location object is what defines whether or not said object is a memory leak or not.

The rule here is pretty damn simple:

Can you still reference the Location object? This implies that there's a variable tracking it. If YES, then you're not leaking anything!

Have you lost reference to the Location object? This implies that you were never tracking it in the first place OR that you changed what that variable was tracking to a different Location object. If YES, then you've created a memory leak! Lord have mercy on our souls.

Unit Groups and Player Groups act the same exact way. They're simply objects that you create and track with variables. If you fail to track them properly then you'll never be able to Destroy them, which is not necessarily bad if you want them to be permanent, but if they're intended to be temporary then you're entering memory leak territory.

Oh, and like how Point = Location and Region = Rect, Destroy/Remove basically mean the same thing as well. HOWEVER, Removing a Unit is much different than Killing a unit, so don't mix those two up, it only applies to this memory leak stuff.