UFOpaedia - User contributions [en]

User:Daiky

2013-05-22T13:15:28Z

Daiky:

I'm a programmer and xcom fan, struggling to find a way to create an "improved" xcom since 2006.
After having coded a somewhat playable battlescape, using a 3D engine called Irrlicht, I bumped into openxcom in 2010 which had no battlescape by then.
I decided to abandon my own project and use my knowledge and free time to start coding the battlescape for openxcom.

[http://www.openxcom.org/ OpenXcom]

ROUTES.DAT

2012-09-23T08:15:26Z

Daiky:

This file is only used by tactical saves.

It is a collection of all nodes on the map, and uses much the same format as the .RMP files in the [[ROUTES|routes]] folder. Aliens and civilians are placed randomly amongst these nodes when combat begins, and (prior to spotting your units) patrol between them.

If a unit cannot be placed because you've run out of appropriate nodes, it'll use a non-appropriate node instead. This means that sometimes alien leaders won't be inside their ships.

X-Com units don't spawn according to these nodes if you use an Avenger. Need to test the other craft, and base offense/defense missions. - BB

After a new tactical map has been generated from the small map sections, the records are read from the corresponding .RMP files in order of left to right, top to bottom. However the X-Com and Alien craft nodes are always saved until last, and so appear at the end of the file.

Each record is 24 bytes, so the total file size is equal to that times the amount of records in the entire map. Decimal/Hex offsets:

== Structure ==
0/00 - Y position of node.

1/01 - X position of node.

2/02 - Z position of node.

3/03 - Map section counter. All nodes from the first map segment will have this flagged as 0, the nodes from the next map segment as 1, the next segment 2, and so on.

4/04 - 18/12 - Each node can connect to multiple other nodes. These 15 bytes contain 5 records of 3 bytes each, detailing those connections:
*0 - The record number of the connected node. 255/FF if unused. When the game engine pieces the small map segments together, if an external node can't be connected, the spare connection record will be disabled. A common example is a connection that would make a unit walk off the playing field. For external node connections this number is FE:North, FD:East, FC:South, FB:West.
*1 - The distance to the connected node. If the connected node was not originally in the same .RMP file, this is calculated by adding the two connection distances together.
*2 - The type of unit that can travel along this connection.
0 = Any
1 = Flying
2 = Flying Large
3 = Large
4 = Small
<blockquote>Check the discussion page for these values, because they are probably wrong</blockquote>

19/13 - The type of unit that can spawn at this node.
0 = Any
1 = Flying Small
2 = Small
3 = Flying Large
4 = Large

<blockquote>Check the discussion page for these values, because they are probably wrong</blockquote>
<blockquote>At least, modulo 8. The above is exhaustive only for reference data in the routes folder, and non-UFO nodes in Battlescape saves.

Bit 3 (value 8) is set for nodes where an alien starts. Whether the alien is alive, or dead from power plant explosion, is irrelevant.

Bit 4 (value 16) may be set for nodes sourced from UFO reference data...and furthermore is sometimes changed by processing during the alien turn for these nodes. Presumed (needs more testing): in patrol mode nodes sourced from UFO reference data, the AI explicitly prefers (but is not guaranteed to) to stop moving on nodes with bit 4 set.

Bits 5-7 are uniformly 0 for medium scouts. Other UFO types have not been verified yet. Neither have terror sites or alien bases.</blockquote>

20/14 - The rank, or the team, of unit that can spawn at this node. (Misc1 is only used on TFTD, Misc2 appears on both games)

0 = Civilian / "Scout"
1 = X-Com
2 = Alien Soldier
3 = Alien Navigator
4 = Alien Leader / Commander
5 = Alien Engineer
6 = "Misc1"
7 = Alien Medic
8 = "Misc2"

21/15 - Ranges from 0 to 8, Daishiva calls this the "flags" byte. Governs whether an alien will attempt to destroy a base module. Apparently, the higher the number, the greater the chance the aliens will start shooting. So far, this has only been tested on an X-COM base defense mission but seems to hold. No other maps or modules have been tried.

An alternative explanation is that the number indicates the 'importance' of the node when the aliens are conducting their patrols. Using Bomb Bloke's graphics I've superimposed on the Battleship map the values for this flag on all the nodes:

[[File:Ufo_160_0_flags.gif]]
[[File:Ufo_160_1_flags.gif]]
[[File:Ufo_160_2_flags.gif]]

According to this theory the aliens will choose a node with the higher value 'flag' when their AI is set for patroling/guarding, unless it is already occupied. The Battleship schematics above show some proof of this, specially on the bridge area (the aliens that start on the bridge room usually never come out except to have a look outside the door). Now look at the plants for the Supply Ship:

[[File:Ufo_170_0_flag.gif]]
[[File:Ufo_170_1_flag.gif]]
[[File:Ufo_170_2_flag.gif]]

The ground and first level almost contains nodes with a 1 value, with a single exception - the 3 and 2 of the engine room. This should explain the aliens' behaviour of only using 1 of the UFO's 2 doors - when an alien moves into the node outside the door, it chooses instead to go to the node with the 3 value, and then to the 2 value, diverting the aliens from the 2nd outside door.

[[File:Ufo_140_0_flag.gif]]
[[File:Ufo_140_1_flag.gif]]

Next one is the Abductor. Usually the aliens don't come out much and you find a large number of them on the main chamber on the ground, due to the concentration of 3/4s that acts as a bottleneck.

Finally here's the remaining medium/large UFOs. Usually the higher value of this byte also corresponds to a high value on 23/17 (which makes sense due to the importance of the node to increase the probability of units spawned there - [[User:Hobbes|Hobbes]] 19:05, 27 January 2012 (EST))

[[File:Ufo_120_0_flag.gif]]
[[File:Ufo_150_0_flag.gif]]
[[File:Ufo_150_1_flag.gif]]

[[File:Ufo_130_0_flag.gif]]
[[File:Ufo_130_1_flag.gif]]
[[File:Ufo_130_2_flag.gif]]

22/16 - Always seems to be set to 0.
(the exception is also seen in TFTD, with a few maps having different values)
(there are also maps on UFO that contain this flag, such as 2 nodes on the Skyranger map that have a value of 10, 1 node on the Battleships that has a 1 value, etc. - some of those look more like coding errors though)

23/17 - Ranges from 0 to 10, Daishiva calls this the "spawn" byte. A value of 0 makes it impossible for a unit to spawn there.

==See Also==
* [[ROUTES|Routes Folder]]
* [[Alien_movement_patterns|Alien Movement Patterns]]
* [[Saved_Game_Files#Battlescape_Files|Battlescape Files]]
[[Category:Game Files]]

Differences to X-COM (OpenXcom)

2012-01-13T21:50:55Z

Daiky:

== General ==
* None of [[Known Bugs|these bugs]].
* Mouse wheel support.
* Caret on text editing.
* No CPU-based speed.
* Mouse input works like modern systems.
* Different savegame format.
* Unicode support.

== Geoscape ==
* Since there's no 80 item limit, items in crafts count towards your [[Base Stores]] to prevent exploiting infinite storage. This also lets you freely move items between bases and crafts without storage issues.
* Each radar facility performs its own detection check, so having multiple [[Small Radar System]]s and/or [[Large Radar System]]s ''does'' improve your chances. The [[Hyperwave Decoder]] still makes all other facilities obsolete though since it has a 100% detection chance.
* The craft phase order when returning to base is: [[Repairs|Repairing]], [[Rearming]], [[Refueling]].
* Stores column in Purchase/Recruit screen.
* Can disarm weapons from crafts.
* Can cancel out of selecting armor for soldiers.
* Selling crafts automatically unequips all their contents.
* No gap in Australasia zone.

== Battlescape ==
* Right-click opens doors.
* Right-click to cancel a unit walking.
* Objects, fire and smoke keeps animating while walking or scrolling the screen.
* Pathfinding is a different algorithm: it will always find a solution, if there is one, no matter how difficult.
* AI of aliens is different (in progress). - Impossible to 100% exactly mimic original AI.
* Explosions are not confined to one level.

== Optional features ==
While the above differences are hardcoded, there are also various new "hidden" features you can choose to enable.
* Alternative grenade handling: when priming a grenade you don't get the "set timer" screen. When throwing the grenade it will immediatly explode on impact.
* Preview path: when choosing the target to move towards with your current unit, it will draw the path on the ground. Tiles will be painted green for how far you can move without running out of TUs. You need to click a second time to make the unit move.
* Range based accuracy: this modifies the accuracy based on the distance from the target. The accuracy decreases linearly (2% per tile or 0.125% per voxel) when shooting beyond the limit of the firing mode: auto shot: 7 tiles or 112 voxels, snap shot: 15 tiles or 240 voxels, aimed shot: no penalty

See [[Customizing (OpenXcom)]]

[[Category:OpenXcom]]

Talk:Night Missions

2012-01-13T20:01:52Z

Daiky:

Do mind controlled aliens see 9 spaces or 20 at night?

What about alien controlled X-com agents? [[User:Jasonred|Jasonred]]

:Mind controlled aliens seem to see the full 20 spaces at night from what I recall. The light around them is only 9 spaces, but they can see aliens shrouded in shadow at further distances. For X-COM soldiers under mind control, it'd be hard to tell. From how it works with the aliens, I'd assume no, but since the computer has been known to cheat, they might see 20 spaces. Not that it matters much, since Night Missions often take a long time and after turn 20 the AI no longer has to deal with Fog of War. [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:29, 28 February 2009 (CST)

== Alien night vision ==
Actually in my opinion there is no such thing as alien night vision. The soldiers are lightbulbs, there is no night vision needed to see a light bulb moving around at night... The aliens are smarter: they stay hidden in the darkness. Suppose a soldier could turn out his personal light to remain unseen to the aliens, then it would be interesting... using only the motion scanner for example.
--[[User:Daiky|Daiky]] 15:01, 13 January 2012 (EST)

Talk:Night Missions

2012-01-13T20:01:31Z

Daiky:

Do mind controlled aliens see 9 spaces or 20 at night?

What about alien controlled X-com agents? [[User:Jasonred|Jasonred]]

:Mind controlled aliens seem to see the full 20 spaces at night from what I recall. The light around them is only 9 spaces, but they can see aliens shrouded in shadow at further distances. For X-COM soldiers under mind control, it'd be hard to tell. From how it works with the aliens, I'd assume no, but since the computer has been known to cheat, they might see 20 spaces. Not that it matters much, since Night Missions often take a long time and after turn 20 the AI no longer has to deal with Fog of War. [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:29, 28 February 2009 (CST)

== Alien night vision ==
Actually there is no such thing as alien night vision. The soldiers are lightbulbs, there is no night vision needed to see a light bulb moving around at night... The aliens are smarter: they stay hidden in the darkness. Suppose a soldier could turn out his personal light to remain unseen to the aliens, then it would be interesting... using only the motion scanner for example.
--[[User:Daiky|Daiky]] 15:01, 13 January 2012 (EST)

Talk:UNITREF.DAT

2012-01-06T10:56:39Z

Daiky: /* Offset 0x2B (43) */

Anyone who has it - can we get listings of values for various aliens on the Unitref page, for some of the variables found in both Unitref and the Geoscape [[Talk:Overviews_of_Aliens|Alien stats]]? E.g. energy recharge (Unitref[35]), energy loss [45]... like what Danial did for Height. Some of it might go to NKF's redesigned [[Soldier]] page. I am trying to flesh out the Geoscape data so I know what everything is there (and can then extend it across difficulty levels). It has unlabelled fields with values, some of which I know must be these values... but there's no list for me to compare against. Thanks if you can help! ---[[User:MikeTheRed|MikeTheRed]] 19:37, 25 Nov 2005 (PST)

P.S. We probably should clean up this Discussion some time. I will if I find the time to make sure everything has made its way to wherever it should go.

----

== Offsets 0x02 - 0x09 ==

It's obvious from unit drawing functions (reversed ones) it's a PCK and TAB spritepack reference address (DWORD).

_pck = (int)unitref_addr->pck_ref;
_tab = (int)unitref_addr->tab_ref;
...
if ( (_WORD)handob != 255 )
xc_BF_Draw_Battlescape_shaded_Sprite((char)v18, (int)vf_handob_pck, (int)vf_handob_tab, v21, v23, shade);
xc_BF_Draw_Battlescape_shaded_Sprite(sprite_num1, _pck, _tab, y0, x0, shade);
--[[User:Volutar|Volutar]] 09:43, 20 February 2011 (EST)

:So you're saying these values point to where the PCK/TAB files used by the unit in concern have been loaded into RAM, similar to how [[UNITPOS.DAT|UnitPos[4-7]]] points to where the UnitRef record is? -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 17:56, 20 February 2011 (EST)
::Exactly. They are simple 32bit pointers to RAM location where exact unit PCK/TAB loaded (I don't know how they worked for DOS version - I guess the same way). You could notice the lowest bytes (2th and 6th) are aligned to 4, as for all memory locations. --[[User:Volutar|Volutar]] 01:13, 21 February 2011 (EST)

::: Since the saves are interchangeable between the Dos and Window versions, and since the Dos version uses the Dos4gw engine to handle the exapanded memory, it could very well be a 32-bit pointer.

::: Still, memory pointers? That would mean these values are used at run-time only and these are just dumps of whatever it was at the time the save was made. Since whatever memory allocation function they used back then (I'm guessing malloc() ) would be storing the graphics at different offsets each time the tactical engine boots up, these would have to be replaced anyway. -[[User:NKF|NKF]] 02:00, 21 February 2011 (EST)

.text:004178EC
cur_unitref_addr = vf_unitref_dat;
i1 = 80;
do
{
if ( cur_unitref_addr->unitType != -1 )
{
unittype_offset = 8 * cur_unitref_addr->unitType;
pck_addr = *(a_allocated_pck_array_dword_4ADE40 + unittype_offset);
tab_addr = *(a_allocated_tab_array_dword_4ADE44 + unittype_offset);
cur_unitref_addr->pck_ref_off02 = pck_addr;
cur_unitref_addr->tab_ref_off06 = tab_addr;
}
cur_unitref_addr = (cur_unitref_addr + 124);
--i1;
}
while ( i1 );

:::: This called each time after setting up or loading UnitRef table. So according this code you can wipe these bytes without any effect, since these values overriden each time.--[[User:Volutar|Volutar]] 03:13, 21 February 2011 (EST)

:::::The save games contain a lot of stuff that's only relevant at runtime, on the basis that it was easier just to write (and then later read) these arrays straight to/from disk then it was to reformat them each time (sorta like how the entirety of MISDATA.DAT gets saved/loaded despite most of it being irrelevant most of the time). I'd been suspecting these to be pointers ever since Seb found the one in UnitPos, but I had no idea ''what'' they were pointing at, and I doubt I'd've ever worked it out. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 07:11, 21 February 2011 (EST)

== Offsets 0x30 & 0x34 ==

I've chopped out the majority of this page as it is no longer required. I'm keeping the heights chart in case it is required - I've also changed the "H-F" field to "H+F", as this actually makes sense.
[49] [51] "Tall" [48] | [49] [48]
Class Ht. Flt H+F Wide | Ht. Wide Area
--------- --- --- ---- ---- | --- ---- ----
Sectoid 16 0 16 2 | 16 2 32 Area=Ht.*Wide
Celatid 12 6 18 3 | 12 3 36
Hovertank* 12 6 18 4 | 12 4 48
Silacoid 10 0 10 5 | 10 5 50
Snakeman 18 0 18 3 | 18 3 54
Zombie 18 0 18 3 | 18 3 54
Cyberdisc 15 2 17 4 | 15 4 60
Ethereal 20 0 20 3 | 20 3 60 ''All Hover/Tanks in their
Chryssalid 21 0 21 3 | 21 3 63 ''class assumed to be same
Civilian 21 2 23 3 | 21 3 63 ''altho not tested yet
Floater 21 2 23 3 | 21 3 63
Muton 21 0 21 3 | 21 3 63
Tank* 16 0 16 4 | 16 4 64
Soldier 22 0 22 3 | 22 3 66
Reaper 23 0 23 4 | 23 4 92
Sectopod 23 0 23 4 | 23 4 92

Anyway, unitref[48] and unitref[52] remain somewhat of a mystery. Thus far we've assumed them to be the unit's width. Today I tried tinkering with [48] to see of this was correct. As I cranked it up, I found no change in my accuracy, or as to how the Sectoid target blocked line of fire to the tiles behind it.

When it reached the value of 37, however, the alien disappeared! I could not view it regardless of distance. In fact, I could even fire right through the tile it was standing on with no obstruction. The only sign that the alien was still there was the fact that my unit could not stand on the same square.

I lowered [48] a bit and tried viewing the alien from different distances, and found that it appeared in the same way as it usually would, regardless of the value used. It's simply the case that going to 37 or above makes the alien invisible.

I also tweaked [52] a bit, but found that it seemed to have no similar effects, if any at all.

Although I haven't tested this any further as yet, it might be possible to use this effect in reverse - Create an 'invisible' X-Com unit, and use it to observe how aliens act when they think we're not looking.

- [[User:Bomb Bloke|Bomb Bloke]] 00:44, 31 July 2006 (PDT)

----

I have a strong belief that offset 48 is nothing else but the loftemps.dat entry used for collision checking with bullets. A first check is done against the unit height (taking into account floating height, terrain height, kneeling). If the check is OK, the loftemps entry is then used as a final check (effectively treating the unit as a cylinder). I'll try to decypher the code further. If others want to have a look, the code is around here:
.text:004116AE 8B 15 5C 28 4A 00 mov edx, pUnitPos
...
[[User:Seb76|Seb76]] 13:24, 10 April 2008 (PDT)

----

I'm inclined to agree with you, though I'm not much good at reading through executable code. :( I hit on the same idea on my [[User_talk:Bomb_Bloke|talk page]]... I've got some notes in there about how I think the firing system works, if you could find code to back it up I'd be a happy boy.

It's something of a long winded work-in-progress ramble, and I'm sure some parts are confusing and/or dead wrong, but with any luck you can make some sort of sense of it. :) - [[User:Bomb Bloke|Bomb Bloke]] 18:34, 11 April 2008 (PDT)

----

[[Image:Loftemps.png|thumb|right]]I mentionned it earlier but got no real feedback so I'm adding a new section for it ;)
It looks like it is the loftemps entry used for collision detection with bullets. The main page says that setting it to 37 make the shots go right through the guys. If you have a look at the entry, you'll see why... The interesting thing is that the big units do not have special entries (unitref is common for all 4 parts so it would not have been possible to do otherwise) so a shot should be able to go through them (between the 4 parts). However, for the shot to be almost horizontal (or vertical) and traveling at the frontier between tiles (to go between the 4 "collision" circles), the shot should come from far far away so it is not likely to happened. Also depending on how the visibility check is performed, it may explain why alien suddenly disappeared when messing with the value (see discussion upper in this page). I suspect it is done using some kind of raytracing between the center of the 2 tiles (between the current unit and the target); so if the loftemps entry for the target has a "hole" in its center, it may become invisible. [[User:Seb76|Seb76]] 07:00, 1 June 2008 (PDT)

----

I just edited unitref 048 and 052 of all my soldiers to 0 and the aliens never tried to shoot at me. When I edited 048 to 0 for all the Sectoids on a mission, my soldiers couldn't see them anymore (only takes effect the following round if edited in unitef.dat, but surprisingly aliens remain visible to you during their movement phase). Since loftemps 0 is an empty cell, the results make perfect sense. A value of 76 (both 48&52) makes aliens disappear too. I'm not sure what the threshold is for disappearing, but a 3x3 block (loftemps 1) is still enough to be seen. --[[User:Zombie|Zombie]] 15:08, 17 August 2008 (PDT)

----

Am I understanding correctly... for purposes of shots hitting, we're all "barrels" with a specific diameter (i.e. [[LOFTEMPS.DAT]] 2-5), height ([49]), and distance (float) off the ground ([51])? Right or wrong, it sounds like this is finally pretty sown up, excellent work. We could update the page's entries. I wonder why they repeated this value twice (i.e. [48] and [52] always the same)... maybe they once considered the possibility of a unit whose diameter can change from turn to turn? If so, some other heretofore unfathomable UNITREF bit or byte may have been intended to dictate whether they're currently using the diameter at [48] or [52]. -[[User:MikeTheRed|MikeTheRed]] 17:06, 17 August 2008 (PDT)

----

While I've no problem believing [48] is a LOF template reference, I hadn't added it to the main page because I wanted to be sure as to it's relationship with [52].

See, at present, all we know about [52] is that it's the same as [48]. We haven't seen any effects from changing it.

What I ''suspect'' is that one offset might be used for shots traveling along an angle parallel to the target, and one offset might be used for shots traveling perpendicular. This would basically allow units to be effectively oval shaped (or it would, if [48] and [52] weren't the same for all units).

Just one of those things that I never got around to finishing the testing on. Would be dead easy to check, though.

There's still a little more to be researched before the entirety of the firing system is understood (see my talk page for a rambling explanation as to what IS known), but that's pretty much the basics of it.

- [[User:Bomb Bloke|Bomb Bloke]] 19:51, 17 August 2008 (PDT)

----

BB and others, see my edits for [48]. Does it make sense? In particular, I estimated pixel width from that little LOFTEMPS .png by magnifying it a ton. Any and all comments or edits welcomed. It's interesting that the silacoid has the highest width, but a low cross-section - did anyone see the Star Trek TOS show with the very short, wide silicon aliens? -[[User:MikeTheRed|MikeTheRed]] 22:53, 23 August 2008 (PDT)

----

Yes, you got the LOF widths correct. Though as you mentioned, they're only accurate assuming you're firing head on at your targets (as the templates aren't perfect circles, their width varies from other angles).

I threw in the kneeling soldier stats and made a note concerning large units.

- [[User:Bomb Bloke|Bomb Bloke]] 22:21, 24 August 2008 (PDT)

----

According my investigations Field52 refers to loft table to determine traced fire line collision, while Field48 used as "unit radius" when probing unit tile for sight or fire possibility, and it should be located inside of loft crossection. If its value will be beyond loft, LOF and LOS will fail at probing of unit "surface" (only central voxel could be aimed). --[[User:Volutar|Volutar]] 23:58, 18 April 2011 (EDT)

== Offset 0x3C ==

I have a gut feeling it is related to the panic/berserk status of the unit... Any volunteer for testing? [[User:Seb76|Seb76]] 10:36, 22 March 2008 (PDT)

----

Made a save where all soldiers had no morale. Ended turn, most of them panicked etc. Saved the game but that offset still came up as 0. Might only be flagged at runtime.

- [[User:Bomb Bloke|Bomb Bloke]] 18:01, 26 May 2008 (PDT)

----

I checked and indeed the game sets and clears it in the same turn so it is always 0 in a savegame and hence there is no 'black box' way of confirming it. I can provide disassembly screenshots if you want proofs however ;) [[User:Seb76|Seb76]] 05:45, 28 May 2008 (PDT)
:Actually after some thinking, it _might_ be possible... If you set the value to 3 for all entries, everyone may go berserk, with 2 they should run in fear and 1, they'll just crap their pants in place... [[User:Seb76|Seb76]] 07:09, 28 May 2008 (PDT)

----

I tried it, and indeed my units did exactly that (at the start of their next turn - not that of the aliens).

- [[User:Bomb Bloke|Bomb Bloke]] 21:08, 28 May 2008 (PDT)

== Offset 0x4A (74) ==
It seems to be some kind of AI mode, which has 4 phases - 0,1,2 and 3. Code at .text:004016C0 (CE version) shows its range. --[[User:Volutar|Volutar]] 02:00, 21 February 2011 (EST)

----

While taking a browse through the [http://www.strategycore.co.uk/files/index.php?dlid=776 pre-release game executable], I found these strings listed together in a clump:

*Patrol
*Sniper
*Combat
*Escape
*Guard
*GoUfo
*Finding Route
*Set Patrol Point
*Moving
*Firing
*Evaluating Mode
*Final Facing
*Attack Attempt
*Find Fire Point
*Select Target
*Find Cover
*Partial Cover

It struck me that the first few could relate to AI modes. Some aliens are known to choose a route node and stick with it (gaurding), and when unarmed, they'll usually run away (escaping); aliens will patrol when they don't know the location of X-COM units, though this seems to halt when turn 20 passes. Presumably these activities can be mapped to the four values. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:20, 6 February 2011 (EST)

That's a great find, BBloke. I never looked at the demo exe. While the debug fonction was deleted in the release, it permits to locate the basic AI fonctions in the code. So we have: AI_patrol_mode (0x4A = 0) at 0x0407D60, AI_Sniper_mode (0x4A = 1) at 0x04081A0, AI_combat_mode (0x4A = 2) at 0x0408430, AI_escape_mode (0x4A = 3) at 0x04067F0 and even the AI_evaluation_mode at 0x0408430, which fills offset 0x4A when it is equal to something else. Other functions can be found as well with the debug info. Fantastic. Now we could try to make AI take cover from time to time, instead of making a stupidly exposed target.--[[User:Kyrub|Kyrub]] 06:02, 13 April 2011 (EDT)

== Offset 0x6F ==
This offset seems to be corresponding for runtime "Attacking" state, not final /0 for unit name. When 1 units drawn with weapon helded in fire position, when 0 - ordinary.--[[User:Volutar|Volutar]] 17:15, 26 February 2011 (EST)
:Well spotted. :) -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 00:43, 27 February 2011 (EST)

== Offset 0x70 (112) ==
It seems to be used in realtime only as "already acted" flag for civilian and alien units...--[[User:Volutar|Volutar]] 09:19, 27 March 2011 (EDT)

== Offset 0x71 ==
Hmm, the code checks this offset before applying stun damage... It looks more like an 'immune to stun damage' flag then. Strange... [[User:Seb76|Seb76]] 13:48, 7 April 2008 (PDT)

----

By memory, the only things that use this are X-Com HWPs (which shouldn't have stun applied). It does toggle inventory access as described though it wouldn't surprise me if it also toggled stun damage.

- [[User:Bomb Bloke|Bomb Bloke]] 05:46, 8 April 2008 (PDT)

:OK, I located the check and it is exactly what happens. BTW, if you want to try something, try to patch this with nops (0x90):
.text:00412A20 A8 40 test al, 40h
.text:00412A22 0F 85 00 02 00 00 jnz exit ; default
:It should enable inventory screen for memory controlled units (could not test since I have no save files with psy units...) [[User:Seb76|Seb76]] 11:37, 8 April 2008 (PDT)

:: So, to be clear, is this the location of the inventory screen check for mind controlled alien units? And here you are disabling the check by overwriting it with NOPS? Is there a nearby section of code that does the same check for tanks? I would like to be able to override this tank inventory check in order to play with [[User:Spike#Tank mods|Tank mods]]. It looks like NOPing the check logic is the right way to do it, since if instead I toggled the 0x71 flag for the tanks, they would than also become vulnerable to Stun? Though I also I think read somewhere that if you get to the inventory screen of a tank, the game crashes. It doesn't crash if you get to the inventory screen of an Alien large unit via the Alien Inventory or Alien Pets hacks (not sure which) in your UFOExtender. I was able to arm Reapers with dual Heavy Plasma or dual Blaster Launchers. (Unpleasant. They have 0% FA so they have to run up to you and spray with the Heavy Plasma. Not a problem with the Blaster Launcher.) [[User:Spike|Spike]] 13:59, 20 August 2009 (EDT)

== Offset 0x77 ==
This isn't field at all. It just ain't even initialized anywhere, so it's obviously a garbage field. I haven't found even one place where it be used...--[[User:Volutar|Volutar]] 06:52, 27 March 2011 (EDT)

== Offset 0xB ==
The value is used together as an offset to [[MCD|MCDData]] offset 39 (describing TUs required to cross a tile walking/flying/sliding) so it most likely represent the way the unit moves. Still needs testing. [[User:Seb76|Seb76]] 13:27, 23 May 2008 (PDT)

----

I took a look at it for Snakemen and Silacoids, it's still 0 (same as it is for everything else).

But that doesn't mean it remains at 0 when the game's running. Do you mean to say that the value here + 39 = the offset in the MCD array that says how many TUs were required to move past any given obstacles in the current map location?

(That is, you'd expect to see a 2 there for sliding units?)

- [[User:Bomb Bloke|Bomb Bloke]] 05:14, 25 May 2008 (PDT)

----

Yep, exactly like that. Also it checks if the value is 0xff and prevent movement in that case. I'll try a live check with a debugger when I encounter snakemen. Maybe it's a part of code that was implemented but not put into usage. [[User:Seb76|Seb76]] 05:20, 25 May 2008 (PDT)
:Did the check and the value is indeed zero even for snakemen... BTW, is the movement type really working? I mean has anybody ever checked that e.g. snakemen really use different TU amount for tiles where TU usage is not the same between crawling and walking? [[User:Seb76|Seb76]] 06:43, 25 May 2008 (PDT)

----

Truth be told I don't remember reading of anyone doing the tests, so I had a go myself.

I tried first with the Avenger ramp, stuck it up in the air and had soldiers walk/fly onto it. Made no effect to their TU usage.

Next I rigged a Snakeman mission in the arctic, stuck one of them in the middle of a pond. It wouldn't move on it's own, and I couldn't move it under mind control.

So then I set 0xB to 2 just for that unit, and hey presto! Suddenly it was able to move freely, either under my control or otherwise. That's certainly the movement type flag... It's just not set in practise.

Still, now I'm wondering if 2 really was for sliders... It doesn't make sense that "fliers" (which I guess was supposed to include the likes of CyberDiscs, which "hover" even when on the ground) wouldn't be able to cross water, yet Snakemen could. Perhaps it should be the other way around?

- [[User:Bomb Bloke|Bomb Bloke]] 19:22, 25 May 2008 (PDT)

----

Note that there are some tiles that have 0 MP cost for sliders. - [[User:Zaimoni|Zaimoni]] 22:28, 25 May 2008 (CDT)

: Yeah, I guess that puts the clincher on it. Only fliers would really be totally unhindered by ground rubble. I've tweaked the MCD details page accordingly. - [[User:Bomb Bloke|Bomb Bloke]] 05:25, 26 May 2008 (PDT)

----

Hehe, I knew it couldn't be anything else but movement type. Yet another entry for known bugs ;) I'll check if it's possible to reenable the feature. It'll depends if it's a bug or if it was voluntarily removed I guess... [[User:Seb76|Seb76]] 04:37, 26 May 2008 (PDT)
: Did a quick check and can confirm what is said in [[GEOSCAPE.EXE#Alien_Stats|Alien Stats]] page. Offset 0xB is filled with the 3rd "unknown" value of alien stats. It is set to 0 for all entries. Could not find any other place where it could possibly be set to another value. [[User:Seb76|Seb76]] 05:17, 26 May 2008 (PDT)

----

So it's just a matter of tweaking that for all relevant units, then. However, I reckon it was left unused intentionally - I doubt the map files really contain enough variety to make it worth including.

- [[User:Bomb Bloke|Bomb Bloke]] 05:25, 26 May 2008 (PDT)

----

Since TFTD was done later with the same engine, perhaps it makes use of this? However, given that a different team made it ([http://www.lasersquadnemesis.com/AboutUs.htm Terror from the Deep was developed by Microprose using code licensed by Mythos]), developers may not have known the feature was available... [[User:Seb76|Seb76]] 07:25, 28 May 2008 (PDT)

----

I took a quick check, and sure enough found a Hallucinoid (the big flying squid thing) set to 2.

- [[User:Bomb Bloke|Bomb Bloke]] 21:31, 28 May 2008 (PDT)

== Offset 0x47 ==

The only use I could find is that of updating [[SOURCEMP.DAT|mobile light sources]] (or something like that) when the unit dies/is rendered unconscious. Could not find anything else about this flag. [[User:Seb76|Seb76]] 05:24, 29 May 2008 (PDT)

:Good work there. As a general statement, can I say - I've been waiting for somebody to disassemble XCOM :) -[[User:MikeTheRed|MikeTheRed]] 21:18, 30 May 2008 (PDT)

I sat down to do some tests with this, but didn't bother too read to closely... I was selecting/moving units around when I probably shoulda been shooting at them.

Oh well. For the record:

Moving a unit causes a light check to be done on all your units. You may not see this light if one of your units is standing in a fog-of-war covered zone (say you just mind controlled an alien and haven't selected it yet).

Selecting a unit does a fog-of-war check concerning what it can see, but does not do a light check.

Whatever this offset is has no effect on the light produced by your units, or the aliens units. Your active guys ALWAYS fully illuminate their tile (even if this is 0) and the aliens provide no illumination at all. Will have to do some tests concerning what happens when you shoot them, but it seems odd: If a unit is dead I'd expect a full light check to be done, since the unit isn't "active" it won't produce light, so I don't see how this offset is helpful there... You can't just remove the light values for this one unit because you might interfere with other nearby light sources, so you really have to calculate them all from scratch.

But likewise it seems [[MCD|MCD[58/3A]]] is similar; a street lamp is set to 1, a normal lamp to 10, but they both provide maximum illumination.

Perhaps the programmers changed their mind about the lighting system at some point? Dunno.

- [[User:Bomb Bloke|Bomb Bloke]] 07:03, 20 June 2008 (PDT)

:Some of your note reminds me of what I wrote at [[Night_Missions#Personal_lighting]] ... does that help any? (probably not) -[[User:MikeTheRed|MikeTheRed]] 16:01, 20 June 2008 (PDT)

== On Fire Flag or Timer ? ==

Do we have any idea where a flag is set to show the unit is on fire? This is persistent between saved games so it must be stored in a file somewhere. Possibly UNITPOS.DAT? It could be a flag, but more likely is either a countdown timer for turns remaining on fire, (values 1-5?), or a "what turn do I stop being on fire" timer value (like a grenade timer).

I have uploaded a saved game file with a burning Aquatoid if anyone wants to take a look. I just don't have the right diff tools. Maybe with the Hex Workshop template... [[User:Spike|Spike]] 19:05, 10 March 2009 (CDT)

:Offset 114 in Unitref holds that data. --[[User:Zombie|Zombie]] 19:15, 10 March 2009 (CDT)

:: Sorry I did not read the article carefully enough. It's in there. [[User:Spike|Spike]] 19:16, 10 March 2009 (CDT)

114 / 72: If not 0, then unit is on fire, and will burn for this amount of turns.

== Floating Civilians ==

Civilians float 2 units off the ground, like Floaters and Cyberdisks. Soldiers don't. Should we consider this to be a bug? [[User:Spike|Spike]] 13:41, 20 August 2009 (EDT)

:Probably. I really doubt it's an intentional feature. --[[User:Zombie|Zombie]] 23:09, 20 August 2009 (EDT)

== Remembering morale vs health and pain killers ==

The game remembers whether a health loss has or has not been used to regain morale via pain killers. Presumably this is stored somewhere in UNITREF.DAT? [[User:Spike|Spike]] 10:30, 5 September 2009 (EDT)

== TFTD ==

It appears the name string starts at the same point in TFTD save points, which leads me to believe that the extra bytes are probably just appended at the end of the file, without much changing in the first 124 bytes per entry, anyone know what these extra 8 bytes might represent? - [[User:Hatfarm|Hatfarm]]

----

They are indeed appended. My battlescape editor deals with TFTD's UnitRef by just adjusting for the larger record size, and then ignoring the extra bytes completely - didn't need to do anything else to make it all match up. I've yet to actually look at some sample values in order to work out what they might be for.

Incidently, you can insert signatures into your postings using four tildes (<nowiki>~~~~</nowiki>). - [[User:Bomb Bloke|Bomb Bloke]] 21:48, 20 January 2010 (EST)

== TFTD's extra bytes ==

It appears that byte 126 is a bit flag array of some sort as I have mostly seen values of 1 and 0 for it, but others have appeared. I saved a single mission at several different times and each one had 0 or 1, but a terror mission save had some different values for this, Like 0x20 and 0x4F. I tried adjusting it and checking the saved game, but nothing seemed to change...

Byte 124 I've seen values of 0,4,6,7,0x0A and 0x0E. No idea what these mean, and changing them did not do anything for me.

They appear to only be for Soldiers as well, none of the aliens in any of my saved games have values for these.
[[User:Hatfarm|Hatfarm]] 15:16, 5 June 2010 (EDT)

----

124 may have something to do with the air-bubbles that trickle up from soldiers when they're underwater - an animation counter, similar to offset 8 of [[SMOKREF.DAT]], but with a higher range (0-15, probably). Granted, there's no real reason to keep track of bubbles when saving the game, but they have to be tracked somewhere at run-time, and this seems to be the logical place (the save files are just raw dumps of RAM anyway).

In theory, if you set this to the same value for all soldiers (say 5), on loading the game, they'd all have identical air bubbles over their heads. - [[User:Bomb Bloke|Bomb Bloke]] 22:26, 5 June 2010 (EDT)

----

You're right, I set them all to 5 and they were all in the same place bubble wise,. However, they don't all "rebubble" at the same time. Good call BB. [[User:Hatfarm|Hatfarm]] 02:16, 12 June 2010 (EDT)

----

I'd guess they "rebubble" randomly, though it may be a rather more elaborate setup - bubbles might appear more often for soldiers with lower stamina levels, maybe, to indicate they're out of breath.

Unfortunately, I can't think of anything else TFTD adds that would warrant using those extra bytes at the end of the file. - [[User:Bomb Bloke|Bomb Bloke]] 05:20, 12 June 2010 (EDT)

----

I'm guessing it's a 2 byte count at least, which would account for the 124 and 125 bytes. If I think of anything for the others, I'll let you know. [[User:Hatfarm|Hatfarm]] 01:07, 13 June 2010 (EDT)

== Offset 0x2B (43) ==

This value is set for some % of alien units at map initialization stage (depending on mission type, alien craft type, and alien rank). If this field set to 1, the unit is spawned at "zero" (scout) point, otherwize appropriate rank spawn points are used. Though, if all rank points being occupied - every next unit spawned at any "zero" point.
This value also used for choosing AI patrol path.

Apparently it can be called "AI_Wanderer_Flag" or something like that.
--[[User:Volutar|Volutar]] 04:40, 26 September 2011 (EDT)
::You say it is also used for choosing AI patrol path. Does it mean that once a unit is assigned as a "scout" it will keep patrolling only on scout ranked nodes for the rest of his life? Does it also work the other way around, if a unit is not marked with this flag, it is not allowed to patrol on scout nodes? --[[User:Daiky|Daiky]] 05:56, 6 January 2012 (EST)

Talk:ROUTES.DAT

2012-01-06T10:45:38Z

Daiky: /* Offsets 0x15 (21) & 0x16 (22) */

Regarding offset 23, Zombie, were you attempting to "clarify" or "correct" it?

Previously it stated that 0-value nodes CAN spawn units, but only if all other nodes are taken...

- [[User:Bomb Bloke|Bomb Bloke]] 21:07, 26 August 2008 (PDT)

----
"Correct" it. In any case, 0-value "spawn" nodes can never have units placed there period. They are only used for alien pathfinding. If all the spawn points with values of 1 or greater get filled and there are still alien units waiting to be placed on the map yet, they don't. This follows the same basic premise as an auto-win base defense mission. --[[User:Zombie|Zombie]] 22:11, 27 August 2008 (PDT)
----
Some wild guesses about the "flags" byte on non-base missions: Aliens patrol around using the spawn points, but sometimes they "guard" a certain point. A theory is that the chance the next state is just guarding this spawnpoint is higher when the "flags" byte is higher. So they save TUs, thus making a strong defense(reaction shots). When the flags is zero, they will not stand still on the point and continue patrolling. You will notice that inside UFO's the values are higher, this makes that aliens inside UFOs have a higher defensive advantage.
So this byte can actually be called the "offensive (x-com base)/defensive (others)" decision score. --[[User:Daiky|Daiky]] 07:26, 21 July 2011 (EDT)

----

== Offset 19 (0x13) ==

According my observation this is a bit field
bit0 (1) = this node is only for flying units (mobility bit, used for '''spawning''').
bit1 (2) = this node is only for small units (used for '''spawning''').
bit2 (4) = this node is only for flying units (movement type).
bit3 (8) = this node was used for NPC placement (runtime bit).
bit4 (16) = this node is only for civilians (runtime bit, cleared when aliens nowhere else to go).
bit5 (32) = cannot be used as patrol point.
so
0 = Any (small walk, large walk, small flying, large flying)
1 = Flying (small flying, large fly)
2 = Small (small flying, small walk)
3 = Flying Small (flying small)
--[[User:Volutar|Volutar]] 05:29, 23 September 2011 (EDT)

== Offset 20 ==
Actually it's not a "rank", it's more abstract version of "rank" which is used by many ranks (if there's no other appropriate spawnpoints left). At the end of priority list are points with value 0. Same value 0 used for spawning "scout" units, which are mainly spawned outside of UFO, and just hanging around (their AI have quite different route priorities). If there is no free spawn points found - unit marked as "dead" instead of spawning.

Scout 0
Commander 4 > 3 > 5 > 8 > 7 > 2 > 0
Leader 4 > 3 > 5 > 8 > 7 > 2 > 0
Engineer 5 > 4 > 3 > 2 > 7 > 8 > 0
Medic 7 > 6 > 2 > 8 > 3 > 4 > 0
Navigator 3 > 4 > 5 > 2 > 7 > 8 > 0
Soldier 2 > 5 > 3 > 4 > 6 > 8 > 0
Terrorist 2 > 5 > 3 > 4 > 6 > 8 > 0
XCom 1 > 0 > 2

So, 1st priority spawn points confirmed to be as they listed on main page. But almost any of these spawn point can be used by number of alien ranks, not only by those you assigned to.

0 = Scout/Any rank
1 = X-Com
2 = Soldier/Terrorist, Medic, Engineer/Navigator, Commander/Leader
3 = Navigator, Commander/Leader, Engineer/Soldier/Terrorist, Medic
4 = Commander/Leader, Engineer/Navigator, Soldier/Terrorist, Medic
5 = Engineer, Commander/Leader/Navigator
6 = ..., Medic, Soldier/Terrorist
7 = Medic, Commander/Leader/Engineer/Navigator
8 = ..., Commander/Leader/Medic, Engineer/Navigator/Soldier/Terrorist
--[[User:Volutar|Volutar]] 03:21, 26 September 2011 (EDT)

little note: "scout" is also a civilian spawn node, they also only spawn at 0 --[[User:Daiky|Daiky]] 15:30, 30 December 2011 (EST)

== Node link offset 2 (travel unit type) ==

This is a bitfield with values as mask for kind of units.

bit0 (1) = this node is only for units in fly mode (mobility bit).
bit1 (2) = this node is only for small units.
bit2 (4) = this node is only for flying units (movement type).
*bit3 (8) = this link was already processed for path estimation (runtime bit).

so
0= any units
1= units of any size in fly mode
2= small units flying or not
3= small units in fly mode
4= any size of flyers
5= any size of flyers in fly mode
6= small flyers
7= small flying flyers

Actually I dont know why there are TWO bits (0 and 2) which stand for flying... AFAIR every flying alien unit unable to walk, so they always have movement type "Fly" and mobility bit "fly mode" (like floaters, who are unable to use steps). Probably some of walking alien units was planned to have flying abilities, but abandoned for some reason.
--[[User:Volutar|Volutar]] 01:51, 27 September 2011 (EDT)

== Offsets 0x15 (21) & 0x16 (22) ==

They seems to be used for AI patrol route distortion for BaseDefence mission type.
Before (and including) 30th turn of battle Aliens seems to be attracted by route nodes having one of these (or both) flags set (as boolean field). It's more like a target points, and they seems to be not interested in others at all. But after 30th turn of battle Aliens seems to be wandering all over the place without paying attention on these flags.

It can be confirmed by clearing all these flags from XCOM base module maps, and setting them only for "lift" module nodes. Apparently they will be swarming around lift area, without trying to get somwehere else. But after 30 turn they must scatter.
--[[User:Volutar|Volutar]] 00:05, 28 September 2011 (EDT)
Yes, this was confirmed. Though if Alien spots your unit, it will pursue (in Snipe mode), no matter what routes and flags are
--[[User:Volutar|Volutar]] 00:51, 28 September 2011 (EDT)

I wonder why there are so-called targetpoints (flags 5 in base defense) in the small rooms around the hangar?
Also, on terror sites there are flags 1 (and I found a flags 2 on a roof). They seem to be somewhat random, however on maps with buildings, the nodes with flags 1 are mostly inside. An explanation may be that aliens are attracted to these flags 1 nodes as targetpoints, making aliens targetting the inside of buildings to terrorise civilians.
On larger UFOs, the flags seems to have the same value as priority? Which might be an error in the data? Or maybe the flags values are not used in UFOs at all. There is a theory that until a certain turn aliens will prefer to stay inside and around the UFO before spreading to the outside, this might be controlled by this flags.
On other terrain once and a while there is a flags 1 value, the rest is 0. It could be aliens walk around and stand still and look around on the nodes with flags 1.
--[[User:Daiky|Daiky]] 15:45, 5 January 2012 (EST)
:Regarding the small rooms I've seen aliens hiding on those, I can't remember if their are spawn points also though. I've made quite a few attempts are figuring out what the values meant on terrain modes I've created, usually based on the assumption that the higher the number on the flag the more the AI would 'choose' to go to that point. Can't really say that it worked all the time.
:I've always disregarded the theory that aliens leave their craft after turn 8. While it may seem that way, a more easy explanation is simply that the more aliens you have on a confined space, the longer it will take for them to reach the outside because they will block each other's movement (unless they spot a hostile unit, their scouting mode seems to be to go from one waypoint to the other unless they are blocked). Again most of this can't be exactly trusted because without some sort of proof, which I dont have other than observation. [[User:Hobbes|Hobbes]] 19:20, 5 January 2012 (EST)
::"the higher the number on the flag the more the AI would 'choose' to go to that point."; I also think this is a "weight" value when evaluating the next target node, but it's possible there is still some randomness on top of that, otherwise alien behaviour could become too predictable.
::Note that offset 0x2B (43) on unitref.dat also has something to do with pathfinding...
::--[[User:Daiky|Daiky]] 05:45, 6 January 2012 (EST)

Talk:ROUTES.DAT

2012-01-06T10:40:13Z

Daiky: /* Offsets 0x15 (21) & 0x16 (22) */

Regarding offset 23, Zombie, were you attempting to "clarify" or "correct" it?

Previously it stated that 0-value nodes CAN spawn units, but only if all other nodes are taken...

- [[User:Bomb Bloke|Bomb Bloke]] 21:07, 26 August 2008 (PDT)

----
"Correct" it. In any case, 0-value "spawn" nodes can never have units placed there period. They are only used for alien pathfinding. If all the spawn points with values of 1 or greater get filled and there are still alien units waiting to be placed on the map yet, they don't. This follows the same basic premise as an auto-win base defense mission. --[[User:Zombie|Zombie]] 22:11, 27 August 2008 (PDT)
----
Some wild guesses about the "flags" byte on non-base missions: Aliens patrol around using the spawn points, but sometimes they "guard" a certain point. A theory is that the chance the next state is just guarding this spawnpoint is higher when the "flags" byte is higher. So they save TUs, thus making a strong defense(reaction shots). When the flags is zero, they will not stand still on the point and continue patrolling. You will notice that inside UFO's the values are higher, this makes that aliens inside UFOs have a higher defensive advantage.
So this byte can actually be called the "offensive (x-com base)/defensive (others)" decision score. --[[User:Daiky|Daiky]] 07:26, 21 July 2011 (EDT)

----

== Offset 19 (0x13) ==

According my observation this is a bit field
bit0 (1) = this node is only for flying units (mobility bit, used for '''spawning''').
bit1 (2) = this node is only for small units (used for '''spawning''').
bit2 (4) = this node is only for flying units (movement type).
bit3 (8) = this node was used for NPC placement (runtime bit).
bit4 (16) = this node is only for civilians (runtime bit, cleared when aliens nowhere else to go).
bit5 (32) = cannot be used as patrol point.
so
0 = Any (small walk, large walk, small flying, large flying)
1 = Flying (small flying, large fly)
2 = Small (small flying, small walk)
3 = Flying Small (flying small)
--[[User:Volutar|Volutar]] 05:29, 23 September 2011 (EDT)

== Offset 20 ==
Actually it's not a "rank", it's more abstract version of "rank" which is used by many ranks (if there's no other appropriate spawnpoints left). At the end of priority list are points with value 0. Same value 0 used for spawning "scout" units, which are mainly spawned outside of UFO, and just hanging around (their AI have quite different route priorities). If there is no free spawn points found - unit marked as "dead" instead of spawning.

Scout 0
Commander 4 > 3 > 5 > 8 > 7 > 2 > 0
Leader 4 > 3 > 5 > 8 > 7 > 2 > 0
Engineer 5 > 4 > 3 > 2 > 7 > 8 > 0
Medic 7 > 6 > 2 > 8 > 3 > 4 > 0
Navigator 3 > 4 > 5 > 2 > 7 > 8 > 0
Soldier 2 > 5 > 3 > 4 > 6 > 8 > 0
Terrorist 2 > 5 > 3 > 4 > 6 > 8 > 0
XCom 1 > 0 > 2

So, 1st priority spawn points confirmed to be as they listed on main page. But almost any of these spawn point can be used by number of alien ranks, not only by those you assigned to.

0 = Scout/Any rank
1 = X-Com
2 = Soldier/Terrorist, Medic, Engineer/Navigator, Commander/Leader
3 = Navigator, Commander/Leader, Engineer/Soldier/Terrorist, Medic
4 = Commander/Leader, Engineer/Navigator, Soldier/Terrorist, Medic
5 = Engineer, Commander/Leader/Navigator
6 = ..., Medic, Soldier/Terrorist
7 = Medic, Commander/Leader/Engineer/Navigator
8 = ..., Commander/Leader/Medic, Engineer/Navigator/Soldier/Terrorist
--[[User:Volutar|Volutar]] 03:21, 26 September 2011 (EDT)

little note: "scout" is also a civilian spawn node, they also only spawn at 0 --[[User:Daiky|Daiky]] 15:30, 30 December 2011 (EST)

== Node link offset 2 (travel unit type) ==

This is a bitfield with values as mask for kind of units.

bit0 (1) = this node is only for units in fly mode (mobility bit).
bit1 (2) = this node is only for small units.
bit2 (4) = this node is only for flying units (movement type).
*bit3 (8) = this link was already processed for path estimation (runtime bit).

so
0= any units
1= units of any size in fly mode
2= small units flying or not
3= small units in fly mode
4= any size of flyers
5= any size of flyers in fly mode
6= small flyers
7= small flying flyers

Actually I dont know why there are TWO bits (0 and 2) which stand for flying... AFAIR every flying alien unit unable to walk, so they always have movement type "Fly" and mobility bit "fly mode" (like floaters, who are unable to use steps). Probably some of walking alien units was planned to have flying abilities, but abandoned for some reason.
--[[User:Volutar|Volutar]] 01:51, 27 September 2011 (EDT)

== Offsets 0x15 (21) & 0x16 (22) ==

They seems to be used for AI patrol route distortion for BaseDefence mission type.
Before (and including) 30th turn of battle Aliens seems to be attracted by route nodes having one of these (or both) flags set (as boolean field). It's more like a target points, and they seems to be not interested in others at all. But after 30th turn of battle Aliens seems to be wandering all over the place without paying attention on these flags.

It can be confirmed by clearing all these flags from XCOM base module maps, and setting them only for "lift" module nodes. Apparently they will be swarming around lift area, without trying to get somwehere else. But after 30 turn they must scatter.
--[[User:Volutar|Volutar]] 00:05, 28 September 2011 (EDT)
Yes, this was confirmed. Though if Alien spots your unit, it will pursue (in Snipe mode), no matter what routes and flags are
--[[User:Volutar|Volutar]] 00:51, 28 September 2011 (EDT)

I wonder why there are so-called targetpoints (flags 5 in base defense) in the small rooms around the hangar?
Also, on terror sites there are flags 1 (and I found a flags 2 on a roof). They seem to be somewhat random, however on maps with buildings, the nodes with flags 1 are mostly inside. An explanation may be that aliens are attracted to these flags 1 nodes as targetpoints, making aliens targetting the inside of buildings to terrorise civilians.
On larger UFOs, the flags seems to have the same value as priority? Which might be an error in the data? Or maybe the flags values are not used in UFOs at all. There is a theory that until a certain turn aliens will prefer to stay inside and around the UFO before spreading to the outside, this might be controlled by this flags.
On other terrain once and a while there is a flags 1 value, the rest is 0. It could be aliens walk around and stand still and look around on the nodes with flags 1.
--[[User:Daiky|Daiky]] 15:45, 5 January 2012 (EST)
:Regarding the small rooms I've seen aliens hiding on those, I can't remember if their are spawn points also though. I've made quite a few attempts are figuring out what the values meant on terrain modes I've created, usually based on the assumption that the higher the number on the flag the more the AI would 'choose' to go to that point. Can't really say that it worked all the time.
:I've always disregarded the theory that aliens leave their craft after turn 8. While it may seem that way, a more easy explanation is simply that the more aliens you have on a confined space, the longer it will take for them to reach the outside because they will block each other's movement (unless they spot a hostile unit, their scouting mode seems to be to go from one waypoint to the other unless they are blocked). Again most of this can't be exactly trusted because without some sort of proof, which I dont have other than observation. [[User:Hobbes|Hobbes]] 19:20, 5 January 2012 (EST)
::"the higher the number on the flag the more the AI would 'choose' to go to that point."; I also think this is a "weight" value when evaluating the next target node, but it's possible there is still some randomness on top of that, otherwise alien behaviour could become too predictable.
Note that offset 0x2B (43) on unitref.dat also has something to do with pathfinding...
--[[User:Daiky|Daiky]] 05:40, 6 January 2012 (EST)

Talk:ROUTES.DAT

2012-01-05T20:45:32Z

Daiky: /* Offsets 0x15 (21) & 0x16 (22) */

Talk:ROUTES.DAT

2011-12-30T20:30:38Z

Daiky: /* Offset 20 */

Talk:Motion Scanner

2011-12-26T12:37:07Z

Daiky:

Someone should make a tutorial on how to use those darn things.

I never manage to get a grasp on how to use it effectively. I often found it easier to turn my soldiers around in circles to clear my immediate vincinity. Maybe a image of the motion detector screen, and another to show the positions of the aliens and how it relates to one another?

--[[User:Vagabond|Vagabond]] 23:16, 15 March 2007 (PDT)

: It's not terribly difficult to use. All it does is pick up movement. Nothing else. The main use is to check for movement of units in an enclosed area - i.e. the UFO or a building or even the outside of the Skyranger before you embark after waiting the first or more turn.

: The orientation is simple. It's the same as the overhead map. Top is North, then clockwise it's East, South and West. The numbers on the rings on the screen represent every tile away from you. It goes up to 8 or 9 rings, so that's a 9 tile radius. Which is coincidentally your visual range at night, so there's absolutely no point in using a motion scanner out in the open.

: Using soldiers as an example, when no movement has occured, you'll get nothing on the screen.

: <div align = "center"> [[Image:Mscannerex1.png]]</div>

: After movement, units that have moved will register on the display. Note that the more they have to walk, the larger their blip on the screen.

: <div align = "centeR" > [[Image:Mscannerex2.png]]</div>

: That's it really. It's useful if you've got a wall and cannot see what's behind it. Out in the open, it's utterly useless.

: - [[User:NKF|NKF]]

----

Off the top of my head, I can describe one case where it's useful: if I'm using Proximity Grenades outside a UFO and there's a pile of stuff I don't want to blow up, I'll have a soldier beside the UFO use a scanner to see if an alien's in the antechamber, ready to exit. If not, I can risk grabbing extra stuff without having to get back into "safe" position.

There might be cases where if you see a single "big dot" inside a UFO, it might be safe to enter since the alien will have used up most its TUs. I'm not confident this is a reliable indicator, however. I sometimes watch a dot from turn to turn to see which way it moves, which at least gives you some warning that an alien's probably on its way out.

The biggest problem with scanners is the false negatives: if you scan no movement, that either means there's no alien, or that there's one that's got all its TUs (''very'' dangerous). You can't assume that the absence of a dot is the absence of an alien.--[[User:Ethereal Cereal|Ethereal Cereal]] 02:16, 16 March 2007 (PDT)

: That's its biggest limitation. It's only good in a "something's moving over there!" way. You otherwise can't be sure what ''is'' over there, except the alien that moved. About the best you can do is deal with it by readying an ambush (such as the case of a UFO assault - which you should already be doing automatically anyway so a scanner isn't necessary), before deploying from the Skyranger after waiting a few turns (about the only place I myself actively use it - it identifies movement beside or behind the ramp) or if you're in, say, the orchards or behind the grass hedges and you want to pinpoint the exact location of an alien you saw move into it. Mind you, a simple toss of a grenade is generally all you need to clear something like the orchards. Actually, alien bases and base defence scenarios are probably a good places to use it. Plenty of partitions and hallways, and in X-Com bases, you can have soldiers on the upper level or inside HWP closets scan the hallways to check if there's anything outside (and then get someone further down the hallway pop out and take it out).

: It's one of those niche tools that can be useful if used right, but still won't be used too much when you've got other simpler and more efficient alternatives available to you. - [[User:NKF|NKF]]

:: I generally get the most use out of a motion scanner with the Large Scout and the Terror Ship. With both of these, it's possible to get relatively close to the center of the ship without going inside...which is useful for detecting when sprinting is/has remained "safe", after clearing the outside. Alien Bases are a bit open for my taste.

:: While theoretically possible, it's a bit harder to get effective use in: Farm, Terror, other large UFOs.

:: And, generally...use all motion scanners in position before moving anyone else.

:: -- [[User:Zaimoni|Zaimoni]], 12:26 March 16 2007 CDT

== Blip sizes ==

Does anyone know the relationship between movement and blip size? Also, does it go off [[Time Units]] used or [[Energy]] used? There are 7 different-sized blips in the [[DETBLOB.DAT]] file, so does that mean there are 7 different levels of "motion"?

----

Nothing to do with energy. If I'm not mistaken, there's a separate stat unitref[062] that increments every time the unit walks, but not when other actions are performed. The amount it increments is based off the stat just before it in unitref[061]. Blip sizes are based off unitref[062]. -[[User:NKF|NKF]]

----
As a pre-emptive clarification, it should be noted that although it seems energy would work as a mechanism for determining it(because the only time you use energy is walking), it wouldn't. While it is true that X-COM soldiers and HWPs only use energy when moving, some aliens ALSO use energy simply while turning in place (rotation). This is determined by another stat that determines at what level energy is depleted; some aliens lose energy at the same rate as TUs spent on movement. This can be tested with a Psi-Amp and a few psi-competent troopers, as well as a few extraterrestrial 'volunteers'.

Also, do elevation changes trigger the motion sensor? We should try and find that out.[[User:Arrow Quivershaft|Arrow Quivershaft]] 10:47, 23 December 2007 (PST)

----

I have investigated this for implementing the motion scanner in OpenXcom. So as said before, sectoids get 3 movement points (called it MP) for 1 tile movement, tanks get 30 MP/tile, rest 4 MP/tile.
Blips are animated in 2 frames, so in fact there are only 6 sizes. The last(7th) blip graphic is just used for the animation of the 6th blipsize.
Through some testing I came up with the following relationship between the number of MPs and blipsize:
*5 MP = blip 1
*10 MP = blip 2
*15 MP = blip 3
*20 MP = blip 4
*25 MP = blip 5
*30 MP = blip 6
Some interesting things to note:
* a movement of 1 tile of a small unit is not seen on the scanner.
* vertical movement is not seen on the scanner.
* you can not see how much a large unit moved (it always shows the largest blips)

Disclaimer: I'm not 100% sure of these values, I did some quick tests and made logical conclusions.
--[[User:Daiky|Daiky]] 07:34, 26 December 2011 (EST)

Talk:Motion Scanner

2011-12-26T12:36:21Z

Daiky:

Someone should make a tutorial on how to use those darn things.

I never manage to get a grasp on how to use it effectively. I often found it easier to turn my soldiers around in circles to clear my immediate vincinity. Maybe a image of the motion detector screen, and another to show the positions of the aliens and how it relates to one another?

--[[User:Vagabond|Vagabond]] 23:16, 15 March 2007 (PDT)

: It's not terribly difficult to use. All it does is pick up movement. Nothing else. The main use is to check for movement of units in an enclosed area - i.e. the UFO or a building or even the outside of the Skyranger before you embark after waiting the first or more turn.

: The orientation is simple. It's the same as the overhead map. Top is North, then clockwise it's East, South and West. The numbers on the rings on the screen represent every tile away from you. It goes up to 8 or 9 rings, so that's a 9 tile radius. Which is coincidentally your visual range at night, so there's absolutely no point in using a motion scanner out in the open.

: Using soldiers as an example, when no movement has occured, you'll get nothing on the screen.

: <div align = "center"> [[Image:Mscannerex1.png]]</div>

: After movement, units that have moved will register on the display. Note that the more they have to walk, the larger their blip on the screen.

: <div align = "centeR" > [[Image:Mscannerex2.png]]</div>

: That's it really. It's useful if you've got a wall and cannot see what's behind it. Out in the open, it's utterly useless.

: - [[User:NKF|NKF]]

----

Off the top of my head, I can describe one case where it's useful: if I'm using Proximity Grenades outside a UFO and there's a pile of stuff I don't want to blow up, I'll have a soldier beside the UFO use a scanner to see if an alien's in the antechamber, ready to exit. If not, I can risk grabbing extra stuff without having to get back into "safe" position.

There might be cases where if you see a single "big dot" inside a UFO, it might be safe to enter since the alien will have used up most its TUs. I'm not confident this is a reliable indicator, however. I sometimes watch a dot from turn to turn to see which way it moves, which at least gives you some warning that an alien's probably on its way out.

The biggest problem with scanners is the false negatives: if you scan no movement, that either means there's no alien, or that there's one that's got all its TUs (''very'' dangerous). You can't assume that the absence of a dot is the absence of an alien.--[[User:Ethereal Cereal|Ethereal Cereal]] 02:16, 16 March 2007 (PDT)

: That's its biggest limitation. It's only good in a "something's moving over there!" way. You otherwise can't be sure what ''is'' over there, except the alien that moved. About the best you can do is deal with it by readying an ambush (such as the case of a UFO assault - which you should already be doing automatically anyway so a scanner isn't necessary), before deploying from the Skyranger after waiting a few turns (about the only place I myself actively use it - it identifies movement beside or behind the ramp) or if you're in, say, the orchards or behind the grass hedges and you want to pinpoint the exact location of an alien you saw move into it. Mind you, a simple toss of a grenade is generally all you need to clear something like the orchards. Actually, alien bases and base defence scenarios are probably a good places to use it. Plenty of partitions and hallways, and in X-Com bases, you can have soldiers on the upper level or inside HWP closets scan the hallways to check if there's anything outside (and then get someone further down the hallway pop out and take it out).

: It's one of those niche tools that can be useful if used right, but still won't be used too much when you've got other simpler and more efficient alternatives available to you. - [[User:NKF|NKF]]

:: I generally get the most use out of a motion scanner with the Large Scout and the Terror Ship. With both of these, it's possible to get relatively close to the center of the ship without going inside...which is useful for detecting when sprinting is/has remained "safe", after clearing the outside. Alien Bases are a bit open for my taste.

:: While theoretically possible, it's a bit harder to get effective use in: Farm, Terror, other large UFOs.

:: And, generally...use all motion scanners in position before moving anyone else.

:: -- [[User:Zaimoni|Zaimoni]], 12:26 March 16 2007 CDT

== Blip sizes ==

Does anyone know the relationship between movement and blip size? Also, does it go off [[Time Units]] used or [[Energy]] used? There are 7 different-sized blips in the [[DETBLOB.DAT]] file, so does that mean there are 7 different levels of "motion"?

----

Nothing to do with energy. If I'm not mistaken, there's a separate stat unitref[062] that increments every time the unit walks, but not when other actions are performed. The amount it increments is based off the stat just before it in unitref[061]. Blip sizes are based off unitref[062]. -[[User:NKF|NKF]]

----
As a pre-emptive clarification, it should be noted that although it seems energy would work as a mechanism for determining it(because the only time you use energy is walking), it wouldn't. While it is true that X-COM soldiers and HWPs only use energy when moving, some aliens ALSO use energy simply while turning in place (rotation). This is determined by another stat that determines at what level energy is depleted; some aliens lose energy at the same rate as TUs spent on movement. This can be tested with a Psi-Amp and a few psi-competent troopers, as well as a few extraterrestrial 'volunteers'.

Also, do elevation changes trigger the motion sensor? We should try and find that out.[[User:Arrow Quivershaft|Arrow Quivershaft]] 10:47, 23 December 2007 (PST)

---
I have investigated this for implementing the motion scanner in OpenXcom. So as said before, sectoids get 3 movement points (called it MP) for 1 tile movement, tanks get 30 MP/tile, rest 4 MP/tile.
Blips are animated in 2 frames, so in fact there are only 6 sizes. The last(7th) blip graphic is just used for the animation of the 6th blipsize.
Through some testing I came up with the following relationship between the number of MPs and blipsize:
*5 MP = blip 1
*10 MP = blip 2
*15 MP = blip 3
*20 MP = blip 4
*25 MP = blip 5
*30 MP = blip 6
Some interesting things to note:
* a movement of 1 tile of a small unit is not seen on the scanner.
* vertical movement is not seen on the scanner.
* you can not see how much a large unit moved (it always shows the largest blips)

Disclaimer: I'm not 100% sure of these values, I did some quick tests and made logical conclusions.
--[[User:Daiky|Daiky]] 07:34, 26 December 2011 (EST)

Talk:Motion Scanner

2011-12-26T12:34:43Z

Daiky:

Someone should make a tutorial on how to use those darn things.

I never manage to get a grasp on how to use it effectively. I often found it easier to turn my soldiers around in circles to clear my immediate vincinity. Maybe a image of the motion detector screen, and another to show the positions of the aliens and how it relates to one another?

--[[User:Vagabond|Vagabond]] 23:16, 15 March 2007 (PDT)

: It's not terribly difficult to use. All it does is pick up movement. Nothing else. The main use is to check for movement of units in an enclosed area - i.e. the UFO or a building or even the outside of the Skyranger before you embark after waiting the first or more turn.

: The orientation is simple. It's the same as the overhead map. Top is North, then clockwise it's East, South and West. The numbers on the rings on the screen represent every tile away from you. It goes up to 8 or 9 rings, so that's a 9 tile radius. Which is coincidentally your visual range at night, so there's absolutely no point in using a motion scanner out in the open.

: Using soldiers as an example, when no movement has occured, you'll get nothing on the screen.

: <div align = "center"> [[Image:Mscannerex1.png]]</div>

: After movement, units that have moved will register on the display. Note that the more they have to walk, the larger their blip on the screen.

: <div align = "centeR" > [[Image:Mscannerex2.png]]</div>

: That's it really. It's useful if you've got a wall and cannot see what's behind it. Out in the open, it's utterly useless.

: - [[User:NKF|NKF]]

----

Off the top of my head, I can describe one case where it's useful: if I'm using Proximity Grenades outside a UFO and there's a pile of stuff I don't want to blow up, I'll have a soldier beside the UFO use a scanner to see if an alien's in the antechamber, ready to exit. If not, I can risk grabbing extra stuff without having to get back into "safe" position.

There might be cases where if you see a single "big dot" inside a UFO, it might be safe to enter since the alien will have used up most its TUs. I'm not confident this is a reliable indicator, however. I sometimes watch a dot from turn to turn to see which way it moves, which at least gives you some warning that an alien's probably on its way out.

The biggest problem with scanners is the false negatives: if you scan no movement, that either means there's no alien, or that there's one that's got all its TUs (''very'' dangerous). You can't assume that the absence of a dot is the absence of an alien.--[[User:Ethereal Cereal|Ethereal Cereal]] 02:16, 16 March 2007 (PDT)

: That's its biggest limitation. It's only good in a "something's moving over there!" way. You otherwise can't be sure what ''is'' over there, except the alien that moved. About the best you can do is deal with it by readying an ambush (such as the case of a UFO assault - which you should already be doing automatically anyway so a scanner isn't necessary), before deploying from the Skyranger after waiting a few turns (about the only place I myself actively use it - it identifies movement beside or behind the ramp) or if you're in, say, the orchards or behind the grass hedges and you want to pinpoint the exact location of an alien you saw move into it. Mind you, a simple toss of a grenade is generally all you need to clear something like the orchards. Actually, alien bases and base defence scenarios are probably a good places to use it. Plenty of partitions and hallways, and in X-Com bases, you can have soldiers on the upper level or inside HWP closets scan the hallways to check if there's anything outside (and then get someone further down the hallway pop out and take it out).

: It's one of those niche tools that can be useful if used right, but still won't be used too much when you've got other simpler and more efficient alternatives available to you. - [[User:NKF|NKF]]

:: I generally get the most use out of a motion scanner with the Large Scout and the Terror Ship. With both of these, it's possible to get relatively close to the center of the ship without going inside...which is useful for detecting when sprinting is/has remained "safe", after clearing the outside. Alien Bases are a bit open for my taste.

:: While theoretically possible, it's a bit harder to get effective use in: Farm, Terror, other large UFOs.

:: And, generally...use all motion scanners in position before moving anyone else.

:: -- [[User:Zaimoni|Zaimoni]], 12:26 March 16 2007 CDT

== Blip sizes ==

Does anyone know the relationship between movement and blip size? Also, does it go off [[Time Units]] used or [[Energy]] used? There are 7 different-sized blips in the [[DETBLOB.DAT]] file, so does that mean there are 7 different levels of "motion"?

----

Nothing to do with energy. If I'm not mistaken, there's a separate stat unitref[062] that increments every time the unit walks, but not when other actions are performed. The amount it increments is based off the stat just before it in unitref[061]. Blip sizes are based off unitref[062]. -[[User:NKF|NKF]]

----
As a pre-emptive clarification, it should be noted that although it seems energy would work as a mechanism for determining it(because the only time you use energy is walking), it wouldn't. While it is true that X-COM soldiers and HWPs only use energy when moving, some aliens ALSO use energy simply while turning in place (rotation). This is determined by another stat that determines at what level energy is depleted; some aliens lose energy at the same rate as TUs spent on movement. This can be tested with a Psi-Amp and a few psi-competent troopers, as well as a few extraterrestrial 'volunteers'.

Also, do elevation changes trigger the motion sensor? We should try and find that out.[[User:Arrow Quivershaft|Arrow Quivershaft]] 10:47, 23 December 2007 (PST)

---
I have investigated this for implementing the motion scanner in OpenXcom. So as said before, sectoids get 3 movement points (called it MP) for 1 tile movement, tanks get 30 MP/tile, rest 4 MP/tile.
Blips are animated in 2 frames, so in fact there are only 6 sizes. The last(7th) blip graphic is just used for the animation of the 6th blipsize.
Through some testing I came up with the following relationship between the number of MPs and blipsize:
5 MP = blip 1
10 MP = blip 2
15 MP = blip 3
20 MP = blip 4
25 MP = blip 5
30 MP = blip 6
Some interesting things to note:
- a movement of 1 tile of a small unit is not seen on the scanner.
- vertical movement is not seen on the scanner.
- you can not see how much a large unit moved (it always shows the largest blips)

Disclaimer: I'm not 100% sure of these values, I did some quick tests and made logical conclusions.
--[[User:Daiky|Daiky]] 07:34, 26 December 2011 (EST)

Medi-Kit (TFTD)

2011-12-22T10:37:36Z

Daiky:

{{Infobox open}}
{{Infobox module/itemcommon
| item =Medi-Kit (TFTD)
| height = 2
| width = 1
| weight = 5
| damagethreshold = 20
| image = [[Image:MediKit_(TFTD).png|64 px]]
| saleprice = 45600
| research = Medi-Kit
}}
{{Infobox module/action
| action = Action
| cost = '''TU Cost'''
| effect = '''Charges'''
}}
{{Infobox module/action
| action = Heal
| cost = 10 TU
| effect = 10
}}
{{Infobox module/action
| action = Stimulant
| cost = 10 TU
| effect = 10
}}
{{Infobox module/action
| action = Pain Killer
| cost = 10 TU
| effect = 10
}}
{{Infobox module/manufacture|28000|420| - | - }}
{{Infobox close}}

To use this you face the injured X-COM agent or stand over the body of a stunned aquanaut.

Healing: Red indicates wounds. Select body part and click on the <nowiki>'Heal'</nowiki> button. One fatal wound will be healed and health restored.

Stimulant: Restores energy and revives stunned aquanauts. To revive an unconscious aquanaut you must stand directly over the body.

Pain Killer: Restores the morale of wounded aquanauts.

<table><tr><td>[[Image:MediKit_(TFTD).png|left|64 px]]</td><td>
*Ammo: 10 charges each of healing, stimulants, and pain killers.
*Size: 2 high x 1 wide
*Weight: 5
*TUs:
**10 per use of a charge.
*[[Buying/Selling/Transferring#Manufacturable_Prices|Manufacturing]]: $28,000 for parts, 420 Engineer Hours
*Sell Price: $45,600</td></tr></table>

==See Also==
*[[Medi-Kit (EU)]] for more detailed information on use, etc.

{{Equipment (TFTD) Navbar}}

[[Category:Equipment (TFTD)]][[Category:Research (TFTD)]]

Medi-Kit (TFTD)

2011-12-22T10:37:08Z

Daiky:

{{Infobox open}}
{{Infobox module/itemcommon
| item =Medi-Kit (TFTD)
| height = 2
| width = 1
| weight = 5
| damagethreshold = 20
| image = [[Image:MediKit_(TFTD).png|64 px]]
| saleprice = 45600
| research = Medi-Kit
}}
{{Infobox module/action
| action = Action
| cost = '''TU Cost'''
| effect = '''Charges'''
}}
{{Infobox module/action
| action = Heal
| cost = 10 TU
| effect = 10
}}
{{Infobox module/action
| action = Stimulant
| cost = 10 TU
| effect = 10
}}
{{Infobox module/action
| action = Pain Killer
| cost = 10 TU
| effect = 10
}}
{{Infobox module/manufacture|28000|420| - | - }}
{{Infobox close}}

To use this you face the injured X-COM agent or stand over the body of a stunned aquanaut.

Healing: Red indicates wounds. Select body part and click on the <nowiki>'Heal'</nowiki> button. One fatal wound will be healed and health restored.

Stimulant: Restores energy and revives stunned aquanauts. To revive an unconscious aquanaut you must stand directly over the body.

Pain Killer: Restores the morale of wounded aquanauts.

<table><tr><td>[[Image:MediKit_(TFTD).png|left|64 px]]</td><td>
*Ammo: 10 charges each of healing, stimulants, and pain killers.
*Size: 2 high x 1 wide
*Weight: 5
*TUs:
**10 per use of a charge.
*[[Buying/Selling/Transferring#Manufacturable_Prices|Manufacturing]]: $28,000 for parts, 420 Engineer Hours
*Sell Price: $45,600</td></tr></table>

==See Also==
*[[Medi-Kit|Medi-Kit_(EU)]] for more detailed information on use, etc.

{{Equipment (TFTD) Navbar}}

[[Category:Equipment (TFTD)]][[Category:Research (TFTD)]]

Differences to X-COM (OpenXcom)

2011-12-15T15:45:19Z

Daiky: /* Battlescape */

== General ==
* None of [[Known Bugs|these bugs]].
* Mouse wheel support.
* Caret on text editing.
* No CPU-based speed.
* Mouse input works like modern systems.
* Different savegame format.
* Unicode support.

== Geoscape ==
* Since there's no 80 item limit, items in crafts count towards your [[Base Stores]] to prevent exploiting infinite storage. This also lets you freely move items between bases and crafts without storage issues.
* Each radar facility performs its own detection check, so having multiple [[Small Radar System]]s and/or [[Large Radar System]]s ''does'' improve your chances. The [[Hyperwave Decoder]] still makes all other facilities obsolete though since it has a 100% detection chance.
* The craft phase order when returning to base is: [[Repairs|Repairing]], [[Rearming]], [[Refueling]].
* Stores column in Purchase/Recruit screen.
* Can disarm weapons from crafts.
* Can cancel out of selecting armor for soldiers.
* Selling crafts automatically unequips all their contents.
* No gap in Australasia zone.

== Battlescape ==
* Right-click opens doors.
* Right-click to cancel a unit walking.
* Objects, fire and smoke keeps animating while walking or scrolling the screen.
* Pathfinding is a different algorithm: it will always find a solution, if there is one, no matter how difficult.
* AI of aliens is different (in progress). - Impossible to 100% exactly mimic original AI.
* Aliens can also suffer from fatal wounds. (still in debate)

== Optional features ==
While the above differences are hardcoded, there are also various new "hidden" features you can choose to enable.
* Alternative grenade handling: when priming a grenade you don't get the "set timer" screen. When throwing the grenade it will immediatly explode on impact.
* Preview path: when choosing the target to move towards with your current unit, it will draw the path on the ground. Tiles will be painted green for how far you can move without running out of TUs. You need to click a second time to make the unit move.
* Range based accuracy: this modifies the accuracy based on the distance from the target. The accuracy decreases linearly (2% per tile or 0.125% per voxel) when shooting beyond the limit of the firing mode: auto shot: 7 tiles or 112 voxels, snap shot: 15 tiles or 240 voxels, aimed shot: no penalty

See [[Customizing (OpenXcom)]]

[[Category:OpenXcom]]

Options (OpenXcom)

2011-12-15T15:43:17Z

Daiky: /* Options */

== User Folder ==
OpenXcom creates a User folder with all the screenshots, savegames and options in one of the following paths:
* C:\My Documents\OpenXcom (Windows 9x/ME)
* C:\Documents and Settings\<username>\My Documents\OpenXcom (Windows 2000/XP)
* C:\Users\<username>\Documents\OpenXcom (Windows Vista/7)
* ~/Library/Application Support/OpenXcom (Mac OS X)
* ~/.openxcom (Linux)
* <working directory>\USER\
* <binary directory>\USER\
* <working directory>

You can also specify your own path by passing the command-line argument "-user <user path>".

== Options ==

OpenXcom stores various game settings in the options.cfg YAML file stored in the User folder, which can be easily edited with any text editor. You can also pass them as command line arguments in the form "-<option name> <option value>". The following settings are available:

*'''battleAlienSpeed''': Battlescape alien movement speed.
*'''battleAltGrenade''': Battlescape hot grenade behaviour (true/false).
*'''battlePreviewPath''': Battlescape preview path + second click to confirm the path (true/false).
*'''battleFireSpeed''': Battlescape fire speed.
*'''battleRangeBasedAccuracy''': Battlescape range-based accuracy (true/false).
*'''battleScrollSpeed''': Battlescape map scrolling speed.
*'''battleScrollType''': Battlescape map scrolling mode (0 = Trigger Scroll, 1 = Auto Scroll, 2 = RMB Scroll).
*'''battleXcomSpeed''': Battlescape X-COM movement speed.
*'''displayHeight''': Display height in pixels.
*'''displayWidth''': Display width in pixels.
*'''fpsCounter''': Shows FPS Counter on the top-left of the screen (true/false).
*'''fullscreen''': Fullscreen (true) or windowed (false) display.
*'''language''': Filename of the language loaded at startup.
*'''musicVolume''': Background music volume (0-128).
*'''soundVolume''': Sound FX volume (0-128).

'''WARNING:''' Invalid values can cause incorrect behaviour or game crashes.

== Keyboard Shortcuts ==
*'''F5''' – Toggles a FPS counter in top-left corner.
*'''F12''' – Saves BMP screenshot to User folder.
*'''ALT-ENTER''' – Toggles fullscreen mode.

== Custom Music ==

If you don't like or have trouble getting the original X-COM music to work, you can use your own (eg. the [http://www.xcomufo.com/x1music.html Playstation] or [http://lorcan.freelanzer.com/ Cydonia's Fall] soundtracks) by putting it in the SOUND subfolder of the [[Installing (OpenXcom)#Data Folder|Data folder]] with the same filenames as the original:

*'''GMDEFEND''' - Base Defense Briefing.
*'''GMENBASE''' - Mission Briefing.
*'''GMGEO1''' - Geoscape 1.
*'''GMGEO2''' - Geoscape 2.
*'''GMINTER''' - Interception / Dogfight.
*'''GMINTRO1''' - Intro 1.
*'''GMINTRO2''' - Intro 2.
*'''GMINTRO3''' - Intro 3.
*'''GMLOSE''' - Game Over.
*'''GMMARS''' - Debriefing.
*'''GMNEWMAR''' - Mars Briefing.
*'''GMSTORY''' - Title.
*'''GMTACTIC''' - Battlescape.
*'''GMWIN''' - Victory.

The formats supported are MIDI, MP3 and OGG. You might need to delete the original music (including GM.CAT) for it to work.

[[Category:OpenXcom]]

Differences to X-COM (OpenXcom)

2011-12-15T15:41:47Z

Daiky: /* Optional features */

== General ==
* None of [[Known Bugs|these bugs]].
* Mouse wheel support.
* Caret on text editing.
* No CPU-based speed.
* Mouse input works like modern systems.
* Different savegame format.
* Unicode support.

== Geoscape ==
* Since there's no 80 item limit, items in crafts count towards your [[Base Stores]] to prevent exploiting infinite storage. This also lets you freely move items between bases and crafts without storage issues.
* Each radar facility performs its own detection check, so having multiple [[Small Radar System]]s and/or [[Large Radar System]]s ''does'' improve your chances. The [[Hyperwave Decoder]] still makes all other facilities obsolete though since it has a 100% detection chance.
* The craft phase order when returning to base is: [[Repairs|Repairing]], [[Rearming]], [[Refueling]].
* Stores column in Purchase/Recruit screen.
* Can disarm weapons from crafts.
* Can cancel out of selecting armor for soldiers.
* Selling crafts automatically unequips all their contents.
* No gap in Australasia zone.

== Battlescape ==
* Right-click opens doors.
* Right-click to cancel a unit walking.
* Objects, fire and smoke keeps animating while walking or scrolling the screen.
* Pathfinding is a different algorithm: it will always find a solution, if there is one, no matter how difficult.
* AI of aliens is different (in progress). - Impossible to 100% exactly mimic original AI.

== Optional features ==
While the above differences are hardcoded, there are also various new "hidden" features you can choose to enable.
* Alternative grenade handling: when priming a grenade you don't get the "set timer" screen. When throwing the grenade it will immediatly explode on impact.
* Preview path: when choosing the target to move towards with your current unit, it will draw the path on the ground. Tiles will be painted green for how far you can move without running out of TUs. You need to click a second time to make the unit move.
* Range based accuracy: this modifies the accuracy based on the distance from the target. The accuracy decreases linearly (2% per tile or 0.125% per voxel) when shooting beyond the limit of the firing mode: auto shot: 7 tiles or 112 voxels, snap shot: 15 tiles or 240 voxels, aimed shot: no penalty

See [[Customizing (OpenXcom)]]

[[Category:OpenXcom]]

Differences to X-COM (OpenXcom)

2011-12-15T15:41:10Z

Daiky: /* Optional features */

== General ==
* None of [[Known Bugs|these bugs]].
* Mouse wheel support.
* Caret on text editing.
* No CPU-based speed.
* Mouse input works like modern systems.
* Different savegame format.
* Unicode support.

== Geoscape ==
* Since there's no 80 item limit, items in crafts count towards your [[Base Stores]] to prevent exploiting infinite storage. This also lets you freely move items between bases and crafts without storage issues.
* Each radar facility performs its own detection check, so having multiple [[Small Radar System]]s and/or [[Large Radar System]]s ''does'' improve your chances. The [[Hyperwave Decoder]] still makes all other facilities obsolete though since it has a 100% detection chance.
* The craft phase order when returning to base is: [[Repairs|Repairing]], [[Rearming]], [[Refueling]].
* Stores column in Purchase/Recruit screen.
* Can disarm weapons from crafts.
* Can cancel out of selecting armor for soldiers.
* Selling crafts automatically unequips all their contents.
* No gap in Australasia zone.

== Battlescape ==
* Right-click opens doors.
* Right-click to cancel a unit walking.
* Objects, fire and smoke keeps animating while walking or scrolling the screen.
* Pathfinding is a different algorithm: it will always find a solution, if there is one, no matter how difficult.
* AI of aliens is different (in progress). - Impossible to 100% exactly mimic original AI.

== Optional features ==
While the above differences are hardcoded, there are also various new "hidden" features you can choose to enable.
* Alternative grenade handling: when priming a grenade you don't get the "set timer" screen. When throwing the grenade it will immediatly explode on impact.
* Preview path: when choosing the target to move towards with your current unit, it will draw the path on the ground. Tiles will be painted green for how far you can move without running out of TUs.
* Range based accuracy: this modifies the accuracy based on the distance from the target. The accuracy decreases linearly (2% per tile or 0.125% per voxel) when shooting beyond the limit of the firing mode: auto shot: 7 tiles or 112 voxels, snap shot: 15 tiles or 240 voxels, aimed shot: no penalty

See [[Customizing (OpenXcom)]]

[[Category:OpenXcom]]

Options (OpenXcom)

2011-12-15T15:32:53Z

Daiky: /* Options */

== User Folder ==
OpenXcom creates a User folder with all the screenshots, savegames and options in one of the following paths:
* C:\My Documents\OpenXcom (Windows 9x/ME)
* C:\Documents and Settings\<username>\My Documents\OpenXcom (Windows 2000/XP)
* C:\Users\<username>\Documents\OpenXcom (Windows Vista/7)
* ~/Library/Application Support/OpenXcom (Mac OS X)
* ~/.openxcom (Linux)
* <working directory>\USER\
* <binary directory>\USER\
* <working directory>

You can also specify your own path by passing the command-line argument "-user <user path>".

== Options ==

OpenXcom stores various game settings in the options.cfg YAML file stored in the User folder, which can be easily edited with any text editor. You can also pass them as command line arguments in the form "-<option name> <option value>". The following settings are available:

*'''battleAlienSpeed''': Battlescape alien movement speed.
*'''battleAltGrenade''': Battlescape hot grenade behaviour (true/false). Makes prime grenades explode even while equipped.
*'''battlePreviewPath''': Battlescape preview path by coloring tiles green or red. A second click confirms the path.
*'''battleRangeBasedAccuracy''': Different type of accuracy calculation that takes into account range to target.
*'''battleFireSpeed''': Battlescape fire speed.
*'''battleRangeBasedAccuracy''': Battlescape range-based accuracy (true/false).
*'''battleScrollSpeed''': Battlescape map scrolling speed.
*'''battleScrollType''': Battlescape map scrolling mode (0 = Trigger Scroll, 1 = Auto Scroll, 2 = RMB Scroll).
*'''battleXcomSpeed''': Battlescape X-COM movement speed.
*'''displayHeight''': Display height in pixels.
*'''displayWidth''': Display width in pixels.
*'''fpsCounter''': Shows FPS Counter on the top-left of the screen (true/false).
*'''fullscreen''': Fullscreen (true) or windowed (false) display.
*'''language''': Filename of the language loaded at startup.
*'''musicVolume''': Background music volume (0-128).
*'''soundVolume''': Sound FX volume (0-128).

'''WARNING:''' Invalid values can cause incorrect behaviour or game crashes.

== Keyboard Shortcuts ==
*'''F5''' – Toggles a FPS counter in top-left corner.
*'''F12''' – Saves BMP screenshot to User folder.
*'''ALT-ENTER''' – Toggles fullscreen mode.

== Custom Music ==

If you don't like or have trouble getting the original X-COM music to work, you can use your own (eg. the [http://www.xcomufo.com/x1music.html Playstation] or [http://lorcan.freelanzer.com/ Cydonia's Fall] soundtracks) by putting it in the SOUND subfolder of the [[Installing (OpenXcom)#Data Folder|Data folder]] with the same filenames as the original:

*'''GMDEFEND''' - Base Defense Briefing.
*'''GMENBASE''' - Mission Briefing.
*'''GMGEO1''' - Geoscape 1.
*'''GMGEO2''' - Geoscape 2.
*'''GMINTER''' - Interception / Dogfight.
*'''GMINTRO1''' - Intro 1.
*'''GMINTRO2''' - Intro 2.
*'''GMINTRO3''' - Intro 3.
*'''GMLOSE''' - Game Over.
*'''GMMARS''' - Debriefing.
*'''GMNEWMAR''' - Mars Briefing.
*'''GMSTORY''' - Title.
*'''GMTACTIC''' - Battlescape.
*'''GMWIN''' - Victory.

The formats supported are MIDI, MP3 and OGG. You might need to delete the original music (including GM.CAT) for it to work.

[[Category:OpenXcom]]

Differences to X-COM (OpenXcom)

2011-12-15T15:27:02Z

Daiky:

Differences to X-COM (OpenXcom)

2011-10-12T11:08:06Z

Daiky: /* Battlescape */

Differences to X-COM (OpenXcom)

2011-10-12T10:57:47Z

Daiky: /* Battlescape */

Rank

2011-09-25T14:11:53Z

Daiky:

:''This article is about the ranks an X-COM soldier can achieve, for alien ranks see [[Alien Ranks]]''

Rank represents the soldier's position within the hierarchy of soldiers. The higher the rank, the more command the soldier can exert over his or her subordinates. In the X-COM world, rank is primarily a conciliatory tool to reassure the lower ranks during times of strife, and also as a cheerleader during times of success.

Higher ranked soldiers that are still in battle help keep morale high in an event of a casualty or injury. They also give extra morale gain whenever your troops kill aliens. However, when they are killed or incapacitated it means that the other soldiers suffer a big morale loss which could mean that they will [[panic]] or go [[berserk]]. You may find it useful for your highest ranked officers to act as a [[Rear Commander]].

== Rookie promotion ==

Rookies can advance to Squaddies if they obtained any combat [[experience]] - except for throwing experience. This type of promotion happens before the higher promotions, it is also not shown on the promotion list after debriefing.

== Higher promotions ==

Your [[soldiers]] can advance to higher '''ranks''' with their "promotion score", assuming you have a large enough number of soldiers to justify the promotion.

The promotion score mainly depends on soldier stats and mission/kill counts, it is calculated as follows:
*c1 = BaseHPs + BaseEnergy + ImproveHPs + ImproveEnergy + 2*( ImproveReactions + BaseReactions + 10*(10-ImproveBravery-BaseBravery) )
*c2 = 2* c1 + 3*( BaseTUs + ImproveTUs + 2*( BaseFireAcc + ImproveFireAcc ) )
*c3 = c2 + ImproveMeleeAcc + ImproveThrowAcc + ImproveStrength + BaseMeleeAcc + BaseThrowAcc + BaseStrength
*if (PsiSkill>0) c3 += PsiStrength + 2* PsiSkill
*result = c3 + 10* ( Missions_cnt + Kills_cnt )

When there is a free position in a certain rank, the soldier with the highest promotion score of the rank below is promoted.

It is worth noting that:
*Once a soldier has been handed a rank above rookie, they can continue to be promoted even if they do not leave base and other soldiers surpass their promotion score.
*Rookies can be immediately promoted to Sergeant in 1 battle.

'''UFO: Enemy Unknown / X-COM: UFO Defense'''

<table {{StdDescTable}}>
<th {{StdDescTable_Heading}}>Rank</th><th {{StdDescTable_Heading}}>Notes</th>
<tr><td>[[Commander]]</td><td> [[Image:XCom1 rank6 Commander.GIF|30px]] Only one allowed over all [[X-COM Bases]], requires at least 30 soldiers in all bases.</td></tr>
<tr><td>Colonel</td><td> [[Image:XCom1 rank5 Colonel.GIF|30px]] Most experienced Captain is promoted to Colonel if opening present. 1 Colonel for 23 soldiers, limit of 10.</td></tr>
<tr><td>Captain</td><td> [[Image:XCom1 rank4 Captain.GIF|30px]] Most experienced Sergeant is promoted to Captain if opening present. 1 Captain for 11 soldiers, limit of 22.</td></tr>
<tr><td>Sergeant</td><td> [[Image:XCom1 rank3 Sergeant.GIF|30px]] Most experienced Squaddie is promoted to Sergeant if opening present. 1 Sergeant for 5 soldiers, limit of 50.</td></tr>
<tr><td>Squaddie</td><td> [[Image:XCom1 rank2 Squaddie.GIF|30px]] Perform any action that qualifies towards promotion, may not be given with high troop counts.</td></tr>
<tr><td>Rookie</td><td> [[Image:XCom1 rank1 Rookie.GIF|30px]] Starting rank for all new recruits.</td></tr>
</table>

'''[[Info (TFTD)|X-COM: Terror From the Deep]]'''

<table {{StdDescTable}}>
<th {{StdDescTable_Heading}}>Rank</th><th {{StdDescTable_Heading}}>Notes</th>
<tr><td>Captain</td><td> [[Image:XCom2 rank6 Captain.GIF|30px]] Only one allowed over all [[X-COM Bases]], requires at least 30 aquanauts in all bases.</td></tr>
<tr><td>Commander</td><td> [[Image:XCom2 rank5 Commander.gif|30px]] Most experienced Lieutenant is promoted to Commander if opening present. 1 Commander for 23 aquanauts, limit of 10.</td></tr>
<tr><td>Lieutenant</td><td> [[Image:XCom2 rank4 Lieutenant.gif|30px]] Most experienced Ensign is promoted to Lieutenant if opening present. 1 Lieutenant for 11 aquanauts, limit of 22.</td></tr>
<tr><td>Ensign</td><td> [[Image:XCom2 rank3 Ensign.gif|30px]] Most experienced Able Seaman is promoted to Ensign if opening present. 1 Ensign for 5 aquanauts, limit of 50.</td></tr>
<tr><td>Able Seaman</td><td> [[Image:XCom2 rank2 Able Seaman.gif|30px]] Promotion Perform any action that qualifies towards promotion, may not be given with high troop counts.</td></tr>
<tr><td>Seaman</td><td> [[Image:XCom2 rank1 Seaman.gif|30px]] Starting rank for all new recruits.</td></tr>
</table>

==See Also==
{{Unit Stats Navbar}}
[[Category:Soldiers]]

Experience

2011-09-25T13:57:08Z

Daiky:

A soldier earns experience during combat. After the mission, the soldier will then earn a random amount of stat increases based on what experience the soldier acquired during combat.

__NOTOC__
== Overview ==

Experience, in X-COM, is the accumulation of combat experience by successfully performing actions. After combat, this experience is applied towards the improvement of stats.

This article discusses how experience is earned and how it affects a soldier's stats.

__TOC__
== How Experience Points Are Applied ==

Soldier stats can be divided into two areas, '''primary''' and '''secondary''' stats.

=== Primary Stats ===

*'''Primary Stats''' are stats that are directly influenced by the actions that they are associated with. Henceforth these actions will be known as '''Primary Actions'''. The following is a list of Primary Stats:
**[[Reactions]]
**[[Firing Accuracy]]
**[[Melee Accuracy]]
**[[Throwing Accuracy]]
**[[Psionic Skill]]
**[[Bravery]]

* Every time a Primary Action is taken, '''Primary Skill Points''' are earned. They count the number of successful primary actions taken. This is used to calculate how much experience is gained at the end of combat. Refer to the individual stat pages by clicking on the links above for the specifics on each stat.

* The number of primary skill points you earn at the end of a mission relies solely on the number of primary actions you perform during combat, and random chance. Your current skill level doesn't matter. It doesn't matter if you have the lowest recruit value, or you're one point below the cap.

*Points assigned have a stairstep function, corresponding to a range within which points are rolled. The range increases as more actions are performed:

{| class= "wikitable" border="1" cellpadding = "3"
|-
! Primary Actions !! Roll Range !! Average Increase !! Ave. Inc. / Min. Actions
|-
| 1 - 2 || 0 - 1 || 0.5 || 0.50
|-
| 3 - 5 || 1 - 3 || 2.0 || 0.67
|-
| 6 - 9 || 1 - 4 || 2.5 || 0.42
|-
| 10+ || 2 - 6 || 4.0 || 0.4
|}
*Successful Psi actions count as 3 actions - see below
*Bravery does not pay heed to this table at all - see below

*Performing more than 10 actions won't cause any more increase. Once you reach that figure you get a 2-6 roll and that's that.

*As you can see, there are distinct breakpoints at 3 actions and 10 actions, corresponding to an average increase of 2 and 4 skill points, respectively. Three actions are the best "bang for the buck", if you have a limited number to spread across your squad (a.k.a., a limited number of aliens to kill). It's not an issue with psi or throwing (which you can do all you want), but is for other primaries. Of course, when a unit is near its cap, you should always aim for the biggest boost for that final roll.

*Related to this, letting your soldiers throw 3 times just before ending a mission maximizes Throwing Accuracy growth vs. your personal time spent. (If you give a damn about Throwing!)

*In a sense, more than 3 actions ''wastes'' those actions, ''unless'' you can get to 10 actions. (Arguably, getting to 6 is an exception, especially if you find yourself at 5 actions after e.g. some reaction firing.) Unless you have plenty of targets (so that many soldiers can make it to 10 actions), try to stop at 3 actions. Either count bullets as a crude approximation, or use a utility that reads the [[UNITREF.DAT]] experience counters from a saved game for exact counts. The number of bullets you've shot will accurately reflect your Reaction counter (unless the person also did direct fire sans reacting), but knowing how many hits were landed for Firing Accuracy can be much more problematic. For a little more detail on efficiency versus experience, see [[User_talk:MikeTheRed#Another_Look_at_Primary_Point_Increases|this]].

*Psi actions are a special case. Successful panic or mind control (MC) attempts cause the psi experience counter to go up by three actions. Thus, you only need to do 4 successful MCs or panics to get all the psi skill points you're going to (4x3=an experience count of 12). But unsuccessful attempts only cause the counter to go up by one. So you need 10 failed attempts to get to the 2-6 roll range, just like for all other primary stats.

*[[Throwing_Accuracy|Throwing Accuracy]] is also an oddball. While it follows the rules for all primaries (except Bravery), it only increases your Throwing Accuracy. It does not trigger secondaries to increase. (It would've been too easy to increase stats, otherwise! Actually, Psi is just as easy to develop, but it takes time to research psi, and then it needs more combats to reach its cap.)

*Performing more than 255 actions of a given type will cause all experience to be lost. This is known to be true for Psi actions, and is undoubtedly true for other actions as well as they are stored in one byte fields. Psi is the only place it's realistically likely. More precisely, experience gets wrapped around, and starts counting again. If you are seriously testing stats, or are challenging yourself by allowing only one psi person, the distance from 255 to 265 (255-10) is only 4.3%, or 3 to 4 MCs on top of 85 successful Psis (28 turns' worth, if they've been successfully MCing since Turn 1). Thus, this may sound scary, but you have '''nothing to fear''' unless you've had someone successfully MCing 3 times every turn, for 30 turns - and even then, just let them MC a few more. What's 10 more compared to 255?

* When you think about it, Ye Olde Programmers Of Yore made a simple and robust system where all squaddies are expected to participate, and hopefully each of them get to make a few primary actions that increase their score some real amount each combat mission.

==== Bravery ====

[[Bravery]] experience can also be gained on the battlefield, but by a very different means from all the other primary stats. The bravery stat itself is stored in increments of 10 (10 minimum, 100 maximum, with 110 possible for certain non-human units), and it can only increase by 10 points following each combat (it either gains 10, or nothing).

To gain bravery experience, a unit must have its [[Morale]] reduced below 50, where it stands a chance of panicking or going berserk. If the unit ''successfully resists'' panicking, it will gain a "bravery experience" point. Each bravery experience point gives the unit an additional ~9% chance (or an eleventh, to be precise) of gaining +10 Bravery at the end of the combat. At 11 or more bravery experience points, the +10 Bravery gain is guaranteed.

Like other primary stats, gaining one or more bravery experience points during a combat triggers secondary stat increases.

=== Secondary Stats ===

*'''Secondary stats''' increase when one or more primary actions are performed (except for throwing). Secondary stats are:
** [[Time Units]]
** [[Health]]
** [[Strength]]
** [[Energy|Energy/Stamina]]

* '''Secondary skill points''' work quite differently from primary skills: It does not matter how many primary actions are taken; all that matters is that you did one primary action (land a non-IN attack on an enemy, react to something, not panic when [[Morale]] is below 50, or use a psi attack) -- your secondaries will increase all that they're gonna. It also doesn't matter if you did more than one kind of primary action.

* The maximum possible increase falls steadily as your secondary skills approach their caps, down to an average of 1 point (range 0-2) per combat for each stat. This is actually a simplification; for a graph of skill increases vs. current levels, see [[User_talk:MikeTheRed#Secondary_.22Steps.22|here]]. Thus, secondary stats which start very low should increase quickly, and will then increase less rapidly as they rise. Rookies with the lowest possible starting stats will have the following as their max possible roll:

{| class= "wikitable" border="1" cellpadding = "3"
|-
!
! Recruit Min !! Max Roll !! Recruit Max !! Overall Cap
|-
| TUs || 50 || 5 || 60 || 80
|-
| Health || 25 || 5|| 40 || 60
|-
| Strength || 20 || 7 || 40 || 70
|-
| Energy || 40 || 6 || 70 || 100
|}

*The minimum possible roll is always zero for secondaries. Across the four secondaries, soldiers will show wide variations of luck or lack of luck following each combat, just like flipping coins. Still, the odds are that someone low will rise fast. It's real hard to roll a lot of zeros in a row when the maximum is two or more (and it always is).

*If a primary skill is over its cap, it does still trigger (non-capped) secondaries to increase, by performing it.

*The formula can be summed up as being a boost of 0 to (a tenth of the distance from the cap rounded down + 2). For example, if a soldier has 67 TUs, they're thirteen away from the cap, so the maximum possible TU boost they can get is 3 points (13/10+2 = 1+2 = 3). 50 TUs would be 5, 79 TUs would be 2. If a roll happens puts a unit above its cap, then so be it.

=== Soldier Advancement ===

Given the rules of how experience works, one can predict how long it will take soldiers to advance their attributes.

Primary skill advances can be based on hypothetical soldiers who always get:
* '''Low experience:''' 3 primary-skill experience points leading to a 1-3 roll and thus, always an average of 2 points per combat
* '''High experience:''' 10 primary-skill experience points leading to a 2-6 roll and thus, always an average of 4 points per combat
Secondary skills likewise use an average roll for advancing, according to the decreasing-slope function described above.

Because you can select or reject soldiers based on their starting stats, the more important question becomes, "which stats take the longest to advance from recruit maximum to its cap?" In other words, values above recruit max can't be "bought"... so which have the farthest to develop and should be focused on, if you want to maximize your stats?

You can use this as a basis for keeping or rejecting new recruits, or otherwise choosing which skills to develop.

The table below shows the number of combats needed for a soldier to advance from recruit maximum to attribute cap, '''on average'''. A more detailed look, including starting from recruit minimum, theoretical min and max advancement times, etc., can be found [[Media:XcomAttributeAdvancement.xls|here]] and a PDF of the same is [[Media:XcomAttributeAdvancement.pdf|here]].

{| class= "wikitable" border="1" cellpadding = "3"
|-
! rowspan = "2" | Stat
! rowspan = "2" | Min
! rowspan = "2" | Max
! rowspan = "2" | Cap
! colspan = "2" | Experience Range
! rowspan = "2" | Secondary
|-
! High
! Low
|-
! colspan = " 7"| Primaries
|-
| style = "text-align:left;" | Reactions
| 30 || 60 || 100 || 10 || 20 ||  
|-
| style = "text-align:left;" | Firing Accuracy
| 40 || 70 || 120 || 13 || 25 ||  
|-
| style = "text-align:left;" | Throwing Accuracy
| 50 || 80 || 120 || 10 || 20 ||  
|-
| style = "text-align:left;" | Psi Skill
| 16 || 24 || 100 || 19 || 38 ||  
|-
! colspan = "7" | Secondaries
|-
| style = "text-align:left;" | Time Units
| 50 || 60 || 80 ||   ||   || 16
|-
| style = "text-align:left;" | Health
| 25 || 40 || 60 ||   ||   || 16
|-
| style = "text-align:left;" | Strength
| 20 || 40 || 70 ||   ||   || 21
|-
| style = "text-align:left;" | Stamina
| 40 || 70 || 100 ||   ||   || 24
|}

=== Putting It All Together ===

* While you might focus on the averages stated above, the actual points assigned are entirely random. The range is what you should expect for any one soldier on any one combat mission. This follows the usual X-COM behavior of defining a range and rolling randomly within it.

* Do your best to get every soldier you are interested in developing, to get at least one primary action (not including throwing). This will trigger secondary stat increases. Then try to shoot for the big breakpoints of 3 or 10 primary actions. Doing more than 10 actions does not increase a particular primary stat any more, so give other soldiers the chance to perform actions once your favorite soldiers have maxed out on theirs.

* Any soldier can (and will!) ultimately become a maxed-out superman. (EXCEPT for Psi-wimps, who will never improve at all) The worse a secondary stat is, the quicker it will rise. And you can try to target who performs which primary actions. Taking advantage of the breakpoints of 3 and 10 can also help you manage potential skill increases (a.k.a. targets) as effectively as possible. That said,

* Early in the game, don't spend much time or money fretting over stats. Any soldier is liable to come up snakes with their Psi strength. And every soldier can otherwise eventually become a superman.

* Once you have Psi on board, you can use [[Experience Training]] to optimize advancement.

*In the endgame (when you have tons of cash), if you're a micromanager role-playing to make soldiers who are maxed across the board, it's arguably more important to pick recruits who are not anomalously low in any one stat, rather than ones who are high in a few things. In other words, if your goal is 100% stats, one really bad stat may slow you down more than e.g. being a particularly good newbie shooter. Firing accuracy, reactions, and stamina have the biggest span between recruit values and work needed to max them out.

== Regarding Caps ==
Every soldier statistic has a maximum allowed value, as shown in the table below. Your soldier will eventually have a value equal to or slightly greater than the cap. It is allowed to go over the cap, the very last time you have a combat while it is still under the cap. For example, the maximum Firing Accuracy is 120. If you go into a combat at 119, do lots of shooting, and get a +5 roll, you will walk away with 124 Firing Accuracy - but it will never increase again.

Primary skills can overflow their cap by 5, and secondary skills can overflow their cap by 1, as shown here:

{|class = "wikitable" border="1" cellpadding = "3"
|-
! Primary Stat !! Min Cap !! Max Cap
|-
| Reactions || 100 || 105
|-
| Firing Accuracy || 120 || 125
|-
| Melee Accuracy || 120 || 125
|-
| Throwing Accuracy || 120 || 125
|-
| Psi Skill || 100 || 105+ '''*'''
|-
| Bravery || 100 || 100
|-
! Secondary Stat !! Min Cap !! Max Cap
|-
| Time Units || 80 || 81
|-
| Health || 60 || 61
|-
| Strength || 70 || 71
|-
| Stamina || 100 || 101
|}

'''*''' Psi Skill is an exception. [[Psionic Skill#Improvement|Psi Lab]] training can continue to add 1-3 points each month after reaching the cap, and will loop the value back down to 0 if it passes 255.

You have a 33% chance of getting capped at Cap+1 for secondary skills, and you have no control over what happens (barring reloading your game and ending combat again). The chance is 33% and not 50% because there are two ways to reach Cap (being at Cap-2 and rolling 2 or being at Cap-1 and rolling 1), but only one way to reach Cap+1 (being at Cap-1 and rolling 2).

For primaries, a soldier that does 10+ actions (for a 2-6 roll) every single combat mission will get Cap+5 in that primary skill 5% of the time, on average. "Every single mission" means, without regard for the fact you're nearing the cap (and playing with the possible roll results). You can increase the odds to as high as 20%, if you use the primary increase roll ranges to inch your way up to Cap-1, then do 10+ actions on your final combat. Or you can have a 0% chance of Cap+5 if you don't pay attention and don't do 10+ actions near the cap!

== Experience training outside combat ==

*With the exception of [[Psionic Skill]] training in the [[Psionic Laboratory|Psi Lab]], all stats can only be trained through combat experience.

== Rookie promotions ==

*A Rookie that has gained any experience except throwing, is promoted to Squaddie (also see [[promotions]]). 
 

==See Also==
*[[Soldiers]]
*[[Experience Training]]
*For "behind the scenes" on experience testing, see [[User_talk:MikeTheRed#The_Experience_of_Experience|this]]
[[Category:Soldiers]]

ROUTES.DAT

2011-07-30T12:03:28Z

Daiky:

Talk:ROUTES.DAT

2011-07-21T11:26:24Z

Daiky:

Talk:ROUTES.DAT

2011-07-21T11:26:02Z

Daiky:

SEEMAP.DAT

2011-07-20T16:36:35Z

Daiky:

This file is only used by tactical saves and has a length of [[WGLOB.DAT|wglob[2] times wglob[3] times wglob[4]]] bytes. It details which areas of the map have been explored.

Each tile is detailed using three bits of an entire byte. The offset for any given byte is ''X Map Length'' * (''Map Level'' * ''Y Map Length'' + ''X'') + ''Y''.

* Bit 1 (1): Has the west wall been seen?
* Bit 2 (2): Has the north wall been seen?
* Bit 3 (4): Has the ground/contents been seen?

When the respective SEEMAP offset for a given tile has bit 3 active you can see all elements (walls, contents, etc) on the screen, otherwise nothing will be visible at all.

For example, if a tile has a northern wall in it and a soldier standing further north looks at it, he'll see the wall (and bit 2 will flip to on) but the wall will still remain invisible on screen because he can't see past it into the rest of the tile.

On the other hand, if he was standing to the south, he'd be able to see everything in the tile and so all three bits would flag and everything becomes visible.

That is to say, the first two bits are redundant. They're set and then ignored.

Not really sure why the programmers bothered with this, I guess they changed their mind on how the fog of war display would work at some point but didn't bother to simplify the backend to match.

''Daiky 20/07/2011 : the first two bits actually are not redundant: they are used to show the west and north doors, these "type of walls" are the only exception. It make sense because otherwise you would never find a door in a west or north wall when it all would remain invisible.''

==See Also==
* [[Saved Game Files]]
* [[Saved_Game_Files#Battlescape_Files|Battlescape Files]]
[[Category:Game Files]]

SEEMAP.DAT

2011-07-20T16:35:54Z

Daiky:

SEEMAP.DAT

2011-07-20T16:35:29Z

Daiky:

This file is only used by tactical saves and has a length of [[WGLOB.DAT|wglob[2] times wglob[3] times wglob[4]]] bytes. It details which areas of the map have been explored.

Each tile is detailed using three bits of an entire byte. The offset for any given byte is ''X Map Length'' * (''Map Level'' * ''Y Map Length'' + ''X'') + ''Y''.

* Bit 1 (1): Has the west wall been seen?
* Bit 2 (2): Has the north wall been seen?
* Bit 3 (4): Has the ground/contents been seen?

When the respective SEEMAP offset for a given tile has bit 3 active you can see all elements (walls, contents, etc) on the screen, otherwise nothing will be visible at all.

For example, if a tile has a northern wall in it and a soldier standing further north looks at it, he'll see the wall (and bit 2 will flip to on) but the wall will still remain invisible on screen because he can't see past it into the rest of the tile.

On the other hand, if he was standing to the south, he'd be able to see everything in the tile and so all three bits would flag and everything becomes visible.

That is to say, the first two bits are redundant. They're set and then ignored.

Not really sure why the programmers bothered with this, I guess they changed their mind on how the fog of war display would work at some point but didn't bother to simplify the backend to match.

Daiky 20/07/2011 : the first two bits actually are not redundant the are used to show the west and north doors, these "type of walls" are the only exception. It make sense because otherwise you would never find a door in a west or north wall when it all would remain invisible.

==See Also==
* [[Saved Game Files]]
* [[Saved_Game_Files#Battlescape_Files|Battlescape Files]]
[[Category:Game Files]]

Accuracy formula

2011-05-01T11:44:32Z

Daiky: /* % Chance to Hit = a * b * c * d * e * f, where */

== % Chance to Hit = a * b * c * d * e * f, where ==

*a = % Accuracy Stat of soldier
*b = % Accuracy of weapon/shot
*c = Kneeling bonus (115% if kneeling, 100% if standing)
*d = One-handed penalty (80% if firing a two-handed weapon without a free hand, 100% otherwise)
*e = health penalty (current health / max health)
*f = Critical wounds penalty (100% - (10% for each critical wound to head or arms, up to 90%))

'''Example:'''

A soldier has 88% Firing Accuracy, is firing a rifle snap shot (60%), is kneeling,
is holding a grenade in his other hand, has half his health remaining, and has a
fatal would to his head and right arm. His % chance to hit will be:

0.88 x 0.6 x 1.15 x 0.8 x 0.5 x 0.8 = 19%

== Close Range ==
The accuracy formula is NOT affected by distance - if you have a 100% chance to hit, you will hit, at any range - but 'missed' shots still have a chance to hit if their randomly distributed path takes them through the target tile. This is why burst shots are your best choice at close range - even if the calculated accuracy is bad, it's still hard to miss.

From work by [[User:NKF|NKF-sensei]], reworded by --[[User:JellyfishGreen|JellyfishGreen]] 09:49, 25 Apr 2005 (BST)
-----
''[ [[User:NKF|NKF]] - Addendum: I think it's best to say that the accuracy value is the level of accuracy that the bullet leaves the gun or the initial firing angle of the bullet. The bullet, after it leaves the gun, is then subjected to outside forces that can make a pefect 100+% accurate launched bullet miss its target. I like to blame it on integer rounding or in other words, decimal point truncation. If a bullet was mean to have a travel velocity of 1.25 map points on its X axis per update, integer rounding causes the .25 to be truncated, so the bullet only increases at 1 points per update. As I don't really know what's going underneath, this is best treated as an educated guess and no more. Anyway, in this case, distance can indeed play a factor in accuracy. If the bullet is meant to go way off its mark, as long as its line of travel happens to make it pass through the hit box of the alien you were aiming at (or anyone that just happens to be in the path of the bullet's trajectory), is counted as a hit. A technical hit, but a hit nonetheless! Another line of thought regarding drift is that the game may purposely introduce a very minor drift value to every attack. A random value may explain why it isn't always apparent. It may be a simulation of gravity or even wind. I find this less likely a <strike>excuse</strike> reason than decimal point truncation, but it's still a possibility worth considering.]''

== See Also ==
*[[Firing Accuracy]] 
*[[Fatal Wounds]] 
*[[Health]]
*''For current work in testing Firing Accuracy, see [[Firing Accuracy Testing]]''

Firing Accuracy

2011-05-01T11:43:16Z

Daiky: /* Influencing Factors */

=Overview=

Firing Accuracy is a measure of the soldier's overall skill at operating any given firearm. In short, it controls how accurate the soldier can be with any given gun.

==Starting Values==
New recruits will always begin with a value between 40 and 70.

==Improvement==
Firing Accuracy increases depending on how many times you '''hit''' an '''enemy'''. Examples / clarification:
*If you aim at one alien but hit a different one, it counts.
*If you hit an alien but don't do any [[Damage]] because it was too weak for their armor, it counts.
*If each of the three shots from a single Auto fire burst hits an alien, it counts as three hits.
*Mind-controlled aliens are ''friendly'' aliens. Hits on MC'd aliens do ''not'' count. Conversely, hitting soldiers under alien mind control ''does'' count. If you see the red "enemy" flag, the hit will count.
*[[Area-effect weapons]] (i.e., [[grenade]]s, [[Rocket Launcher|rockets]], [[Blaster Bomb]]s, and even [[Stun Bomb]]s) also count toward Firing Accuracy experience. You will score a "hit" for every alien within the blast's [[Explosions#HE_Statistics|radius]], regardless of whether they were hurt.
*Missed shots, hitting friendlies (including MC'd aliens or civilians), shooting scenery, distance to target, [[rank]], etc. - none of these matter or count.

All that matters is that you ''hit'' an enemy. Kills, per se, nor damage matter at all towards Firing Accuracy improvement. Only hits. (Kills do increase your Kill counter, but that's '''all''' - kills don't otherwise do anything at all for you, as far as is known.)

Weak weapons like pistols and laser pistols mean the alien won't die as quick, which means more hits, which means more chance of Firing Accuracy improvement. Because their skin is so thick and they have lots of Health, Mutons (and their Silacoid buddies) are great for multiple hits with a weak weapon. For more information, see [[Experience Training]].

You can be awarded up to an average of 4 skill points (range 2-6) per combat mission if you make at least 11 hits. The point award does not depend on your current skill level, only on the number of hits. For more particulars on skill-point increases, see [[Experience#How_Experience_Points_Are_Applied|Experience]].

==Maximum Caps==
An X-COM soldier's Firing Accuracy is capped at 120. However, because you can get a +6 roll when at 119, a soldier can have up to 125 Firing Accuracy (if they're really lucky!). For more info, see [[Experience#Regarding_Caps|Regarding Caps]].

==Base Chance To Hit==

The value that you see when you select your current weapon's firing mode is your base chance to hit. Though this is normally done for you in the game, if you wish to calculate the accuracy levels yourself, use the following formula:

:''Base Chance To Hit = Firing Accuracy × Weapon Firing Mode Accuracy''

'''Examples'''

:Soldier A has 50% firing accuracy and is firing a pistol with an aimed shot. Aimed pistols have 78% accuracy.

::{|
|-
| Soldier A's Base To hit|| = 50% × 78%
|-
|| || = '''39%'''
|}

:Soldier B has 75% firing accuracy and is firing a snapshot with the Heavy cannon. The Heavy Cannon has 60% accurate snapshots.

::{|
|-
| Soldier B's Base To hit|| = 75% × 60
|-
|| || = '''45%'''
|}

This is a very broad overview of how base-chance-to-hit is calculated. There are other percentages that influence the soldier's base firing accuracy.

==Influencing Factors==
Base Chance To Hit is also affected by other factors:

* Kneeling: +15% (x 1.15) when kneeling.
* Weapon Grip: -20% (x 0.8) when holding a two-handed weapon with one hand.
* Wounds: -10% per wound up to not beyond -90%.
* Health: percentage of max health

The above factors are all multiplied together, so...

*E.G.: A kneeling soldier (ACC: 65%) with two wounds, down to 80% of max health, making a snap shot with a rifle (ACC: 60%) would have a grand total of (0.65 * 0.60) * (1 + 0.15) * (1 - (2 * 0.10)) * 0.80 = 0.28704, or ~29% net chance of hitting the target.

For a full breakdown and example, see:

*The [[Accuracy formula]]

=See Also=
*[[Accuracy formula]]
*[[Damage]]
*[[Experience#How_Experience_Points_Are_Applied|Experience]]
*[[Grenade]]s
*[[Experience Training]]
*[[Firing Accuracy Testing]]

{{Unit Stats Navbar}}
[[Category:Soldiers]]

Throwing Accuracy

2011-05-01T11:38:37Z

Daiky: /* Influencing Factors */

=Overview=

Throwing Accuracy is one of the simplest skills in the game and only performs one task. It controls how well a soldier is able to actually hit the target tile with a thrown object. Nothing much else.

Throwing Accuracy works in conjunction with [[Strength]], where one controls the accuracy of the throw, the other controls the range of the throw depending on the weight of the object.

==Starting Values==
New recruits will always begin with a value between 50 and 80.

==Improvement==
Throwing Accuracy points are awarded (at end of combat) depending on how many times you '''throw''' objects. (How obtuse is that?) If your throw misses its intended target/square, it still counts as a throw.

You are awarded an average of 2 skill points (range 1-3) per combat mission if you make at least 3 throws, and an average of 4 (range 2-6) for 11 or more. The point award does not depend on your current skill level, only on the number of throws. For more particulars on skill-point increases, see [[Experience#How_Experience_Points_Are_Applied|Experience]]. Note that unlike any other [[Experience#Primary_Stats|primary skill]], throwing does not trigger an increase in secondary skills (TUs, Health, Strength, Energy). That would've been too easy!

All in all, few people bother much with this skill. But if you're interested in it, note that the maximum gain for minimum personal (real world) time spent, would be to have your soldiers throw 3 things each mission. Probably just before ending a mission.

Note that throwing live [[grenade]]s gives you both Throwing and [[Firing Accuracy]] skill increases as long as enemies are caught in the blast.

==Maximum Caps==
An X-COM soldier's Throwing Accuracy is capped at 120. However, because you can get a +6 roll when at 119, a soldier can have up to 125 Throwing Accuracy (if they're really lucky — and dedicated as hell to chucking stuff!!). For more info, see [[Experience#Regarding_Caps|Regarding Caps]].

==Influencing Factors==
Throwing Accuracy is also affected by critical wounds and health percentage:

Throwing Accuracy = Base Throwing Accuracy × a × b

* a = 1 - 0.1 * Wounds(capped at 9)
* b = current health / max health

==Throwing Distance==

While not exactly Throwing ''Accuracy'', this is as a good a place as any for this:

Throwing Distance roughly = 2.5 × Strength / Weight

So, [[Strength]] directly affects throwing distance (range). Refer to the handy list of [[Item Weight]]s for weight information.

The "2.5" appears to vary from ~ 2.1 to 3.3.
The "2.5" is an approximation for Strength_Multiplier/Maximum_Throw_Range. To find the exact value you can use the .XLS file linked below.

When weapons are tossed, the weight of the ammo (if loaded) is not counted. (But weight from loaded ammo does otherwise count for [[Time Units#Encumbrance|weighing down]] a soldier carrying the weapon.)

As NKF points out, the throw always travels in an arc. Sometimes this arc is blocked by Skyranger wings, overhanging trees, ceilings, or even the 4-level-high virtual ceiling of the Battlescape itself. This results in the message "'''Unable to throw here!'''" even when the line of sight is clear.

Kneeling allows you to throw farther under ceilings, increasing this distance slightly.

Throw Range forms a box, not a circle. If your soldier can throw an object 16 tiles straight ahead, he can also throw 16 tiles diagonally.
The Following is an .xls file which shows how maximum throw ranges are calculated, and can calculate how far a soldier with a given strength can throw any item:

[[Media:Xcomthrowdata.xls | XComthrowdata.xls]]

There are only 21 maximum throw ranges: 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 16, 18, (22)21, (27)23, (35)27, (51)33, (??)46, -1 (unable to throw) - you will only see the last 2 if you hack .DAT files. For (X)Y the X represents the maximum range before you receive the "'''Out of Range!'''" message, and the Y represent the maximum range you can throw (beyond that you receive the 'Unable to throw here' message due to the limited height of the battlespace).

Note: the following only applies if you hack X-Com data/savegame files

Maximum throw range is a signed integer, so if you hack your soldier's strength too high or an item's weight too low it will become negative rendering your soldier unable to throw lightweight items. Throwing with 0 strength crashes the game.

=See Also=
*[[Item Weight]]s
*[[Grenade]]s
*[[Explosions]]
*[[Experience#How_Experience_Points_Are_Applied|Experience]]

{{Unit Stats Navbar}}
[[Category:Soldiers]]

Daiky

2011-03-27T21:41:08Z

Daiky:

OpenXCom battlescape developer.
[http://openxcom.ninex.info/ OpenXcom]

Daiky

2011-03-27T21:38:17Z

Daiky: Created page with "OpenXCom battlescape developer."

OpenXCom battlescape developer.

Fatal Wounds

2011-03-27T21:36:08Z

Daiky: /* Other effects of Fatal Wounds */

For each Fatal Wound a unit has, they will lose one point of [[Health]] each turn. For instance, a soldier with 2 Fatal Wounds will lose 2 Health points per turn. Each time a soldier is shot but not killed by weapons fire, he or she may be dealt 1-3 fatal wounds. All of these fatal wounds will be dealt to the same part of the body.

Fatal Wounds can be healed using a [[Medi-Kit]]. 3 Health points will also be restored with each wound healed. Quickly healing a wounded soldier also means less [[recovery_time|wound recovery time]] (back at base), because recovery time is based on the number of health points lost in a mission.

'''Warning:''' Unconcious soldiers still take damage from Fatal Wounds each turn and CAN DIE if not treated. So if one of your soldiers is knocked unconscious by shots or explosions (as opposed to a stun bomb), it is important that you immediately run a diagnostics scan on him or her. See [[Medi-Kit]] and [[Unconscious]] for more information on how to do this. Keep in mind that you can pick up and move (or even throw) someone, if you have a man down in a hot zone.

== Other effects of Fatal Wounds ==

*Each wound to the '''head''' or '''gun-holding arm''' applies a 10% penalty to your [[Firing Accuracy]], down to but not below -90%. This means that someone with 100 '''base''' firing accuracy who has 9 or more wounds will be left with a '''base''' accuracy level of 10 points. This is before you consider any other accuracy modifiers such as your remaining health percentage (see [[Accuracy formula]]).
*Each wound to the '''legs''' reduces the soldier's [[Time Units]] by 10%.
*Each wound to the '''torso''' reduces the soldier's [[Energy]] by 10%.

''I did a test on this and have lots of doubts on this info above, my unit got 3 fatal wounds on the torso only, and I got a penalty to both throwing and firing accuracy. But no penalty on energy. And with a unit with fatal wounds to the left arm, I got a penalty on the Energy Replenishment level. - [[Daiky|Daiky]]''

== Aliens and Fatal Wounds ==

Aliens never get fatal wounds - they never crawl off and die - except if you were mind controlling them when they were wounded. In other words, only friendlies can get Fatal Wounds, and MC'd aliens count as friendlies. Be careful of mixing MC'd with non-MC'd aliens - you might reaction shoot the one, and hit the other. But wait, there's more - aliens with Fatal Wounds do not suffer any health decrease, for as long as you MC them. They only suffer health loss from their Fatal Wounds on turns that you do not MC them.

''Once I had an MC'd alien taking point, when a different one blaster bombed the lot of us. All hell broke loose, and I lost track of the pet (I assumed he got killed in the blast). Many turns later I heard the entirely unexpected cry of an alien dying, far off in the distance. "Oops" - [[User:MikeTheRed|MikeTheRed]]''

== Probability of Fatal Wounds ==

As shown by Zombie's [http://www.strategycore.co.uk/forums/index.php?showtopic=746&view=findpost&p=72949 research], if you receive more than 10 health [[damage]], you have an equal, random chance of receiving from 1 to 3 Fatals Wounds (a 33.3% chance of 1, 2, or 3 FWs). Higher damage does not change these chances, and you can never receive more than 3 FWs (in a given shot or blast!), even if you're hit so hard you only have 1 hitpoint of life left. Stated another way, if you take 11+ damage, you always get at least one Fatal Wound, an average of 2, and a maximum of 3. Thus, never leave your [[Medi-Kit]]s behind.

If you receive from 1 to 10 damage, the likelihood of a Fatal Wound ''roll'' increases, in which case you roll again for 1, 2, or 3 FWs, evenly. In other words:
Chance of Fatal Wounds
Damage 0 1, 2, or 3 1-3_
1 90.9% 3.03% 9.1%
2 81.8% 6.06% 18.2%
3 72.7% 9.09% 27.3%
4 63.6% 12.12% 36.4%
5 54.5% 15.15% 45.5%
6 45.5% 18.18% 54.5%
7 36.4% 21.21% 63.6%
8 27.3% 24.24% 72.7%
9 18.2% 27.27% 81.8%
10 9.1% 30.30% 90.9%
11+ 0.0% 33.33% 100.0%
Stated another way, the chance of receiving NO Fatal Wounds is: (11 - Damage) / 11, if you receive 1-10 damage. And as discussed, at 11+ hits, you receive the even 33.3% chance of 1 to 3 FWs. Of course, if you receive no damage (0 hitpoints lost), you never get a Fatal Wound.

==See Also==
*[[Medi-Kit]]
*[[Damage]]
*[[Unconscious]]
*[[Accuracy formula]]
*[[Recovery time]]

{{Unit Stats Navbar}}
[[Category:Soldiers]]

Fatal Wounds

2011-03-27T21:33:25Z

Daiky: /* Other effects of Fatal Wounds */

For each Fatal Wound a unit has, they will lose one point of [[Health]] each turn. For instance, a soldier with 2 Fatal Wounds will lose 2 Health points per turn. Each time a soldier is shot but not killed by weapons fire, he or she may be dealt 1-3 fatal wounds. All of these fatal wounds will be dealt to the same part of the body.

Fatal Wounds can be healed using a [[Medi-Kit]]. 3 Health points will also be restored with each wound healed. Quickly healing a wounded soldier also means less [[recovery_time|wound recovery time]] (back at base), because recovery time is based on the number of health points lost in a mission.

'''Warning:''' Unconcious soldiers still take damage from Fatal Wounds each turn and CAN DIE if not treated. So if one of your soldiers is knocked unconscious by shots or explosions (as opposed to a stun bomb), it is important that you immediately run a diagnostics scan on him or her. See [[Medi-Kit]] and [[Unconscious]] for more information on how to do this. Keep in mind that you can pick up and move (or even throw) someone, if you have a man down in a hot zone.

== Other effects of Fatal Wounds ==

*Each wound to the '''head''' or '''gun-holding arm''' applies a 10% penalty to your [[Firing Accuracy]], down to but not below -90%. This means that someone with 100 '''base''' firing accuracy who has 9 or more wounds will be left with a '''base''' accuracy level of 10 points. This is before you consider any other accuracy modifiers such as your remaining health percentage (see [[Accuracy formula]]).
*Each wound to the '''legs''' reduces the soldier's [[Time Units]] by 10%.
*Each wound to the '''torso''' reduces the soldier's [[Energy]] by 10%.

I did a test on this and have lots of doubts on this info above, my unit got 3 fatal wounds on the torso only, and I got a penalty to both throwing and firing accuracy. But no penalty on energy. And with a unit with fatal wounds to the left arm, I got a penalty on the Energy Replenishment level. - Daiky

== Aliens and Fatal Wounds ==

Aliens never get fatal wounds - they never crawl off and die - except if you were mind controlling them when they were wounded. In other words, only friendlies can get Fatal Wounds, and MC'd aliens count as friendlies. Be careful of mixing MC'd with non-MC'd aliens - you might reaction shoot the one, and hit the other. But wait, there's more - aliens with Fatal Wounds do not suffer any health decrease, for as long as you MC them. They only suffer health loss from their Fatal Wounds on turns that you do not MC them.

''Once I had an MC'd alien taking point, when a different one blaster bombed the lot of us. All hell broke loose, and I lost track of the pet (I assumed he got killed in the blast). Many turns later I heard the entirely unexpected cry of an alien dying, far off in the distance. "Oops" - [[User:MikeTheRed|MikeTheRed]]''

== Probability of Fatal Wounds ==

As shown by Zombie's [http://www.strategycore.co.uk/forums/index.php?showtopic=746&view=findpost&p=72949 research], if you receive more than 10 health [[damage]], you have an equal, random chance of receiving from 1 to 3 Fatals Wounds (a 33.3% chance of 1, 2, or 3 FWs). Higher damage does not change these chances, and you can never receive more than 3 FWs (in a given shot or blast!), even if you're hit so hard you only have 1 hitpoint of life left. Stated another way, if you take 11+ damage, you always get at least one Fatal Wound, an average of 2, and a maximum of 3. Thus, never leave your [[Medi-Kit]]s behind.

If you receive from 1 to 10 damage, the likelihood of a Fatal Wound ''roll'' increases, in which case you roll again for 1, 2, or 3 FWs, evenly. In other words:
Chance of Fatal Wounds
Damage 0 1, 2, or 3 1-3_
1 90.9% 3.03% 9.1%
2 81.8% 6.06% 18.2%
3 72.7% 9.09% 27.3%
4 63.6% 12.12% 36.4%
5 54.5% 15.15% 45.5%
6 45.5% 18.18% 54.5%
7 36.4% 21.21% 63.6%
8 27.3% 24.24% 72.7%
9 18.2% 27.27% 81.8%
10 9.1% 30.30% 90.9%
11+ 0.0% 33.33% 100.0%
Stated another way, the chance of receiving NO Fatal Wounds is: (11 - Damage) / 11, if you receive 1-10 damage. And as discussed, at 11+ hits, you receive the even 33.3% chance of 1 to 3 FWs. Of course, if you receive no damage (0 hitpoints lost), you never get a Fatal Wound.

==See Also==
*[[Medi-Kit]]
*[[Damage]]
*[[Unconscious]]
*[[Accuracy formula]]
*[[Recovery time]]

{{Unit Stats Navbar}}
[[Category:Soldiers]]

Fatal Wounds

2011-03-27T19:39:58Z

Daiky:

For each Fatal Wound a unit has, they will lose one point of [[Health]] each turn. For instance, a soldier with 2 Fatal Wounds will lose 2 Health points per turn. Each time a soldier is shot but not killed by weapons fire, he or she may be dealt 1-3 fatal wounds. All of these fatal wounds will be dealt to the same part of the body.

Fatal Wounds can be healed using a [[Medi-Kit]]. 3 Health points will also be restored with each wound healed. Quickly healing a wounded soldier also means less [[recovery_time|wound recovery time]] (back at base), because recovery time is based on the number of health points lost in a mission.

'''Warning:''' Unconcious soldiers still take damage from Fatal Wounds each turn and CAN DIE if not treated. So if one of your soldiers is knocked unconscious by shots or explosions (as opposed to a stun bomb), it is important that you immediately run a diagnostics scan on him or her. See [[Medi-Kit]] and [[Unconscious]] for more information on how to do this. Keep in mind that you can pick up and move (or even throw) someone, if you have a man down in a hot zone.

== Other effects of Fatal Wounds ==

*Each wound to the '''head''' or '''gun-holding arm''' applies a 10% penalty to your [[Firing Accuracy]], down to but not below -90%. This means that someone with 100 '''base''' firing accuracy who has 9 or more wounds will be left with a '''base''' accuracy level of 10 points. This is before you consider any other accuracy modifiers such as your remaining health percentage (see [[Accuracy formula]]).
*Each wound to the '''legs''' reduces the soldier's [[Time Units]] by 10%.
*Each wound to the '''torso''' reduces the soldier's [[Energy]] by 10%.
*Each wound to the '''left-arm''' also reduces the soldier's [[Energy]] by 10%.

== Aliens and Fatal Wounds ==

Aliens never get fatal wounds - they never crawl off and die - except if you were mind controlling them when they were wounded. In other words, only friendlies can get Fatal Wounds, and MC'd aliens count as friendlies. Be careful of mixing MC'd with non-MC'd aliens - you might reaction shoot the one, and hit the other. But wait, there's more - aliens with Fatal Wounds do not suffer any health decrease, for as long as you MC them. They only suffer health loss from their Fatal Wounds on turns that you do not MC them.

''Once I had an MC'd alien taking point, when a different one blaster bombed the lot of us. All hell broke loose, and I lost track of the pet (I assumed he got killed in the blast). Many turns later I heard the entirely unexpected cry of an alien dying, far off in the distance. "Oops" - [[User:MikeTheRed|MikeTheRed]]''

== Probability of Fatal Wounds ==

As shown by Zombie's [http://www.strategycore.co.uk/forums/index.php?showtopic=746&view=findpost&p=72949 research], if you receive more than 10 health [[damage]], you have an equal, random chance of receiving from 1 to 3 Fatals Wounds (a 33.3% chance of 1, 2, or 3 FWs). Higher damage does not change these chances, and you can never receive more than 3 FWs (in a given shot or blast!), even if you're hit so hard you only have 1 hitpoint of life left. Stated another way, if you take 11+ damage, you always get at least one Fatal Wound, an average of 2, and a maximum of 3. Thus, never leave your [[Medi-Kit]]s behind.

If you receive from 1 to 10 damage, the likelihood of a Fatal Wound ''roll'' increases, in which case you roll again for 1, 2, or 3 FWs, evenly. In other words:
Chance of Fatal Wounds
Damage 0 1, 2, or 3 1-3_
1 90.9% 3.03% 9.1%
2 81.8% 6.06% 18.2%
3 72.7% 9.09% 27.3%
4 63.6% 12.12% 36.4%
5 54.5% 15.15% 45.5%
6 45.5% 18.18% 54.5%
7 36.4% 21.21% 63.6%
8 27.3% 24.24% 72.7%
9 18.2% 27.27% 81.8%
10 9.1% 30.30% 90.9%
11+ 0.0% 33.33% 100.0%
Stated another way, the chance of receiving NO Fatal Wounds is: (11 - Damage) / 11, if you receive 1-10 damage. And as discussed, at 11+ hits, you receive the even 33.3% chance of 1 to 3 FWs. Of course, if you receive no damage (0 hitpoints lost), you never get a Fatal Wound.

==See Also==
*[[Medi-Kit]]
*[[Damage]]
*[[Unconscious]]
*[[Accuracy formula]]
*[[Recovery time]]

{{Unit Stats Navbar}}
[[Category:Soldiers]]

MCD

2011-03-01T19:52:27Z

Daiky:

{{tocright}}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 [[Image_Formats#PCK|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|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 [[MAPS|associated map modules]] are also loaded into a [[MAP.DAT|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|44]] and [[#46|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 [[Known_Bugs#Door_jam|doors to stick open]], as offset [[#47|47]] won't be correctly tracked.

==Structure==

{| class="wikitable"
|-
!Offset (Decimal)
!Offset (Hex)
!Usage
|- valign="top"
!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|[46]]]), bubbles on TFTD, blinking lifts, etc. If all eight frames are the same, it's a static tile.
|- valign="top"
!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]].
|- valign="top"
!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]].
|- valign="top"
!22-25
!0x16-0x19
|Four byte value pointing to the RAM location of the [[Image_Formats#PCK|TAB index for the PCK data]] used by the terrain file. Only used at run-time.
|- valign="top"
!26-29
!0x1A-0x1D
|Four byte value pointing to the RAM location of the [[Image_Formats#PCK|PCK set]] used by the terrain file. Only used at run-time.
|- valign="top"
!30
!0x1E
|Boolean: Is sliding door? See [[#46|[46]]].
|- valign="top"
!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 visibility of terrain, although their flag is 0, but it's ignored for floor tiles.
|- valign="top"
!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''
|- valign="top"
!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|[39]]]) and height ([[#48|[48]]]). Called "BigWall" in [[MapView]].
|- valign="top"
!34
!0x22
|Boolean: Is Grav lift? Up/down of lifts is determined by whether there is another one above or below in the .MAP.
|- valign="top"
!35
!0x23
|Boolean: Is hinged door? See [[#46|[46]]].
|- valign="top"
!36
!0x24
|Boolean: Blocks fire?
|- valign="top"
!37
!0x25
|Boolean: Blocks smoke?
|- valign="top"
!38
!0x26
|Unknown - Always 3.
|- valign="top"
!39
!0x27
|Time units used to walk across the tile (255 means unpassable).
|- valign="top"
!40
!0x28
|Time units used to slide across the tile (255 means unpassable).
|- valign="top"
!41
!0x29
|Time units used to fly across the tile (255 means unpassable).
|-
|colspan="3"|For [[#39|[39]]] to [[#41|[41]]], values range from 0 to 8, or are 255. There are only a few places where they are not all the same ([[#39|[39]]]=[[#40|[40]]]=[[#41|[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.DAT#11|UnitRef[11]]]. Note that by default, ALL units are "walkers".
|- valign="top"
!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|[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 [[Explosions#Mile-High Madness|Mountain Madness]].
*''[[User:NKF|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.
|- valign="top"
!43
!0x2B
|[[Explosions#HE Block|HE Blockage]]
|- valign="top"
!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|[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.)
|- valign="top"
!45
!0x2D
|The higher this is, the less likely the tile will be set on fire.
|- valign="top"
!46
!0x2E
|If the tile is a door ([[#30|[30]]] or [[#35|[35]]]), the tile will become this tile number when opened. Animation [0] (see [[#0-7|[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.
|- valign="top"
!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 [[Known_Bugs#Door_jam|cause them to jam]] until another door of the same type is opened.
|- valign="top"
!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.
|- valign="top"
!49
!0x31
|Subtract this value from the graphical Y offset of the tile image (used for hills).
|- valign="top"
!50
!0x32
|Unknown - Always 0.
|- valign="top"
!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.
|- valign="top"
!52
!0x34
|Footstep sound effect. Most likely an index to the .CAT file RAW wave ''-[http://www.strategycore.co.uk/forums/Map-Control-Data-MCD-long-Post-t1468.html BladeFireLight]
0 Not used in XCOM (makes a metal sound if hacked); is used on TFTD for some objects ''-[[User:Hobbes|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)
|- valign="top"
!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|[44]]]): There are 22 instances of [[Explosions#Mile-High Madness|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).
|- valign="top"
!54
!0x36
|Explosive type; [[#55|[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|[42]]]=0) are obliterated before exploding (i.e., they won't explode, no matter how high [[#55|[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). ''[[user:Hobbes|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 [[User:Hobbes|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).
|- valign="top"
!55
!0x37
|Strength of explosion when tile is destroyed.
|- valign="top"
!56
!0x38
|Smoke blockage. This is set to 0 for all UFO tiles!

'''''Perhaps [[#36|[36]]] is used only? A varying [56] might have been where the 2 un-used smoke sprites would have come in. --[[User:Danial|Danial]]'''''
|- valign="top"
!57
!0x39
|The amount of turns this tile will burn for.
|- valign="top"
!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#Artificial_Lighting|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 [[Night Missions|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. - [[User:Bomb Bloke|Bomb Bloke]] 06:48, 20 June 2008 (PDT)''
|- valign="top"
!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)''
|- valign="top"
!60
!0x3C
|Set to 1 for [[Base_Defense#Destruction_Of_Base_Facilities|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, [[Base_Defense#Destruction_Of_Base_Facilities|it may be destroyed]].
|- valign="top"
!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):
<table cellpadding="10">
<tr><td valign="top">
<table {{StdCenterTable}} class="sortable">
<caption>X-COM MCD Files</caption>
<tr {{StdDescTable_Heading}}><th width="100" align="left">File</th><th>Terrain</th><th>Records</th></tr>
<tr><td align="left">avenger</td><td>Avenger</td><td>59</td></tr>
<tr><td align="left">barn</td><td>Farm</td><td>29</td></tr>
<tr><td align="left">blanks</td><td>All</td><td>2</td></tr>
<tr><td align="left">brain</td><td>Alien Base</td><td>4</td></tr>
<tr><td align="left">cultivat</td><td>Farm</td><td>37</td></tr>
<tr><td align="left">desert</td><td>Desert</td><td>66</td></tr>
<tr><td align="left">forest</td><td>Forest</td><td>83</td></tr>
<tr><td align="left">frniture</td><td>City</td><td>26</td></tr>
<tr><td align="left">jungle</td><td>Jungle</td><td>82</td></tr>
<tr><td align="left">lightnin</td><td>Lightning</td><td>42</td></tr>
<tr><td align="left">mars</td><td>Cydonia</td><td>36</td></tr>
<tr><td align="left">mount</td><td>Mountain</td><td>78</td></tr>
<tr><td align="left">plane</td><td>Skyranger</td><td>65</td></tr>
<tr><td align="left">polar</td><td>Polar</td><td>81</td></tr>
<tr><td align="left">roads</td><td>City</td><td>23</td></tr>
<tr><td align="left">ufo1</td><td>Small Scout</td><td>20</td></tr>
<tr><td align="left">urban</td><td>City</td><td>112</td></tr>
<tr><td align="left">urbits</td><td>City</td><td>25</td></tr>
<tr><td align="left">u_base</td><td>Alien Base</td><td>67</td></tr>
<tr><td align="left">u_bits</td><td>UFOs</td><td>8</td></tr>
<tr><td align="left">u_disec2</td><td>UFOs</td><td>17</td></tr>
<tr><td align="left">u_ext02</td><td>UFOs</td><td>34</td></tr>
<tr><td align="left">u_oper2</td><td>UFOs</td><td>15</td></tr>
<tr><td align="left">u_pods</td><td>UFO/Alien Base</td><td>11</td></tr>
<tr><td align="left">u_wall02</td><td>UFO/Alien Base/Cydonia</td><td>47</td></tr>
<tr><td align="left">xbase1</td><td>X-COM Base</td><td>97</td></tr>
<tr><td align="left">xbase2</td><td>X-COM Base</td><td>62</td></tr></table>
</td>
<td>
<table {{StdCenterTable}} class="sortable">
<caption>TFTD MCD Files</caption>
<tr {{StdDescTable_Heading}}><th width="100" align="left">File</th><th>Terrain</th><th>Records</th></tr>
<tr><td align="left">asunk</td><td>Sunken Galleon</td><td>50</td></tr>
<tr><td align="left">atlantis</td><td>Atlantis</td><td>77</td></tr>
<tr><td align="left">barracud</td><td>Barracuda</td><td>46</td></tr>
<tr><td align="left">blanks</td><td>All</td><td>2</td></tr>
<tr><td align="left">cargo1</td><td>Cargo Ship</td><td>103</td></tr>
<tr><td align="left">cargo2</td><td>Cargo Ship</td><td>13</td></tr>
<tr><td align="left">cargo3</td><td>Cargo Ship</td><td>6</td></tr>
<tr><td align="left">coral</td><td>Coral</td><td>28</td></tr>
<tr><td align="left">crypt1</td><td>Crypt</td><td>45</td></tr>
<tr><td align="left">crypt2</td><td>Crypt</td><td>49</td></tr>
<tr><td align="left">crypt3</td><td>Crypt</td><td>12</td></tr>
<tr><td align="left">crypt4</td><td>Crypt</td><td>7</td></tr>
<tr><td align="left">debris</td><td>Seabed</td><td>50</td></tr>
<tr><td align="left">deckc</td><td>Liner Ship (Top)</td><td>18</td></tr>
<tr><td align="left">entry</td><td>Entry</td><td>12</td></tr>
<tr><td align="left">grunge1</td><td>Artifact Site</td><td>38</td></tr>
<tr><td align="left">grunge2</td><td>Artifact Site</td><td>8</td></tr>
<tr><td align="left">grunge3</td><td>Artifact Site</td><td>10</td></tr>
<tr><td align="left">grunge4</td><td>Artifact Site</td><td>37</td></tr>
<tr><td align="left">hammer</td><td>Hammerhead</td><td>44</td></tr>
<tr><td align="left">island1</td><td>Island</td><td>50</td></tr>
<tr><td align="left">island2</td><td>Island</td><td>50</td></tr>
<tr><td align="left">island3</td><td>Island</td><td>35</td></tr>
<tr><td align="left">leviath</td><td>Leviathan</td><td>47</td></tr>
<tr><td align="left">linera</td><td>Liner Ship</td><td>99</td></tr>
<tr><td align="left">linerb</td><td>Liner Ship</td><td>24</td></tr>
<tr><td align="left">linerc</td><td>Liner Ship</td><td>40</td></tr>
<tr><td align="left">linerd</td><td>Liner Ship</td><td>23</td></tr>
<tr><td align="left">manta</td><td>Manta</td><td>44</td></tr>
<tr><td align="left">msunk1</td><td>Sunken Ship</td><td>50</td></tr>
<tr><td align="left">msunk2</td><td>Sunken Ship</td><td>29</td></tr>
<tr><td align="left">mu</td><td>Mu</td><td>80</td></tr>
<tr><td align="left">organic1</td><td>Alien Base/Level/Entry</td><td>96</td></tr>
<tr><td align="left">organic2</td><td>Alien Base/Level</td><td>10</td></tr>
<tr><td align="left">organic3</td><td>Alien Base/Level</td><td>4</td></tr>
<tr><td align="left">pipes</td><td>Pipes</td><td>55</td></tr>
<tr><td align="left">planes</td><td>Sunken Plane</td><td>79</td></tr>
<tr><td align="left">port01</td><td>Port</td><td>95</td></tr>
<tr><td align="left">port02</td><td>Port</td><td>78</td></tr>
<tr><td align="left">psynom</td><td>Alien Base/Level</td><td>2</td></tr>
<tr><td align="left">pyramid</td><td>Artifact</td><td>24</td></tr>
<tr><td align="left">rocks</td><td>Artifact/Seabed/Galleon</td><td>15</td></tr>
<tr><td align="left">sand</td><td>several</td><td>20</td></tr>
<tr><td align="left">sea</td><td>several</td><td>18</td></tr>
<tr><td align="left">triton</td><td>Triton</td><td>46</td></tr>
<tr><td align="left">uext1</td><td>?</td><td>4</td></tr>
<tr><td align="left">uext2</td><td>USO/Entry</td><td>9</td></tr>
<tr><td align="left">uext3</td><td>USO/Entry</td><td>25</td></tr>
<tr><td align="left">ufobits</td><td>several</td><td>5</td></tr>
<tr><td align="left">uint1</td><td>USO</td><td>41</td></tr>
<tr><td align="left">uint2</td><td>USO</td><td>11</td></tr>
<tr><td align="left">uint3</td><td>USO</td><td>14</td></tr>
<tr><td align="left">volc</td><td>Volcanic</td><td>80</td></tr>
<tr><td align="left">weeds</td><td>Artifact/Coral/Seabed</td><td>10</td></tr>
<tr><td align="left">xbases1</td><td>X-COM Base</td><td>87</td></tr>
<tr><td align="left">xbases2</td><td>X-COM Base</td><td>42</td></tr>
<tr><td align="left">xbases3</td><td>X-COM Base</td><td>37</td></tr>
<tr><td align="left">xbases4</td><td>X-COM Base</td><td>43</td></tr>
<tr><td align="left">xbases5</td><td>X-COM Base</td><td>42</td></tr>
<tr><td align="left">xbits</td><td>Cargo Ship</td><td>39</td></tr></table>
</td></tr></table>

==Additional Information==

===MikeTheRed's MCD Database===
An Access 2000 copy of all MCD data is [[Media:XcomMCD.zip|here]]. It's from X-COM DOS 1.4, but AFAIK, all X-COM versions use the same data (even down to the buggy [[Explosions#Mile-High_Madness|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 [http://www.strategycore.co.uk/forums/lofiversion/index.php?t1468.html this] message by BladeFireLight. His post also contains a [http://www.HexWorkshop.com HexWorkshop] template for viewing MCD files in a logical manner.

===MCD Editor===
Koralt's MCDEdit can view or modify MCD files. Find it here: [http://mypage.bluewin.ch/xcom/mcdedit.zip mcdedit.zip]. To see a screencap, scroll to the very bottom of BladeFireLight's MCD posting (above). MCDEdit needs [http://mypage.bluewin.ch/xcom/vbrun200.zip vbrun200] to run!

===MapView===
DaiShiva has an excellent utility called [http://www.daishiva.com/phpBB2/generic.php?page=progLinks.shtml 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===
[[User:Bomb Bloke|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|[42]]], HE Block [[#43|[43]]], and Explosion Strength [[#55|[55]]] (but not type, [[#55|[54]]]), and it includes all four types of terrain item. Find his hacked terrain
[http://www.strategycore.co.uk/forums/index.php?showtopic=746&st=195&# here] or bundled with a savegame [http://www.xcomufo.com/forums/index.php?showtopic=8701&st=114&# here]. To see a screencap of the tiles in action, see [http://www.xcomufo.com/forums/index.php?showtopic=8701&st=112&# this] message.

[[Category:Game Files]]

MCD

2011-03-01T19:51:30Z

Daiky:

{{tocright}}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 [[Image_Formats#PCK|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|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 [[MAPS|associated map modules]] are also loaded into a [[MAP.DAT|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|44]] and [[#46|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 [[Known_Bugs#Door_jam|doors to stick open]], as offset [[#47|47]] won't be correctly tracked.

==Structure==

{| class="wikitable"
|-
!Offset (Decimal)
!Offset (Hex)
!Usage
|- valign="top"
!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|[46]]]), bubbles on TFTD, blinking lifts, etc. If all eight frames are the same, it's a static tile.
|- valign="top"
!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]].
|- valign="top"
!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]].
|- valign="top"
!22-25
!0x16-0x19
|Four byte value pointing to the RAM location of the [[Image_Formats#PCK|TAB index for the PCK data]] used by the terrain file. Only used at run-time.
|- valign="top"
!26-29
!0x1A-0x1D
|Four byte value pointing to the RAM location of the [[Image_Formats#PCK|PCK set]] used by the terrain file. Only used at run-time.
|- valign="top"
!30
!0x1E
|Boolean: Is sliding door? See [[#46|[46]]].
|- valign="top"
!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.
|- valign="top"
!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''
|- valign="top"
!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|[39]]]) and height ([[#48|[48]]]). Called "BigWall" in [[MapView]].
|- valign="top"
!34
!0x22
|Boolean: Is Grav lift? Up/down of lifts is determined by whether there is another one above or below in the .MAP.
|- valign="top"
!35
!0x23
|Boolean: Is hinged door? See [[#46|[46]]].
|- valign="top"
!36
!0x24
|Boolean: Blocks fire?
|- valign="top"
!37
!0x25
|Boolean: Blocks smoke?
|- valign="top"
!38
!0x26
|Unknown - Always 3.
|- valign="top"
!39
!0x27
|Time units used to walk across the tile (255 means unpassable).
|- valign="top"
!40
!0x28
|Time units used to slide across the tile (255 means unpassable).
|- valign="top"
!41
!0x29
|Time units used to fly across the tile (255 means unpassable).
|-
|colspan="3"|For [[#39|[39]]] to [[#41|[41]]], values range from 0 to 8, or are 255. There are only a few places where they are not all the same ([[#39|[39]]]=[[#40|[40]]]=[[#41|[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.DAT#11|UnitRef[11]]]. Note that by default, ALL units are "walkers".
|- valign="top"
!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|[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 [[Explosions#Mile-High Madness|Mountain Madness]].
*''[[User:NKF|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.
|- valign="top"
!43
!0x2B
|[[Explosions#HE Block|HE Blockage]]
|- valign="top"
!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|[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.)
|- valign="top"
!45
!0x2D
|The higher this is, the less likely the tile will be set on fire.
|- valign="top"
!46
!0x2E
|If the tile is a door ([[#30|[30]]] or [[#35|[35]]]), the tile will become this tile number when opened. Animation [0] (see [[#0-7|[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.
|- valign="top"
!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 [[Known_Bugs#Door_jam|cause them to jam]] until another door of the same type is opened.
|- valign="top"
!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.
|- valign="top"
!49
!0x31
|Subtract this value from the graphical Y offset of the tile image (used for hills).
|- valign="top"
!50
!0x32
|Unknown - Always 0.
|- valign="top"
!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.
|- valign="top"
!52
!0x34
|Footstep sound effect. Most likely an index to the .CAT file RAW wave ''-[http://www.strategycore.co.uk/forums/Map-Control-Data-MCD-long-Post-t1468.html BladeFireLight]
0 Not used in XCOM (makes a metal sound if hacked); is used on TFTD for some objects ''-[[User:Hobbes|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)
|- valign="top"
!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|[44]]]): There are 22 instances of [[Explosions#Mile-High Madness|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).
|- valign="top"
!54
!0x36
|Explosive type; [[#55|[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|[42]]]=0) are obliterated before exploding (i.e., they won't explode, no matter how high [[#55|[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). ''[[user:Hobbes|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 [[User:Hobbes|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).
|- valign="top"
!55
!0x37
|Strength of explosion when tile is destroyed.
|- valign="top"
!56
!0x38
|Smoke blockage. This is set to 0 for all UFO tiles!

'''''Perhaps [[#36|[36]]] is used only? A varying [56] might have been where the 2 un-used smoke sprites would have come in. --[[User:Danial|Danial]]'''''
|- valign="top"
!57
!0x39
|The amount of turns this tile will burn for.
|- valign="top"
!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#Artificial_Lighting|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 [[Night Missions|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. - [[User:Bomb Bloke|Bomb Bloke]] 06:48, 20 June 2008 (PDT)''
|- valign="top"
!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)''
|- valign="top"
!60
!0x3C
|Set to 1 for [[Base_Defense#Destruction_Of_Base_Facilities|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, [[Base_Defense#Destruction_Of_Base_Facilities|it may be destroyed]].
|- valign="top"
!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):
<table cellpadding="10">
<tr><td valign="top">
<table {{StdCenterTable}} class="sortable">
<caption>X-COM MCD Files</caption>
<tr {{StdDescTable_Heading}}><th width="100" align="left">File</th><th>Terrain</th><th>Records</th></tr>
<tr><td align="left">avenger</td><td>Avenger</td><td>59</td></tr>
<tr><td align="left">barn</td><td>Farm</td><td>29</td></tr>
<tr><td align="left">blanks</td><td>All</td><td>2</td></tr>
<tr><td align="left">brain</td><td>Alien Base</td><td>4</td></tr>
<tr><td align="left">cultivat</td><td>Farm</td><td>37</td></tr>
<tr><td align="left">desert</td><td>Desert</td><td>66</td></tr>
<tr><td align="left">forest</td><td>Forest</td><td>83</td></tr>
<tr><td align="left">frniture</td><td>City</td><td>26</td></tr>
<tr><td align="left">jungle</td><td>Jungle</td><td>82</td></tr>
<tr><td align="left">lightnin</td><td>Lightning</td><td>42</td></tr>
<tr><td align="left">mars</td><td>Cydonia</td><td>36</td></tr>
<tr><td align="left">mount</td><td>Mountain</td><td>78</td></tr>
<tr><td align="left">plane</td><td>Skyranger</td><td>65</td></tr>
<tr><td align="left">polar</td><td>Polar</td><td>81</td></tr>
<tr><td align="left">roads</td><td>City</td><td>23</td></tr>
<tr><td align="left">ufo1</td><td>Small Scout</td><td>20</td></tr>
<tr><td align="left">urban</td><td>City</td><td>112</td></tr>
<tr><td align="left">urbits</td><td>City</td><td>25</td></tr>
<tr><td align="left">u_base</td><td>Alien Base</td><td>67</td></tr>
<tr><td align="left">u_bits</td><td>UFOs</td><td>8</td></tr>
<tr><td align="left">u_disec2</td><td>UFOs</td><td>17</td></tr>
<tr><td align="left">u_ext02</td><td>UFOs</td><td>34</td></tr>
<tr><td align="left">u_oper2</td><td>UFOs</td><td>15</td></tr>
<tr><td align="left">u_pods</td><td>UFO/Alien Base</td><td>11</td></tr>
<tr><td align="left">u_wall02</td><td>UFO/Alien Base/Cydonia</td><td>47</td></tr>
<tr><td align="left">xbase1</td><td>X-COM Base</td><td>97</td></tr>
<tr><td align="left">xbase2</td><td>X-COM Base</td><td>62</td></tr></table>
</td>
<td>
<table {{StdCenterTable}} class="sortable">
<caption>TFTD MCD Files</caption>
<tr {{StdDescTable_Heading}}><th width="100" align="left">File</th><th>Terrain</th><th>Records</th></tr>
<tr><td align="left">asunk</td><td>Sunken Galleon</td><td>50</td></tr>
<tr><td align="left">atlantis</td><td>Atlantis</td><td>77</td></tr>
<tr><td align="left">barracud</td><td>Barracuda</td><td>46</td></tr>
<tr><td align="left">blanks</td><td>All</td><td>2</td></tr>
<tr><td align="left">cargo1</td><td>Cargo Ship</td><td>103</td></tr>
<tr><td align="left">cargo2</td><td>Cargo Ship</td><td>13</td></tr>
<tr><td align="left">cargo3</td><td>Cargo Ship</td><td>6</td></tr>
<tr><td align="left">coral</td><td>Coral</td><td>28</td></tr>
<tr><td align="left">crypt1</td><td>Crypt</td><td>45</td></tr>
<tr><td align="left">crypt2</td><td>Crypt</td><td>49</td></tr>
<tr><td align="left">crypt3</td><td>Crypt</td><td>12</td></tr>
<tr><td align="left">crypt4</td><td>Crypt</td><td>7</td></tr>
<tr><td align="left">debris</td><td>Seabed</td><td>50</td></tr>
<tr><td align="left">deckc</td><td>Liner Ship (Top)</td><td>18</td></tr>
<tr><td align="left">entry</td><td>Entry</td><td>12</td></tr>
<tr><td align="left">grunge1</td><td>Artifact Site</td><td>38</td></tr>
<tr><td align="left">grunge2</td><td>Artifact Site</td><td>8</td></tr>
<tr><td align="left">grunge3</td><td>Artifact Site</td><td>10</td></tr>
<tr><td align="left">grunge4</td><td>Artifact Site</td><td>37</td></tr>
<tr><td align="left">hammer</td><td>Hammerhead</td><td>44</td></tr>
<tr><td align="left">island1</td><td>Island</td><td>50</td></tr>
<tr><td align="left">island2</td><td>Island</td><td>50</td></tr>
<tr><td align="left">island3</td><td>Island</td><td>35</td></tr>
<tr><td align="left">leviath</td><td>Leviathan</td><td>47</td></tr>
<tr><td align="left">linera</td><td>Liner Ship</td><td>99</td></tr>
<tr><td align="left">linerb</td><td>Liner Ship</td><td>24</td></tr>
<tr><td align="left">linerc</td><td>Liner Ship</td><td>40</td></tr>
<tr><td align="left">linerd</td><td>Liner Ship</td><td>23</td></tr>
<tr><td align="left">manta</td><td>Manta</td><td>44</td></tr>
<tr><td align="left">msunk1</td><td>Sunken Ship</td><td>50</td></tr>
<tr><td align="left">msunk2</td><td>Sunken Ship</td><td>29</td></tr>
<tr><td align="left">mu</td><td>Mu</td><td>80</td></tr>
<tr><td align="left">organic1</td><td>Alien Base/Level/Entry</td><td>96</td></tr>
<tr><td align="left">organic2</td><td>Alien Base/Level</td><td>10</td></tr>
<tr><td align="left">organic3</td><td>Alien Base/Level</td><td>4</td></tr>
<tr><td align="left">pipes</td><td>Pipes</td><td>55</td></tr>
<tr><td align="left">planes</td><td>Sunken Plane</td><td>79</td></tr>
<tr><td align="left">port01</td><td>Port</td><td>95</td></tr>
<tr><td align="left">port02</td><td>Port</td><td>78</td></tr>
<tr><td align="left">psynom</td><td>Alien Base/Level</td><td>2</td></tr>
<tr><td align="left">pyramid</td><td>Artifact</td><td>24</td></tr>
<tr><td align="left">rocks</td><td>Artifact/Seabed/Galleon</td><td>15</td></tr>
<tr><td align="left">sand</td><td>several</td><td>20</td></tr>
<tr><td align="left">sea</td><td>several</td><td>18</td></tr>
<tr><td align="left">triton</td><td>Triton</td><td>46</td></tr>
<tr><td align="left">uext1</td><td>?</td><td>4</td></tr>
<tr><td align="left">uext2</td><td>USO/Entry</td><td>9</td></tr>
<tr><td align="left">uext3</td><td>USO/Entry</td><td>25</td></tr>
<tr><td align="left">ufobits</td><td>several</td><td>5</td></tr>
<tr><td align="left">uint1</td><td>USO</td><td>41</td></tr>
<tr><td align="left">uint2</td><td>USO</td><td>11</td></tr>
<tr><td align="left">uint3</td><td>USO</td><td>14</td></tr>
<tr><td align="left">volc</td><td>Volcanic</td><td>80</td></tr>
<tr><td align="left">weeds</td><td>Artifact/Coral/Seabed</td><td>10</td></tr>
<tr><td align="left">xbases1</td><td>X-COM Base</td><td>87</td></tr>
<tr><td align="left">xbases2</td><td>X-COM Base</td><td>42</td></tr>
<tr><td align="left">xbases3</td><td>X-COM Base</td><td>37</td></tr>
<tr><td align="left">xbases4</td><td>X-COM Base</td><td>43</td></tr>
<tr><td align="left">xbases5</td><td>X-COM Base</td><td>42</td></tr>
<tr><td align="left">xbits</td><td>Cargo Ship</td><td>39</td></tr></table>
</td></tr></table>

==Additional Information==

===MikeTheRed's MCD Database===
An Access 2000 copy of all MCD data is [[Media:XcomMCD.zip|here]]. It's from X-COM DOS 1.4, but AFAIK, all X-COM versions use the same data (even down to the buggy [[Explosions#Mile-High_Madness|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 [http://www.strategycore.co.uk/forums/lofiversion/index.php?t1468.html this] message by BladeFireLight. His post also contains a [http://www.HexWorkshop.com HexWorkshop] template for viewing MCD files in a logical manner.

===MCD Editor===
Koralt's MCDEdit can view or modify MCD files. Find it here: [http://mypage.bluewin.ch/xcom/mcdedit.zip mcdedit.zip]. To see a screencap, scroll to the very bottom of BladeFireLight's MCD posting (above). MCDEdit needs [http://mypage.bluewin.ch/xcom/vbrun200.zip vbrun200] to run!

===MapView===
DaiShiva has an excellent utility called [http://www.daishiva.com/phpBB2/generic.php?page=progLinks.shtml 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===
[[User:Bomb Bloke|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|[42]]], HE Block [[#43|[43]]], and Explosion Strength [[#55|[55]]] (but not type, [[#55|[54]]]), and it includes all four types of terrain item. Find his hacked terrain
[http://www.strategycore.co.uk/forums/index.php?showtopic=746&st=195&# here] or bundled with a savegame [http://www.xcomufo.com/forums/index.php?showtopic=8701&st=114&# here]. To see a screencap of the tiles in action, see [http://www.xcomufo.com/forums/index.php?showtopic=8701&st=112&# this] message.

[[Category:Game Files]]

LOFTEMPS.DAT

2011-03-01T19:47:50Z

Daiky:

{{tocright}}

'''LOFTEMPS.DAT''' is found in the [[GEODATA]] folder. It contains "Line of Fire Templates", used to create 3D representations of the creatures and objects within the battlescape. These are used for [[Line of sight]] (LOS) (to see units, terrain uses MCD[31]) and line of fire (LOF) purposes.

The file is made up of multiple 16x16 bitmaps (32 bytes each, one bit per pixel, where 1 is solid and 0 is empty). These are then double layered using the 12 LOF references for tiles defined in the [[MCD|MCD files]], to create 3D 16x16x24 objects for each.

Units are represented by a single LOF template, usually a round one, which is defined by offset 48 of the [[UNITREF.DAT]] record for that unit. This is stacked according to the unit's [[height]] (offset 49 or 50, depending on whether the unit is standing or kneeling), to create a cylinder shape. Note that "large" units, which cover four tiles, are made up of four such cylinders.

In UFO there are 112 entries, 3,584 bytes in total (or, in TFTD, 114 entries spanning 3,648 bytes). TFTD stores the LOFTEMPS tables in the [[TERRAIN]] folder, but also keeps a copy of UFO's version in its original location - though this old version is unused.

==Template Usage==
[[image:Loftemps_Example.png|right|thumb|150px|An example of a 3D tree made up of stacked LOF templates. Click for a larger view.]]
Both UFO and TFTD are presented as 2D games, that is to say, all the images on the screen are made up of sprites. In the battlescape, everything is shown from an isometric perspective.

However, the games are only ''presented'' in 2D - much of the actual processing is done on 3D objects (albeit primitive ones). These are defined by stacking the LOF templates stored on this file on top of each other.

When a soldier crouches next to a short wall, for example, he may no longer be able to see over it if his head is now below the top. Likewise, he may or may not be able to see through the slats of a picket fence, depending on what angle he views it from.

Likewise, these 3D objects also come into play when bullets fly though the air. If a unit is hiding behind a tree, the thick foliage will likely protect his head from a bullet aimed high - but a low flying shot may easily go past the thin trunk and get him in the legs.

A soldier's head is positioned slightly higher then the barrel of his gun. For this reason, it is possible for him to be able to ''see'' an alien (that is, he has a valid "line of sight"), but not ''shoot'' it (because he has a blocked "line of fire").

==Template Oddities==
===Diagonal Processing===
If two "solid" points of a template are placed next to each other, horizontally or vertically, then there will be no way to see/shoot between them. This is not the case, however, if they are only connected diagonally. This is why no diagonal "lines" of a single pixel in width exist within the template tables (as they would be very ineffective at blocking sight/bullets).

However, a problem occurs when placing two templates next to each other on the diagonal: You can't "widen" them at the meeting point, so at that exact spot there'll be two "solid" template points that ''only'' touch on the diagonal. Units can see/shoot right through these! Quite a few examples of this occur in the wall layout of the [[Lightning]] craft, while in (most) other cases such gaps are blocked off using additional tiles.

The below images show the contrast between the Lightning's design, and that of the [[Medium Scout]]. Putting aside for now the rather large gap in the north-facing wall of the Lighting's LOFTemps diagram (refer [[LOFTEMPS.DAT#Blatant_LOFTemps_Bugs|below]] for more on that), note that the diagonal "holes" (marked in red) do not exist in the Scout, due to the placement of pillars in the gaps. Click the images for a larger view.

''(Note that despite this, it is '''still''' possible to see/shoot through most of those points if a unit stands in the same tile as a pillar - though the mechanics as to how that works really belongs on the [[Line of sight]] page. Some parts of this article may get moved over there later, for now I consider both to be a "work in progress"). - [[User:Bomb_Bloke|BB]]''

<center><table><tr>
<td>[[Image:Lightning_LOFTemps_Topview.png|right|thumb|150px|Lightning LOFTemps wall layout; top-down view.]]</td>
<td>[[Image:LIGHTNIN-L1.PNG|right|thumb|150px|Lightning as presented graphically.]]</td>
<td>[[Image:Medium_Scout_LOFTemps_Topview.png|right|thumb|150px|Medium Scout LOFTemps wall layout; top-down view.]]</td>
<td>[[Image:UFO_110MAP-L1.JPG|right|thumb|150px|Medium Scout as presented graphically.]]</td>
</tr></table></center>

Just as sight/shot lines can pass between diagonally adjacent points placed side-by-side, the same thing can happen when the upper or lower edges of these points only meet on the diagonal. This is a far more common situation (for example, it applies to every single staircase in the entire game), and is the reason why soldiers can "look out" through the (apparently solid) walls of their drop ships. Here are two side-on cross sections, one of the [[Skyranger]]'s troop bay, and one of the small two-story house from [[Urban_Terrain|urban]] terror missions ([[MAPS_Terrain#City_Terror_Site|map module 15]]):

<center><table><tr>
<td>[[Image:SkyRanger_LOFTemps_Cross-section.png|right|thumb|250px|SkyRanger cross-section view.]]</td>
<td>[[Image:Urban15_LOFTemps_Cross-section.png|right|thumb|250px|Two-story house cross-section view.]]</td>
</tr></table></center>

[[:Image:LOS_Test_-_Passenger_Ship.zip|This sample save game for TFTD]] demonstrates how these diagonal joins can be "peeped" through. Turn the lone trooper to face the Triton, and she will be able to see inside it.

===Blatant LOFTemps Bugs===
While the game developers showed a large amount of attention to detail in constructing the 3D objects used in the game, there exist a number of errors. Here we have some of the more notable "gaps" in supposedly solid shapes, going beyond those caused by the diagonal joins mentioned above.

These images were created using [[User:Bomb_Bloke|Bomb Bloke's "LOF Terrain"]] program, which allows you to see the 3D shapes using the game engines themselves. Although still viewed in 2D (hence making it impossible to see all the details without "cutting away" certain tiles), this still shows many such problems at a glance.

<center><table><tr>
<td>[[Image:Lightning_LOFTemps_Hole.png|right|thumb|240px|The central northern wall of the [[Lightning]] floats out into space. Note that the soldiers can walk through the diagonal walls due to another bug completely unrelated to the LOF templates.]]</td>
<td>[[Image:Supply_Ship_LOFTemps_Hole.png|right|thumb|240px|The [[Supply Ship]] has a hole in its hull, circled in yellow in the center image. It's even possible for units equipped with [[Flying Suit]]s to hover up through this gap and walk directly into the UFO.]]
<td>[[Image:Triton_LOFTemps_Hole.png|right|thumb|240px|A large hole under the [[Triton]]'s wing reveals the aquanauts inside.]]</td>
</tr></table></center>

==Template Tables==
===UFO===
Here are the 112, 16x16 bitmaps (white is solid):

[[Image:Loftemps.png]]

===TFTD===
Here are the 114, 16x16 bitmaps (white is solid):

[[Image:Loftemps_TFTD.png]]

==See Also==
* [[Line of sight]]
* [[MCD|MCD structure]]
* [http://www.strategycore.co.uk/forums/Map-Control-Data-MCD-long-Post-t1468.html BladeFireLight's MCD/LOFTemps explanation (StrategyCore forums)]
* [http://www.strategycore.co.uk/forums/The-Lightning-t417.html Discussion of the Lightning's glitchy design (StrategyCore forums)]

[[Category:Game Files]]

Talk:LOFTEMPS.DAT

2011-03-01T19:46:28Z

Daiky:

Danial or BombBloke - thanks for making this. I am curious about how these files work...

"There are 112 entries, each of which are 32 bytes long. ... In Binary, the file creates 16x16 bitmaps, where 1 is solid and 0 is empty. These are then layered using the 12 loft references in the MCD files to create a 16x16x12 3D object."

I can see how 16x16 bits = 32 bytes for a 16x16 bitmap. But why are there "112" entries? How does this fit in with the "12 loft references" from MCD? (112/12=9.33... does it mean there there can be up to 9 "whole" 12-high objects in LOFTEMPS.DAT?)

Also: We're talking about the battlescape map, I presume... How does the "112" fit with the total number of objects in the game and/or max that can be on the battlefield at any given time? Is there any relationship?

And, BB you've said LOFT probably = Line Of Fire Table. What might EMPS mean?

As you can see, I know almost nothing about how the graphics are set up. So I have questions. :) If either of you can fill in any, please do so. If all the above can be addressed, delete this comment. Thanks! ---[[User:MikeTheRed|MikeTheRed]] 12:27, 17 Nov 2005 (PST)
----
Each MCD entry has 12 LOFT references, with each one pointing to the 16x16 bitmaps (the 112 entries on the LOFTEMPS.DAT file. The shape of the tile is thus built from the entries on the LOFTEMPS file. Those entries can have several shapes, like this: | . _ (I'm using punctuation marks that resemble it). Those are very simple shapes: if you want to 'draw' a wall you would use something like this: | | | | | | | | | | | | (the 12 LOFT references on the MCD file, each refering to an entry on the LOFTEMPS). When the game stacks them one over the other it produces a wall.

For a very technical explanation check this post by BladeFireLight: [http://www.strategycore.co.uk/forums/lofiversion/index.php?t1468.html Map Control Data (MCD)]

Also, check the end of that post. There's a link there to Koralt's MCD Editor. That is what I use for modifying the terrain files and it is easier to understand how it works with it, I think.

And the LOFTEMPS has nothing to do with the objects limit on the battlefield. I have no idea why there's only 112 entries though.

[[User:Hobbes|Hobbes]] 13:24, 17 Nov 2005 (PST)

----
They probably just kept adding to the file when needed, and 112 just happened to be the number they ended on.

I think, with the 112 lofts, by the 12 elevations, there's a possible 1344 "3D" objects in the game...

I've just added a graphic that should help you (and everyone else) understand a little better.

--[[User:Danial|Danial]] 9:16, 18 Nov 2005

P.S. I figured that loftemps was "Loft Elevation Maps" myself.

----

Thanks everybody! Wow, that's a lot of info. Cool... I (or anybody else) will copy over to the Article anything in this Discussion that's not yet there (looks like most of it is), then delete this Discussion ---[[User:MikeTheRed|MikeTheRed]] 16:38, 17 Nov 2005 (PST)

----

I get the impression that you could add to the loftemps.dat file, if you wanted to allow for more shapes... I see no reason why 256 different indexes would be a problem.

--[[User:Bomb Bloke|Bomb Bloke]] 04:20, 18 Nov 2005 (PST)

==LOFTemps visibility VS MCD visibility==

The article says "These are used for Line of sight (LOS) and line of fire (LOF) purposes." But in the MCD record, offset 31, there is a flag "Can see through?"... This makes me think LOFTEMPS are not used for LOS?

--[[User:Daiky|Daiky]] 19 Nov 2010

:If you try [http://www.strategycore.co.uk/files/index.php?dlid=671 this patched version of the Lightning], you should find that the thing has no "cracks"; that is to say, you can't see out of it unless you ''step'' out of it. However, the walls have that MCD flag set to 1, while the floors/ceiling have it set to 0. Both are obviously blocking visibility, hence the MCD article is either wrong, or at the very least misleading.

:I know for a fact that tiles with an MCD[31] value of 0 will block visibility according to their LOFTemps records. It may be that tiles with a value of 1 block ''all'' visibility regardless of their LOFTemps records. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 13:10, 19 November 2010 (UTC)

::Tried setting UFO floor tiles to 1 tonight, didn't affect the vision of either my soldiers or the aliens. Still not conclusive, mind you - it may only work on walls or other "non-floor" tiles. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 10:32, 20 November 2010 (UTC)

I have another possible theory, but not tested it yet.
1) MCD[31] is used for scanning the static terrain and reveiling fog of war. The LOFTemps are used only to test on visibilty between units. The reason why I think this, is because using LOFTemps to test on the visibility of all tiles in the field of view would take a lot of calculations, because the resolution is so much higher.
2) floors/ceiling tiles always block LOS. MCD[31] is ignored for floor type tiles. There are no floor tiles that I know of in the game where you can see through. By the way other types of blocking (HE, smoke, fire) are 0 too in the MCD, but I believe HE/smoke/fire is not going through roofs like they don't exist? So they must have some seperate hardcoded block value (I guess 1 in all cases).
Anyway, this is the way it'll be implemented in OpenXcom, until a better theory shows up.
--[[User:Daiky|Daiky]] 01 Feb 2011
:Floor/ceiling tiles do not always block LOS - they only block what their associated LOFTemps records tell them to block. For example, the red gravlift tiles present in UFOs and alien bases don't block sight at all.''(Edit: Scratch that, they DO block LOS, but not LOF - making them a good tile to investigate!)''

:I strongly recommend testing the patched version of the Lightning I linked above, and comparing it to the original version. ALL the changes made to alter the way it blocks vision were applied to the LOFTemps record indexes, whereas attempts to mess with MCD[31] did nothing we were able to discern. It would also be a good idea to read [http://www.strategycore.co.uk/forums/The-Lightning-t417.html this thread], which discusses the redesign process.

:It does seem to be true that the game uses slightly more advanced calculations to determine whether you can see an alien, as opposed to whether you can see a given tile. If you have a soldier standing inside the Skyranger, for example, and tell him to turn around, he'll be able to see terrain outside the craft that shouldn't be visible EVEN IF you account for the diagonal gaps in the LOFTemps - and yet, if you block these gaps, the tiles in concern would otherwise be hidden. Whether an alien can be seen, on the other hand, seems to depend entirely on whether there's a line going from the head of the unit to the center of the alien's LOFTemp object (Seb located the firing point-of-origins and noted them [[User_talk:Bomb_Bloke:Firing_Accuracy#Firing_Point_Origin|here]] (they're adjusted according to unit [[Height]], presumably the sight point-of-origin uses the same co-ords but located at the very top of the unit instead of partway down - this seems to be the case, given how LOS is affected by soldiers standing on haybales in barns for eg), while you can get some info on the use of LOFTemp objects by units [[Talk:UNITREF.DAT#Offsets_0x30_.26_0x34|here]]).

:I've since done some further tests with MCD[31] and found it doesn't seem to affect "object" tiles either. I'm beginning to strongly suspect it has nothing to do with vision at all. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 06:20, 1 February 2011 (EST)

I have done testing myself on this topic. I set the mcd[31] to 0 (= see through) of a ufo wall, and I can see the inside of the ufo, but not the aliens in it. And my theory is confirmed. Visibility of tiles and units are calculated in two ways: visibility of tiles uses mcd[31], visibility of aliens uses loftemps.dat. I will update ufopaedia accordingly.

--[[User:Daiky|Daiky]] 01 March 2011

Talk:LOFTEMPS.DAT

2011-03-01T19:46:08Z

Daiky: /* LOFTemps visibility VS MCD visibility */

BIGOBS.PCK

2011-02-14T21:16:09Z

Daiky: /* General Information */

==General Information==
Contains all the large Battlescape graphics for what is held in each hand. They have size 32x48.

==Details==
Contains 57 (0-56) objects.

{| {{StdDescTable}}
|- {{StdDescTable_Heading}}
! Index !! Object !! Index !! Object !! Index !! Object
|-
| 00/x00 || Laser Rifle || 19/x13 || Grenade || 38/x26 || Stun Bomb
|-
| 01/x01 || Rifle || 20/x14 || Smoke Grenade || 39/x27 || Alien Grenade
|-
| 02/x02 || Rifle Clip || 21/x15 || Proximity Grenade || 40/x28 || Hovertank Turret
|-
| 03/x03 || Pistol || 22/x16 || High Explosive || 41/x29 || Plasma Rifle Clip
|-
| 04/x04 || Pistol Clip || 23/x17 || Motion Scanner || 42/x2A || Tank/Rocket Launcher Turret
|-
| 05/x05 || Laser Pistol || 24/x18 || Medi-Kit || 43/x2B || Tank/Cannon Turret
|-
| 06/x06 || Heavy Laser || 25/x19 || Heavy Plasma Clip || 44/x2C || Power/Flying-Suited Corpse
|-
| 07/x07 || Auto-Cannon || 26/x1A || Stun Rod || 45/x2D || Soldier Corpse
|-
| 08/x08 || Auto-Cannon AP-Ammo || 27/x1B || ''Un-used Grenade'' || 46/x2E || Sectoid Corpse
|-
| 09/x09 || Auto-Cannon HE-Ammo || 28/x1C || Personal-Armoured Corpse || 47/x2F || Celatid Corpse
|-
| 10/x0A || Auto-Cannon I-Ammo || 29/x1D || Mind Probe || 48/x30 || Muton Corpse
|-
| 11/x0B || Heavy Cannon || 30/x1E || Heavy Plasma || 49/x31 || Ethereal Corpse
|-
| 12/x0C || Heavy Cannon AP-Ammo || 31/x1F || Plasma Rifle || 50/x32 || Snakeman Corpse
|-
| 13/x0D || Heavy Cannon HE-Ammo || 32/x20 || Plasma Pistol || 51/x33 || Silacoid Corpse
|-
| 14/x0E || Heavy Cannon I-Ammo || 33/x21 || Psi-Amp || 52/x34 || Floater Corpse
|-
| 15/x0F || Rocket Launcher || 34/x22 || Plasma Pistol Clip || 53/x35 || Chryssalid Corpse
|-
| 16/x10 || Small Rocket || 35/x23 || Blaster Launcher || 54/x36 || Tank/Laser Turret
|-
| 17/x11 || Large Rocket || 36/x24 || Blaster Bomb || 55/x37 || Electroflare
|-
| 18/x12 || Incendiary Rocket || 37/x25 || Small Launcher || 56/x38 || Elerium-115
|}

== Images ==
<table style="border:1px gray solid;">
<tr style="border:1px gray solid;"><td style="border:1px gray solid;">[[Image:BIGOBS00.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS01.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS02.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS03.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS04.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS05.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS06.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS07.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS08.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS09.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS10.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS11.GIF]]</td></tr>
<tr style="border:1px gray solid;"><td style="border:1px gray solid;">[[Image:BIGOBS12.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS13.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS14.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS15.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS16.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS17.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS18.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS19.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS20.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS21.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS22.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS23.GIF]]</td></tr>
<tr style="border:1px gray solid;"><td style="border:1px gray solid;">[[Image:BIGOBS24.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS25.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS26.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS27.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS28.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS29.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS30.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS31.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS32.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS33.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS34.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS35.GIF]]</td></tr>
<tr style="border:1px gray solid;"><td style="border:1px gray solid;">[[Image:BIGOBS36.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS37.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS38.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS39.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS40.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS41.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS42.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS43.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS44.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS45.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS46.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS47.GIF]]</td></tr>
<tr style="border:1px gray solid;"><td style="border:1px gray solid;">[[Image:BIGOBS48.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS49.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS50.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS51.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS52.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS53.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS54.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS55.GIF]]</td><td style="border:1px gray solid;">[[Image:BIGOBS56.GIF]]</td></tr>
</table>

==See Also==
* [[OBDATA.DAT]]
* [[UNITS]]
[[Category:Game Files]]

Talk:MAPS

2011-02-11T21:24:39Z

Daiky:

Errr... need a bit of formatting help... see the page? I want to put on all the separate levels so that they are easily seen to readers. I managed to get the Skyranger showing as thumbnails, but the next heading should be below the thumbs, but isn't... :o( How can I get it to format right, or any other ideas would be appreciated! Cheers ---- [[User:Phoenix|Phoenix]] 18 April 2006 09:59 BST

-----

One possible option would be to put a '''<nowiki> </nowiki>''' after the image, so that all text that follows the image will continue underneath it.

For more image manipulators, check out [http://meta.wikimedia.org/wiki/Help:Magic_words Magic Words].

- [[User:NKF|NKF]]

----

Excellent! Cheers NKF!

- [[User:Phoenix|Phoenix]]

== Extra/unused .MAP files? ==

Hi all,

I've been looking at UFO's .MAP files in quite a bit of depth and I've found a few that don't seem to be used in the game. I've done a cursory examination of them in Hex Workshop and listed some of their attributes below. In a plain steam distribution, the files are:

MAP3.MAP
32X48X3

MAP4.MAP
32X48X3

PABDUCT.MAP
10X20X4

PHARVEST.MAP
20X20X4

PSCOUT.MAP
10X10X4

TEMP.MAP
10X10X1

TEMP1.MAP
10X10X1

TEMP2.MAP
20X20X1

TEMP3.MAP
20X20X1

UFO_000.MAP
10X10X2

Anybody know what they are? The first two are especially weird; there's no way they could fit into an X-Com map unless it was the same map every time, like a TFTD ship attack. [[User:Off the Rails|Off the Rails]] 11:02, 8 February 2011 (EST)

:There's also UFO_010, UFO1A and UFO1B. Obviously, some of these are early UFO designs (for which we haven't been able to determine a correct set of MCD files to use - we'd probably have to build an MCD from scratch if we ever wanted to see them), but some I'm outright unsure about. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 17:25, 8 February 2011 (EST)

::actually UFO1A is the small scout it uses UFO1.MCD, UFO_010 is the medium scout. UFO1B.MAP (2x2x3) and UFO_000.MAP (10x10x2) are the two unknown ufos. - [[User:Daiky|Daiky]]

Talk:MAPS

2011-02-11T21:24:10Z

Daiky:

Errr... need a bit of formatting help... see the page? I want to put on all the separate levels so that they are easily seen to readers. I managed to get the Skyranger showing as thumbnails, but the next heading should be below the thumbs, but isn't... :o( How can I get it to format right, or any other ideas would be appreciated! Cheers ---- [[User:Phoenix|Phoenix]] 18 April 2006 09:59 BST

-----

One possible option would be to put a '''<nowiki> </nowiki>''' after the image, so that all text that follows the image will continue underneath it.

For more image manipulators, check out [http://meta.wikimedia.org/wiki/Help:Magic_words Magic Words].

- [[User:NKF|NKF]]

----

Excellent! Cheers NKF!

- [[User:Phoenix|Phoenix]]

== Extra/unused .MAP files? ==

Hi all,

I've been looking at UFO's .MAP files in quite a bit of depth and I've found a few that don't seem to be used in the game. I've done a cursory examination of them in Hex Workshop and listed some of their attributes below. In a plain steam distribution, the files are:

MAP3.MAP
32X48X3

MAP4.MAP
32X48X3

PABDUCT.MAP
10X20X4

PHARVEST.MAP
20X20X4

PSCOUT.MAP
10X10X4

TEMP.MAP
10X10X1

TEMP1.MAP
10X10X1

TEMP2.MAP
20X20X1

TEMP3.MAP
20X20X1

UFO_000.MAP
10X10X2

Anybody know what they are? The first two are especially weird; there's no way they could fit into an X-Com map unless it was the same map every time, like a TFTD ship attack. [[User:Off the Rails|Off the Rails]] 11:02, 8 February 2011 (EST)

:There's also UFO_010, UFO1A and UFO1B. Obviously, some of these are early UFO designs (for which we haven't been able to determine a correct set of MCD files to use - we'd probably have to build an MCD from scratch if we ever wanted to see them), but some I'm outright unsure about. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 17:25, 8 February 2011 (EST)

:actually UFO1A is the small scout it uses UFO1.MCD, UFO_010 is the medium scout. UFO1B.MAP (2x2x3) and UFO_000.MAP (10x10x2) are the two unknown ufos. - Daiky

Talk:MAPS

2011-02-11T21:21:48Z

Daiky:

Errr... need a bit of formatting help... see the page? I want to put on all the separate levels so that they are easily seen to readers. I managed to get the Skyranger showing as thumbnails, but the next heading should be below the thumbs, but isn't... :o( How can I get it to format right, or any other ideas would be appreciated! Cheers ---- [[User:Phoenix|Phoenix]] 18 April 2006 09:59 BST

-----

One possible option would be to put a '''<nowiki> </nowiki>''' after the image, so that all text that follows the image will continue underneath it.

For more image manipulators, check out [http://meta.wikimedia.org/wiki/Help:Magic_words Magic Words].

- [[User:NKF|NKF]]

----

Excellent! Cheers NKF!

- [[User:Phoenix|Phoenix]]

== Extra/unused .MAP files? ==

Hi all,

I've been looking at UFO's .MAP files in quite a bit of depth and I've found a few that don't seem to be used in the game. I've done a cursory examination of them in Hex Workshop and listed some of their attributes below. In a plain steam distribution, the files are:

MAP3.MAP
32X48X3

MAP4.MAP
32X48X3

PABDUCT.MAP
10X20X4

PHARVEST.MAP
20X20X4

PSCOUT.MAP
10X10X4

TEMP.MAP
10X10X1

TEMP1.MAP
10X10X1

TEMP2.MAP
20X20X1

TEMP3.MAP
20X20X1

UFO_000.MAP
10X10X2

Anybody know what they are? The first two are especially weird; there's no way they could fit into an X-Com map unless it was the same map every time, like a TFTD ship attack. [[User:Off the Rails|Off the Rails]] 11:02, 8 February 2011 (EST)

:There's also UFO_010, UFO1A and UFO1B. Obviously, some of these are early UFO designs (for which we haven't been able to determine a correct set of MCD files to use - we'd probably have to build an MCD from scratch if we ever wanted to see them), but some I'm outright unsure about. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 17:25, 8 February 2011 (EST)

actually UFO1A is the small scout it uses UFO1.MCD, UFO_010 is the medium scout. UFO1B.MAP (2x2x3) and UFO_000.MAP (10x10x2) are the two unknown ufos.

Talk:LOFTEMPS.DAT

2011-02-01T10:30:09Z

Daiky: /* LOFTemps visibility VS MCD visibility */

User:Daiky

2010-11-21T18:55:36Z

Daiky: Created page with "[http://openxcom.ninex.info/ OpenXcom]"

[http://openxcom.ninex.info/ OpenXcom]