Wc3C.net

Wc3C.net (http://www.wc3c.net/forums.php)
-   Scripts (http://www.wc3c.net/forumdisplay.php?f=737)
-   -   AutoIndex (http://www.wc3c.net/showthread.php?t=105643)

grim001 04-24-2009 07:23 PM

AutoIndex
 
Optional add-on library: AutoEvents

AutoIndex is a very simple script to utilize. Just call GetUnitId(unit) to get get the unique value assigned to a particular unit. The GetUnitId function is extremely fast because it inlines directly to a GetUnitUserData call. AutoIndex automatically assigns an ID to each unit as it enters the map, and instantly frees that ID as the unit leaves the map. Detection of leaving units is accomplished in constant time without a periodic scan.

AutoIndex uses UnitUserData by default. If something else in your map would conflict with that, you can set the UseUnitUserData configuration constant to false, and a hashtable will be used instead. Note that hashtables are about 60% slower.

If you turn on debug mode, AutoIndex will be able to display several helpful error messages. The following issues will be detected:
  • Passing a removed or decayed unit to GetUnitId
  • Code outside of AutoIndex has overwritten a unit's UserData value.
  • GetUnitId was used on a filtered unit (a unit you don't want indexed).

AutoIndex provides events upon indexing or deindexing units. This effectively allows you to notice when units enter or leave the game. Also included are the AutoData, AutoCreate, and AutoDestroy modules, which allow you to fully utilize AutoIndex's enter/leave detection capabilities in conjunction with your structs.

Expand JASS:

moyack 04-24-2009 07:41 PM

Lol, your comments are longer that the code itself.... that's what I call a good code. Seriously. :)

akolyt0r 04-24-2009 07:59 PM

CON: you can only have 8190 units totally in your map, with regular unit-indexing, you can have 8190 indexed units in your map.

This will for example index dummy units aswell, and if you got really many triggered spells in a 12 player map with lots of units/heros/whatsoever this might hit the limit...

maybe this system shouldnt index dummy units (+= one dummy unitid constant ..), dunno...
I would add this as an optional condition ...

grim001 04-24-2009 08:00 PM

CON: Warcraft 3 crashed a long time before you had 8000 units in your map.

Magissia 04-25-2009 02:32 AM

2 Attachment(s)
In this map (look attachments)

A trigger spawn 8000 footmans, my computer don't crashed, just had some strange polys' that go away

So the game don't crash before 8000 units please

akolyt0r 04-25-2009 03:08 AM

1 Attachment(s)
no problem to have 8000 dummy units ...

grim001 04-25-2009 03:13 AM

The answer is: no.

dead_or_alivex 04-25-2009 03:14 AM

^ His point was that most maps don't reach the limit so easily. In any case, couldn't struct storage space simply be increased to handle more than 8190 units? (Edit: Oops, posted a bit late. I was responding to Magissia.)

Amazingly concise for something so elaborate - great job.

Quote:

I am tired of the issues associated with H2I(u)-0x100000
What issues are these? (I use that method quite a bit.)

grim001 04-25-2009 03:35 AM

Increasing storage space would have no effect on performance except when allocating or freeing an ID. All you would have to do is add [size] next to the AutoIndex struct declaration. So it would be a great idea, except that no real map has ever, or will ever, be created that uses more than 8000 units at the same time. I'm not going to respond to any more stuff about that since it is so outlandish that it doesn't warrant discussion.

dead_or_alivex, before this I used H2I(u)-0x100000 all the time, so I think it is the next best option. But here are the downsides compared to automatic unit indexing:
1.) It is slower.
2.) It is possible to break it if handles get too high (rarely a problem in practice)
3.) It forces you to type a lot of code in every system (arrays, set/get functions, MaxHandles constant).
4.) It generates even mode code once compiled because of bigarrays.
5.) You are obligated to include a note explaining how the user should deal with the MaxHandles constant in every system.

Captain Griffen 04-25-2009 11:45 AM

If you're using 8000 units in a map, you're doing it wrong.

Anyway...I think you should have a GetUnitId function. It'll get inlined, but it'll make it far more implementation independant, and make systems much more interoperable (which, given you can only have one unit indexing system in a map using GetUnitUserData...is incredibly important). Not using a wrapper function because you think it's cooler really doesn't cut it now that they have no performance hit and provide potentially important forward/backward compatability.

Vexorian 04-25-2009 03:05 PM

Quote:

2.) It is possible to break it if handles get too high (rarely a problem in practice)
Not that rare.

It requires a very messed up map, but for some reason those maps are not rare.

Like Griffen said, Make a GetUnit**** function thingy. Guys wanting speed can make it dependent on the UserData implementation (Err, not really, it'll get inlined) but if there was a GetUnit*** function you wouldn't have to make it dependent.

You can make an AutoIndex that uses handle table, Table's only problem was the lack of auto destruction, this effectively fixes it . People that already use UserData in one of those zillion other systems could just use the Table version if they had to implement a system/spell requiring it. The rest, would still see the UserData native inlined anyway. Sounds like win-win to me...

Quote:

Increasing storage space would have no effect on performance except when allocating or freeing an ID.
In order to actually be able to use the index, you would need to also enlarge the arrays to which this is used as index.

Could just have an exceptions list/hash for typeids - assuming this problem is actually important.

Mr.Malte 04-25-2009 04:59 PM

I think it could make some maps really slower.
In my map for example, I've got a spell which creates 45 units per second.
If you implement this library, that spell would lag, wouldn't it.
Also if you don't use this a lot, it could be slower than other systems. Anyways, I am gonna do speed tests with this.

Vexorian 04-25-2009 05:21 PM

Quote:

I think it could make some maps really slower.
In my map for example, I've got a spell which creates 45 units per second.
If you implement this library, that spell would lag, wouldn't it.
no?

Quote:

Also if you don't use this a lot, it could be slower than other systems. .

???

Mr.Malte 04-25-2009 05:49 PM

Ok. Then I'll test this.
This seems great.

grim001 04-25-2009 07:04 PM

Quote:

Originally Posted by Captain Griffen
I think you should have a GetUnitId function.

Done.

Quote:

Originally Posted by Vexorian
You can make an AutoIndex that uses handle table

Pretty good idea, handle table would not have been possible if you are relying on the UnitUserData becomes 0 trick for removal detection, but with this, any storage method is possible.

So I'll make it as soon as you make Table initialize its gamecache in a struct init, otherwise it would fail on every unit entering the map or created from a a unitEntersMap method.

Quote:

Originally Posted by Mr.Malte
I think it could make some maps really slower.
In my map for example, I've got a spell which creates 45 units per second.

Seriously, creasing 45 units per second will lag your map. If you need to do something like that, you should recycle those units. Indexing an entering unit is like 0.001% of the cost of actually creating a unit.


All times are GMT. The time now is 10:34 PM.

Powered by vBulletin (Copyright ©2000 - 2019, Jelsoft Enterprises Ltd).
Hosted by www.OICcam.com
IT Support and Services provided by Executive IT Services