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? 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 vision, althought 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: Blocks smoke?
38	0x26	Unknown - Always 3.
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. Tile must take this amount of damage to be destroyed, at which point it changes to a tile set according to [44]. Terrain items do not "remember" damage (like units); terrain is either destroyed in a single blast/shot (if damage >= armor) or not. Some things are set to 255 to mean "indestructible" but actually, anything >100 is indestructible in a non-hacked game, and anything >127 (for explosives, 255/2) or >191 (firearms, 255x.75) cannot be destroyed, even in a hacked game (see Damage re: Damage to terrain). With explosions, all four terrain items in the tile are hit by the same strength, but firearm shots target only one of them. For a loopy exception to explosions being equally applied (due to erroneous data), see Mountain Madness. NKF: 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	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	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	Unknown - Always 0.
51	0x33	From 0 to 10, amount of light blocked by tile. Note that the actual game seems to ignore this value. 0 Blocks no light. ... up to ... 10 Blocks all light.
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 -Hobbes 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: To see explosive objects in XCOM, see Explosions#Explosive Map Objects. Type 0 (HE) explosions follow the usual rules for explosions (average damage to units decreases by 10 per tile outward, etc.). Hackers: Type 0 (HE) terrain items with little or no armor ([42]=0) are obliterated before exploding (i.e., they won't explode, no matter how high [55] is). Probably also depends on whether it was a very big blast relative to the armor. Chain reactions are exceedingly difficult to set up (per Hobbes). Most of the time when you see e.g. the four sections of the Navigator's table explode, it's because you used explosives that actually set off each one individually. It has to do with a balance of, among other things, not obliterating the object (see previous point). Type 1 (Smoke) explosives are strange, and mainly only affect aliens - and very haphazardly at that. XCOM units are only very rarely affected; I could only get it to work if they were 1) unarmored, 2) on a diagonal, and 3) no other objects are "in the way" between the blast moving "over and up" or "up and over" to the diagonal (blast propagation never moves directly diagonally per se; see Explosions#Playing With Fire). -MTR Chain reactions are not possible with Type 1 (Smoke) explosive objects. Also, when dealing with smoke damage, remember that if there is already tons of smoke on the map (filling up the smoke table) such that no new smoke can appear, you might get unexpected results (or no effect). Hobbes: One strange thing that can happen when there's already too much smoke on the map and an object with [54]=1 explodes is that the alien dies and in the dying animation there's smoke on that square. Just in the dying animation, not after he's down? -MTR - I can't remember right now if the smoke remains afterward. Next time it happens I will check it Hobbes 12:00, 18 Nov 2005 (PST) There are no "naturally occuring" HE explosives tiles in UFO. All explosive objects are MCD[54]=1. TFTD uses both values for [54], 0 (more common, like the barrels on Port) and 1 (the Synomium device on Grunge/Artifact Site).
55	0x37	Strength of explosion when tile is destroyed.
56	0x38	Smoke blockage. This is set to 0 for all UFO tiles! Perhaps [36] is used only? A varying [56] might have been where the 2 un-used smoke sprites would have come in. --Danial
57	0x39	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 0: No Special Properties 0: No Special Properties 1: Starting Point (place to Abort mission) 1: Starting Point (place to Abort mission) 2: UFO Power Source 2: Ion-Beam Accelerators 3: UFO Navigation 3: Target for Destruction 4: UFO Construction 4: Magnetic Navigation 5: Alien Food 5: Alien Cryogenics 6: Alien Reproduction 6: Alien Cloning 7: Alien Entertainment 7: Alien Learning Arrays 8: Alien Surgery 8: Alien Implanter 9: Examination Room 9: Alien Sub Construction (unconfirmed) 10: Alien Alloys 10: Aqua Plastics 11: Alien Habitat 11: Examination Room 12: Dead Tile 12: Dead Tile 13: End Point (from surface of Mars to base) 13: End Point (entrance to next stage of multi-part missions) 14: Alien Brain (final mission victory condition) 14: T'leth Power Cylinders (final mission victory condition)
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.
61	0x3D	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. Some kind of pointer?

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):

X-COM MCD Files File Terrain Records avenger Avenger 59 barn Farm 29 blanks All 2 brain Alien Base 4 cultivat Farm 37 desert Desert 66 forest Forest 83 frniture City 26 jungle Jungle 82 lightnin Lightning 42 mars Cydonia 36 mount Mountain 78 plane Skyranger 65 polar Polar 81 roads City 23 ufo1 Small Scout 20 urban City 112 urbits City 25 u_base Alien Base 67 u_bits UFOs 8 u_disec2 UFOs 17 u_ext02 UFOs 34 u_oper2 UFOs 15 u_pods UFO/Alien Base 11 u_wall02 UFO/Alien Base/Cydonia 47 xbase1 X-COM Base 97 xbase2 X-COM Base 62

TFTD MCD Files File Terrain Records asunk Sunken Galleon 50 atlantis Atlantis 77 barracud Barracuda 46 blanks All 2 cargo1 Cargo Ship 103 cargo2 Cargo Ship 13 cargo3 Cargo Ship 6 coral Coral 28 crypt1 Crypt 45 crypt2 Crypt 49 crypt3 Crypt 12 crypt4 Crypt 7 debris Seabed 50 deckc Liner Ship (Top) 18 entry Entry 12 grunge1 Artifact Site 38 grunge2 Artifact Site 8 grunge3 Artifact Site 10 grunge4 Artifact Site 37 hammer Hammerhead 44 island1 Island 50 island2 Island 50 island3 Island 35 leviath Leviathan 47 linera Liner Ship 99 linerb Liner Ship 24 linerc Liner Ship 40 linerd Liner Ship 23 manta Manta 44 msunk1 Sunken Ship 50 msunk2 Sunken Ship 29 mu Mu 80 organic1 Alien Base/Level/Entry 96 organic2 Alien Base/Level 10 organic3 Alien Base/Level 4 pipes Pipes 55 planes Sunken Plane 79 port01 Port 95 port02 Port 78 psynom Alien Base/Level 2 pyramid Artifact 24 rocks Artifact/Seabed/Galleon 15 sand several 20 sea several 18 triton Triton 46 uext1 ? 4 uext2 USO/Entry 9 uext3 USO/Entry 25 ufobits several 5 uint1 USO 41 uint2 USO 11 uint3 USO 14 volc Volcanic 80 weeds Artifact/Coral/Seabed 10 xbases1 X-COM Base 87 xbases2 X-COM Base 42 xbases3 X-COM Base 37 xbases4 X-COM Base 43 xbases5 X-COM Base 42 xbits Cargo Ship 39

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!

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.