Unit attachement points, do they leak?

Do things like origin, overhead, and such leak like a location? If so, how can this be avioded. I know of no way to define an attachement point because they are in the x-y-z world and not just the x-y plane. Plus they are almost always subject to movement of some sort.

No they are strings and part of the model. Strings don't leak. The special effects can leak so remember to destroy them.

Thanks weaaddar.

Complete noob here, but what do you mean by "leak"? Attachment points are the main reason I'm trying to learn jass.

Hmmm.... there needs to be a tutorial on this somewhere. Leaking is when you create something and then don't use it again. GUI users leak tons of stuff all of the time because they lack the ability to destroy and remove handles that they have generated. Everytime you use a function like GetRectCenter, it calculates a locaiton variable for the center. Now unfortunatly that location is remembered, but not used every again. Which causes a leak, because it is sitting unused in your RAM. When too many of these unused things sit in your RAM a noticable difference in gameplay occurs. Which is why many TD's start running slower and slower towards the end. Leaked locations when creating units, and leaked locations when ordering units. A location may leak up to 500 bytes of data, and while that is not much by itself, by the time 3000 units have been created and ordered to move to 10x that many locations, it starts being 60 + megs of leaked locations. Only counting the locations, not counting all of the other leaked handles.

Ah, so that explains why WC3 lags so much after I've played it for a while. Yes, I agree there should be a tutorial on this.

So when writing your own jass, is it possible to order it to delete unused variables?

call that as many times as you want, it won't leak.

What is the purpose of the set joe = null? (I do similar things in C, but that is just so I can do if (somepointer) to see if it's free'd or not ;))

Wait, whoa... Does that mean that JASS doesn't have its own garbage collector? That sucks.

How, about these leaks, in order to prevent them, should I convert all my normal triggers into text triggers and modify them as to delete all handles allocated by internal functions?

EDIT: Oh, and I'm wodering, what's the extent of the leakage? I mean, what functions (or groups of functions) cause leaks when used, and how does one remedy such leaks?

Or use custom script lines to remove and destroy handles. JASS has no garbage collector which is why we have to set handle variables equal to null at the end of a function.

You have to catch the return of all functions that return a location (except "GetPlayableMapRect()") and all functions that return a group...and destroy/remove it.

And wc3 does seem to have some kind of garbage collector, just not working quite as effectively as you'd want it too. You may have noticed that after long times of play when it has gotten seriously laggy, then it sometimes suddenly stops being laggy, but it becomse slowly laggy again. That was a emergenzy garbage collection. It's pretty rare.

Cubasis

I've tried telling that...

1. Leaks are caused not by handles, but objects that handles are referred. So setting handle to null does almost nothing. You should destroy object instead!
2. Even object is destroyed, handle isn't set to null. You know well that handles are just integers. NULL handle is integer equal to 1. Empty string has handle equal to 0.
3. String causes memory LEAK every time it changes! But declaring a string equal to previous declared DOESN'T cause memory leak.
   For example: set Str = "a" + "b" will allocate 3 strings in memory: "a", "b" and "ab". Being executed second time, this action WILL NOT allocate additional strings.

1. Yes, it's deffinetely more important to Destroy Objects. However, not de-referencing a local handle variable at the end of a often-used function can cause alot of leak when you're being a perfectionist. Each location-object you leak is cirka 200 kb's (how wierd that is) while each non-de-referenced local location variable leaks cirka 40 kbs. That can sum up pretty quick if you're doing alot of location-related work. However, while Object-leaks happen each time you don't destroy a object, handle-leaks happen only once per local-handle-variable per function. These facts are the results of recent tests.

2. It isn't the integer that leakes, it's the thing it points too that leaks. Our current suspicion (and tests confirm) is that the handle-variables point to a entry in a certain "Handle Array". This keeps track of the number of references a certain object has, and it also is a reference for the "real" object somewhere else in memory...as blizzard would never give us this easy access to the real objects in memory.

3. Yes, but in most cases, (minus all string constants) you only leak strings up to a certain points, mostly including all the alphabet (single-char strings) and some more. Becouse that's exactly the strings most string-handling functions create/leak. So after that, these string-handling functions will use the same strings again and again. So it isn't all that serious. Sure it may add 1-5 MBytes to the RAM usage of you map but...I doubt it will go from there to infinity and cause massive laggyness in your map as other object-leakage.

Oh, and, it's been awhile i've seen you here Caco =)

Cubasis

I don't think the string leak is something that we have to take care that much, since strings get recicled every time So the first time you put "a" it will create a new string but when you put "a" again it will just reuse it.