Map Data Strings Header

Back to String Compressor page

The Strings Section Header
The Strings Section of a GameX MSQ block is the third major section. .It holds all of the pertinent text messages which are spewed to the user on this map. Any and all string data held in the WL.EXE program file are also stored as mini String Sections. The strings area is split into two sections, a Header, described here, and the strings data, which constituted the Section's Body.

The header itself is further split into two sections


 * 1) CharacterTable of 60 bytes.

The character table forms the key for the string compression over the string body. So, the overall layout of the Strings Section is:
 * 1) A Table of Pointers to the strings. This acts as a lookup for finding the right string for a message number.

With the first two parts making the header, and the subsequent strings being the body.

The Pointer Table
Immediately following the character table is a pointer table. This table contains 2-byte words, each of which is the offset based from the BEGINNING OF THIS POINTER TABLE. therefore, if the Strings Header starts at 0x1004, and the character table is 60 bytes (3c) wide, then the pointer table starts at 0x1040. With Highpool, the first entry is located at 0x004e, which defines address 0x1040+0x4E = 0x108E. At this address is the start of the first string "The limestone cliffs loom overhead...", a common string which is displayed if you attempt to move into the rocks surrounding Highpool.

As with all of the pointer tables found so far, the first entry (which is the address of the first thing in the table), also defines the end of the table. There is a slight exception in this case. For some unknown reason, the pointer table spans from 0x1004 to 0x108C, which means there are two bytes (at 0x108C and 0x108D) which contain non-pointer and non-string data. These bytes have not yet been deciphered. At the moment, the only hypothesis is that they are packing.

How was this found?
By trawling through the code, and a lot of lateral thinking. The actual algorithm is quite clever, and does manage to decrease the number of bytes needed by the strings to less than 60% of their original size. The character and pointer tables are fairly easy to spot, and a little shuffling around the decrypted msq blocks shows how they work. The hard part was decoding the strings themselves...