System Unit Indexer

[Jesus4Lyf]

I actually checked this out last night straight after it was posted. A few things:

>It's simply impossible for AIDS to be faster than this given its current code.
AIDS is faster if you use a periodic timer. Nothing is faster than AIDS' periodic timer, because it distributes units which die in spikes. I'm aware what I'm saying is irrelevant. So are you.

Now, I think you've come up with something innovative here which can be used to optimise AIDS' non-periodic recycler very slightly, and perhaps make AIDS support AutoIndex's full interface in addition. That means when I get time, I intend to update AIDS and give you credit for your innovation (naturally), after I test it and find that it actually works under various circumstances (I did a bit last night, it's looking ok).

Still, this system is broken on recursion and stuff, but you might at least get credit in AIDS. And nice work.

PS. To everyone who immediately discounted Nes, I know he makes ridiculous and incorrect claims all the time which are founded on nothing except assumptions, but I do check to make sure they're ridiculous and incorrect first, generally speaking - I think he may have found something on this.

 

[Deaod]

Do you really think that a shortened implementation of AutoIndex is going to be as robust as its original? Why do you even debate its usefulness? It doesnt contribute anything that wasnt there before, or is useful.

After some debate between me and someone else, we came to the conclusion that locking, as well as index verification are useless features, which could only ever be abused by someone who doesnt know what the heck hes doing, or worse, relying on unsanitary practices. If you need data associated to a unit until its removal, use AutoDestroy, no need for locking. You have OnUnitIndex and OnUnitDeindexed, you KNOW when a specific index is not being used anymore. IsUnitIndexed is already provided by AutoIndex.

Also, who the hell would EVER need to stop indexing units?

 

[Nestharus]

The reason for locks is for structs that are impossible to deallocate until something happens. Furthermore, if these structs allocate and use the index of the allocated unit for themselves and their previous index was not deallocated because it was somehow impossible to deallocate (thinking of stuff like KT2), then you have an immediate and unfixable bug.

Furthermore, the overhead on locks is almost nothing with Unit Indexer... it's one extra boolean check, lol.

Originally I was going to do keys to determine whether the instance was still valid or not, but keys would be entirely useless given the above scenario.

Also, who the hell would EVER need to stop indexing units?

If you wanted to replace the indexed unit ; ), which I will support in this. Replacing would allow things like SetUnitType.

The idea with replacement is that the unit is the same but the handle of that unit is different (like the SetUnitTypeId example).

AIDS is faster if you use a periodic timer. Nothing is faster than AIDS' periodic timer, because it distributes units which die in spikes. I'm aware what I'm saying is irrelevant. So are you.

By allowing access to the unit on deindexing in one mode and not allowing in another mode, you are creating an unstable API. The thing needs to either allow full access on all modes or no access on all modes, otherwise you could have buggy code or people would have to code specifically for each mode ; |.

Also, it's impossible to support all of the AutoIndex API without having stuff like IsUnitAnimated or w/e. This is the reason why I'm just calling that library evil.

I personally think that this + my planned ReplaceIndexedUnit and API support will make the perfect unit indexer ; ).

Obviously it would be nice if you could also add the code straight to the enter and undefend triggers and return true on the filter to fire them, but deindexing would cause issues as the thing needs to be checked/deindexed after done firing ; |.

Still, this system is broken on recursion and stuff, but you might at least get credit in AIDS. And nice work.

I also don't get what you are saying about broken on recursion. It deindexes when it's supposed to and indexes when it's supposed to... it works with multiple undefends... where does this recursion come into play????

I also don't condone you changing the AIDS design to match this library's design. If you are going to do that, make AIDS use this -.-...

Given my design is different from any of these other unit indexing systems, I think my system is the one that merits ownership of the design and that these other systems, if they choose to match its design, should use this system rather than copying it. I know I certainly didn't copy these other systems at all. When I make a system where another system already exists that does the same thing, I condone that as proper because my design will be totally different from the designs of those other systems, making my system its own system in its own right.

Now if it was just changing like one line of code to be a little more optimal, then yea, I'd suggest it for that system. If it was about adding functionality, I'd create a library for that system. If it's about an entire design change of one or more of the core components, then I make my own system.

