[JASS] Discussion--Unit Recycling

[PurplePoot]

Same would be good for Jass systems too. For example Dusks DamageDetection leaks trigger events, if you dont recycle your units.

( I recycle them, but most of Jassers dont as far as I know )

Meh, recycling units is a waste of time.

 

[Anachron]

Hmm, thats how I thought, but wc3c.nets programers tell other things...

 

[D4RK_G4ND4LF]

Meh, recycling units is a waste of time.

I made some damage show system for my map which destroys the trigger from time to time
does that count as recycling/does it leak?

and why should spells be a thousand times more instanceable as they will ever be cast? e.g. jump- or movement-systems will lag at 100 at the latest anyway

and which types of "gui recycling" is allowed?
(e.g. sort algorithms, reset on run-out or something else)

 

[Viikuna]

Unit recycling a waste of time?

Ha and lol, you obviously dont know what you are talking about.

But anyways, my point was that some system might seem to be leaking for some people, when for some people it does not.

( Well, even that system leaks triggerevents it is not really a that kind of leak that causes problems anyways )

 

[PurplePoot]

If you insist on recycling, I'll just let you waste your time (Oh, and I guess I should use GetWidgetLife <=/> .405 to check if my units are dead/alive).

Also, I don't mind event leaks if handled responsibly.

 

[Viikuna]

~Void~ does vJass too.

about unit recycling! well i am sure you know that removeing unit causes a little leak!

Actually, I dont. Grim001 did some testing and noticed that wc3 memory usage goes up without going down, when creating and removing units. Captain Griffen did some testing too, and it seems that its not permament.

I dont really know whats the truth, but it doesnt really matter since I recycle my units anyways, because unit recycling offers too much cool possibilities that are unnecessary hard to make without.

 

[PurplePoot]

I dont really know whats the truth, but it doesnt really matter since I recycle my units anyways, because unit recycling offers too much cool possibilities that are unnecessary hard to make without.

Like?

 

[Anachron]

Like?

Recycling units means you can remove really really small leaks from the event queue, but as far as I know it doesn't really matter.

 

[Viikuna]

Well, its faster to get recycled dummy unit for some visual thingy ( like a projectile ) than using that sorry ass slow CreateUnit.

Caster dummies dont have to be recycled, because spell casting is instant, so one or few static dumies are enough. However, for dummies casting channeling spells recycling might be a good idea, since its faster than CreateUnit ( people usually like fast code )

So, for dummies, its a speed thing.



For non dummy-units, recycling with custom death stuff, offers you more control over units death and stuff related to it. ( The more you trigger stuff, the more you have controll over it )

For example, if you want to make a spell that makes some Hero to take credit from all kills in some area, it would be pretty fast job to do.

( Just use the most highest priority for your event, and change that killing unit variable before other events trigger. If you have used to use GetKillingUnit instead of custom function, it might be a quite tricky spell to do. )

Well, ofc you can use a custom death system without recycling, so its not really a recycling thing..
But I dont really see how it is waste of time, since writing a system like that doesnt really take too much time at all. ( Well, maybe your time is more expensive than mine.. )


And yea recycling also makes unit indexing easy, since you dont have to recycle those indexe´s. You can also have non leaking damage detection systems without using DestroyTrigger.




And you dont have to null units, which is actually a bad thing, since I keep forgotting that I have to null units when I do code for some other guys.

 

[Eccho]

I read somewhere that everytime you create a handle the memory wc3 uses is increases by 4 bytes. However, this value seems to never decrease, even after destroying the handle.

 

[PurplePoot]

I read somewhere that everytime you create a handle the memory wc3 uses is increases by 4 bytes. However, this value seems to never decrease, even after destroying the handle.

Reference leaks?

Well, its faster to get recycled dummy unit for some visual thingy ( like a projectile ) than using that sorry ass slow CreateUnit.

Caster dummies dont have to be recycled, because spell casting is instant, so one or few static dumies are enough. However, for dummies casting channeling spells recycling might be a good idea, since its faster than CreateUnit ( people usually like fast code )

So, for dummies, its a speed thing.

