PST: GAM file

[Displacer]

I think the IESDP entry for v1.1 of the GAM file is off by 4 bytes where it states the current area, at least in PST. I think this starts at 0x5C instead of 0x58. I found this by tracing the load process, from what I see 0x58 is loaded as a single byte. Looking at the GAM file with a hex editor supports this as the area name starts at offset 0x5C in the hex editor. I haven't found where it deviated by the 4 bytes, so its possible that previous offsets are off by 4 bytes as well, and possible later offsets (unless the current area entry is only 4 bytes instead of 8)

 

One other thing, v1.1 of GAM does not list PST in the "Applies to" section.

[Avenger]

000000h Signature GAMEV1.1

000008h Gametime 00001ec9

00000ch Active formation 0001

00000eh Formation 1 0000

000010h Formation 2 0000

000012h Formation 3 0000

000014h Formation 4 0000

000016h Formation 5 0000

000018h Party gold 00000073

00001ch UNKNOWN 0002

00001eh Weather 0000

000020h PC offset 000000b8

000024h PC count 00000003

000028h Unknown offset 00000000

00002ch Unknown count 00000000

000030h NPC offset 00001670

000034h NPC count 00000000

000038h Variable offset 00001d28

00003ch Variable count 000007f9

000040h Area AR0100

000048h UNKNOWN ffffffff

00004ch Journal count 00000021

000050h Journal offset 00032628

000054h Maze offset 00001670

000058h Reputation 00000064

00005ch Current area AR0100

000064h Killvar offset 0002badc

000068h Killvar count 00000147

00006ch Bestiary offset 000327b4

000070h Current area AR0100

[Displacer]

Hmm, when is this going to be updated then so I don't scrounge around finding stuff that's already known?

 

Also offset 0x58 is loaded as a word, not a dword, here's the code from torment.exe:

 

.text:005AFC16                 mov     eax, [ebp+var_24]
.text:005AFC19                 mov     cx, [eax+50h]
.text:005AFC1D                 mov     [edx+2110h], cx

 

Note eax+50h is actually +58h, as its been set to point past the header

[Avenger]

I don't know how well known is this.

I try to keep ielister up to date.

[Displacer]

I don't know how well known is this.

I try to keep ielister up to date.

 

 

Sorry, I meant is the IESDP ever going to be updated

[Avenger]

I keep reputation as a dword only for simplicity. The other half of the dword isn't used for anything, is it?

[Displacer]

I keep reputation as a dword only for simplicity. The other half of the dword isn't used for anything, is it?

 

I'm still going through the loading routine, so I don't know whats used and whats thrown away. By experience with other engines, I know that some of them have data that's unused, its usually there to make a code alignment but that's yet to be seen.

 

The loading of a saved game is pretty involved, its been kind of fun seeing how this works. First thing is the temp folder is cleared of any files. Next the contents of the selected save folder is copied to the temp folder. This I assume is to assure that only copies are used so if a crash occurs, the originals will be safe and uncorrupted. Its a really good safeguard I've not seen before. Anyway after the files are copied the temp folder is checked to see if all the necessary files are there (.gam, .sav, .wmp, etc.) Next all the compressed files in the .sav file are extracted to the temp folder. Now all unnecessary files are deleted. This includes the now unneeded .sav file, portrait files, and the like. Next the world map is processed. After that the .gam file is processed, which is where I am now, and it looks like the area file extracted from the .sav file is processed next.

 

At any rate is there an active place that is updating IE data? I hate to keep posting new info here when it appears it will never be used...

[Avenger]

I will at least read it.

Even if i know something, it is good to have confirmation of that knowledge.

[Displacer]

Any new info on the variables? the IESDP shows each entry as 0x6C in length, but the load routine shows them as 0x54 in length.

[Displacer]

Ok, also on the variables the unknown at 0x20 is loaded as:

 

WORD

WORD

DWORD

 

And at 0x2C:

 

DWORD

DWORD

0x20 string

[Avenger]

0x54 is correct

 

But other than the variable name and value i don't know any other field.

 

IESDP is correct too, as the 40 is decimal, not hexadecimal.

0x2c+0x28 = 0x54

[Displacer]

0x54 is correct

 

But other than the variable name and value i don't know any other field.

 

Well we at least have the sizes for the unknowns as posted above. After I get the memory struct sorted out I can find how their used in-game.

 

Pity there doesn't seem to be an interest in this stuff anymore...

[devSin]

There's always an interest in this stuff.

 

BUT... there never was much for PST, sorry.

[Displacer]

There's always an interest in this stuff.

 

BUT... there never was much for PST, sorry.

 

But this GAM version also applies to some of the other games, so it should also fit for those, or am I mistaken?

[devSin]

In some ways, sure. But I read everything as it relates to NI code, and the GAM header is common only up to the journal entry count, so everything subsequent is totally off my radar (BG2, for instance, goes dwReputation, refCurARE, dwFlag, unknown, dwFamiliarOff, dwStoredLocOff, dwStoredLocNum, dwGameTimeReal, dwPointsToEndOfFileNonsenseOff, dwPPLocOff, dwPPLocNum).