edit
I added stuff to this post, so be sure to take a look at the new stuff ;p
end edit
Too bad it's still bugging out for you. Your explanation of it makes sense though - but the array will often have holes I think. But it's smart to index by count and angle. Very good thinking.
If the allowed variance in the queues is >1, then it will have holes, you are correct. If it's 1, then it will never have holes (which is why I talked about benching SetUnitFacing).
There is one other interesting thing... you can put the active counts into a list. If you have a variance of 16, then your list size will be a maze of 16. This will allow you to get the next active count = O.
For this list, every value will be unique, meaning that the list will only ever at most swap 2 nodes. You won't have one node magically go up. The reason that the swapping doesn't work that way for my old implementation was because the values weren't unique, so you could have 125 125 125, then get 126 125 125 and have to move the 126 to the end ;o.
So anyways, the list of counts will allow you to have holes, the array of lists referenced by count will allow you to retrieve the min/max stuff for recycling, and the array of queues referenced by the angle will allow you to retrieve a dummy given an angle.
That is the final design >: O. Not bad if I do say so myself, pure O(1) operations ; ).
If you want to code it all and save me the trouble of doing it, then let me know. I'm personally just not in the mood to work with dummy recyclers anymore after working on it so long yesterday and through half of today : |. Just make sure that it's good, and I will pound it into perfection as I will be needing it for the projectile system I'll be doing.
Also, please use this for comments
Rather than this
The first one is easier to read. Also, your docs are very hard on my eyes. tbh, I started working on the dummy recycler w/o even reading through a lot of your stuff primarily because I didn't like your docs. You have a huge useless preface that I and other people using your resource don't care about.
how does this help me use dummy recycling in any way???
JASS:
Recycling dummy units is important because the CreateUnit call is one of,
if not the, most processor-intensive native in the entire game. Creating
just a couple dozen dummy units in a single thread causes a visible frame
glitch for that instant. The overhead is even higher if you are using a
Unit Indexing library in the map which causes some extra evaluations per
new unit.
It doesn't, it's just useless information. Put that into the post so that people who want to just use the resource can have easy and direct access to the API. Keep the docs in the code uncluttered please ; ). Uncluttered docs are just so much easier to get through.
This, as I'm sure you know, is unsafe and isn't really acceptable in public resources anymore
//! external ObjectMerger w3u ewsp dumi unam "Missile Dummy" ubui "" uhom 1 ucol 0.01 umvt "None" umvr 1.00 utar "" uspa "" umdl "war3mapImported\dummy.mdl" umxr 0.00 umxp 0.00 ushr 0 uerd 0.00 udtm 0.00 ucbs 0.00 uble 0.00 uabi "Aloc,Amrf
The user will have to import the model from the map anyways, so might as well just keep it all in a map. Can also do a small Lua generation snippet if you want ;o.
And really, all of your protection stuff in there... what I might do is write my own version with debug only protection that supports your API so that people can pick between whatever they want. You can also support my version's API ; |. I think that's the best scenario. Really, we're doing it two very dif ways and both have dif things we want our resources to do ;p. I like mine to be as optimal as possible and disable it and crash it if any errors occur. You want to just protect against all errors regardless w/o crashing it and so on so that the map can just limp its way through =p. They are just two different styles = ).
So anyways, I think that that is the best approach at this point. Also, what you could do is write the resource and then I could modify it up a bit and we could have two versions on this thread, one with my style stuff and one with yours. They would both share the same API, that way a user could pick whichever one they wanted. They could also have dif style docs if you want to keep with your current doc style (I seriously can't handle that style).
In fact, this might be a good solution for UnitIndexer as well. You want hook RemoveUnit right (even though it'll cut the speed down by quite a lot as it'll run through 3x rather than 2x). Yea, this might be a good approach to take for resources from now on. As long as they share the same APIs, no worries. If people prefer different style APIs, then as long as they all support all of the styles, it's all good ^_^.
edit
As for the projectile system debate, all current projectile systems, including the one I have up, are written incorrectly and should be terminated once I get a correctly designed projectile system up (hence the reason I started working on a DummyRecycler ^^). They all have very serious design flaws. The reason I rewrote all of my damage stuff was because my damage stuff, and all other damage stuff, had serious design flaws as well =O. Now look at damage, it's designed beautifully. It uses the same design (or possibly a better design) than top commercial games ;D. And yes, Purge's stuff was also written incorrectly.
And btw, I know you may not like all of the rewrites, but very few people are willing to work with me on rewriting their code. Most people say good enough. This is the reason I do the rewrites, because good enough is not good enough for me ; ). For example, Dirac's damage stuff was good enough for most people, but to me it looked like absolute garbage. Purge's stuff seemed good enough for most people, but I didn't like his lib either. Dirac's projectile system seems good enough for most people, but to me it just looks like a heavyweight monster that's going for the world championship.. you obviously couldn't run 2D projectiles effectively on it... furthermore, it isn't very flexible at all >.<. You get what you get with it. This means that if you wanted 2D projectiles, u'd need a 2D projectile resource. If you wanted 3D, then you'd need a whole separate resource... and it just goes on and on... this is why I try to make it so that my own resources are highly flexible. It means that #1, you can easily extend off of them to add your own functionality to them. #2, you don't have to add band-aids to get your own functionality in (resulting in a jumble of unmanageable spaghetti code). I do realize that most of my older resources, like Unit Indexer and Unit Event, are like this, but I have been getting away from the business of spaghetti code ever since vex fixed his optimizer ; ). Also, if you notice, I continue to change my doc styles and comment styles with the goal of making them as easy to read as possible ^_^.
So anyways, back on topic... getting a good dummy recycler with O(1). Two flavors, one version with safety always on (your style) and one version that disables itself and crashes thread with debug only safety (my style) ^_^. We are obviously never going to agree on the safety styles, which is why two versions are necessary. You'll likely never use my style and I'll never use your style, so just have two versions to support both styles ;o. Also, a function API + struct API. I personally like the API I did better, and I'm sure that you like your API more, so support both. Furthermore, you are still missing some functions in your API, like IsUnitDummy and what not ; ). Also, I personally like to pass in the unit index of the unit whereas you like to pass in the unit. In my code, I'm always working with indexes, not units, so it's just easier for me to pass in an index. In the resource itself, I'm always working with indexes, so it's easier to take an index. Passing in the unit handle just results in more GetUnitUserData calls and more array reads in order to convert the index back into a unit to be passed into the function. To support both styles, you'd have wrapper functions that take units but call the other functions that take indexes ; ). This makes everyone happy.