Talk:MCD

52: Footstep sound effect.

I didn't log in because I don't have an account... yet. I looks like I was wrong on the arctic terrain, I thought it uses sand effect, but I checked it's actually normal (2).

---

I've started writing a section on Terrain/Map Editing and the technical portion (the structure of the MCD files and so on) has been already presented here. Should I add the Terrain Editing material to this page or start a new one? Hobbes 19:39, 18 Nov 2005 (PST)

---

I am wondering if we might not have a major restructuring of all this stuff. Instead of first "Under the Hood", then "Game File Analysis", and then on yet another link, "Saved Games"... I think these parts warrant enough attention (at least by many wiki regulars) that they have their own link off the main page, and then something like this structure:

 Overviews
 (right here goes overviews of everything, then:)
   Main Programs And Data
   Savegame Files
 Specific Directories And Files
   Main Programs And Data
   Savegame Files

Something like that... ANY suggestions welcome, but I think it's time to revamp the lot of it to show it's importance to many regulars, and leave places for overviews versus specific things.

Edit: To answer you more specifically, Hobbes: Choose your place; a general place is fine for me. I think we should overhaul the whole structure. I think it's grown past its original little pecks and nibbles.

What do the rest of you think? ---MikeTheRed 19:58, 18 Nov 2005 (PST)

---

Sounds spiffy. --Danial 20:01, 18 Nov 2005 (PST)

---

Yup, I was planning on doing something like that later on... We'll have to do it a few times as we introduce more pages, in order to keep everything easy to find.

--Bomb Bloke 20:59, 18 Nov 2005 (PST)

Offsets 22-29 / 0x16-0x1D

They seem to be the same as 2-9 bytes of UnitRef table. After MCD loading they are filled with pointers to appropriate pck/tab.

 v60 = &a_mcd_data[result];
 v60->field_1A_pck = a_TileSet_Catalog[v_BF_Tileset_Cnt].pck;
 v60->field_16_tab = a_TileSet_Catalog[v_BF_Tileset_Cnt].tab;

I've found this the same way as for unit pck/tab pointers. --Volutar 14:27, 21 February 2011 (EST)

Offset 47 / 0x2F

It is set to 1 when the MCD data is used as an opened door tile type. It is only set at runtime when a door is opened. Since MCD data is not saved, this explains the door jam bug that makes the doors stay opened when you reload. You can test that on the medium scout ship: if you open the door to the central reactor room and save/reload, the door will stay stuck. If you now open a door of the same type (and same orientation) and end the turn, the door to the reactor chamber will be closed again on the next turn. Seb76 14:18, 13 December 2008 (CST)

Offset 51 / 0x33

Who said this is LIGHT block? Game uses this field in calculations of explosion wave permeability, so it apparently should be called "explosion block" Function at address .text:00417F40 refers to this field and to the table (dimensions is 11x17: 11 block values for 17 levels of intensity) at .data:0046C45C. This function is used for calculation of how much explosion will come from x/y/z to its neighbour x1/y1. --Volutar 14:28, 15 April 2011 (EDT)

It's not that easy as it meets the eye. This function (using field 51) works only for second chained explosion. It doesn't create lot of smoke comparing to original and first chained explosions...

Does anyone have particular observation of such non standard explosions behaviour? --Volutar 05:55, 16 April 2011 (EDT)

This field indeed was ment to be used for lighing calculation (they were using same function for explosion field calculation and for lighting). But they calceled use of this function for light blocking, I dont know why, maybe its results wasn't very good. Still they've left this "lighting" function and it is used after first chained explosion (original, chained1,(enabling!), chained2, chained3, etc). Results are quite unpredictable, since intensivity more than 16 cause getting out of bounds. If you manage to get to this second chained explosion you may notice it looks weird.

void DoExplosion(x,y,z,intens,radius)
{
  isExplosion=1;
  ClearChainedExplBuffer();
  CalcExplosionLightMap(x,y,z,intense,radius); //<--- depending on isExplosion it calculates damage field or lighting
  ApplyExplosionDamage(); //<--- adds chained, if something with flag "HE" got exploded
  while(!ChainedExplosionsEOF())
  { 
    GetNextChainedExplosion(&x,&y,&z,&intense,&radius)
    CalcExplosionLightMap(x,y,z,intense,radius);
    ApplyExplosionDamage(); 
    isExplosion=0; /// <--- WHY??? Obviously a bug
  }
  isExplosion=0;
}

BTW, there are only 50 chained explosions possible, 51th won't explode. --Volutar 06:41, 16 April 2011 (EDT)

MCDedit

Urgh. MCDedit and support files are gone. Anyone want to put it somewhere more ... permanent? Strategycore files section, for example? Knan 21:25, 13 March 2009 (EDT)

It's been in StrategyCore's files section for years now. Clicky. :) --Zombie 21:52, 13 March 2009 (EDT)

Right. Only went looking in the Editors section, Maps didn't register on the radar. --Knan 17:47, 14 March 2009 (EDT)

Ground with TUs = 0

There are at least 2 ground tiles which consumes 0 TUs to walk through them. Interesting thing, that pathfinder deny walk directly on them, you can only walk through. These are 6 and 7 tiles in U_BITS tileset. --Volutar 08:02, 12 October 2011 (EDT)

Offset 38 (0x26)

 Zombie: 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.

Where is it "defined"? It's not used in the game code AT ALL. There is no check whether it 3,2 or 1. What map designer do you mean?

I seems to me as just a fantasy. --Volutar (talk) 10:34, 19 June 2015 (EDT)

Before you accuse me of being delusional or making stuff up, consider that I am working directly off of dev comments from part of the ACTUAL C code from UFO which I received recently. It's commented in there plain as day. Whether it is actually used in-game anymore is not a earth shattering concern - providing explanations to the remaining unknowns is what I'm after. The burden of proof lies in testing or code digging to see if it is used or not. (You are more than welcome to provide any additional information you can find out). And before this discussion degrades into a "but you only have it, I can't trust you unless I can see it myself" issue, no, you may not get the C code until I can get it cleared through 2K/Firaxis. --Zombie (talk) 01:08, 20 June 2015 (EDT)

I wasn't going to accuse you, it's just... this info is too "out of nowhere" tho _pretty_ detailed, that I suspected it might be the real game source (if I remember correctly they claimed it was simply "lost"). My sources are just reversed exes, tho I tried to dig up through everything I could. Of course they don't contain any comments or var names to figure out something about structure members which actually were "optimized" and thrown away from EXE as not used. Of course initially they must be having some purpose devs quitted eventually. And of course I trust you. Partial tile rendering COULD be used for some volumetric tiles like wheat, and for some reason that concept was rejected. But structure member remains. --Volutar (talk) 03:45, 20 June 2015 (EDT)