MSQ Block

Back to GameX page

## MSQ block [ Map Data ]

Each MSQ block is self-contained, the data within each block can be described as in the following image. Each of the sections of the MSQ block are stored or encrypted differently. The game employed a sort of 'just enough' encryption scheme. Each section was encrypted just enough to make it difficult to decipher.

## Encryption Routines for each Section

 Action / Encounter Strings
 Shop / NPC Data
 Monster Names / Data
 String Table

Apart from the "save game" block, each of the MSQ blocks in the gameX files adheres to the same general structure:

For an example of how this information is used, see the player movement flowchart for a runthrough of a user 'moving' their character onto an 'interesting' tile (i.e. with something that happens, like a skill check or encounter).

## Map Tile Information

The actions that occur on each of the maps are controlled from the first three sections of that map's MSQ block. We call these the "map layers". The size of each layer is dependent upon the size of the map. common sizes are 32x32 and 64x64.

### Action Classes Layer (aka nibble layer)

While the user is walking around the map, certain actions are triggered. In order to keep things neat and tidy, these actions are sorted into classes. Each tile in this layer is represented by a nibble, therefore there can be up to 16 different action classes. Once an action has been run, this layer can be modified to change the trigger class for the tile. For example, the cave entrance in Highpool starts off as a "stat check" class. Once the player completes the action, the class is changed to a "location change" class, and the selector layer is changed so that the player is transported to the caves when (s)he steps on the tile.

### Action Selector Layer

The action classes layer defines which \_type\_ of action is performed, however, one more layer is needed to select which exact action is run. Each tile in this layer is represented by a byte, therefore there can be up to 256 different actions in each class. This is extremely flexible, and allows for fairly rich maps. The way it is most effectively used is to give each 'interesting' tile a different ID, and place this ID into the selector layer. Like the Action Classes Layer, this can be modified so that the tile has a different effect once the action has been completed.

## Central Directory

The MSQ block's central directory contains a bunch of pointers. It's an index to all the important parts of the MSQ block. To see how the various map layers, and the central directory are used during player movement, see the movement flowchart.

## Map Info

The Map Info block is a 54 bytes long block following immediately after the central directory. It contains various information about the map like the encounter frequency, time factor, tileset id and so on.

## Action Tables

When a player enters a tile (or several other cases), the action class for that tile is worked out (say 1), then the entry from the action class table gives the location of the action table for action class "1". This could be (say) 0x65c. Then, the game extracts the action selector from the third map layer, and uses this as an offset into the table. Let's say the action selector was 4, then this yields an address of 0x65c + (4\*2) = 0x67c. This is the location of the particular action code string which is run for that tile.

## Action Code Strings

This is a huge chunk of bytes. Each of the action code strings is a parsed bytecode instruction string, which can perform tasks such as printing out strings, modifying map and player data, checking for appropriate stat levels and so on.

## Shop Data

Each of the maps can contain some shops. The shop data section is divided into a header, which gives the offsets to each of the shops, and the actual shop sections themselves

## NPC Data

Each map can contain NPCs, which can be hired, etc.

## Monster Data

This block contains all of the information about the monsters which occur on this map.

## String Data

Contains a huffman-coded set of strings which are printed out in response to various actions or triggers.

### How was all this found?

The layout of the MSQ blocks has been under study for quite a long time. It's absolutely certain that early hackers will have had a good crack at decoding the game. In the lifetime of this project, work was initially started by some members of this project, and some great discoveries and visualisations done by Ian Goodale from the Wasteland Yahoo Newsgroup. Help was also pitched in by other major contributors to the newsgroup, including Ranger Ben, Another Ranger called Ben, Wild Bill, Nick, and Ian. Work ground to a halt at the end of 2004, and was picked up in 2005 by Displacer, with some algorithmic help from Nick. Eyemixer joined the project, also contributing visualisations. In mid-2006, Ian Goodale updated some of his visualisations of the map data, and along with some of the new utilities and Eyemixer's talents, we now have some excellent graphics of what's going on inside the game.