[vJASS] Quick question about forGroup

[dardas]

I gotta know.. does forGroup remove every unit that is used inside?
because when i do this:

set capGroup = GetUnitsOfTypeIdAll('hwtw') 
call ForGroup(nodeGroup, function nodeGroupSetupLoop)

and then in a loop do this:

call BJDebugMsg(I2S(CountUnitsInGroup(nodeGroup)))
call ForGroup(nodeGroup, function nodeGroupLoop)

i get spam of "0".. and yeah, it does run on initialization (the first code),
because its not the entire thing.. the other thing are just debug messages..

 

[Troll-Brain]

No ForGroup doesn't remove units, as long you don't ask it in the callback function.

You probably doesn't enum units at all, or you are destroying the group somewhere, or even use a GroupEnum.

Your lines of code by themselves are not enough, we miss a part of the code.

Also make sure you don't use the custom script set bj_wantDestroyGroup = true.
If it still not fixed in the new patch (which is probably the case) it doesn't work very well with GroupEnumUnitOfType, because of the lame gui functions.
It will enumerate units of player red ( Player(0) ) and then will destroy the group and have a group leak or something like that (have to check these functions to remember it exactly).
I'm just sure it will enum only Player(0) 's units.

 

[dardas]

btw.. i didnt fix any leaks to this point.. lol
not heavy 1's atleast, and no, i dont use bj_wantdestroygroup.
and well.. i did this:

    public function stackEnumoration takes integer data, string messageKey returns nothing
        if messageKey == "nodeID" then
            set capGroup = GetUnitsOfTypeIdAll('hwtw') 
            //to be honest, the forGroup i thought was buggy was here..
            // but removed it, cuz it wasnt needed, found a way to make it easier for me ;p (removed a part of the code which was defintly unneeded)
        endif
        if messageKey == "capSpeed" then
            set captureSpeed[GetHandleId(GetEnumUnit())] = data
        endif
        if messageKey == "unitID" then
            set capturingUnitID[GetHandleId(GetEnumUnit())] = data
        endif
    endfunction
    
    public function nodeGroupLoop takes nothing returns nothing
        call BJDebugMsg("Another Test")
    endfunction
    
    public function loopHandler takes nothing returns nothing
        //call BJDebugMsg(I2S(CountUnitsInGroup(nodeGroup)))
        call ForGroup(nodeGroup, function nodeGroupLoop)
    endfunction
    
    private function onInit takes nothing returns nothing
        set captureSpeed = iStack.create()
        set percentsTaken = iStack.create()
        set capturingUnitID = iStack.create()
        call TimerStart(CreateTimer(), 0.032, true, function loopHandler)
        
        call nodeData.stackData.enumorate(stackEnumoration, false)
    endfunction

those are the functions who serve the group functions.
btw, stackEnumoration is a function interfance,
and stackData is just.. well stack [my version of it]

Edit2: just realisd the stack enumoration GetEnumUnit, gonna fix it

 

[Troll-Brain]

set capGroup = GetUnitsOfTypeIdAll('hwtw') 

public function loopHandler takes nothing returns nothing
    //call BJDebugMsg(I2S(CountUnitsInGroup(nodeGroup)))
    call ForGroup(nodeGroup, function nodeGroupLoop)
endfunction

As long you don't set them to the same group (set groupA = groupB will be done by reference not by value, which means it will be the same group) :

capGroup != nodeGroup != nodeGroupLoop

 

[dardas]

Thank's it worked =]
i did capGroup = instead of nodeGroup =

 

[Dr Super Good]

Do keep in mind how groups work.

Create group -> fill group -> use group.

Natives which add units to the group such as all units of player and all units in area do not create a group and need a pre created group passed to them to fill. This level was obscured by GUI which ruined a major optimization potential. It is recommened to recycle groups as much as possible and in a lot of cases a global constant group could be used instead of a locally created group for instantly computed functions (logically you load it into a local if you plan to use it extensivly). You can also recycle groups just like timers.

 

[Bribe]

The best of the best of global groups is bj_lastCreatedGroup. Never gets destroyed, perfect for one-shot enumerations.

 

[Troll-Brain]

The best of the best of global groups is bj_lastCreatedGroup. Never gets destroyed, perfect for one-shot enumerations.

Perfect if you don't use gui at all (at least with groups), including of course the gui functions used in jass (blizzard.j).

One constant group is not to much a burden, plus i hate typing bj_lastCreatedGroup.

At least that is definitely a bad idea to use it in a public resource.

 

[Bribe]

For the most part, it will only fail if GUI is referencing (Last created group) after a wait, in which case the user deserves the error.

 

[Troll-Brain]

For the most part, it will only fail if GUI is referencing (Last created group) after a wait, in which case the user deserves the error.

And for the rest ?

 

[Bribe]

The rest: if some kind of event fires off in the meanwhile which triggers another system using it, before using (Last created group)

 

[Troll-Brain]

I just wanted to mean that is not a good idea for a public resource that's all.
Now if you are happy with this ugly name instead of using your own, i would be silly to have something about it.
Personnaly i still hate the variable name even if i'm agree with your points.

 

[Dr Super Good]

Variable space and code has a very low cost of only RAM. It is far more important to get the code to execute as fast as possible rather than make everything as neat as possible.

In some cases, doing stuff like loop unwinding could be better than a nice neat loop for example as yes it makes more code but it means less computations needed (as loops have an overhead). There is dimishing returns though as if you make too much code that it can no longer fit it all in cache, it will slow down as cache faults occur.

 

[Troll-Brain]

if you make too much code that it can no longer fit it all in cache, it will slow down as cache faults occur.

And how can we know if we have reach this limit, or better, when will we ?

 

[Dr Super Good]

Yeh but you see, that is the hard part. Different processor models have different sizes of cache and the WC3 game engine and its data also has to fit inside the cache.

Thus there is no real way.

 

[Troll-Brain]

I expected a such answer
Anyway it's not likely i would reach this limit ever which would mean finish a map

Thx.

 

[Dr Super Good]

You reach the limit all the time.

Even really modern processors like the lattest core I7 have only 16 MB cache or so and those are really expensive. The average processor WC3 was made for was sub 1 MB cache. Some laptop processors have cache in the order of hundreds of kilobytes.

A cache miss only causes a memory access which is 10-100 (depending on age of system) slower than if it was in cache. It is pointless even trying to factor in cache as like I said, it can vary greatly between systems. The only real time it could be considered is if you unwind a 1000000 itteration loop (only possible in programming languages) but in WC3 its existance is near meaningless. I should not have mentioned it come to think of it.