The first handle index

08-02-2006, 01:25 PM

In a map with no custom sounds/ preplaced units, the first handle ever created is in InitBlizzard

JASS:

function InitBlizzardGlobals takes nothing returns nothing
    local integer index
    local integer userControlledPlayers
    local version v

    // Init filter function vars
    set filterIssueHauntOrderAtLocBJ = Filter(function IssueHauntOrderAtLocBJFilter)

So I made a trigger to show I2S(H2I(filterIssueHauntOrderAtLocBJ))

The result is 1048600 (0x100018), that's a very random number, it is not even a power of 2.

08-02-2006, 01:39 PM	#2
Captain Griffen	What about those handles in common.j and blizzard.j?

08-02-2006, 01:40 PM	#3
shadow1500	That is in Blizzard.j. common.j shouldn't create any new handles by itself. If you want to test put set udg_SomeInt = H2I(Location(0,0)) at the first line in config.

08-03-2006, 12:02 AM	#4
PipeDream	The first handle is 0x100000. Probably players or something else take up the first 18. There's a comparison to check that the number is >= 0x100000 before every function that messes with handles.

08-03-2006, 12:27 AM	#5
Vexorian	there are 16 players in total the things after 0x100000 are 24 , also I wouldn't think players are created besides their indexes are 0 to 15. If nothing else is called then these 24 handles should be secret ones or something , cause the first call that seems to create a handle is that Filter(function IssueHauntOrderAtLocBJFilter) one

08-03-2006, 01:02 AM	#6
PipeDream	BTW whenever I checked first handle created once game begins I would get 0x10000C (12). Also players are in the normal handle range but I don't remember where. Edit: Nevermind, it was 0x10005C to below: No, I mean once the loading is finished and the players begin playing. Not relevant.

08-03-2006, 02:59 AM	#7
Vexorian	I could swear H2I(Player(1)) returned 1 although I don't now. 0x10005C and 0x100018 are wide different results, so you should show your tests. If It really was 0x10000C it still wouldn't have any sense cause there are 16 players.

08-03-2006, 01:01 PM

PitzerMike

The config function gets executed way before main and InitBlizzard. So I would suggest that the missing 24 handles are getting allocated there by functions like Player(0), ConvertPlayerColor(0) and the like. If those are implemented as singletons that would make sense. In that case the number of handles would however increase from 24 in a map with more player slots.

JASS:

globals
   trigger udg_t = CreateTrigger()
endglobals

Also a global declaration like above would be executed before main and increase the handle count.

08-03-2006, 07:36 PM	#9
Vexorian	The map had no preplaced units, no rects, no items, nothing. No globals that created handle in their initialization either. And config did not seem to create any handle. Players have indexes from 0 to 15 , the same with playercolor and all the handles that act as just arguments, they seem to just be integers with the handle disguise to prevent weird values to be used in the functions.

08-03-2006, 11:01 PM

#10

PitzerMike

From blizzard.j

JASS:

    timer              bj_volumeGroupsTimer        = CreateTimer()
    timer              bj_queuedExecTimeoutTimer   = CreateTimer()
    group              bj_suspendDecayFleshGroup   = CreateGroup()
    group              bj_suspendDecayBoneGroup    = CreateGroup()
    timer              bj_delayedSuspendDecayTimer = CreateTimer()
    group              bj_lastCreatedGroup         = CreateGroup()
    timer              bj_lastStartedTimer         = CreateTimer()

That's 7.

08-03-2006, 11:03 PM	#11
Vexorian	crap for got them, still 7 vs. 24 where are the other 17 ? , then volumeGroupsTimer should have the first index

08-04-2006, 01:16 PM	#12
Vexorian	New test shows that it is bj_volumeGroupsTimer 1048577 (0x100001) makes sense, 0x100000 is probably null. Although H2I(null) returns 0

08-04-2006, 01:58 PM

#13

blu_da_noob

If 0x100000 is null, it is conceivable that the next 23 before the first one you checked are taken up by those 7 that Mike found plus the 16 players.

Edit: Just tested. It (mostly) makes sense. Those 7 from BJ make up 1048577 - 1048583 (assumed, not tested). These are my results for player handle values:
Player(0) - 1048584
Player(1) - 1048588
Player(2) - 1048589
Player(3) - 1048590
Player(4) - 1048591
Player(5) - 1048592
Player(6) - 1048593
Player(7) - 1048594
Player(8) - 1048595
Player(9) - 1048596
Player(10) - 1048597
Player(11) - 1048598
Player(12) - 1048599
Player(13) - 1048587
Player(14) - 1048622
Player(15) - 1048624

Meaning that 14 of the 16 players take up slots in the next range of 16, but 1048585 and 1048586 are skipped.

08-05-2006, 04:07 PM	#14
Vexorian	The first one used by a map is 1048666 or 0x10005C

08-05-2006, 04:36 PM	#15
vile	I truly dont understand what the hell you guys are talking about, but I have a question. Can you understand what causes a crash through an error log? it has those numbers you mentioned. Or am I just being dumb..