I hope I'm making sense here.

 

[Jesus4Lyf]

I also don't condone you changing the AIDS design

Who said anything about that? I just considered optimising a line or two. AIDS structs are still its core.
And why am I bothered by what you condone?

After some debate between me and someone else, we came to the conclusion that locking, as well as index verification are useless features, which could only ever be abused by someone who doesnt know what the heck hes doing, or worse, relying on unsanitary practices.

That's a dryly academic thing to say, considering how irrelevant and arbitrary "unsanitary practices" are in Jass. If you think of locking as reference counting followed with garbage collection, suddenly it makes sens in my books. And despite common belief, neither of our opinions matters more than the other, so whilst I'm happy to discuss the proven use cases for this, I'll have to take you simply saying "you're wrong and I'm right" as a joke.

 

[Nestharus]

Who said anything about that? I just considered optimising a line or two. AIDS structs are still its core.

Was talking about how the system runs in the background for design. I don't mind if you change a couple of lines, I just thought you were moving to the overall design of this one (where timer no longer needed, undefend loops no longer needed, and etc).

But if you aren't, I'm ok then ; D.

You just made it sound like you were going to take this library and put it into AIDS and then reject this one, so I was upset o-o.

Although at this point, I think this should be approved as an alternative. While making my Unit Event library (which is epic btw), I've been slowly finding the last of the little bugs in this (accidentally set a boolean value here, did this there, had a parameter that wasn't even used, haha).

At this point I think it's safe to use... I'm very satisfied with the API now and I have used every single feature in this but ReplaceUnit ; P, so that's the only thing left to be tested (even though I'm confident it works since it is rather simple o-o).

 

[Jesus4Lyf]

You just made it sound like you were going to take this library and put it into AIDS and then reject this one, so I was upset o-o.

The entire sum of the difference was removing the 0.0 sec delay after the undefend check, which has naught to do with design, and is an insignificant implementation detail which I intend to optimise once I'm satisfied that this approach works.

If that's "taking this library and putting it into AIDS", you've broken what you've been told multiple times, which is when you spot an optimisation to a system which already exists, you post in the respective thread. The courteous thing for the author to do is credit you for it, which I would naturally do, as I stated.

 

[Nestharus]

Aye, but I've tried that before (tell fixes and so on), and I've been ignored every time... first time was with GetItemCost ;o.

Anyways, I did put a lot of effort into this library. When this design is completely proven to work, it would be nice if this was approved as this is the library I'd want to use since it has features I do need for some of my other things... like enabling/disable unit indexing and unit replacement.

I'm also done with Unit Event, and it does use this library. Guess what, I did it with 0 hooks >: D.

Oh well, it'll be going up in a second here, so you can take a look at it : P.

Also, it uses the all too useful Trigger script to save on trigger evaluations =\.

 

[Jesus4Lyf]

like enabling/disable unit indexing and unit replacement.

If unit replacement does not leave the unit in control groups and global variables, I'm not interested. We can already change a unit's type without resetting references to it.

I'm also done with Unit Event, and it does use this library. Guess what, I did it with 0 hooks >: D.

Grats, looking forward to it.

Also, it uses the all too useful Trigger script to save on trigger evaluations =\.

Whatever.

 

[Nestharus]

If unit replacement does not leave the unit in control groups and global variables, I'm not interested. We can already change a unit's type without resetting references to it.

OnReplaceEvent, but that'd require everything run through Unit Indexer ; |.

Global variables, if using an indexing system, should pretty much just use integers.

 

[Jesus4Lyf]

Global variables, if using an indexing system, should pretty much just use integers.

This is a false and arbitrary opinion stated as fact, we can change an indexed unit's type in one line of JASS code, irrelevant of variables using it, without manually changing references. We don't need some useless feature in an indexing system which does the same thing but resets variables and crap by destroying the original handle.

 

[Nestharus]

This is a false and arbitrary opinion stated as fact, we can change an indexed unit's type in one line of JASS code, irrelevant of variables using it, without manually changing references. We don't need some useless feature in an indexing system which does the same thing but resets variables and crap by destroying the original handle.

