TERRAIN

This folder contains the information used for tiles in the battlescape view, both statistical and graphical.

Each of the three files used for each tileset contains a variable amount of records. PCK files and their respective TAB files should always contain an equal amount of records.

MCD

Files made up of a variable amount of records, each of 62 bytes.

Things to search for: - Stun caused by explosion.

- Stun caused by explosion comes from mcd[54], when the setting for explosive type is Smoke. - Hobbes

0-7: Animation of the tile.

The eight bytes refer to images on the PCK files which are used in a sequence (from the first byte to the last) to animate tiles. This animation is used by several tiles on both games, such as doors, bubbles on TFTD, blinking lifts, etc.

8-19: Loft of the tile. 12 values, each references into LOFTEMPS.DAT file.

Each record is a 16x16 grid, which are stacked one over the other, starting with byte 8. Used to create a 3D map of the tile, for LOS.

20-21: Referance into SCANG.DAT file. [20] + [21] * 256 + 35 = offset. Used for top-down map.

22-29:

30: Boolean: Is sliding door?

31: Boolean: Can't be seen through?

32: Boolean: Can't be stood on?

33: Boolean: Is impassable? (Used for objects)

34: Boolean: Is a Grav lift?

35: Boolean: Is a hinged door?

36: Boolean: Blocks fire?

37: Boolean: Blocks smoke?

38: Always 3.

39: Time units used to walk across the tile. (255 means unpassable)

40: Time units used to fly across the tile. (255 means unpassable)

41: Time units used to slide across the tile. (255 means unpassable) (Used for some aliens. Tanks?)

42: Armor of tile. Tile must take this amount of damage to be destroyed (in a single blast). Tile will then change to mcd[44]. (255 Indestructable!) Note: I suppose you could make a gate out of this, by creating two tiles, each easily destroyed, which change to the other when hit. One could be walked across, the other could not.

- Yes, but you'd have to destroy the gate to open/close it Hobbes

43: HE Blockage.

44: Tile becomes a tile of this type when destroyed.

45: The higher this is, the less likely the tile will be set on fire.

46: If the tile is a door, the tile will become this tile number when opened.

47: Always 0.

48: Signed value; add this to the y offset of units when on this tile.

49: Subtract this value from the y offset of the tile image.

50: Always 0.

51: From 0 to 10, amount of light blocked by tile.

 0 Blocks no light.
... up to ...
10 Blocks all light.

52: Footstep sound effect.

0 ?
1 Metal
2 Normal (Grass, Wood, Dirt)
3 Object?
4 ?
5 Sand (Desert)
6 Martian

53: Tile type:

0 Floor
1 West Wall
2 North Wall
3 Object

Always assume destroyed tiles and opened tiles match original tile types?

54: Explosive type:

0 HE
1 Smoke

55: Strength of explosion when tile is destroyed.

56: Smoke blockage.

57: The amount of turns this tile will burn for.

58: Brightness of tile. Amount of light produced.

59: Special properties of tile:

 0 No Special Properties
 1 Starting Point
 2 UFO Power Supply
 3 UFO Navigation
 5 Alien Food
 7 Alien Entertainment
 8 Alien Surgery
 9 Examination Room
10 Alien Alloy
12 Dead Tile
13 End Point
14 Alien Brain

60:

61:

PCK / TAB

Graphical tile data. The TAB file is made up of two byte values, each stating the starting offset of the respective graphic in the PCK file.

PCK decoding is fairly simple: the first byte in the data stream tells you how many rows you should skip. Then you just draw each byte afterwards directly onto the screen (which should be using a 256 color palette).

Values 254/255 are not to be drawn. If you encounter a byte with a value of 254 (FE), then the next byte tells you how many pixils you should skip. If you encounter a byte with a value of 255 (FF), then you're done.

While simplistic, I've found that the best way to use PCK files is to store them 'as is', then decode them straight onto the screen as needed (as opposed to pre-rendering them and storing the completed graphics in memory). This makes lighting effects that much easier to implement.