[vJASS] FirstOfGroup Question

[BPower]

Assuming that there are three units A, B and C in Group g

Will unit A always be FirstOfGroup g on any GroupEnumUnitsInRange?

Or is it random, which of the three units is first?

 

[Spartipilo]

Why don't you test it? Create units and a floating text above them with their Index (based on group enum), and repeat process several times (moving the units) to see if the same unit gets the same index, or if they're indexed in the group based on distance from the center or some other logic.

 

[FUJI]

I think it is starting from the nearest unit in the desired range/radius/area of GroupEnumUnitsInRange.

 

[Maker]

It is not random.

 

[Spartipilo]

Tested with Paladins and Peons, using the following script:

globals
    group Group = CreateGroup()
    hashtable GroupHash = InitHashtable()
endglobals

function Trig_Untitled_Trigger_001_Actions takes nothing returns nothing
    local unit u
    local integer i = 1
    local texttag t
    local integer id
    
    call GroupEnumUnitsInRange(Group, 0, 0, 1000, null)
    loop
        set u = FirstOfGroup(Group)
        exitwhen u == null
        set id = GetHandleId(u)
        call DestroyTextTag(LoadTextTagHandle(GroupHash, id, 0))
        set t = CreateTextTagUnitBJ( I2S(i), u, 0, 10, 100, 100, 100, 0 )
        call SaveTextTagHandle(GroupHash, GetHandleId(u), 0, t)
        set i = i+1
        call GroupRemoveUnit(Group, u)
    endloop
endfunction

- Heroes are indexed first, Peons were indexed later.

- Units were indexed in the same order they where created. X, Y, and distance from the center of the group enum doesn't matter.

- Units that went off the enum range just reduced the index of the units inside range by 1, but keeping the creation order.

- When units outside the range came inside, they took again their initial index, based on the creation order.

EDIT: Added some Footmans: - Footmans were indexed after Peons.

EDIT: Added some Human Sorceress: - These were indexing after peons and before footmans.

EDIT: Added some Human Snipers and Dragonhaw: - Snipers were indexed after Sorceress and Before Footmans. Dragonhaw Riders were indexed lastly, after Footman.

I speak about the order, because they where not created in that order. They were being indexed or selected as "First of Group" based on Unit Type (or Unit Level or some other thing in the Object Editor or internal game behavior) and lastly on the Creation Order.

So far: Heroes > Workers > Sorceress > Snipers > Footman > Dragonhawk Riders

EDIT: Moved Dragonhaws: Moved the dragons around and they were getting different indexes based on... something. They were always indexed after heroes, but the distance or angle had some effect. Moving on the Y axis had no effect. The Unit kept it's index. But moving on the X axis had some effects. The Index was lower as X was lower (or higher if it was negative)

EDIT: Changed Order
Created Paladins (Diagonals), Peons (X+), Footmans (X-), Sorceress(Y+), Rifleman(Y-), and Dragonhaw(0,0). Now the index order was Heroes, Rifleman, Footman, DragonHawk, Workers, and Sorceress, starting from the center. Moved the heroes, and the one with the higher X was being indexed first.

The only conclussion i can came up with is that Heroes with higher X-axis value are the FirstOfGroup(). Never found a Y-axis effect on them. After that, the rest of the units are indexed following some relation with X/Y, distance from the center, and unit type (Unit Priority and Unit level apparently had no effect at all) and the order the unit was created (The unit Handle ID)

 

[muzzel]

These things are, as Maker said, not random but also not defined. "Not defined" means that you can only guess the behaviour and therefore not rely on it.

If you really need to be sure about the order trigger it yourself...

To clarify: in general it is very bad style to use/abuse things that are not defined in a languages specification but for some reason work. These things may be unreliable and even change in future versions and the readability of your code decreases.

 

[Spartipilo]

There's an advantage on all This.

Heroes are always indexed first, so if you want to do GroupEnumUnitsInRange() and just enum the heroes, you can check when the FirstOfGroup != Hero to stop the loop.

 

[BPower]

Another question just came up.

Scenario

                        call GroupEnumUnitsInRange(bj_lastCreatedGroup, x, y, range, null)
                        loop
                            set u = FirstOfGroup(bj_lastCreatedGroup)
                            exitwhen u == null
                            call GroupRemoveUnit(bj_lastCreatedGroup, u)
            
                            if Filter(u) then
                                set target = u
                                set u = null
                            endif
                            exitwhen u == null
                        endloop

This will exit the loop in many case, before all units are removed from the group. Do i have to:

call GroupClear(bj_lastCreatedGroup)

or is it nescessary to create a group g instead of of using bj_lastCreatedGroup?

And thanks to Spartipilo for your answer. Really helpfull

 

[Spartipilo]

GroupEnumUnitsInRange clears the group by default before doing the enum, so, you're good there. No need to clear.

bj_lastCreatedGroup is just a default Wc3 global group (as it has predefined globals for almost everything). You're good with it since it saves you from constantly creating local groups "g", or creating your own global.... ofc, only for instant stuff

 

[chobibo]

bj_lastCreatedGroup is just a default Wc3 global group (as it has predefined globals for almost everything). You're good with it since it saves you from constantly creating local groups "g", or creating your own global.... ofc, only for instant stuff

Nope, that variable just stores the last created group handle* by the user.