AIDS or AutoIndex?

[Bribe]

I've opted to run with a unit indexing library because I want access to UnitUserData (to not use hashtables wastefully), and I know it's taboo to use that feature without proper handling.

What would be the pro's and con's of using one or the other? I'm looking for things like:

• Which is the most popular?
• What features does one have that the other does not?
• Any bugs or "gotcha's" I should know about?
• Differences in performance?

Thanks

Please note I have no interest with "aids structs" or the like. Ideally, there are three things I want:

• GetUnitId
• UnitExists Event
• UnitDeath/Removal Event

 

[Tyrande_ma3x]

AutoIndex + AutoEvents
They should be pretty well documented and basically that's all you would need! :thup:

 

[Zwiebelchen]

Probably the most important decision factor when selecting the indexing system is the systems you want to use in your map. Performance-wise, they should be pretty equal.

I prefer AIDS, however, for two reasons:
- Jesus4Lyf's systems always use AIDS (you can't blame him for that :>) and Jesus4Lyf did write a system for almost any aspect of mapping. That way you can ensure perfect compat 99% of the time
- AIDS has PUI property and PUI structs for compatibility ... PUI property is awesome if you want to add simple custom stats to units, as you can do that with a 1-liner.

However, in the end, it doesn't really matter, as most of the systems use GetUnitId anyways and this command is the same for all indexing systems.
All you have to do is changing the library requirement to AIDS or AutoIndex, depending on what you use.

 

[kingkingyyk3]

Depends on.
If you loved to use systems at here, use AIDS.
If you loved to use systems at wc3c, use AutoIndex instead.

 

[Bribe]

I've been toying around with AutoIndex/AutoEvents and found that the unload/load transport and reincarnation start/finish are perfect compliments for my system, because I should destroy the struct when the unit itself is not capable of moving.

 

[Jesus4Lyf]

What would be the pro's and con's of using one or the other? I'm looking for things like:

• Which is the most popular?
• What features does one have that the other does not?
• Any bugs or "gotcha's" I should know about?
• Differences in performance?

Kingking and Zwiebelchen pretty much nailed it, but...
To delve a little more into subtleties in an unbiased fashion (because I honestly don't care which you use):

>Which is the most popular?
AIDS here, Autoindex on WC3C.

>What features does one have that the other does not?
AIDS has struct locking so you can make an index live longer than a unit (and backwards compatibility with PUI).
AutoIndex has a just-before-unit-leaves-game event. AIDS' event actually fires the frame after the unit leaves, so you do not have access to it.

So there is a subtle philosophical difference. AIDS believes you should be able to extend the life of a struct longer than the unit if you're not done with that data, AutoIndex believes you should have access to the unit the instance before it leaves the game.

There are other new things with AutoIndex I'm not familiar with. I'm sure they're pretty cool, but could be done with AIDS also.
AIDS also has other features I haven't mentioned - I just wanted to mention the key difference that would always separate the two.

>Any bugs or "gotcha's" I should know about?
AIDS structs use the unit id for their index. AutoData does not. Means AIDS structs are slightly (in some stupidly small way) more efficient to load, but you need to use this [LJASS]extends array[/LJASS] thing.

Do not issue an undefend order to units in transport with AutoEvents, or pause units while they are in transport.
The AIDS equivalent is Transport, which has the limitation of not moving a unit whilst in transport.

Now for my personal opinion:
I made AIDS for AIDS structs. I use AIDS structs for everything.
AIDS structs are all I need.
They do not use a struct allocator/deallocator every time a unit enters/leaves the map.

 

[BlackRose]

I made AIDS for AIDS structs. I use AIDS structs for everything.
AIDS structs are all I need.

If you didn't know that it was a wc3 system, you'd go wtf. Lolz.

AIDS [del]structs[/del] are all I need.

 

[Bribe]

I didn't spot the keyword "Reincarnate" or "Resurrect" in the AIDS struct. Is there functionality to recognize that event or would I have to program that myself, if I were to switch over to AIDS?

 

[kingkingyyk3]

I didn't spot the keyword "Reincarnate" or "Resurrect" in the AIDS struct. Is there functionality to recognize that event or would I have to program that myself, if I were to switch over to AIDS?
Actually for those event(are made for AutoEvents), you can trigger them by yourself.

 

[Tyrande_ma3x]

Systems should not be chosen by their popularity among some websites but by their usefulness to you. If you feel AIDS is what you need, go ahead and use AIDS. The same applies for the other sys.

 

[Bribe]

I was leaning towards popularity to that the users won't have to sacrifice for, say, AutoIndex, when their map has AIDS.

I currently have a fully-functional system going now, the biggest update to the "time warp" library I've ever made (now known as Retro):

http://www.thehelper.net/forums/showthread.php?p=1242137

 

[Tyrande_ma3x]

AutoIndex can use a hashtable instead of UnitUserData and thus they won't interfere with each other.
Speaking of popularity, now I see that you're a system maker so, yeah, it has been said above - AutoIndex is more popular at wc3c.net and AIDS is popular here. As a sys maker you'll have to make a compromise and probably have 2 versions of your scripts (if you want to post them on both sites).

 

[Nestharus]

You can also use my newly released Unit Indexer: http://www.thehelper.net/forums/forumdisplay.php?f=131

It includes complete APIs for the other indexing systems (AutoIndex API was a pain..), so you wouldn't have to change your code (you could make it a bit more efficient). The only prob is that it has the same issue with not being able to get the unit before it goes out of scope like AIDS : (. I'm still trying to figure out how to do it, but multiple undefends are a living hell /cry. Oh yea, and you can have AutoEvent in the map and it won't throw syntax errors because I really meant that it has every public method, operator, and field you can get for each of the systems (except it excludes the public functions that you aren't supposed to be using in AIDS, the ones with AIDS_ before them).

