HomeUser Control Panel (unavailable in archive)ForumsTutorialsArt GalleryResourcesMaps

Problems of unit recycling systems ?

08-17-2009, 10:34 AM#1
Flame_Phoenix
I remembered I once suggested to ANitarf to do like Moyack and merge a unit recycling system with a damage detection one. He said that recycling units would add more problems instead of solving them. I believed this was because of "CreateUnit" native, however now that we have "hook" we can simply hook that native, thus solving that problem.
But I am not "in" the problems of recycling units.

What are the other problems of recycling units?
08-17-2009, 11:23 AM#2
Anitarf
Summoned units, structures, raise dead to name a few.
08-17-2009, 11:52 AM#3
Flame_Phoenix
Mmm, if I hook CreateUnit, will I be able to "not create the unit" and replace it by something else?
Also, my idea is only about units, though raise dead raises an obvious problem ...
08-17-2009, 01:13 PM#4
moyack
As more specific and defined are the unit types used in your map and the abilities more triggered, the usefulness of recycling units is greater.

Yes, buildings and summoned units cannot be recycled, but I don't know a map where there are more buildings than normal units, and the same with summoned ones. anyways, if it exits, UR is not the system for them.
08-17-2009, 11:26 PM#5
Themerion
Call me conservative, but why can't you stick with just Creating units, letting them die and then reincarnating them?

I do believe that in almost all cases unit recycling do not matter at all performance-wise (as in, you won't notice the difference), and that the time spent on trying to make it work could be better invested into actually adding content to the map you are working on.
08-18-2009, 12:37 AM#6
moyack
Unit recycling is not because we think is cool, is because it improves damage detection code in the way it reuses the units connected to the events EVENT_UNIT_DAMAGED. And as a bonus, your map consumes less memory because it doesn't have to create more events for the damage detection by reusing the units killed.

When you check a DD in the database, review the evil part of "how to destroy the events".
08-18-2009, 08:36 AM#7
Anachron
Well, summons and structures are indeed very evil against unit recycling, but as for now, I think its not that hard to just remove them from the system, you understand what I mean?

A unit dies
Unit is a spawn == true
call UnitRecycling.RemoveUnit(GetTriggerUnit())
08-18-2009, 08:45 AM#8
Fledermaus
You could also fake Summoned units.
08-18-2009, 08:57 AM#9
Anachron
Can't you do the following:

local unit array units
set units[0] = 1
call TriggerRegisterUnitEvent(trigger, UNIT_EVENT_DAMAGED, units[1])

Wouldn't it work for every unit on position 1?
08-18-2009, 10:12 AM#10
Viikuna-
Unit Recycling also makes unit indexing easy, since you dont have to do any extra stuff to detect when unit decays or is removed or anything like. You dont have to recycle indexes at all, since you recycle units.

Also if you fake units death, like in that moyacks system, you have to do all units death related stuff by yourself. It might sound like a ot of useless extra work, but then again you can easily do pretty cool stuff when you have control over units death.

Like some cheat death ability, which allows caster to fake hes death, or some ability that makes caster take credit of all deaths in area, or stuff like that.

Basicly, the more you trigger stuff, the more you can control it. It might not work for every map, but I personaly kinda like it.
08-18-2009, 11:31 AM#11
Fledermaus
Quote:
Originally Posted by Anachron
Can't you do the following:

local unit array units
set units[0] = 1
call TriggerRegisterUnitEvent(trigger, UNIT_EVENT_DAMAGED, units[1])

Wouldn't it work for every unit on position 1?
No, it would only work for the unit assigned to units[1] at the time you registered the Damage event.
08-18-2009, 02:02 PM#12
Themerion
Quote:
Originally Posted by moyack
...because it improves damage detection code...

...When you check a DD in the database, review the evil part of "how to destroy the events"...

I thought trigger generations was a pretty good solution...

Quote:
Originally Posted by moyack
...your map consumes less memory because it doesn't have to create more events for the damage detection by reusing the units killed.

Do I dare to call this irrelevant for practically all maps (TD's and tower wars included)?

Quote:
Originally Posted by Viikuna-
Unit Recycling also makes unit indexing easy, since you dont have to do any extra stuff to detect when unit decays or is removed or anything like. You dont have to recycle indexes at all, since you recycle units.

Au contraire, it makes it harder. You have to manually nullify all data that you associated with its index. Normal indexing can differ between the units, recycled units have the exact same ID, so there's no way to tell...

Actually, any variable pointing to the unit have to be nullified. I expect this would cause some really nice bugs when nullifying is forgotten... What do you get in return? "Performance". Show me a map that's being played (no test case where you spam 1000 units/second just to prove your point, thanks) that suffers from create/remove performance penalty.

Quote:
Also if you fake units death, like in that moyacks system, you have to do all units death related stuff by yourself.

Such as scripting corpses and that kind of stuff. Then scripting decay, and whatever else you have to do. Including nulling all variables (how the heck are you going to know which are pointing to it!?)

Sounds great! xD

------
I heard the people behind Tides of Blood have made a system that uses units for all projectiles (unit attacks, spells, everything). They used recycling at first, but due to problems (with set unit facing, and other obscure bugs) they reverted to just creating and removing, noticing no performance penalties at all.
------

I'm not trying to be a bitch, I just still don't think this is such a good idea :P
08-18-2009, 02:25 PM#13
Flame_Phoenix
Quote:
I'm not trying to be a bitch, I just still don't think this is such a good idea :P
And now you made me join the dark side xD
08-18-2009, 02:35 PM#14
Viikuna-
Quote:
Show me a map that's being played (no test case where you spam 1000 units/second just to prove your point, thanks) that suffers from create/remove performance penalty.

I know many maps that probably suffer from that, but since I havent seen the code it I dont really know. They probably suffer from other stuff too.

Quote:
Do I dare to call this irrelevant for practically all maps (TD's and tower wars included)?

Well, most of TD´s I have played, spawn shitloads of units that usually die fast because of all those towers. Without recycling I would have to, for example, keep creating new damage events all the time. Probably its irrevelant. One can make a fully playable and laggless map with GUI too. You dont really notice those few leaks when playing the map.

Quote:
Au contraire, it makes it harder. You have to manually nullify all data that you associated with its index. Normal indexing can differ between the units, recycled units have the exact same ID, so there's no way to tell...

I dont really get what you are saying here. I usually use UnitUserData to index units, and that index is usually used as an array idex for various struct arrays. Resetting all the units properties and system instances thingies isnt that big job, since if I created new units, I would have to create those properties and register units to those systems anyways.


And recycling dummies for projectiles is no problem. You probably want to instantly set units 3d facing angle to make cool missiles that can reflect and do cool stuff, so you arent doing that just for sake of recycling.


And if I recycle all my units, I dont have to null local unit variables anymore, because those handle indexes are never recycled anyways.

( This is the reason why I decided to do it in the first place, believe me. o_O )
08-18-2009, 02:44 PM#15
Anachron
Quote:
Originally Posted by Fledermaus
No, it would only work for the unit assigned to units[1] at the time you registered the Damage event.
Damn, thanks for clearing that.