• Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
  • Read Evilhog's interview with Gregory Alper, the original composer of the music for WarCraft: Orcs & Humans 🔗Click here to read the full interview.

Unit Leak

Status
Not open for further replies.
Level 33
Joined
Mar 27, 2008
Messages
8,035
I know that each unit created has a permanent leak effect, but is it a tolerable leak ?

In my case, I would like to create a dummy that will spawn next to attacker, everytime the attacker land a hit on an enemy unit.
The dummy then is ordered to Attack Once towards the enemy unit and is killed afterwards.

If this continues for a long period of time, will it eat memory greatly ?
 
//===========================================================================
// How bad are memory leaks?
//==========================
// If you don't remove memory leaks, they suck memory:
//
// Location: 0.361 kb
// Group: 0.62 kb + 0.040 kb for each unit in the group. // So that means 0.040kb every dummy unit which is affordable definately.
// Effect: 11.631 kb
//
// Both, locations and groups are used very frequently. So when you don't fix those memory leaks,
// you will experience lag.
Source : http://www.hiveworkshop.com/forums/2424274-post3.html
 
Level 9
Joined
Dec 12, 2007
Messages
489
I know that each unit created has a permanent leak effect
no, created units only cause lag on creation and mass ordered. Properly handled and removed will leaves no leak.

In my case, I would like to create a dummy that will spawn next to attacker, everytime the attacker land a hit on an enemy unit.
The dummy then is ordered to Attack Once towards the enemy unit and is killed afterwards.

If this continues for a long period of time, will it eat memory greatly ?
supposedly no if you handled the creation and removal. Efficient? probably no, how about permanent dummy which stored at certain unreacheable point, then on damage by attacker, move the dummy to position then order attack, then store it back. at least this is a workaround if you overthinking about lots of unit creation and removal.
 
no, created units only cause lag on creation and mass ordered. Properly handled and removed will leaves no leak.

supposedly no if you handled the creation and removal. Efficient? probably no, how about permanent dummy which stored at certain unreacheable point, then on damage by attacker, move the dummy to position then order attack, then store it back. at least this is a workaround if you overthinking about lots of unit creation and removal.

The creation of units cause a leak that can't be cleaned which is why people suggest special effects if you can. Mass orders usually will only generate delay, but sometimes it can do lag too. Properly handled and removed won't clean it all thanks to Blizzard.

Your second point sounds ideal, I like it. I would of suggested it, but not many people like dealing with already made units.
 
Level 33
Joined
Mar 27, 2008
Messages
8,035
how about permanent dummy which stored at certain unreacheable point, then on damage by attacker, move the dummy to position then order attack, then store it back
I have tried this method but the drawback is that if more than 5 units attacking at the same time, only 3~4 unit gets registered by the dummy to attack, because it simply happens too fast because dummy is a unit too and has their minimal delay between each attack.

And yes, I have set the Combat - Attack - Animation Backswing/Damage Point to 0.000.
Also, their attack cooldown to 0.

Perhaps maybe other data that I missed out ?

Setting Movement Speed to 0 will enable the unit to attack without facing the target, I have it at 0, but still no avail.
 
Level 9
Joined
Dec 12, 2007
Messages
489
I have tried this method but the drawback is that if more than 5 units attacking at the same time, only 3~4 unit gets registered by the dummy to attack, because it simply happens too fast because dummy is a unit too and has their minimal delay between each attack.

And yes, I have set the Combat - Attack - Animation Backswing/Damage Point to 0.000.
Also, their attack cooldown to 0.
so its capable of lots of units attacking at same time?
why not attaching one permanent dummy unit per unit capable of doing it?

or how about doing it like the old caster system? stock some dummy units which is usable by all unit,
on use pick a dummy and do all stuff with it after that return to the stock.
if on use the stock is empty because all the dummy is being used, create another dummy and use it, after that store it back at stock.

The creation of units cause a leak that can't be cleaned which is why people suggest special effects if you can.
where did you got this? all unit data reference are lost when that unit finishes decay or removed from the game.
 
Level 33
Joined
Mar 27, 2008
Messages
8,035
or how about doing it like the old caster system? stock some dummy units which is usable by all unit,
on use pick a dummy and do all stuff with it after that return to the stock.
if on use the stock is empty because all the dummy is being used, create another dummy and use it, after that store it back at stock.
I'll try with this solution first, will report with result.
Thanks.
 
Level 9
Joined
Dec 12, 2007
Messages
489
I can't find anything related about permanent leak in that post nor the source thread specified there. The only information in the post is how much kb you lost "If you don't remove memory leaks", and the only closest information is about the unit group leak amount which increases according to amount of units in it.

are you sure about your source? or do I misinterpret?
 
Unless I am mistaken it means 0.040 kb per dummy unit.

Though I could be really wrong with that because it was mostly an estimate/guess however the creation of dummy units do create permanent leaks because I have seen it myself.

Play a wc3 map with heavy use of dummy units, check the memory useage with task manager at the start then at the end.
 
Level 9
Joined
Dec 12, 2007
Messages
489
Unless I am mistaken it means 0.040 kb per dummy unit.

Though I could be really wrong with that because it was mostly an estimate/guess however the creation of dummy units do create permanent leaks because I have seen it myself.
since you provided the numbers, let me rephrase the meaning on the source you gave.

Your source states that if a group variable leaks, then the amount of leak is equal to 0.62kb + 0.40kb per each unit stored in the group. Its not stating that unit creation cause a permanent leak. If you interpret that as dummy unit in group, at the very least its not leak if its properly handled and stored. Of course you might have seen some evidence of leaks, but the source of the leak? relating to your earlier post about using dummy unit as special effect, probably what you saw are just lag by mass sfx use. but of course to be sure of it, test would be needed.
 
Okay, seems we got a little thread here.

AFAIR, according to Maker, almost all handles leaks, but in unit case, I believe it's not so big that it can disrupt anything if handled properly [using variables is a nice protection against the leak as you can just use it then null it]. But please be noted : Game will gain an unavoidable lag if there's too many unit, so it's wise to avoid too many unit if its not necessary. About 1K unit in 1 time on the screen [exclude SFX, Doodads, etc] can cause a lag that needs you to stay away from screen.
Also, does the dummy uses models? If so, avoid models that aren't designed for special effects, so it can greatly reduces lag possibility.

Side Note : using CreateNUnitsAtLoc with more than 1 unit means you make an unit group [AFAIR].
 
Level 9
Joined
Dec 12, 2007
Messages
489
Side Note : using CreateUnitAtLoc with more than 1 unit means you make an unit group [AFAIR].
probably you mean this
function CreateNUnitsAtLoc takes integer count, integer unitId, player whichPlayer, location loc, real face returns group

as what you mean actually
native CreateUnitAtLoc takes player id, integer unitid, location whichLocation, real face returns unit
 
Status
Not open for further replies.
Top