Difference between revisions of "TERRAIN"

From UFOpaedia
Jump to navigation Jump to search
m
Line 36: Line 36:
 
'''37:''' Boolean: Blocks smoke?
 
'''37:''' Boolean: Blocks smoke?
  
'''38:'''
+
'''38:''' Always 3.
  
 
'''39:''' Time units used to walk across the tile. (255 means unpassable)
 
'''39:''' Time units used to walk across the tile. (255 means unpassable)
Line 58: Line 58:
 
'''46:''' If the tile is a door, the tile will become this tile number when opened.
 
'''46:''' If the tile is a door, the tile will become this tile number when opened.
  
'''47:'''
+
'''47:''' Always 0.
  
 
'''48:''' Signed value; add this to the y offset of units when on this tile.
 
'''48:''' Signed value; add this to the y offset of units when on this tile.
Line 64: Line 64:
 
'''49:''' Subtract this value from the y offset of the tile image.
 
'''49:''' Subtract this value from the y offset of the tile image.
  
'''50:'''
+
'''50:''' Always 0.
  
 
'''51:''' From 0 to 10, amount of light blocked by tile.
 
'''51:''' From 0 to 10, amount of light blocked by tile.

Revision as of 02:16, 15 November 2005

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.

0-7: Animation of the tile.

The second four bytes always seems to be a copy of the first four bytes. This animation only works for doors when they are opened.

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

Each record is a 16x16(?) grid. 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.

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.

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 Power Supply
 3 Destroy Objective
 7 Alien Entertainment
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.