Well I know I need it, lol... to me it is highly useful for a slew of things ^.^. Reason? It's essentially like cloning a unit... removing it and creating != cloning because the original data doesn't transfer over then.

A replace event is the best way to clone as no data is lost.

Reason I always refused to use indexing systems was because they didn't support a way to be able to replace a unit. That was the primary feature I was gunning for (which I also knew that you'd ever ever add to AIDS).

 

[Jesus4Lyf]

we can change an indexed unit's type in one line of JASS code, irrelevant of variables using it, without manually changing references. We don't need some useless feature in an indexing system which does the same thing but resets variables and crap by destroying the original handle.

What did you miss in there? You can change a unit's type without removing it. WC3 has a native way of doing that. They do it in the campaigns, for chaos orcs...

That was the primary feature I was gunning for (which I also knew that you'd ever ever add to AIDS).

So can I graveyard this, yet? o.o

 

[Nestharus]

Er... I can remove ReplaceUnit but I don't think this should be graveyarded.. lemme upload the one without Trigger =\.

I'm working as fast as I can, lol.

 

[Deaod]

That's a dryly academic thing to say, considering how irrelevant and arbitrary "unsanitary practices" are in Jass. If you think of locking as reference counting followed with garbage collection, suddenly it makes sens in my books. And despite common belief, neither of our opinions matters more than the other, so whilst I'm happy to discuss the proven use cases for this, I'll have to take you simply saying "you're wrong and I'm right" as a joke.

So show me code where locking actually saves the day, and could not be replaced by AutoDestroy and/or good code.
Someone mentioned KT2. Im not too familiar with KT2s API, but i think you cant stop scheduled execution of code from outside (ie. you have to execute the next iteration and stop it there). This fix is fairly easy: dont use KT2. Theres no reason anyway. Low periods shouldnt be handled by KT2, as KT2 is slower than the alternative of a stack you loop over every fraction of a second (also, you can remove instances from that stack at any time). High timer durations make KT2 rather inefficient as it uses a separate trigger for every duration. High timer durations can be handled better by raw timers (which in turn can be paused at any time).
So yeah, usage of KT2 is not a good example, as there are better ways to do what you want to do.

Furthermore, the overhead on locks is almost nothing with Unit Indexer... it's one extra boolean check, lol.

That is ... ... totally irrelevant.

If you wanted to replace the indexed unit ; ), which I will support in this. Replacing would allow things like SetUnitType.

While it does sound cool, i dont think this is too useful. Like it was already said, you cant update every reference to the old unit, and unless that works replacing a unit is completely worthless. Chaos is the better approach for SetUnitType (although it has quirks of its own), simply because it leaves all references intact.

 

[Nestharus]

ok ok, give me a second to update all of this : O.

edit
And Unit Event uses locks because it runs on an undefend event like this does ; P.

 

[Jesus4Lyf]

Someone mentioned KT2. Im not too familiar with KT2s API, but i think you cant stop scheduled execution of code from outside (ie. you have to execute the next iteration and stop it there). This fix is fairly easy: dont use KT2. Theres no reason anyway. Low periods shouldnt be handled by KT2, as KT2 is slower than the alternative of a stack you loop over every fraction of a second (also, you can remove instances from that stack at any time). High timer durations make KT2 rather inefficient as it uses a separate trigger for every duration. High timer durations can be handled better by raw timers (which in turn can be paused at any time).
So yeah, usage of KT2 is not a good example, as there are better ways to do what you want to do.

All of this is well said, standard on TH seems to be using TU for long periods, T32 for short periods. Both, you can pause from outside. But for the sake of perfection, I have to correct you in that KT2 is faster than a bunch of struct loops with one instance each, like you might experience in spells. Doesn't mean I recommend it - T32 solves this issue, too.

So show me code where locking actually saves the day, and could not be replaced by AutoDestroy and/or good code.

"Good" is subjective. To me, good means

1. quick to write
2. intuitive
3. adequately efficient
4. reasonably maintainable; ie. maintainability is good, but don't try to future-proof

which leads me to my classic use case of the creep you wish to respawn 50 seconds after it dies. Make an AIDS struct; in AIDS_onCreate lock the struct and store unit type, location, etc; on death wait 50 seconds and re-create the unit, unlock the struct, you're done.

