Memory leak Q

would functions such as (Picked Player) and especially event responses like (Ability Being Cast) cause memory leaks? I heard somewhere that fucntions which return non-native handles (Unit/Player/Ability/ect...) cause leaks. Would it be better to do something like:

Set local_player = (Picked Player)
Set temp_location = random point in...
Set map_center = center of playable map area
Create 1 Footman for local_player at temp_location facing map_center
destroy temp_location
destroy local_player
destroy map_center

^just an example, i know i would prolly keep map center to use in othe triggers but is this better than just having it in one line and not destroying?

First off...

Esoteric, Picked Player (GetEnumPlayer()) is not the same as picked Unit (GetEnumUnit()). As is Unit group not the same as Player Group.
The "set bj_wantdestroygroup = true" hack is only applyable too UnitGroup leaks (like when picking all units in the map).

However. Forces (Player Groups) do also leak, and if you are picking every player in a custom-created PlayerGroup (like if you use some function in the PlayerGroup window), then you are leaking the Group.

However, Players, like Units, are objects that are already in memory and don't need to be destroyed... F.ex. when you work with a player, you're not creating a player that you need to destroy later, are you? No... you're setting your variable to reference a already created player, Player 1 f.ex., and we wouldn't want to "destroy" that player, would we? :D.

The same is with units. If we have a variable pointing at a unit, we don't want to destroy that variable...as then we would be killing the unit.

But you are right on the spot with locations.

Now, about abilities... that's a tricky Q... as.... ability ID's are just integers, but there is still a special "type" for abilities (even though they are representable as a integer). But i doubt you need to worry about them, as you can't "create" abilities...you just keep referencing existing abilities...

So basicly, you mostly need to worry about Locations, Unit Groups, and Player Groups.

Cubasis

Would the following leak?


function Whatever takes nothing returns nothing
local unit tmp_unit = GetEnumUnit()
call DisplayTextToForce( GetPlayersAll(), GetUnitName(tmp_unit))
endfunction

function Main takes nothing returns nothing
local group tmp_group = [ALL UNITS IN ENTIRE MAP]
call ForGroupBJ(tmp_group, function Whatever)
call DestroyGroup(tmp_group)
endfucntion

Kolibri:

You're doing the right thing there, that's the alternative to using the other hack, and is ofcourse more reccomendable instead of counting on some hacks to do the job.

But yeah, you're safe there.

Cubasis

Safe except for the left open force you created. Create another local force = GetPlayersAll() and then display the text to the local force and do call DestroyForce( local force variable ) after you are done using the force. Then that would be 100% lag proof.

Yeah, well, it was just an example. You'd never display text like that unless it was a temporary hack. But thanks anyway. ;)

I always thought that GetPlayersAll() pointed to a global variable declared in blizzard.j, I don't think it causes leak, and destroying a force variable that points to GetPlayersAll() may cause problems as well.

These stuff return things that need to be destroyed:

Get Unit Position
Target Point of ability Being cast
Convert Player to Player Group
All players matching Condition
All Players of Control
Units in <rect>
Units in <rect> of type
Units owned by player of type

Lord Vexorian,

GetPlayersAll just creates a object with all the players in the map and returns it to the caller. The consiquences would be to high to give users a (Destroy) access to a important object like this. Generally... you need to destroy any (!) location, group and force that any function returns needs to be destroyed/referenced, if it is not done, then it will leak.

About GetPlayersAll(), feel free to proof me wrong, as i'm not 100% certain on it.

Cubasis

In this case Vex is right about GetPlayersAll(), altough the only way to know that is to look through blizzard.j.

I think that GetPlayerAll() is the only function that returns a force that shouldn't be destoyed. (modifying it would also be inadvisable)

This was taken from the blizzard.j as it appears at this website http://jass.sourceforge.net/doc/api/...rce.shtml#8606

ahh,

Interesting, thanks, that's a good thing to know about.

Cubasis

Actually, it depends if you're using the expansion or not. This is from blizzard.j in war3.mpq:
function GetPlayersAll takes nothing returns force
local force f = CreateForce()
call ForceEnumPlayers(f, null)
return f
endfunction

Quite a bit depends on expansion/not expansion, or tech levels. For example once upon a time destroying "Last Created Units" group would have been bad, now it's nessecary.