[System] Dummy

[Fingolfin]

I was not refering to your particular indexer, it is fine. I just don't need ALL the units on my map to be indexed just to be able to use a few dummies. I hate throwing code on stuff i don't need, like i said, it just turns into overhead. I think this system could easily be made witout an indexer.

 

[PurgeandFire]

@Fingolfin:

It can be done without an indexer, but the indexer allows you to achieve O(1) without using a hashtable.

Theoretically, you could just do this:

library Loldex initializer Init 
    globals
        private constant integer DUMMY_ID = 'n000'
        private integer index = 1
    endglobals
    private function IndexDummy takes nothing returns boolean
        local unit f = GetFilterUnit()
        if GetUnitTypeId(f) == DUMMY_ID then
            call SetUnitUserData(f, index)
            set index = index + 1
        endif
        set f = null
        return false 
    endfunction
    private function Init takes nothing returns nothing 
        local trigger t = CreateTrigger()
        local region  r = CreateRegion()
        local rect    z = GetWorldBounds()
        call RegionAddRect(r, z)
        call RemoveRect(z)
        call TriggerRegisterEnterRegion(t, r, Condition(function IndexDummy))
        set z = null
    endfunction
endlibrary

And it would work. I don't really recommend it (because I don't think using a unit indexer adds too much overhead), but if the only indexes you need are for dummies for this system, then go for it (no deindex is needed because this system recycles them anyway).

 

[Luorax]

It is just stupid overhead code, and i have never found myself in need of one ever.

Well, they're really, really damn useful. Usually you could get away without using them, that's true, but you couldn't make it so that only an array read is required. Not to mention how easy it is to work with integers.

 

[Nestharus]

Not using a unit indexer adds more overhead than using an indexer.

You can use something like PUI if you want, which is just IndexUnit and DeindexUnit (you call them)

 

[Fingolfin]

It really depends on the situation. In my case, i have an sfx struct for creating special effects with custom height and orientation. I then iterate through the structs using a linked list and update their ages etc (there is only one single timer for updating the decay of all effects). I never iterate through more units than i have to, so the O(n) factor is really not an issue. I would just love it if there was a system that just saved the dummies in some kind of stack, where you could deposit or extract them, which also considered their facing.

I agree that an indexer can be a faster substitute for hash tables if you have a lot of units you need to keep track on though, but this is rarely the case in my maps, i often only have to attach data to a very small percentage of the units. In all other cases, the unit is attached to the data instead (as the member of a struct) where i don't need to find the struct from the unit recursively.

 

[Nestharus]

Huh, so you want dummies that you can iterate over? You don't care about accessing them from the units, you just want like a list of dummies?

 

[Fingolfin]

Yeah, that's right! Where i can just withdraw or deposit them based on angle.

 

[Nestharus]

Hm... well, if you get rid of all of the SetUnitUserData stuff and GetUnitUserData stuff, this'll be close, but you can add them to your own collection for iterating I suppose.