The code is

1. VERY quick to write
2. intuitive
3. efficient
4. and maintainable

and the fact that it is academically bad doesn't stop me from doing it.

Another example is using Status to apply Statuses to units, if you cannot be bothered accounting for the unit disappearing whilst under a status. Just lock the damn struct and forget about it.

ok ok, give me a second to update all of this : O.

This is still just an indexer that fails on recursion, to me...

 

[Nestharus]

This is still just an indexer that fails on recursion, to me...

I still don't get what you mean.. this doesn't need recursion...

What I mean to say is you can have things running through multiple times and it'll just block it rather than add the thing to an array 50x.

Oh yea, and I finally got this thing freaking updated, lol.

edit
this [ljass] if (GetUnitAbilityLevel(u, 'OUIN') == 0) then [/ljass] will run once for each undefend.

this [ljass] if (indexedUnit[indexed] == u) then [/ljass] only lets first undefend through.

What are you talking about with recursion???

edit 2
w/e, I'm 100% exhausted so I'm going to bed now. I see nothing wrong with this library now based on all of the previous arguments except for the init, which I am just too tired to fix up right now -.-... I think using recursion with this design is absolutely pointless, and I stand by that 100%. It's overhead for 0 gain...

edit 3
bah, fixed ini on both this and Unit Event.

 

[Jesus4Lyf]

What are you talking about with recursion???
...
I think using recursion with this design is absolutely pointless, and I stand by that 100%. It's overhead for 0 gain...

struct tester extends array
    private static method run takes nothing returns nothing
        call CreateUnit(Player(15),'hfoo',0,0,0)
    endmethod
    
    private static method onIndex takes nothing returns boolean
        if CreateUnit(Player(15),'hfoo',0,0,0)==GetIndexedUnit() then
            call BJDebugMsg("fail")
        endif
        return false
    endmethod
    
    private static method onInit takes nothing returns nothing
        call TimerStart(CreateTimer(), 1, false, function thistype.run)
        call UnitIndexEvent.add(Condition(function thistype.onIndex))
    endmethod
endstruct

It just fails. I didn't want to post this because if you fix it, you'll think this warrants approval. Honestly, there is nothing new in this library to warrant approval. I hate saying this, because I note the effort in what you've done, and you actually contributed something valuable in your discovery around the undefend tweak for on removal, but I still can't find anything in here to warrant a new system, instead of an update to an already existing unit indexing system, such as AIDS. It's just not necessary..

 

[Nestharus]

Oh I see what you're talking about ;o.

That would fail on multiple trigger evaluations.


I actually know how to fix it too ; |.

edit
that literally didn't even take me a minute to fix...

I need to fix Unit Event recursion too : P, but it's 4 am now so I will do it tomorrow.

edit
fixed it, lol... all that's left to do is upload latest test maps, which I will do tomorrow. Having the scripts up is enough for me -.-.

edit
Ok, looked through AIDS lib again and I think I'm totally ok if you update it, but there would have to be a lot of little changes. I do want it to have all of the current features of this (and it's only missing the enable and disable indexing). The enable/disable is extremely important for me because of Unit Event ini.

The other thing is update your dang macro to use static ifs, get rid of the dummy struct... for filtering, the thing shouldn't even be running in the first place if it wasn't indexed to begin with ; |.

Seriously, the code I have right here is fine for the actual library (now that it has recursion in it ^.^).

Now, if those are like way too many little changes and you don't want to do enable/disable indexing and so on, then I think just having two alternatives, this library and AIDS, would be the best option. For one, Unit Event requires enabling/disabling of the indexing.

There are just lots of little things : |. See, because there are so many things, I made a whole separate library.

Up to you jesus4lyf, but yo know my stance on the features and on the code ; ).

And oh yea, the lack of documentation on the public functions + the fact that they are public irritated me to the point of using GetHandleId with a hashtable over using AIDS back when I had tried using it.

 

[Jesus4Lyf]

it's only missing the enable and disable indexing
...
There are just lots of little things : |. See, because there are so many things, I made a whole separate library.

Eh? Look, AIDS already supports enabling/disabling indexing out of the box... Just make the "index filter" read a global...