TERRAIN

From UFOpaedia
Revision as of 08:53, 15 October 2005 by Bomb Bloke (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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, but each file in a set contains the same number of records.

MCD

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

Things to search for:
- Energy used when crossing tile. (38?)
- Stun caused by explosion.

mcd[00]-[07]:
Animation of the tile.
The second four bytes always seems to be a(n ignored?) copy of the first four bytes. This animation only works for doors when they are opened.

mcd[08]-[19]:
Loft of the tile. 12 values, each referances into loftemps.dat file.
Each record is a 16x16(?) grid. Used to create a 3D map of the tile, for LOS.

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

mcd[22]-[29]:

  • UNKNOWN*


mcd[30]: Sliding door? (0 for false, 1 for true?)
mcd[31]: Can be seen through? (1 for false, 0 for true?)
mcd[32]: Cannot be stood on? (0 for false, 1 for true?)
mcd[33]: Impassable? (Used for objects). (0 for false, 1 for true?)
mcd[34]: Grav lift? (0 for false, 1 for true?)
mcd[35]: Hinged door? (0 for false, 1 for true?)
mcd[36]: Blocks fire? (0 for false, 1 for true?)
mcd[37]: Blocks smoke? (0 for false, 1 for true?)
mcd[38]: *UNKNOWN*
mcd[39]: Time units used to walk across the tile. 255 means unpassable.
mcd[40]: Time units used to fly across the tile. 255 means unpassable.
mcd[41]: Time units used to slide across the tile. 255 means unpassable. (Used for some aliens. Tanks?)

mcd[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]. Assume 255 is indestructable?
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.

mcd[43]: Explosive blockage. Unsure of what different values do; blocks explosive effects.
mcd[44]: Tile becomes a tile of this type when destroyed. See mcd[42].
mcd[45]: The higher this is, the less likely the tile will be set on fire.
mcd[46]: If the tile is a door, the tile will become this tile number when opened.
mcd[47]: *UNKNOWN*
mcd[48]: Signed value; add this to the y offset of units when on this tile.
mcd[49]: Subtract this value from the y offset of the tile image.
mcd[50]: *UNKNOWN*
mcd[51]: From 0 to 10, amount of light blocked by tile. (Not sure if 0 or 10 is 'transparent').
mcd[52]: Footstep sound effect to use when walking (as opposed to flying or sliding) across tile.

mcd[53]:
Tile type.
0 - Floor
1 - West Wall
2 - North Wall
3 - Object
Always assume destroyed tiles and opened tiles match original tile types?

mcd[54]: Explosive type. 0 for HE, 1 for smoke.
mcd[55]: Strength of explosion when tile is destroyed. 0 for none.
mcd[56]: Could be amount of smoke blocked by tile?
mcd[57]: The amount of turns this tile will burn for. (Used when tile is destroyed?)
mcd[58]: Brightness of tile. Amount of light produced.

mcd[59]:
Special properties of tile.
1 - Starting Point
(Other values unknown, check DiaShiva's viewer for the rest.)

mcd[60]: *UNKNOWN*
mcd[61]: *UNKNOWN*

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.