MCD
MCD (Map Control Data) files, which are stored in the TERRAIN folder, contain multiple 62-byte records that define the tiles that make up a given terrain. For example, BARN.MCD defines a number of terrain items such as walls, haybales, floors and ceilings, while DESERT.MCD defines things like sand (ground tiles), sand dunes, rocks, and cacti.
Each MCD file is accompanied by a PCK and a TAB file with the same filename. These contain the image data referenced by the MCD itself. The tiles within the MCD files are referenced by both the files in the MAPS folder and MAP.DAT, in order to create "map modules"; these are then grouped together at run-time to create randomly generated battlescapes.
Often, more than one MCD file will be required to represent a given map. For example, farms are made using tiles from both the CULTIVAT (fields) and BARN (farmhouse) sets.
Usage
At run-time, a collated MCD array is created from the smaller sets stored in this folder. In order, this is made up of:
- BLANKS.MCD (two records, the first of which is the black tiles rendered outside of the "map boundaries", and the second of which is the burnt dirt resulting from explosions).
- The set(s) corresponding to the terrain (for example, the MCD files corresponding to the desert or forest areas).
- The set corresponding to the X-COM dropship, if one is present on the map.
- The set(s) corresponding to the alien craft, if one is present on the map.
This large table may never exceed 256 total entries (or the game will crash). For example, you can't have an X-COM and an alien craft present in an urban map; this will result in a "too many map-codes" error.
The associated map modules are also loaded into a single large map array, with the tile indexes modified to account for the re-positioning caused by appending the MCD tables together. For example, a wall tile in the Supply Ship MCD file might be the second record, and that's what the map module file will index to (well, that plus 2, but see the MAPS page for more on that): However, after appending the Supply Ship MCD file to the end of the collated MCD array, that wall tile might now be index number two hundred!
Likewise, any tile indexes within the collated MCD files themselves, or to the associated PCK sprites (which are also collated into a single array), need to be "updated" in the same way (tile indexes within the MCD structure are at offsets 44 and 46 of each record).
Because the collated MCD array can be (mostly) recreated at any time, it is not written to the hard drive when the user saves the game mid-battle. This has a side effect of causing doors to stick open, as offset 47 won't be correctly tracked.
Structure
Offset (Decimal) |
Offset (Hex) |
Usage |
---|---|---|
0-7 | 0x00-0x07 | 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 (see [46]), bubbles on TFTD, blinking lifts, etc. If all eight frames are the same, it's a static tile. |
8-19 | 0x08-0x13 | Line Of Fire Template (LOFT) for the tile. 12 values, each references into LOFTEMPS.DAT file.
Each LOFT record is a 16x16 grid; these are stacked one over the other, with mcd[8] being the bottom. Used to create a 3D map (16x16x12) of the tile, for LOS. For more info, see LOFTEMPS.DAT. |
20-21 | 0x14-0x15 | Reference into SCANG.DAT file. Two-byte integer ([20] + [21] * 256 + 35 = offset). 4x4 bmp images for the top-down map; see SCANG.DAT. |
22-25 | 0x16-0x19 | Four byte value pointing to the RAM location of the TAB index for the PCK data used by the terrain file. Only used at run-time. |
26-29 | 0x1A-0x1D | Four byte value pointing to the RAM location of the PCK set used by the terrain file. Only used at run-time. |
30 | 0x1E | Boolean: Is sliding door? See [46]. |
31 | 0x1F | Boolean: Blocks visibility of terrain? AKA LOS (Line Of Sight)
0 = False = Doesn't block visibility. 1 = True = Blocks visibility. Visibility of units is blocked by voxels formed with LOFTEMPS.DAT. Note that floor tiles always block visibility of terrain, although their flag is 0, but it's ignored for floor tiles. |
32 | 0x20 | Boolean: Can't be stood on? For ground tiles: non-flying units fall through. Only two ground tiles have this set: BLANKS MCD id 0 and UFO1 MCD id 0 |
33 | 0x21 | Boolean: Is Wall? Used for Objects intended to act as Walls; used to make UFO, Skyranger, and Avenger outer "walls" that aren't otherwise possible as "real" North or West walls. If that sounds ambiguous, that's because no one's worked out what it actually does; whether an object can be walked on/through depends on it's TU cost ([39]) and height ([48]). Called "BigWall" in MapView. |
34 | 0x22 | Boolean: Is Grav lift? Up/down of lifts is determined by whether there is another one above or below in the .MAP. |
35 | 0x23 | Boolean: Is hinged door? See [46]. |
36 | 0x24 | Boolean: Blocks fire? |
37 | 0x25 | Boolean: Tile blocks smoke (or a "gas" type which was never implemented) from spreading. Used in smoke propagation routine. |
38 | 0x26 | Always 3. Defined as "printype"; 3=whole, 2=right side, 1=left side. Since this is always 3 the game prints the entire object, while the assumption is that values of 2 or 1 are possibly used for the map designer. |
39 | 0x27 | Time units used to walk across the tile (255 means unpassable). |
40 | 0x28 | Time units used to slide across the tile (255 means unpassable). |
41 | 0x29 | Time units used to fly across the tile (255 means unpassable). |
For [39] to [41], values range from 0 to 8, or are 255. There are only a few places where they are not all the same ([39]=[40]=[41]):
Walk Slide Fly File Description 2 0 2 Avenger Middle ramp object 255 255 4 Arctic Water pools in ice (18 ground MCDs) 2 2 0 U_Base Death objects for large round containers in alien bases (four quadrants)... thus, their remnants don't add TUs for fliers 1 1 0 U_Base Little green plant objects found on black "base garden" flooring 2 2 0 Urbits Two death objects (splinters on ground) for city's tall green picket fence (one is a North-wall fence, the other is a West-wall fence) Which of the three movement types a given unit uses is determined by UnitRef[11]. Note that by default, ALL units are "walkers". | ||
42 | 0x2A | Armor of tile.
|
43 | 0x2B | HE Blockage |
44 | 0x2C | Tile becomes a tile of this type (i.e., this other MCD record in the same MCD file) when destroyed. Also known as the death tile. Also see [53].
Note: If [44]=0, it means there is no death tile per se; it reverts to a "raw earth" (BLANKS[01]) tile if on ground, or nothing if in air. (It does not revert to the MCD id 0 record in the current collection.) |
45 | 0x2D | Flammability - the higher this is, the less likely the tile will be set on fire. |
46 | 0x2E | If the tile is a door ([30] or [35]), the tile will become this tile number when opened. Animation [0] (see [0-7]) is shown until someone walks through the door, in which case it cycles through its animation stopping and holding Animation [7]. Then it will return to a closed door next turn. |
47 | 0x2F | Flags 1 for the "open" version of a sliding door if a door of that type was opened this turn (hence notifying the game that it needs to search the map for doors to close on the next). Because this value is only used at run-time, and the collated MCD array is not written to disk if the player saves the game, reloading while sliding doors are open will cause them to jam until another door of the same type is opened. |
48 | 0x30 | Signed value, usually negative; add this to the graphical Y offset of units or objects on this tile (adding a negative is the same as subtracting, and the lower the Y offset is, the higher the unit will appear on-screen). The value is relative to the level the tile is placed on, so it's usually 0 (meaning "at the same level").
A unit may only step from one tile to another if the effective difference in tile heights are 8 or less. For example, ground level is at 0, while the lower segment of a staircase will typically have this set to -8 and the higher segment at -16. A soldier can step onto the lower segment from the ground, then onto the upper segment, then finally onto the next level above. He cannot step directly from the ground to the upper staircase, let alone to the next level, as it's too great a "jump" to perform in a single movement. The effective difference between levels on the map is 24. |
49 | 0x31 | Subtract this value from the graphical Y offset of the tile image (used for hills). |
50 | 0x32 | Received damage modifier type (taken from Damage modifier table) - Always 0. |
51 | 0x33 | Lightblock. Note that the actual game seems to ignore this value.
0 Blocks no light. ... up to ... 10 Blocks all light. Is apparently percentage based: 1=10%, 10=100%. |
52 | 0x34 | Footstep sound effect. Most likely an index to the .CAT file RAW wave -BladeFireLight
0 Not used in XCOM (makes a metal sound if hacked); is used on TFTD for some objects 1 Metal 2 Normal (Grass, Wood, Dirt) 3 Three mountain ground tiles, and some city apt. furniture objects that can't be walked on? (six furniture objects might've been - but they're death tiles that nothing points to.) Uses same sound as 6 in DOS version. 4 Pool of water (Not used in XCOM) 5 Sand (Desert) 6 Martian ground (DOS version), snow (CE version) 7 Snow (only DOS version, Not used in XCOM, Arctic terrain actually uses 2) |
53 | 0x35 | Tile type:
0 Floor 1 West Wall 2 North Wall 3 Object In the map, there are four bytes per tile: One each for the floor, west wall, north wall and object. If one of those changes (eg is destroyed, or in the case of a door, opened), it is removed from the map and a new object is placed instead. This byte is used to work out which of the four map bytes should recieve the new object. For example, in the mountains, if you destroy the ground tile you get an object (tree stump). The new tile gets written into the fourth byte of the map record, even though the original tile that was destroyed belonged in the first byte. As for the potential for change in tile type when becoming death tile ([44]): There are 22 instances of Mountain Madness (ground to object), 1 instance of North Wall becoming an object (XCOM1 northwall door becomes rubble), one MCD record with tile type of 10 (Barn 7 which looks like a North Wall and becomes northwall when killed; obviously a typo'd Tile Type), and 31 total instances on 18 different tilesets where objects become ground upon dying (probably to "scorched earth", but this was not checked). |
54 | 0x36 | Explosive type; [55] must be >0:
0 HE 1 Smoke Notes:
|
55 | 0x37 | Strength of explosion when tile is destroyed. |
56 | 0x38 | Smoke blockage. This is set to 0 for all UFO tiles!
Technically called "gasblock" by the game. Supposedly it would block the gas type from spreading. Not sure if this is intended to be just smoke, gas or a combination of the two. Needs testing. |
57 | 0x39 | Fuel. The amount of turns this tile will burn for. |
58 | 0x3A | Brightness of tile. Amount of light produced.
11 MCDs produce light: 7 alien base objects (several pulsing fuel pods and several 4-part round "museum containers"), 2 XCOM base ground tiles, and 2 city objects (street lamp and large standing room lamp). See Night Missions for pictures. Oddly, values range from 1 for the street lamp to 16 for the alien base museum containers, so lower values must be brighter. The distances of projected light have yet to be determined, but note that flares and personal lighting ignore vertical distance... at night, a soldier can see aliens on the ground exactly 9 tiles away, regardless of whether the soldier is at ground level or 4 levels high. In practise, it seems if this is not zero then the tile will be fully illuminated regardless of the value. - Bomb Bloke 06:48, 20 June 2008 (PDT) |
59 | 0x3B | Special properties of tile. Determines what is salvaged at end of mission. Note that some are not actually used within their respective games:
UFO TFTD TFTD (per MapView) 0: No Special Properties 0: No Special Properties 0: No Special Properties 1: Entry Point 1: Entry Point 1: Entry Point 2: UFO Power Source 2: Ion-Beam Accelerators 2: Ion-Beam Accelerators 3: UFO Navigation 3: Magnetic Navigation 3: "Destroy Objective" 4: UFO Construction 4: Alien Sub Construction 4: Magnetic Navigation 5: Alien Food 5: Alien Cryogenics 5: Alien Cryogenics 6: Alien Reproduction 6: Alien Cloning 6: Alien Cloning 7: Alien Entertainment 7: Alien Learning Arrays 7: Alien Learning Arrays 8: Alien Surgery 8: Alien Implanter 8: Alien Implanter 9: Examination Room 9: Examination Room 9: "Unknown9" 10: Alien Alloys 10: Aqua Plastics 10: Aqua Plastics 11: Alien Habitat 11: Alien Re-animation Zone 11: Examination Room 12: Dead Tile 12: Dead Tile 12: Dead Tile 13: Exit Point 13: Exit Point 13: Exit Point 14: Alien Brain 14: T'leth Power Cylinders 14: T'leth Power Cylinders Notes:
|
60 | 0x3C | Set to 1 for some X-COM base tiles, 0 otherwise. At the end of the battle, the game tallies up the amount of these existing within each "module" of the base (the results are stored in MISSION2.DAT, offsets 80-151) - if the end result for any given module is 0, it may be destroyed.
If an alien patrols to a route node which has offset [21] flagged as anything other then 0, it will intentionally shoot at any tiles with this offset likewise flagged. If you're playing a CE version of UFO/TFTD the game will then crash immediately afterwards... either way, best not to let them go up the stairs to where these objects can be found. ;) |
61 | 0x3D | Unused. Almost half (560 of 1317) MCD records have widely varying values here, from 1 to 255 with no apparent pattern or preferred value. The remaining MCD records are 0. Called "VPs" by the game, this was supposed to be a victory point value for recovery/destruction. Doubt it's actually used, but needs to be tested. |
List of MCD Files
Here are the MCD files in Enemy Unknown and Terror From The Deep along with a list of the number of records in each one. Refer to TERRAIN for more info on their usage in-game (load orders etc):
|
|
Additional Information
MikeTheRed's MCD Database
An Access 2000 copy of all MCD data is here. It's from X-COM DOS 1.4, but AFAIK, all X-COM versions use the same data (even down to the buggy Mile-High Madness MCD record). You will need to use this wiki page to understand it; I did not name the fields. They're just called by their offset address (see above). This Access database can be readily exported to Excel if you want. Or contact me. There are also a few files giving overall stats; the "Exclude" field for tblFileTypes only means, I excluded them for most counts I've made. There are also a few queries that might or might not be helpful.
BladeFireLight's MCD Info
Another in-depth look at MCD (and more) can be found on this message by BladeFireLight. His post also contains a HexWorkshop template for viewing MCD files in a logical manner.
MCD Editor
Koralt's MCDEdit can view or modify MCD files. Find it here: mcdedit.zip. To see a screencap, scroll to the very bottom of BladeFireLight's MCD posting (above). MCDEdit needs vbrun200 to run!
There's also MCDEdit made by volutar. It doesn't need of any extra library and works in windows x64.
MapView
DaiShiva has an excellent utility called MapView for viewing or editing maps. However, it does not allow editing of MCD terrain items per se, AFAIK; just moving/placement of them. Caution: You must install the extensive Microsoft .NET platform to use MapView; see DaiShiva's site.
BombBloke's Hacked Desert Terrain
Bomb Bloke has a numerical (ground) tileset which makes weapon damage blast testing easy as pie. It also has a little applet that lets you edit MCD variables Armor [42], HE Block [43], and Explosion Strength [55] (but not type, [54]), and it includes all four types of terrain item. Find his hacked terrain here or bundled with a savegame here. To see a screencap of the tiles in action, see this message.