In exchange for facing problems, the speed difference being negligible, and then of course overhead throughout the entire game (it's negligible, but so is the speed difference between recycling and creation...).

But I dont really see how it is waste of time, since writing a system like that doesnt really take too much time at all. ( Well, maybe your time is more expensive than mine.. )

Because you've spent however long only to have more problems (see above) than you did at the start.

And yea recycling also makes unit indexing easy, since you dont have to recycle those indexe´s.

Because putting an if statement on death is so hard?

You can also have non leaking damage detection systems without using DestroyTrigger.

DestroyTrigger is underrated. It isn't stupid to keep it out of public systems, but it's stupid to never use it when you know how to avoid the bugs.

 

[Eccho]

I'm not sure, but even after nulling variables, it increases. I might have interpret it wrong.

 

[Viikuna]

In exchange for facing problems, the speed difference being negligible, and then of course overhead throughout the entire game (it's negligible, but so is the speed difference between recycling and creation...).

There is no such thing as facing problem if you know how to do stuff right. Didnt find any other "problems" from your post.

Because you've spent however long only to have more problems (see above) than you did at the start.

I see no problems above.

Because putting an if statement on death is so hard?

Its not hard, the other option is just easier. And you dont want to recycle index right a way when unit dies. That would be pretty stupid thing to do.

DestroyTrigger is underrated. It isn't stupid to keep it out of public systems, but it's stupid to never use it when you know how to avoid the bugs.

I have used DestroyTrigger without any bugs, but it is quite useless function in the end. UnitRecycling + one trigger, simply works better for me, than creating some useless triggers for every unit and then destroying them. Its just a better option. If you really need some unit comes in range -events, you can ofc create them for your units, but destroying those triggers becomes useless when you recycle your units.


It seems to me that you dont undestand unit recycling and thats why you find it "waste of time". Its like some bloody GUI vs Jass conversation here. If you dont even know how to instantly set projectiles 3d facing angle, you should not come posting any bullshit about unit recycling being waste of time.

( Im not saying that it is the ultimately best option always, but its deffinetly not a waste of time. )

 

[Dark_Dragon]

I'm not sure, but even after nulling variables, it increases. I might have interpret it wrong.

indeed it seems that way! memory will never come back after allocationg it (this 4 bytes). ~via some people testing it i think that blizzard did not maybe use delete/free functions/actions at some point... i belive that this are not like objects but just an integers which have a reference at objects... smth like that but i am not sure about this so i cant talk to much! i only heard that as same as you did and thats that memory never returns after clearing handle. nulling does indeed work it clear memory but part from VM (structs) or better to say handle id goes down...

currently reasons why i most likely dont use recycling of anything is just coz well that handle id-s never goes down as well that class-es from c++ which are heavy well unit is most likely 100+ variables and when i say 100+ that means unit has some more class-es in itself to like point class, attachments dynamic string array well string is dynamic char array through so u know how much leaks it is already...

however i really dont care does someone recycle/remove units its just an option for any programmer to select does he want or not to use it! depends does it make stuff more easy to do or harder! everyone should pick one that is more easy for him to work with!

btw Poot if you know more about that every removed handle leaks feel free to say! i am not sure about this one and through it does not matter 4 bytes... well recycling is trying not to cause that but anyway its for me same as for Poot (i dont care to much about this little leak) so if you dont want to talk about this Poot and find it a wast of time coz really 4 bytes is nothing, then ofc there is no need to answer. however i am not asking you this coz i would like to care for this leaks but just from wish to learn more on how this all stuff works!

ty and greets all!
~Dark Dragon

 

[PurplePoot]

There is no such thing as facing problem if you know how to do stuff right. Didnt find any other "problems" from your post.

Takes time for a unit to turn.

It seems to me that you dont undestand unit recycling and thats why you find it "waste of time". Its like some bloody GUI vs Jass conversation here. If you dont even know how to instantly set projectiles 3d facing angle, you should not come posting any bullshit about unit recycling being waste of time.

I know about SetUnitLookAt and its problem.

 

[Viikuna]

And how is SetUnitLookAt a problem?

 

[PurplePoot]

Flashes to their old facing for a frame when you use it.

 

[moyackx]

Flashes to their old facing for a frame when you use it.

But Grim001 has explained in his tutorial how to fix that.

About unit recycling, I want to contribute with some of my experiences. If you do this in maps where the unit types and their abilities are few or well predefined, this alternative works great. When I applied unit recycling to PoC, I've reached reductions in the memory consumption up to 40% respect to other DD alternatives.

The only inconvenience is that you have to take into account -and code- the "special cases" (example: abilities which work when a unit dies like parasite), but they can be triggered.

In AoS and other highly customized maps, this is not a problem, in fact all is naturally triggered, which should make Unit recycling a natural option for damage detection and gains memory improvement as a bonus.

Now the opposite case: as more normal abilities the map has and less coded is the map and more specific situations the map has, then unit recycling becomes more problem and less efficiency.

So saying that unit recycling is a waste of time is... well... I'd say it depends of the map type. Personally I believe in melee maps is a big pain in the ass for the diversity of conditions, but in other map style is easier to cover all the alternatives and it offers an impressive amount of advantages.

 

[PurplePoot]

He doesn't say how to fix it; he acknowledges it's a problem and you have to live with it and have fixed-facing projectiles.

Anyhow, I just use DestroyTrigger damage detection systems (so sue me, if it's private code you can make it safe) which more effectively handle memory than creating a trigger per unit, and don't find any problems with it. I also have no experience with lag due to excessive unit creation, both from dummies (done some tests actually) and from maps in which plenty of units are trained over the course of the game.

 

[Anachron]

Well, how small are thos leaks anyway? And destroying triggers doesn't clean events, so isn't it useless to destroy triggers and create new ones?

 

[PurplePoot]

What makes you think it doesn't clean events (it does)?

 

[Anachron]

I mean the events are still prevent ingame, aren't they? I heared that events can not be destroyed. Isn't that true? Someone from wc3c.net told me so.

 

[Dark_Dragon]

I mean the events are still prevent ingame, aren't they? I heared that events can not be destroyed. Isn't that true? Someone from wc3c.net told me so.

i dont know what people on wc3c are talking or thinking however let me explain. when you add event to triggger, it is stored on trigger and then that trigger fires on that event (all events trigger it when event in game happen). so once you registerd event to that trigger you cant remove that event. when you add triggercondition you can clear it ~via TriggerRemoveCondition

native TriggerRemoveCondition takes trigger whichTrigger, triggercondition whichCondition returns nothing

events cant be removed... however ones trigger is destroyed, there is really no need to keep events in game and infact all this events will be destroyed. like poot said there is a way to make dynamic DD ~via trigger destroy.

 

[Viikuna]

Flashes to their old facing for a frame when you use it.

Yea, it flickers when you call it every .025 sec, but thats not how you should be doing it anyways. I still see no problem.

And you only need one trigger for damage detection. No need to dynamicly create and destroy them.

 

[Dark_Dragon]

Yea, it flickers when you call it every .025 sec, but thats not how you should be doing it anyways.

And you only need one trigger for damage detection. No need to dynamicly create and destroy them.

having one static trigger vs having only dynamic triggers... why have at least one when u can have zero?

 

[Anachron]

I prefer recycling triggers.

 

[Viikuna]

having one static trigger vs having only dynamic triggers... why have at least one when u can have zero?

Well, ofc you can make damage detection without triggers, if all damage in your map is dealt through some custom damage function, so you know when it is dealt, but I dont think thats what you mean.

How would you create damage detection with zero triggers, ey?

 

[moyackx]

I prefer recycling triggers.

You definitely don't know what are you talking about....

Anyhow, I just use DestroyTrigger damage detection systems (so sue me, if it's private code you can make it safe) which more effectively handle memory than creating a trigger per unit, and don't find any problems with it.

As I said, it's a matter of taste. If you have full control of the triggers in your map, destroy triggers whatever you want and no problem, but if you offer a resource with DD needs, then the thing changes a lot. I don't want to promote any Unit Recycling versus DD alone systems.

I also have no experience with lag due to excessive unit creation, both from dummies (done some tests actually) and from maps in which plenty of units are trained over the course of the game.

Yes, and timers when they're created don't produce a noticeable lag too, and they can be destroyed and no problem. But then why is better recycle them? because reusing an already done and functional timer (handle) is faster than creating them. Therefore, recycling handles (when possible) is a good jass coding practice.

I'll go to sleep, I'm so tired. If something is unclear, I'll fix it later.

 

[PurplePoot]

I don't see the point of "good coding practice" which takes longer and doesn't actually give you any long-term advantage.

 

[Anachron]

You definitely don't know what are you talking about....

Lol, what? I mean I destroy triggers and create another ones.

Yes, and timers when they're created don't produce a noticeable lag too, and they can be destroyed and no problem. But then why is better recycle them? because reusing an already done and functional timer (handle) is faster than creating them. Therefore, recycling handles (when possible) is a good jass coding practice.

Yeah, but is it really that much to create an new handle?

 

[Viikuna]

Creating handles is slow, probably not too much, but since it doesnt really take too much time to make these recycling systems it is a easy way to do things lil faster.

And which one you think is faster ey? Create one trigger for your damage detection system at map init or keep creating and destroying triggers during the whole time your map is being played?

And, PurplePoot, I still dont undestand why keep saying that it takes too much time. Making a map takes shitloads of time when you have to solve anoying problems and figure out how to code complex systems and then try to balance your map and do all kind of little gameplay changes to get it works nicely. Writing an unit recycling is a really small job when compared to all that stuff.

edit. And recycling timers takes only few functions lol, you cant possibly say that it takes any time at all. Writing a reply to my post probably takes more.

 

[Eccho]

Isn't Jass already that slow slready, that minor things such as recycling certain stuff (I see the reason for timers since they can bug, and locations which are overall dumb to use) - would make almost no visible difference? It saves me a few nanos/micros...

 

[moyackx]

It saves memory usage, and much more if your map effects and damage are triggered.

 

[Anachron]

maps* ...
Anyway, it doesn't only save memory, but also increases the usability from the damage event, such as deciding whether the damage should apply or not. Easily configureable attack and armortables would be also makeable.

 

[D4RK_G4ND4LF]

it seems like events aren't destroyed with using DestroyTrigger()
however I'm noob and I might have done something wrong
1 minute after a trigger with thousands of events got destroyed the ram usage was still ~30 mb higher than before
or it's just the type of event registering but it should be much less imho

http://www.hiveworkshop.com/forums/...nyuniteventbj-really-leak-136843/#post1233414

 

[Eccho]

Events are destroyed, since there is allocated a new handle index on the position where the event was held before. The RAM-usage was the thing I talked about before - Might be that it never goes down...