Does this leak?

Heres the trigger

I belive that because i used variables for everything it won't create memory leaks, but i just wanted someone to check it for me. If this doesn't leak then i know i have a proper understanding of preventing memory leaks, if it does then obviously i dont. Thanks guys!

Edited by Blade.dk. Reason: Trigger tags.

There is no point in using a local variable instead of a global in GUI if there are no waits.

Distance between (Position of (Casting unit)) and (Target point of ability being cast)

Leaks.

temppoint leaks. Never destroyed.

Suggest you read some tutorials, as you don't appear to understand what you are doing, which is vital.

Learn to use the [trigger] tags.

I tried destroying the variables afterwards, but when i did that it could only run the trigger once. i have read some tutorials on the topic and never came across anything on the "Distance Between" function. As for the local your absolutely right, i originally planned on having waits but in the end decided against it. Thanks captain, youve been a big help lately. :)

Region centered at ((Position of (Casting unit)) offset by (Real((Integer A))) towards (Facing of (Casting unit)) degrees)

Also leaks twice.


No, you don't destroy the variables, but the objects that the variables point to.

I assume it leaks at "Position of (Casting unit))" and "offset by (real((integer A)))"

Creates two new locations, yes.

If you can, I'd suggest learning JASS, so you can throw away locations pretty much for good and use co-ordinates.

Ofc, griff is right again, using X/Y/Z is much better than handling locations, yes locations have some advantages, but coords are not handles, they dont leak.
Its easier to use them, and is just better! Rawr!

Position of UNIT always leaks, set it to a location, then use:


Remember, if you set a variable to a location, then you dont destroy and set it to another, then destroy, dont hope it will remove them both, you need to destroy it each time you'v finished using it before you should set it again.

A memory leak is when you create something, making it take up memory, but then is never removed where it should be or the variable/whatever which is referring to it is lost
Right, well I don't see why you loop through each "1" distance, eg a distance of 500 would result in 500 regions, 1000 locations and 500 groups leaking . Not only that, but it would be unbelievably slow as well since you use everything "random". You see, when you pick a random unit for example, it loops through the entire group and then returns a unit based on that. While for eg First unit of group is a native; "1 line of code" instead of 10 with a slow loop

You've come a bit along the way by storing the handles that leak,
but to take care of a memory leak you need to remove it once you're done with it:
to fix the other leaks it's the same thing that goes except for the custom script. Below is how to destroy a unit group and region (a region is actually a rect(angle) in jass) respectively: