- Joined
- Apr 24, 2012
- Messages
- 9,797
Would a unit group leak if only used GroupClear? Because for me, DestroyGroup either a.) makes the next ForGroup only pick one unit, b.) does not pick at all, or c.) messes with add/remove unit.
Well if you try and use something that has been destroyed what do you expect? I mean you would hardly go back to living in a building after it has been demolished would you? Once a group has been destroyed all variables pointing at it will have a destroyed handle and so any operations that use such variables will not work. You will need to set the variable to a new, freshly created group for them to work again.Would a unit group leak if only used GroupClear? Because for me, DestroyGroup either a.) makes the next ForGroup only pick one unit, b.) does not pick at all, or c.) messes with add/remove unit.
The variables are set. So why do those even happen?Well if you try and use something that has been destroyed what do you expect? I mean you would hardly go back to living in a building after it has been demolished would you? Once a group has been destroyed all variables pointing at it will have a destroyed handle and so any operations that use such variables will not work. You will need to set the variable to a new, freshly created group for them to work again.
You don't use this bj_destroy with combination of a varibale or?
After this you would be not able to use it anymore.
- Custom script: set bj_wantDestroyGroup = true
- Unit Group - Pick every unit in UnitgroupVariable and do Actions:
Actually that would not do anything since it does not call the function that creates a unit group. So yes you would be able to use it again.
How about local groups?If you keep clearing a unit group that you recycle (use again and again) it will not leak. Be aware that GUI does not support this well as most group fill methods (except individual units or from other groups) create a new group.
If you keep clearing a unit group that you recycle (use again and again) it will not leak. Be aware that GUI does not support this well as most group fill methods (except individual units or from other groups) create a new group.
Yes if you are using the natives directly. GUI's BJs create a new group...Groups are cleared upon enumeration if I remember correctly.
function GetUnitsInRangeOfLocMatching takes real radius,location whichLocation,boolexpr filter returns group
local group g = CreateGroup()
call GroupEnumUnitsInRangeOfLoc(g, whichLocation, radius, filter)
call DestroyBoolExpr(filter)
return g
endfunction
function GetUnitsInRectMatching takes rect r,boolexpr filter returns group
local group g = CreateGroup()
call GroupEnumUnitsInRect(g, r, filter)
call DestroyBoolExpr(filter)
return g
endfunction
function GetUnitsInRectOfPlayer takes rect r,player whichPlayer returns group
local group g = CreateGroup()
set bj_groupEnumOwningPlayer = whichPlayer
call GroupEnumUnitsInRect(g, r, filterGetUnitsInRectOfPlayer)
return g
endfunction
function GetUnitsOfPlayerAndTypeId takes player whichPlayer,integer unitid returns group
local group g = CreateGroup()
set bj_groupEnumTypeId = unitid
call GroupEnumUnitsOfPlayer(g, whichPlayer, filterGetUnitsOfPlayerAndTypeId)
return g
endfunction
function GetUnitsOfPlayerMatching takes player whichPlayer,boolexpr filter returns group
local group g = CreateGroup()
call GroupEnumUnitsOfPlayer(g, whichPlayer, filter)
call DestroyBoolExpr(filter)
return g
endfunction
function GetUnitsOfTypeIdAll takes integer unitid returns group
local group result = CreateGroup()
local group g = CreateGroup()
local integer index
set index = 0
loop
set bj_groupEnumTypeId = unitid
call GroupClear(g)
call GroupEnumUnitsOfPlayer(g, Player(index), filterGetUnitsOfTypeIdAll)
call GroupAddGroup(g, result)
set index = index + 1
exitwhen index == bj_MAX_PLAYER_SLOTS
endloop
call DestroyGroup(g)
return result
endfunction
function GetUnitsSelectedAll takes player whichPlayer returns group
local group g = CreateGroup()
call SyncSelections()
call GroupEnumUnitsSelected(g, whichPlayer, null)
return g
endfunction
Maybe if you post the trigger that has problems we could? By the sounds of what you posted it brings back the first point, you cannot expect to use groups after you destroy them, you should only destroy groups you no longer need to use.Speaking of my problem, can someone explain why that happens?
Why would you be concerned about the memory use? I mean JASS variables are only a couple dozen bytes and all locals are removed when the thread dies anyway. Locals do not and cannot leak in WC3 (as far as I know).Meanwhile, can you please clarify if creating locals at either of these will take much memory: