Transition Data

Go back to the Action Class index

Transition Data
Transition squares are for lack of a better term teleportation squares. They are used to jump you around to other locations in the game, enter shops and other buildings. They are very flexible, able to move you around on the same map, or move you to a completely new map. You can be moved with or without your permission, for example when you enter a new place, you may get the question "Enter new location?" or just zapped away somewhere without knowing where you are or how you got there. A transition square is denoted by a 0Ah nibble on the map.

BYTE 0
This byte is divided into 2 parts. The upper 2 bits, and the lower 6 bits Bit 7 is how to make the transition. If it is clear then it is an absolute position to move to. If its set then its an offset from your current position. Bit 6 determines if the "Enter new location?" question is asked. If its set then the question is asked. If its clear it is not.

The lower 6 bits are what string to print on the lower part of the screen. The upper 4 bits of these 6 bits are used to determine the string block (So only the string blocks 0 to 15 are available for transition texts). The lower 2 bits are used to determine which one of the four strings in the string block is used.

BYTE 1
X position on map to move to depending on bit 7 above. The byte is signed. So FFh means moving the player one step to the left if relative positioning is selected in byte 0. FEh means moving 2 steps to the left and so on.

BYTE 2
Y position on map to move to depending on bit 7 above. The byte is signed as already explained for the X position.

BYTE 3
Location to move to. If bit 7 is cleared then the other seven bits are just the index to the location table explained below. If bit 7 is set then the other seven bits are used as an index in the //derelict table// (explained below) which contains the real location id to use for determining which map to draw. Why it's done like this, is a little bit unclear. They could have achieved the same effect when they had just used the full 8 bits as location id and using a 256 bytes table to map the locations to maps.

Please note that a location is ==not== a map. A location just ==uses== a map. Best examples to see the difference are the derelict buildings in Quartz and Las Vegas. If you enter a derelict building (let's say location 82h), then leave a party member on it and then move to an other derelict building (let's say location 83h) you may notice that the same map (map 5 in game1 for Quartz) is displayed but your other party is not there, because it's still on location 82h. Go back to the first derelict building and you can see your lost party member again. So the separation of locations and maps allow the game to have different places without the need to have separate maps for each of these places. But this is only used for the derelict buildings because it's ok for them when they all look the same.

Location id FFh is a special case: It means to use the previous map and position you were on this map. Bit 7 of byte 0 and X and Y position bytes are ignored in this case.

BYTE 4 - 5
Bytes 4 and 5 are nibble/byte pair to change square to if any, if no change byte 4 will be FFh and byte 5 will not be present. FDh and FEh are special cases and will be posted at a later time.

The location-to-map table
To find out which map the game has to display for a specific location it uses a table which is hardcoded in the EXE file at seg2:BEC9h. The table has at least 50 entries. Maybe more. But because location 49 is the last used location it's unknown how many more bytes are used for this table. Each byte in the table is separated into two parts. The first part (bits 7-6) defines the game number where the map is located. 10b means game1 and 01b means game2. The other six bits are used for the map number in the gameX file. So the byte 86h means that the map is MSQ block 6 in game 1.

The //derelict table//
For some reason the authors decided to implement the derelict building locations in a different way. They added another table in the EXE file at seg2:BF9Ch. The table contains 125 entries. The first 64 entries are all set to 05h. This is the location id of the derelict building in Quartz. The other 61 entries are all set to 0Bh which is the location id of the derelict building in Las Vegas.

How the game finds out which map is used by a location

 * 1) It takes the location id from the transition data.
 * 2) If the location id is FFh then the previously used map is used.
 * 3) If bit 7 of the location id is cleared then the id is used as an index in the location-to-map table (explained above) to find the map. Example: Location ID is 10h. The location-to-map-table maps this id to the value 89h. The upper two bits in this byte say the map is in game1. The other six bits say the map is in MSQ block 9 in this file.
 * 4) If bit 7 of the location id is set then the rest of the byte is used as an index in the //derelict table// to find the real location id which is then used as an index in the location-to-map table to find the map. Example: Location ID is 82h. Bit 7 is set so the other seven bits (02h) are used as an index in the //derelict table// to find the value 05h. 05h is used as the real location id and therefor it's used as an index in the location-to-map table to find the value 85h which means MSQ block 5 in game1.