3rd May 2016

General Info

Your resource has been reviewed by BPower. In case of any questions or for reconfirming the moderator's rating, please make use of the Quick Reply function of this thread.

Review:

Highly recommended for projectile and fx utility systems or
for anyone who needs a lot of dummy units for his/her code.

The option to share units among unit lists is very neat.
I ran a couple of stress tests and everything seems to be in perfect order.

In the vJass version the onInit function could be placed into a module initializer.

Troubleshooting:

• Nothing

Review changelog:

1. -

 

You can still make the DummyRecycler without using a hashtable

Overall, I think this should still be based on Bribe's Recycler

[edit]
GetRecycledDummy is much better than Dummy_GetRecycledUnit, same goes to RecycleDummy

also, I think the recycle delay should be the same for all dummies, i mean, declare a time constant, then apply that to all recycled dummies

Also, Allow the users to disable their Unit Indexers to prevent dummy indexing.

 

How (but still being O(1))? Anyway, it doesn't matter much because hashtables are O(1).

I honestly doesn't understand how Bribe's work. Didn't also bother to have a detailed look at it. Also, where's the fun in that if I'm just gonna copy someone else's design? I like thinking my own design.

Agree, will change that in the next update.

Actually, the AddRecycleTimer is just a bonus feature. Users will mostly just recycle the Dummy instantly. It will still show

effect

being destroyed because the Dummy's are not moved anywhere when recycled.

I don't use Unit Indexer so I don't know how to do that.

 

Add a function where they put the Indexer disabler in(see ToggleIndexer function in MissileRecycler)

 

This does exactly what Bribe's does.

A good one will always throw the unit into the least populated angle in O(1).


I'll give you a hint on how to do this.

list[1] = angles with a population of 1
list[2] = angles with a population of 2
list[3] = angles with a population of 3
list[x] = angles with a population of x


at most, only 3 lists may be active at a time. You would have a lower bound and an upper bound. Whenever an angle goes below the lower bound for population, it takes from the upper bound. When the upper bound becomes empty, the upper and lower bound are shifted down. As things get put in, then lower bound angles get populated first as they are the most sparse. When the lower bound becomes empty, the lower bound and upper bound are shifted up. This is how my recycler works and how you can achieve O(1) recycling while optimally throwing units into the most sparse angles : ).



You'll also need the following

list[90] = units facing direction 90
list[270] = units facing direction 270
list[x] = units facing direction x


Angles are added to the first set of lists. Units are added to the second set of lists. You'll also need angle counts.


count[angle] = value (how many units are in the list for an angle)





This is the very best way to do unit recycling. Bribe has yet to implement this. It's only in my library, which is broken : p.

 

However, when a Recycled Unit is thrown to the list with the least number, they will be able to see the Dummy Unit turning while it gets destroyed. Actually, that reminds me, this system currently throw recycled units to it's original list, where it should throw it to the list nearest to the current angle of the recycled unit so that the dummy will not be seen turning.

This is still not O(1) because what if list[1] is empty? Then it will go to the next until it reaches a non-empty list?
Example, all list contains 5 units. Then it will go to list[1] then list[2] then list[3] up to list[5].


Currently, it's worst case scenario (DummyRecyclerEx) is O(n) and best case is O(1).

 

The below is a snapshot of what the data structure looks like. If you were to retrieve a unit from angle 45, it'd be pushed into 0, which is below the lower bound. Because the upper bound is not empty, it would take from the upper bound and push angle 45 back to a count of 1. Angle 90 would be pushed down from 2 to 1.

0 would never go to -1 because a unit is not popped off of a list unless that list isn't empty and has a ready unit.

When recycling a unit, you'd always throw it into an angle in the lower bound. This keeps everything as evenly distributed as possible.

When the upper bound becomes empty, bounds go down by 1. When the lower bound becomes empty, bounds go up by 1. For bounds, you only need the lower bound variable.





Hope this makes things more clear : )


If you still don't understand, I can try doing an animation ^_^

 

^ Make an animation.

 

Thanks Nestharus! That makes it more clear.
No need to animate but if you want to, feel free to do it.

Though I disagree on this part, it should be thrown to the closest angle it is currently facing then the lower bound will take a unit from the upper bound. Else, when a unit facinf 80 degrees is recycled and the lower bound is 270 degrees, the recycled unit will be seen turning as the effect attached to it destroyed.

 

Er, it's not going to be seen turning because it won't be visible. If you recycle it and it's seen turning after it's recycled, you're doing something wrong : P.

 

Why would it be not visible? A destroyed

effect

still must show the death animation.

 

because when it's recycled, it will already not have any effects on it...

that's like calling something like RemoveUnit and complaining that the unit is visible after removing it. It doesn't even make sense >.<.


If your recycling doesn't work like RemoveUnit, you've got some serious problems.


Sending to the nearest angle doesn't provide any benefit because the recycle method should work in the same way RemoveUnit does. Once you call it, the unit vanishes immediately. I think good recycling will move the unit to the edge of the bounds of the map so that it's not visible.


Recycle != KillUnit. Recycle = RemoveUnit : ).



Now if you want to show the death animation on top of that, then you recycle on a delay.


Not moving the unit can have unintended consequences in a map as it may interact with other elements of the map. For example, unit in range.

 

Dummies, units with 'Aloc' in general, neither pop up in units in range enumeration nor do they fire the unit comes in range event.

They fire unit enter region events.

 

Then perhaps the SetUnitFacing bit should be done on a timer queue to allow for death animations? Maybe set facing after 3 seconds, which should be more than enough time for any death animation.

 

Updated.
- No longer comes in 'Basic' and 'Advance' versions. 'Basic' version is removed.
- Changed API name, removed the "Dummy_" prefix.
- Improved the data structure, all operations are now O(1).
- Recycling a unit is now the equivalent of removing a unit, thus users should use AddRecycleTimer to allow the death time of the attached effect to show.

 

You should recycle newly created units too. Shouldn't remove "excess" units. The data structure can adapt to new units being put into it.

 

Okay, and on that part, it should not have been KillUnit but RemoveUnit. But it doesn't matter anyway since I'll change it.

Do you think I also should add a safety mechanism on recycling unit. Because currently, let's say I recycle a unit facing 0 degree and it is thrown to 180 degrees (with empty list) so it is now starting to turn. However while turning, I retrieved a unit from the 180 degrees list but the only unit in the list is still turning. So should I only add it when the unit is completely turning already and the action should have created a new unit instead? However, it would require calculation based on turning speed and angle difference.

 

if GetUnitFacing == angle, return unit
otherwise create unit

 

How the fuck did I fail to think that?
Thanks!


Update:
- Excess recycled units are no longer removed, but permanently added to the list.
- GetRecycledUnit will no longer return units that are still turning.
- Added a vJASS version since it is different from Bribe's MissileRecycler.