quick memory leak question

[afisakov]

I know most points like GetUnitLoc tend to leak, but does point offset as well?
for example

• testtrigger
  • Actions
    • Set TempPoint = (Position of (Triggering unit))
    • Unit - Create 1 Footman (2) for Player 1 (Red) at (TempPoint offset by (0.00, 100.00)) facing Default building facing degrees
    • Unit - Create 1 Footman (2) for Player 1 (Red) at (TempPoint offset by (0.00, -100.00)) facing Default building facing degrees
    • Custom script: call RemoveLocation(udg_TempPoint)

Also, I believe GetRectCenter(region_001) does leak but wanted to confirm.

 

[Accname]

I am not 100% sure about the center of a rect, but I think it does. If you want to be certain you can look at the Jass implementation of these methods. The offset definitely leaks though.

The reason I believe the center of rect leaks is that if you remove the location you can "get" it again by calling GetRectCenter another time. This implies that a new Point-Object is generated on each call. Take UnitGroups as an example. UnitGroups leak if you create them with functions like "get all units inside rect" or something like that. But if you simply add units to a group, remove the units, etc it does not leak. It always uses the same group. If you were to destroy a group and then try to add units to it it wouldnt work. There would be no group to have units added to.

 

[afisakov]

blizzard.j defines it as

function GetRectCenter takes rect whichRect returns location
    return Location(GetRectCenterX(whichRect), GetRectCenterY(whichRect))
endfunction

does the fact it uses return Location mean it creates a location=point and therefore leaks
or does

If you want to be certain you can look at the Jass implementation of these methods.

mean a deeper dive into Jass?

 

[Accname]

blizzard.j defines it as

function GetRectCenter takes rect whichRect returns location
    return Location(GetRectCenterX(whichRect), GetRectCenterY(whichRect))
endfunction

does the fact it uses return Location mean it creates a location=point and therefore leaks

Yes. Where it says "Location(...)" it creates a new Location-Object and therefore leaks memory. This object needs to be removed/destroyed or else it will continue to exist within your RAM.

 

[afisakov]

Another question, if a trigger has no waits in it, am I safe from other triggers overwriting the variables, or could other triggers still jump in midway?

for example
trigger 1:
unit starts effect of ability
ability=blaze
set temppoint=spelltargetlocation
set tempgroup=unitsinrangeoflocationmatching...
call forgroup(tempgroup, damage function)
call DestroyGroup(tempgroup)
call Removelocation(temppoint)

trigger 2:
a unit dies
dying unit=spider
set temppoint=getunitlocation(triggerunit)
createitemloc(temppoint)
call RemoveLocation(temppoint)

yes I know these are in pseudocode, did not look up exact names for example.
The question is, if trigger 1 kills several units, trigger 2 activate each time and "steal" the temppoint before it can be removed at the end, causing a leak? or will it wait to process triggers 2 after trigger 1 completes?

 

[Accname]

That is something which should be fairly easy for you to test, isnt it?

But as far as I know only a wait can cause one trigger to yield control to another. (and of course calling the other directly!)

 

[afisakov]

In case anyone wanted to know, I did test this with another trigger and proved it can lose control of variables without a wait.

the first trigger sets global variable fint2 based on hero str and other data, deals damage, and then displays a texttag of how much damage dealt, all without waits.
The second sets fint2 based on unittype of dying unit and pays bonus gold.

Baseed on play-testing
If the target survives the dmg display matches dmg done in first trigger, but if the target dies it displays the bonus gold instead. Triggers below, removed some unneeded parts for ease of viewing.

function Trig_FSkillDK_Conditions takes nothing returns boolean
return (GetSpellAbilityId()=='A0YZ')
endfunction
function Trig_FSkillDK_Actions takes nothing returns nothing
set fint2=GetHeroStr(GetTriggerUnit(),true)*(GetUnitAbilityLevelSwapped('A0YZ',GetTriggerUnit())+1)+udg_SoulInt*20
call UnitDamageTargetBJ(GetTriggerUnit(),GetSpellTargetUnit(),fint2,ATTACK_TYPE_NORMAL,DAMAGE_TYPE_UNIVERSAL)
set udg_Lock=GetUnitLoc(GetSpellTargetUnit())
call AddSpecialEffectLocBJ(udg_Lock,"Abilities\\Spells\\Undead\\RaiseSkeletonWarrior\\RaiseSkeleton.mdl")
call DestroyEffectBJ(GetLastCreatedEffectBJ())
call CreateTextunit_sec_speed(I2S(fint2),GetSpellTargetUnit(),3,30,10.00,13.00,20.00,20.00,90.00,15.00)
call RemoveLocation(udg_Lock)
...
endfunction

event: a unit dies

function Trig_Money_creeps_Actions takes nothing returns nothing
local integer uid=GetUnitTypeId(GetTriggerUnit())
local texttag tag1
local unit u=GEtKillingUnit()
if (uid=='uske') then
set fint4=2
elseif (uid=='ucry')or(uid=='nnwa') then
set fint4=3
elseif (uid=='nzom')or(uid=='ugho')or(uid=='nits') then
set fint4=4
endif
...
call SetPlayerState(GetOwningPlayer(u),PLAYER_STATE_RESOURCE_GOLD,GetPlayerState(GetOwningPlayer(u),PLAYER_STATE_RESOURCE_GOLD) + fint2+rcount(u) )
...endfunction

 

[Accname]

I do not understand what you are trying to tell me.

 

[afisakov]

But as far as I know only a wait can cause one trigger to yield control to another.

In my test, trigger 2 stole control of "fint2" before trigger 1 was done with it. Specifically after dealing damage but before displaying the texttag, without a wait or a direct call.

This is also relevant for cleaning up leaks in general because it shows you cannot use the same temppoint for everything. If you use it for "a unit dies" events to drop items this can cause it to overwrite the one still open in your damage triggers (used to select tempgroup in area) and cause that to leak. Even if neither trigger contains waits.

 

[jonas]

is it intentional that you use fint4 in the second trigger?

Also, control is the position in the code, ownership is who has access to the variables.