[1.10] ptUnit and ptGame structures

[Hammerman]

I just came home from a vacation and guess what: 1.10 beta is out! So, a look at the new ptUnit and ptGame structures was a good start. This is only a small portion of it ofcourse, since I haven't had much time with the new patch. Some elements of the two structures are probably the same as in 1.09, but these are the ones I have confirmed.

Oh and the ptUnit list is only confirmed for players, since I only looked at the ptUnit generation for type 0 (ie players).

Code: Select all

ptUnit

+00	unit type
+04	unit id
+08	ptGame+1C
+0C	unit unid
+10	Current animation mode 
+14	ptUnitData (was at +70)
+18	act
+1C	ptAct
+20	Seed (Low) 
+24	Seed (High) 
+28	Starting LowSeed
+2C	hPath (no internal changes?)
	+1C = hRoom
+3C          Animspeed (DWORD)
+38	ptPos (hPath Structure)
+44          Current Frame the animation is (aka Frame counter)
+48	Remaining Frame
+4C	Animation Speed(Word)
+4E          Action Flag (Byte) 
+50	AnimData.D2 record address for current mode
+5C	ptStatsList
	+24h = ptStats[Param]   [color=#5f5f5f]Param = [ItemStatCost].[SendParams][/color]
		+00h = iStatIndex[0]
		+02h = iStatID[0]
		+04h = iStatValue[0]
		+08h = iStatIndex[1]
		+0Ah = iStatID[1]
		+0Ch = iStatValue[1]
		+xxh = iStatIndex[X]
		+xxh = iStatID[X]
		+xxh = iStatValue[X]
	+28h = iStatCount
	+2Ah = iStatCount again?
+60	ptInventory
	+00 = 1020304
	+04 = ptGame+1c
	+08 = ptUnit
	+24 = unit unid
+74	0 at start, gets MemoryPool ptr at times
+80	ptGame
+94	originator ptUnit type (ptUnit+00) (missiles use this)
+98	originator ptUnit unID (ptUnit+0C) (missiles use this)
+A8	ptInfo
	+00 = ptGame+1c
+AC	Combat data
+B8	ItemCode for an item being dropped by this unit
+C4	flags
	0010 = spawning
	players
		0E = inventory/skill spawning 
+C8	flags
	2000000 = lod
+D0	client # (0B at start)

Code: Select all

ptPlayerData Structure

+00	Player Name (0x10 Bytes)
+10 = normal quest ptr
   +00 = ptBuffer 
   +04 = 60h * 2^3, 768 
+14 = nightmare quest ptr 
   +00 = ptBuffer 
   +04 = 60h * 2^3, 768 
+18 = hell quest ptr 
   +00 = ptBuffer 
   +04 = 60h * 2^3, 768 
+1c = normal waypoint ptr 
   +00 = flags 
+20 = nightmare waypoint ptr 
   +00 = flags 
+24 = hell waypoint ptr 
   +00 = flags 
+34 = ptArenaUnit
+48 Object Unique_ID
+9C	ptClient

Details on quests and waypoints structures at these links.

Details on stat list structures and functions at this link.

Code: Select all

ptItemData Structure

+00	quality
+14	cmdFlags
+18	flags
		0000 0001 - ITEMFLAG_NEWITEM  
		0000 0004 - ITEMFLAG_TARGETING 
		0000 0010 - ITEMFLAG_IS_IDENTIFIED 
		0000 0020 - ITEMFLAG_QUANTITY 
		0000 0100 - ITEMFLAG_DURABILITY 
		0000 0800 - ITEMFLAG_SOCKETED 
		0000 1000 - ITEMFLAG_NON_SELLABLE 
		0000 2000 - ITEMFLAG_NEWITEM2 
		0001 0000 - ITEMFLAG_CHECKSECPRICE 
		0002 0000 - ITEMFLAG_CHECKGAMBLEPRICE 
		0040 0000 - ITEMFLAG_ETHEREAL 
		0100 0000 - ITEMFLAG_FROMPLAYER 
		0400 0000 - ITEMFLAG_RUNEWORD 
		8000 0000 - ? (always set for items, do not use)
+28	PlayerClass (What class requirement this item has)
+2C          ilvl
+45	StorePage (BYTE)
+5C	ptNode
	+0C = Page

Code: Select all

ptInventory Structure

+00 nIdentifier (1020304)
+08 ptUnit
+24 Unit unid
+28 Socket_Counter
+34 ptCorpse
+3C next ptCorpse Unique_id

Code: Select all

PtGame

+0018	_ptLock (8 bytes, unknown what it's used for)
+001C	MemoryPool 
	+00	ptQuestInfo
	+04	ptUnit+74 of locking unit (forms a linked list?)
+006A	Game type? (3 = realm?)
+006D	Difficulty (0,1 or 2)
+0070	Lod(1) or D2c(0)
+0088	*ptClientLastJoined
+0090	# of players spawned counter 
+0094	# of monsters spawned counter 
+0098	# of objects spawned counter 
+009C	# of missiles spawned counter 
+00A0	# of items spawned counter 
+00A4	# of tiles spawned counter 
+00A8	Current Frame (FrameCounter)
+00D0	low seed
+00D4	high seed
+00D8	ptRoom (act 1) list
+00DC	ptRoom (act 2) list
+00E0	ptRoom (act 3) list
+00E4	ptRoom (act 4) list
+00E8	ptRoom (act 5) list
+00F4
	+300 Ptr for Level with ID0 -->ID132(Levels.txt)
+10F0	shrine random effects list
	+00	low seed
	+04	high seed
	+08	(8) shrine effects codes
	+28	pointers to the (8) effects
+10F4
	+00	last quest in linked list of quests
	+0C
		+00 pHistory (quest) -- 
			20 = completed this game
			80 = completed previous game
+10F8	ptClient list 
+1120	ptUnit (character) list (80h dword) 
+1320	ptUnit (monster) list (80h dword) 
+1520	ptUnit (object) list (80h dword) 
+1720	ptUnit (missile) list (80h dword) item? 
+1920	ptUnit (item) list (80h dword) missile? 
+1B20	ptUnit (tile) list (1 dword) 
+1B24	ptUnit (tile) list (80h dword)
+1D28	ptArena

Code: Select all

ptClient

+004	conn_state (4 == connected) 
+00D	name 
+174	*ptUnit (the player unit this client structure belongs to) 
+4A8	*ptClientPrev (ptClient of previous player unit)

Code: Select all

ptSkill

+00	Pointer to Skills.txt

Code: Select all

ptRoom

+48 Flag (0 = spawn new units, 1 = don't spawn new units)

Not much, but more to come in following days (and hopefully from other members).

The only difference I have noticed in ptGame is that the player spawn count is now at +90, where frame count used to be.

[Myhrginoc]

Here are some more ptUnit(player) locations:

Code: Select all

+10 Current animation mode
+2C hPath (no internal changes?)
  +1C hRoom
+50 AnimData.D2 record address for current mode
+5C ptStats?

ptPlayerInfo still seems to have the same structure as before, at least in the first 48 bytes.

[Sir_General]

More info here.

Code: Select all

005Ch	ptStatList
	0024h	ptStats
		0000h	iStatIndex[0] (WORD)
		0002h	iStatID[0] (WORD)
		0004h	iStatValue[0]
		0008h	iStatIndex[1]
		000Ah	iStatID[1]
		000Ch	iStatValue[1]
		XXXXh	iStatIndex[X]
		XXXXh	iStatID[X]
		XXXXh	iStatValue[X]
	0028h	iStatCount (WORD)
	002Ah	iStatCount again? (WORD)

The number of stats stored in the list has changed. It looks like now it stores all the stats in the ptStats section. When it adds a new stat, it automatically arranges the array to be in order of smallest to largest ID.

EDIT:

Well, it turns out the the WORD there is an index for the stat, which is also what the new param for D2Common 10517, 10518, 10519, and 10521 are. This means that you can save the same stat ID multiple times using different index values.

[afj666]

Here's one i found when searching for the ptClient.

It's located in the ptPlayerData structure:

Code: Select all

+14	ptPlayerData
	+9C	ptClient

[Myrdinn]

Some more info

Code: Select all

PtUnit (Player Monster)
+20    Seed (High)
+24    Seed (Low)

PtGame
+70 Lod(1) or D2c(0) 

Added to top thread by afj666

[mitja]

ptClient
+ 0x4 conn_state (4 == connected)
+ 0xd name
+ 0x174 *ptUnit (the player unit this client structure belongs to)
+ 0x4a8 *ptClientPrev (ptClient of previous player unit)

PtGame
+ 0x88 *ptClientLastJoined

Added to top thread by afj666

[afj666]

Code: Select all

ptGame
+18	_ptLock (Unknown what it's used for)
+6D	Difficulty (0,1 or 2)

Code: Select all

ptSkill
+00	Pointer to Skills.txt

Code: Select all

ptPlayerData
+00	Player Name (0x10 Bytes)	

Code: Select all

ptUnit
+38	ptPos (hPath Structure)

[Myhrginoc]

Some more ptGame locations:

((+10F4)+0C)+00 pHistory (game) -- This is updated when primary goal of quest achieved, for each quest 20 = completed this game and 80 = completed previous game

+10F8 ptClient list
+1124 ptUnit (character) list
+1324 ptUnit (monster) list
+1524 ptUnit (object) list
+1724 ptUnit (missile) list
+1924 ptUnit (item) list
+1B24 ptUnit (tile) list

Added to top thread by afj666

[EviLDreams]

Okey i have now read alot of posts and noticed the name "ptUnits" "ptGame" , etc.. ,etc... Can anyone explain to me what it is? what is it good for, ie what can i do with it? and in what file lies the ptUnits?

[Myhrginoc]

These are all structures used within the game code and found in the DLLs. For example, ptGame is a structure which holds dynamic data about the game in process, such as difficulty, various entities in the current map, and a host of other details. Each entity on or in the map has an associated structure called ptUnit, the list in my previous post has the six types of entities handled this way.

Each structure has an associated pointer for the address at the base of the structure. So if you are looking at some code in this forum that might be annotated ESI = ptUnit, that tells you if you do a memory dump at the location stored in register ESI you should see data arranged in the manner listed in these structure definition threads.

Many entries in these structures are themselves pointers to other structures, such as ptUnit+80 = ptGame.

[Myrdinn]

OkAbout speed Mechanisms

Not sure, this works for all speeds mechanisms. Anyway what i understant about this is

PtUNIT [+48] Remaining Frame for the current Animation (With extraprécision) The famous 256*(Base+1) In fact Base+1="Frames per direction" read in AnimData.D2 (Loaded in memory)256 for the Extraprécision

PtUNIT [+4C] Animation Speed. formula is "Animation Specific"
for FastCast for example it is Animrate*(100+EffectiveFastCast)/100
Animrate read in AnimData.D2
EffectiveFastCast= 120*FastCast/(120+FastCast)
FastHitRecovery uses Animrate*(50+EFHR)/100)
...

Each frame [Ptunit+48]=[PTUNIT+48]-PTUnit[+4C]
You cannot perform new action until Ptunit[+48]=0
PtUnit+3C often hold a copy of AnimationSpeed ???

IT's with extraprécision, it's why in speeds formula (Well for human, the game uses substration) most use RoundUp
Formula is {Animlength/animspeed }-1 with {} mean Round up
it's equivalent to
{256*(Base+1)/[Animrate+(100+[120*FastCast/(120+FastCast)]/100]}-1 for FastCast
[] mean truncature so round down.

Remember that diminishing return use Interger division so you have to truncate this result Animation Speed is also a Integer Division, so another round Down.

[afj666]

Added the above to top post.

I found this when looking into Objects. It appears that when a drop has been determained, the itemcode is place into the ptunit.

Code: Select all

ptUnit
+B8	dwDropItemCode

This doesn't drop the item automaticaly but is used some functions. I dunno if this applies to all units, but it at least works for Objects.

[Jarulf]

Noted an entry that is not mentioned.

hUnit + AC: Combat data

At this offset the game will hold the combat data for the current attack. Actually, it will be a linked list with such combat data. I call it combat data since it holds all the info about an attack. Basically it will be a pointer to a structure and starting at offset +14 in this structure is the "normal" combat data (that is the first two dwords are flags, the next the physical damage and so on). The first 5 dowrds hold info about who attacks who and their modes and the pointer to the next structure. I can give details if anyone is interested. The structure data at +14 an onwards is the one passed arround in all functions dealing with attacks. The first 5 entries is attached when stored away like this when the game awaits the attack to come to the point were the attack blow lands so to speak.

Added to top thread by afj666

[Myrdinn]

Some New Structures

Code: Select all

PtGame +A8 = Current Frame (FrameCounter)
PtGame +F4 --> +300 Ptr for Level with ID0 -->ID132(Levels.txt)

In 1.09 the structure for these pointers was

Code: Select all

+00	Act?
+0c 	-1 at start
+10	 byte, monster count
+11	byte, total rarity
+12	byte, monster count
+14	start of monster list. 2 dwords each, first is populate id, second is rarity
+118	MonDen
+11c  	byte, MonUMin + extra unique monsters
+11d  	byte, MonUMax + extra unique monsters
+11e  	byte, MonWndr
+120	 level ID
+134	-1 at start
+138	byte, Quest

Don't check if it's the same for 1.10


PtUnit

Code: Select all

+20	Low Seed
+24	HighSeed
+28	Starting LowSeed

Sorry i give Low and High Seed in reverse order in my previous post

Added to top thread by afj666

[enjahova]

does anyone know the location of the pNext pointer in the ptUnit struct?
in 1.09 it was +10c, im guessing it would be the last item?

[Myhrginoc]

PtGame +F4 --> +300 Ptr for Level with ID0 -->ID132(Levels.txt)

In 1.09x the hardcoded level limit was 85h, or 133 lines in Levels.txt with IDs 0 through 132. With 1.10 final, this hardcoded limit was bumped up to 400h or 1024 lines in Levels.txt. In ptGame that space was similarly expanded to 4096 bytes (1024 dword pointers). Presumably all the extra levels one might define would yield similar structures to the first 133.

[kingpin]

+1124 ptUnit (character) list
+1324 ptUnit (monster) list
+1524 ptUnit (object) list
+1724 ptUnit (missile) list
+1924 ptUnit (item) list
+1B24 ptUnit (tile) list

This is wrong, found that ptUnit (tile) list is located at +1B20 and think all the others should be the same

EDIT:

Found some new:

Code: Select all

ptGame + d8 ptRoom for act 1 (Point.X + Point.Y)
ptGame + dc ptRoom for act 2 (Point.X + Point.Y)
ptGame + e0 ptRoom for act 3 (Point.X + Point.Y)
ptGame + e4 ptRoom for act 4 (Point.X + Point.Y)
ptGame + e8 ptRoom for act 5 (Point.X + Point.Y)

~ Added to top thread by afj666 ~

[Myhrginoc]

This is an extract where ptGame was at 0220007C. (I have yet to see a ptGame that doesn't start at 0xxxxx7C, btw.)

Players:

Code: Select all

0220119C  00 00 00 00 00 21 5E 02 00 00 00 00 00 00 00 00  .....!^........

Monsters/NPCs:

Code: Select all

0220139C  00 00 00 00 00 A4 DA 02 00 A5 DA 02 00 A6 DA 02  .....¤Ú.¥Ú.¦Ú

Objects:

Code: Select all

0220159C  00 00 00 00 00 A0 DA 02 00 A1 DA 02 00 A2 DA 02  ..... Ú.¡Ú.¢Ú

Items:

Code: Select all

0220179C  00 00 00 00 00 24 5E 02 00 25 5E 02 00 26 5E 02  .....$^.%^.&^

This is a function heavily used in D2Game.dll:

Code: Select all

6FCBBB00   /$  85C9                      TEST ECX,ECX
6FCBBB02   |.  56                        PUSH ESI
6FCBBB03   |.  75 1E                     JNZ SHORT D2Game.6FCBBB23
6FCBBB05   |.  68 C9020000               PUSH 2C9
6FCBBB0A   |.  68 B0EED36F               PUSH D2Game.6FD3EEB0
                 ;  ASCII "C:\projects\D2\head\Diablo2\Source\D2Game\UNIT\SUnit.cpp"
6FCBBB0F   |.  68 48C3D26F               PUSH D2Game.6FD2C348      ;  ASCII "ptGame"
6FCBBB14   |.  E8 D50B0600               CALL <JMP.&Fog.#10023>
6FCBBB19   |.  83C4 0C                   ADD ESP,0C
6FCBBB1C   |.  6A FF                     PUSH -1
6FCBBB1E   |.  E8 CA0C0600               CALL D2Game.6FD1C7ED
6FCBBB23   |>  8B7424 08                 MOV ESI,DWORD PTR SS:[ESP+8]
6FCBBB27   |.  83FA 05                   CMP EDX,5
6FCBBB2A   |.  75 08                     JNZ SHORT D2Game.6FCBBB34
6FCBBB2C   |.  8D81 201B0000             LEA EAX,DWORD PTR DS:[[b]ECX+1B20[/b]]
6FCBBB32   |.  EB 1E                     JMP SHORT D2Game.6FCBBB52
6FCBBB34   |>  85D2                      TEST EDX,EDX
6FCBBB36   |.  7C 18                     JL SHORT D2Game.6FCBBB50
6FCBBB38   |.  83FA 05                   CMP EDX,5
6FCBBB3B   |.  7D 13                     JGE SHORT D2Game.6FCBBB50
6FCBBB3D   |.  8B1495 4493D26F           MOV EDX,DWORD PTR DS:[[b]EDX*4+6FD29344[/b]]
6FCBBB44   |.  8BC6                      MOV EAX,ESI
6FCBBB46   |.  83E0 7F                   AND EAX,7F
6FCBBB49   |.  8D0482                    LEA EAX,DWORD PTR DS:[EDX+EAX*4]
6FCBBB4C   |.  03C1                      ADD EAX,ECX
6FCBBB4E   |.  EB 02                     JMP SHORT D2Game.6FCBBB52
6FCBBB50   |>  33C0                      XOR EAX,EAX
6FCBBB52   |>  8B00                      MOV EAX,DWORD PTR DS:[EAX]
6FCBBB54   |.  85C0                      TEST EAX,EAX
6FCBBB56   |.  74 0F                     JE SHORT D2Game.6FCBBB67
6FCBBB58   |>  3970 0C                   /CMP DWORD PTR DS:[EAX+C],ESI
6FCBBB5B   |.  74 0C                     |JE SHORT D2Game.6FCBBB69
6FCBBB5D   |.  8B80 E4000000             |MOV EAX,DWORD PTR DS:[EAX+E4]
6FCBBB63   |.  85C0                      |TEST EAX,EAX
6FCBBB65   |.^ 75 F1                     \JNZ SHORT D2Game.6FCBBB58
6FCBBB67   |>  33C0                      XOR EAX,EAX
6FCBBB69   |>  5E                        POP ESI
6FCBBB6A   \.  C2 0400                   RETN 4

and the table at 6FD29344:

Code: Select all

6FD29344  20 11 00 00 20 13 00 00 20 15 00 00 20 19 00 00   .. .. .. ..
6FD29354  20 17 00 00                                       ..

The question is, does the game use the null case in Line 6FCBBB49? Otherwise the actual list for each ptUnit type begins at (table offset)+04, which is borne out by the excerpts above.

[Jarulf]

Lets see if we can clear this up

The game has 6 chunks of lists, one for each unit type, there is 128 lists for each type. The lists starts at (copy from my ptGame info):

1120 ptUnit (character) list (80h dword)
1320 ptUnit (monster) list (80h dword)
1520 ptUnit (object) list (80h dword)
1720 ptUnit (missile) list (80h dword) item?
1920 ptUnit (item) list (80h dword) missile?
1b20 ptUnit (tile) list (1 dword)
1b24 ptUnit (tile) list (80h dword)

Now, it seems that for tiles, the game, although adding it, don?t use the 80 lists at +1b24, but instead there is an additional list at +1b20 and that one list is used for all tile units.

In addition, we have the following counters for each unit:

0090 # of players spawned counter
0094 # of monsters spawned counter
0098 # of objects spawned counter
009c # of missiles spawned counter
00a0 # of items spawned counter
00a4 # of tiles spawned counter

These counters are all initialized to 0, but when the game creates a unit, it advances the number by 1 and when it hits max value for a dword (in the 4 billion range) it loops back to 1, not 0. So the first unit of each type will have the counter id 1. Note that one can?t ever have two units of the same counter id, although if we loop arround (should probably not be possible, but if you spawn enough missiles, well, you get the idea). As long as there doesn?t exist an old unit of the same counter id, it works fine though.

Now, when the game creates a unit, it gets the running counter value as the id for that unit type. This value will thus start at 1 and increase for each unit. So what list, of the 128 for each unit type except tiles, is the unit added to? Well, the game takes the value and basically do a mod 128. Thus, the first unit will be added to list 1, the next to list 2 and so on. Hence why you don?t see a unit in list 0. However, as soon as you get to unit 128 added for a type, it will be added to list 0. Unit number 129 will be added to list 1 and so on. Each list is basically a linked list of units (and as we know, the hUnit has at offset +e4 a pointer to the next unit in its list).

Hope this clears up a few missunderstandings.

~ Added to top thread by afj666 ~

[Myhrginoc]

So each type block in ptGame is actually a list of lists? That answers another question I have had for some time: how do you have more items/monsters/objects/tiles than the spaces in each ptGame block?

Thanks for another excellent clarification!

[Jarulf]

[quote=Myhrginoc";p="154387"]So each type block in ptGame is actually a list of lists? That answers another question I have had for some time: how do you have more items/monsters/objects/tiles than the spaces in each ptGame block?

Thanks for another excellent clarification! [/quote]

Yes, it is a list. And the +e4 offset in the hUnit is the way the list is linked. Seems to be a one way linked list though since there is no pointer back to a previous entry.

[kingpin]

This is the structure that ptGame +d8 holds. It contains more unknown info than I have identidy so far.

+0 Point.X
+4 Point.Y
+8 Unit ID
+c Unique ID

I'm sure at this point that the name for ptGame +d8 should be another one, but isn't sure what to call it

[Jarulf]

[quote=kingpin";p="154507"]This is the structure that ptGame +d8 holds. It contains more unknown info than I have identidy so far.

+0 Point.X
+4 Point.Y
+8 Unit ID
+c Unique ID

I'm sure at this point that the name for ptGame +d8 should be another one, but isn't sure what to call it [/quote]

I think it holds a linked list of ptRooms for act 1. What I have:

00d8 ptRoom (act 1) list
00dc ptRoom (act 2) list
00e0 ptRoom (act 3) list
00e4 ptRoom (act 4) list
00e8 ptRoom (act 5) list

I have very little knowledge and have not looked much into stuff related to the dungeon, pathing and such.

{Added to topic -Kingpin}

[kingpin]

think it holds a linked list of ptRooms for act 1. What I have:

00d8 ptRoom (act 1) list
00dc ptRoom (act 2) list
00e0 ptRoom (act 3) list
00e4 ptRoom (act 4) list
00e8 ptRoom (act 5) list

You are right when I think a bit about it. Since this list is built up when monsters/objects are spawn in a level and its a list for each individual monster/object that are spawned in a room. So, we can just update the ptGame info with your description instead, it was better than mine

Do you have notes about what ptGame +10F0 is?

[Jarulf]

Do you have notes about what ptGame +10F0 is?

10f0 objectlist
0000 seed_lo
0004 seed_hi
0048 0
004c ptObjects.txt
0050 ptObjects.txt
1110 0
end
10f4 questlist

As you can see, 10f0 is one pointer into a 0x1114 size structure that seems to hold entries to Objects.txt. It is initialized when the game is created. At least I think it is a list of pointers to Objects.txt. It do loops number of objects though. The seed is probably a start seed. It is generated based on the current seed of the game (at +d0/d4 at the moment the structure is created. I just added the 10f4 to show that it is just a 1 dword in size. I have NO idea about the quest structure, I just noted it was quest related stuff that got initilized there. Could even be that several entries are quest related, no idea. I have no notes on anything from there onto the unit lists a few entries later.

I have a bunch of other entries in ptgame not listed here as well, I would have like to make a few checks on some of the first though, but, what the heck, perhaps others can help out. Here is my list:

Code: Select all

ptGame 
0000	set on ptGame creation
0004	
0008	
000c	
0010	
0014	byte, set on ptGame creation
0018   	_ptLock (LPCRITICAL_SECTION)
001c	fog:279e (memory allocation stuff), (0 in d2game:273f)
0020	
0022*	word, act
0024	1 on creation
0028	word, game number (in 1-1024)
002a	game name (10 chars)
003a	(password?) (10 chars) (ej i d2game:2713)
004a	(password?) (20 chars) (ej i d2game:2713)
005a	
005c	
0060	
0064	
0068	byte
0069	byte
006a	byte, set on creation (net, i d2game:2713) (0,1,2)
006b	byte, set on creation
006c	byte, set on creation (in d2game:273f)
006d	byte, difficulty (0,1 or 2)  (in d2game:273f, part of flags)
006e	byte, set on creation (in d2game:273f)
006f	byte
0070	Lod(1) or D2c(0) 00100000 flag in
0074	Lod(100) or D2C(0)
0078	00200000 flag in => 1
007c	start (map?) seed (same as initseed with -seed)
0080	start (object?) seed (from initseed with -seed) 
0084	1 if -seed
0088	ptClient list (+4a8 ptnext)
008c	# of clients
0090	# of players spawned counter
0094	# of monsters spawned counter
0098	# of objects spawned counter
009c	# of missiles spawned counter
00a0	# of items spawned counter
00a4	# of tiles spawned counter
00a8	frame counter, nope!!! 1501-7499 (1-5 min) delete game, empty
00ac	+b0*1000/(Tick-b4)
00b0	counter
00b4	GetTickCount
00b8	hEvent
00bc	ptAct1 (+20=ptArt (+04 ptRoom) )
00c0	ptAct2
00c4	ptAct3
00c8	ptAct4
00cc	ptAct5
00d0	seed_lo
00d4	seed_hi
00d8	ptRoom (act 1) list
00dc	ptRoom (act 2) list
00e0	ptRoom (act 3) list
00e4	ptRoom (act 4) list
00e8	ptRoom (act 5) list
00ec	start (monsterregion?) seed (from initseed with -seed) 
00f0	ptmonsterregion 0 (2e4 size)
00f4	ptmonsterregion 1
...

03d4	flags

10f0	objectlist
	0000 seed_lo
	0004 seed_hi
	0048 0
	004c ptObjects.txt
	0050 ptObjects.txt
	1110 0
	end
10f4	questlist
10f8	
10fc	
1100	
1104	
1108	
110c	
1110	
1114	
1118	
111c	
1120	ptUnit (character) list (80h dword) (+e4 ptnext)
1320	ptUnit (monster) list (80h dword) (+e4 ptnext)
1520	ptUnit (object) list (80h dword) (+e4 ptnext)
1720	ptUnit (missile) list (80h dword) item? (+e4 ptnext)
1920	ptUnit (item) list (80h dword) missile? (+e4 ptnext)
1b20	ptUnit (tile) list (1 dword) (+e4 ptnext)
1b24	ptUnit (????) list (80h dword) (+e4 ptnext)
1d24	??? (6fccba30)
1d28	ptArena
1d2c	hParty (8 size, 0003, 0000)

1d70
1d74	*100/1db4
1d78	*100/1db4
1d7c
1d80
1d84	*100/1db4
1d88	*100/1db4
1d8c
1d90
1d94
1d98
1d9c
1da0
1da4
1da8
1dac	*100/1db4
1db0
1db4	divisor
1db8
1dbc	GetTickCount on creation
1dc0	tick counter >300000 delete game, empty
1dc4	fog:2747 (2 if >1)
1dc8	d2game:273a
1dcc	
1dd0	
1dd4	
1dd8	
1ddc	type of "exception" to throw

Some comments. The _ptLock that someone mentioned having no idea about is as far as I can see what gets returned by the system ALI (is that what one call them?) when calling the "initilizeCriticalSection" or somethig like that. The type I mentionis defined and can be read about in MSDN online or on computer if someone has it installed. The +1c also calls a memory handling function of fog.dll. Didn't sound interesting to me so I never went looking at it in more detail. I am mostly interested in game play reated things

There are three strings compied to the strucutre, I would say one is the game name (as noted), one should be the password, have not thought about what the other could be. They are both 32 bytes in size. Also note that on realms or perhaps also open mulitplyaer, there are all sort of realm related issues and net connection data that needs to be saved and such. I have never bothered tracking or checking those. Anyway. I have not had time to run the game through a debuger, where it should be obvious what strings are compied into those locations.

The unknown bytes arround the difficulty should probably be stuff like hard core game and ladder game. Ladder game should be set from realms only by the way. Since some rune recipies only works there, it should be easy to check which one that is. There are two initializations of a game, one should prbably be realm and/or open and the other single player, no idea yet which one is which.

There is a whole lot of counters set and maintained in the structure to keep track of how long the game has been running, been empty and such things. I have not yet looked much at it, hence why some of those entries
are not fully documented.

Also, many entries related to communication and messages to/from clients is something I am not interested in and have not noted when comming accross.

Perhaps this helps some.


[/i]