This also does not have struct locking because I didn't see too much of a purpose to it. I felt that the overhead didn't justify the feature since you should be cleaning up your data as soon as the unit goes out of scope : |.

It also includes event add ons like AutoIndex, which are Resurrect, Animate Dead, and Death. The reason they are there is because they are best done inside of an indexing system : D.

I can do things like reincarnate as well, but those can be coded completely separately.

I'm also planning to support the AutoEvent API for use with Unit Indexer : P.

Oh yea, and until I make the AutoEvent API for use with Unit Indexer, the 3 events i mentioned above won't run for it. Don't worry, I'm getting there ; o.


edit
Unit Indexer can now access units before they go out of scope (on remove, on decay, on explode)

edit 2
Oh and performance wise...

AutoIndex is by far the worst because it evaluates a lot of triggers rather than using triggerconditions and evaluating one trigger. It's speed would be about half the speed of AIDS and Unit Indexer.

Between Unit Indexer and AIDS, I'm not sure at the moment... AIDS has the overhead of locks and uses a timer to determine when a unit goes out of scope. Unit Indexer has the overhead of a couple of extra array sets + timestamps. It uses the timestamps to determine when a unit goes out of scope.

 

[Jesus4Lyf]

I'd like to note Nestharus is talking crap, and I don't recommend you use a system which is not yet approved, as it may not be stable.

PS. @Nestharus: Grim conducted benchmarks. You made a bunch of assumptions and stated them as fact. Please, stop it. You do this always.

 

[kingkingyyk3]

As long as the system does not cause lag and bug, it is good to use with, IMO.

 

[Jesus4Lyf]

Nestharus' code looks like it would fail recursively. So that's out on the "bugs" criteria.

I also fully agree.

 

[Nestharus]

PS. @Nestharus: Grim conducted benchmarks. You made a bunch of assumptions and stated them as fact. Please, stop it. You do this always.

not at all assumption -.-...

Actually, AutoIndex runs through a loop of trigger evaluations (vJASS evaluations, which was like 17 ms compared to 11 ms? pulling these numbers from a thread I saw over a year ago on wc3c when they were benched, so I might be a little off) and a group of triggerconditions on one trigger evaluation is much faster.

The ratio, if I remember correctly from my tests a very long time ago, was about trigger evaluations * 2 - 1 : triggerconditions, but again that was a very long time ago so that ratio might be a little off. vJASS evaluations will ofc be worse =).

I haven't been able to get RtC to run lately, so no way for me to bench it again.

edit

Nestharus' code looks like it would fail recursively. So that's out on the "bugs" criteria.

And btw, when it came to indexing/deindexing and all of the add on events, I tested very thoroughly and it has no bugs for the events -.-... Unit Indexer uses time stamps and state booleans, so everything runs just as it should.

I also made sure to use units with multiple defend abilities, tried to remove units multiple times, etc.

edit
Oh yea and I will recommend w/e system I damn well please. If I like it, I'll recommend it.

I've recommended graveyarded systems before as well.

 

[Jesus4Lyf]

Back on topic, please. Happy to continue that discussion in that system's thread.

 

[Bribe]

When I'm done making some tactical adjustments, I'll copy the system so it uses AIDS, as I have come across some weird events with AutoIndex (huge lag when I called RemoveUnit, hence the use of ExplodeUnit, which may be more efficient anyway).

 

[Nestharus]

The huge lag came from the hooks (RemoveUnit and ReplaceUnitBJ were both hooked).