UFOpaedia - User contributions [en]

Talk:IGLOB.DAT

2010-12-21T19:29:15Z

Knan:

Hmm. There ought to be a Year field in here somewhere, no? [[User:Knan|Knan]] 14:29, 21 December 2010 (EST)

Talk:IGLOB.DAT

2010-12-21T19:29:01Z

Knan: Created page with "Hmm. There ought to be a Year field in here somewhere, no?"

Hmm. There ought to be a Year field in here somewhere, no?

Known Bugs

2009-04-18T00:45:28Z

Knan: DOS/4GW update reference added (untested)

== Game Destroying Bugs ==

These are the list of the worst bugs of them all, because they can render your entire game unplayable. Until a fix/ workaround is found, these bugs result in your entire X-com campaign being scuttled:

[[Minimized interceptor bug]]
[[Big text bug]]

== Base Construction Bugs ==

=== Base Disjoint Bug ===
Base facilities built along the right or bottom edges of the base building area may end up being cut off from each other by dirt walls, a bug in the routine meant to keep soldiers from accidentally exiting the map edges during [[Base Defense]] missions. The dirt walls can be knocked down by Blaster Bombs or excessive amount of heavy plasma fire during combat but are otherwise unbreakable.

[[image:bdb.gif|center|Base Disjoint Bug]]

The walls marked in white are removed if there is an adjacent module. All green modules are not affected while the yellow modules are. The red module will be sealed off completely if anything smaller than a hangar is placed here at any given time.

[[XcomUtil]] works around this problem by stripping out the walls entirely in all the base modules.

The bug can be profitable if the hangars and the lift are accessible only through in these areas - you can gather and supply all your soldiers heavily without aliens interfering, then knock a hole in the wall and cover the area with explosives and blaster launcher fire.

===Displayed Base Maintenance Costs===
Although X-COM charges the right monthly fees for base modules, the maintenance fee displayed ''in the base info screen'' is always wrong. The displayed number is actually based on the placement within the base grid, '''not''' the price displayed in the in-game UFOpaedia. However, at the end of the month, the right fee is deducted. For more information, see [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]]. The Geo finance Graph shows a correct maintenance summary ([[LIGLOB.DAT]], updated once a month). Also see the next section.

===Paying For Dirt===
If you take down any facility in any base that you own and leave bare dirt, then you will continue to pay maintenance on it. But not at the old rate of whatever the facility cost per month, filling the hole back with dirt means it needs special attention at all times by specialists. In fact for every square of dirt you have that used to be a facility you will pay 80k per month. Thats 320k per hangar you take down. There are only two known ways to stop paying this premium - if you completely dismantle the base you stop paying any money for it, or if you build over all the spaces that you have vacated. In fact as soon as you start building the new facility you stop paying the premium, as well as not having to pay the cost of the new facility until it is complete.

If you start a facility and change your mind before it is complete, after the time when it would have completed you will start paying this 80k premium on that land as well.

===Base Facility Dismantle-Construction Crash===
In the Collectors Edition version, dismantling a facility while its construction is in progress can cause a crash when a second facility on another base square completes its construction. To work around this, dismantle a facility only after its construction is complete. If you have already dismantled such a facility, build something like a general stores on the same square to avoid the crash. It is not known if this crash happens intermittently or always, or if it happens on most versions of the game or just the Collectors Edition.

===Radar Stacking===
Despite the "Short Range" and "Long Range" detection bars displayed on each base's Information screen, only one radar of each type will be used at each base. Building additional radars of the same type will have no effect. One short and one long are useful until the [[Hyper-wave Decoder|Hyper-Wave Decoder]] makes both of them obsolete.

===Phantom Radar===
When you dismantle detection equipment such as a radar or hyperwave detector, the related detection ability of the base does not decrease until a new facility of some kind is built in that base. Until a new facility is completes building at that base, the base continues to use this "phantom radar".

This bug allows you to "upgrade in place", for example building a new Hyper-Wave Decoder over the top of an existing Large Radar, and retaining the detection capability of the Large Radar until the Hyper-Wave Decoder completes building. (Unless something else completes building first).

===Fixes for Base Construction Bugs===

As mentioned above, [[XcomUtil]] prevents the Base Disjoint bug (crudely). The [[User:Spike#Base_Fixer|BaseFixer]] utility corrects the Paying for Dirt, Phantom Radar, and Radar Stacking bugs. BaseFixer can be used manually on saved game files, or automatically via XcomUtil's hook mechanism.

==Geoscape Bugs==

===First Radar Detection Data bug===
When a UFO is detected by a radar, you get certain data on it depending on the type of radar that detected it. If the UFO later enters the range of another radar while staying in the range of the first, you will continue to get the initial data given, even if the new radar is more powerful than the first! So if you detect a craft with a [[Small Radar System]], then the UFO moves into the range of a [[Hyper-wave Decoder]], clicking on the UFO will only give you the data as if the Small Radar detected it, so long as it remains in the Small Radar range! In effect, the data you get about a UFO is determined when you first detect it, and not changed after that until you lose detection on the craft with the radar that first detected it.

This bug most commonly shows up when a UFO is first detected by a patrolling aircraft and then remains in the range of the aircraft while also entering the range of a Hyper-Wave Decoder.

=== Minimized Interceptor Bug ===
One fairly consistent cause of crashes is saving the geoscape game during a UFO standoff, with a [[UFO Interception]] window minimized to an icon. The next mission after that point will likely dump you to the green text screen, and perhaps an earlier battlescape mission instead of the proper one. What it seems to do is zoom back out of the combat too far when the fight is over, eventually causing the crash once it has gone a couple of steps further than it normally allows you.

'''Solution:''' Open up [[UIGLOB.DAT]] in a hex editor. Change hex offset 0x06 to 00. This will reset the number of minimized interceptor windows to zero. Your interceptor unit can be selected to either return to base or continue on to complete its ground assault mission. ''NOTE: Make sure to back up your save game before editing it.''

''-- I was able to recover from this state by quickly sending in another interceptor ([[Firestorm]]) to take over, which allowed my first interceptor ([[Avenger]]) to break off and go home without crashing the game again. After the shootdown I overwrote the buggy savegame. --[[User:JellyfishGreen|JellyfishGreen]] 03:11, 22 Aug 2005 (PDT)''

''This happened to me also. I fixed it by replacing "[[UIGLOB.DAT]]" in the save folder with the same file from another saved game (from the same campaign a month earlier) [[User:bylund|bylund]] 00:15, January 12, 2007 (GMT+01)''

=== Interceptions: Last Shot Always Misses ===
When using Cautious attack when [[UFO Interception|intercepting a UFO]], your craft will stay at the maximum range of your longest-range weapon. When using Standard attack, your craft will stay at the maximum range of your shortest-range weapon. (Usually players use two weapons of the same type, so Cautious and Standard attack will behave the same in this regard.)

As soon as the craft fires its last shot (expending all its ammo), it will drop back to "Standoff" range (70km). This will make it appear that the UFO has backed away while the last missile(s) are in-flight, causing them to miss.

In order to hit a UFO with your last salvo of missiles (Stingrays, Avalanches, or Fusion Balls), you must switch to "Aggressive" attack before the last salvo reaches the UFO. This will cause your craft to close in with the UFO, allowing the missiles to be in range when they reach the UFO. However, Aggressive attacks will also bring you within range of the UFO's weapons, so you should hit the "Disengage" button as soon as the last salvo hits.

===Elerium-fueled Craft Bug===
A [[Skyranger]] or [[Interceptor]], once dispatched, will return to base when it's fuel supply has dropped to a level that it will only have just enough fuel to return to base. Craft fueled by Elerium-115, however, will always report the "Low Fuel" message as soon at the fuel supply is 50% depleted, no matter where they are on the globe. This significantly shortens the already minute time that a [[Firestorm]], [[Lightning]], or [[Avenger]] can be dispatched to patrol.

===Floater Medic Research Bug===
Every single time a Floater Medic is found and researched, the game crashes after it is interrogated! I [muton commander] used a hack system to view the alien's profile, and it was a Commander with no race attached. This is probably the cause, but I have no explaination for why this situation occurs.

== Battlescape Bugs ==

=== Faulty Large Units ===
If you move a tank off a northward facing ledge, the rest of the tank will sink into a wall (if there is one), and cause the tank to get stuck. This won't happen if the tank moves off a south facing ledge as the primary quarter will fall after the rest of the tank. Aliens can also get stuck this way.

Another, potentially annoying bug occurs when a large unit's graphics become messed up. During a base defense mission, a rocket tank may end up looking like 4 silacoids bunched together.

===Unconscious Units are items===
This is actually an intentional programming choice... but it leads to several consequences which are bugs.

Firstly, any unconscious unit can be killed instantly by even a weak explosion, like being nearby an exploding AC-HE shell... even a Muton with 125 Health or an X-com agent in Flying Armor whose high armor ratings normally make him immune to AC-HE damage.
Secondly, no experience is gained for killing enemies in this manner.

You can prevent an unconscious unit's death from an explosion by picking it up... if a blaster bomb strikes the carrier and kills him, the unconscious unit will safely fall to the floor, unharmed.

Unlike a conscious unit (not wearing x-com armor), an unconscious unit can laze about in the middle of a fire without taking damage, since a UNIT standing in fire takes damage, but an unconscious unit is an item, which all ignore fire.

Forcing an MCed alien to pick up an unconscious X-com agent an carry him in it's right hand can cause weird things to occur when you release the mind control. I think the game might crash when the alien tries to shove the agent into it's magic pocket.

If a non-flying unconscious unit wakes up while being carried by a flying unit, it will gain some sort of temporary hover ability. (I once placed an unconscious Chryssalid in my flying agent's backpack. A few turns later, some growls and screams were heard from overhead.)

Save space! Each conscious unit takes up 1 tile (4 tiles for large units). An unconscious unit does not use up the tile... this might conceivably be useful if you wanted to abort a mission, but several panicked units were preventing other agents from boarding the skyranger...
X-com agents refuse to ride piggyback or be picked up while conscious. So, if you want a non-flying unit to reach an 2nd floor place with no stairs or elevator, you will have to knock him out, then either throw him up, or have a flying unit pick him up and drop him... and presumably administer stimulant.

This also leads to the INVISIBLE UNIT glitch. Frequently happens during Base Defence missions, since the item table is usually maxed out. Basically, the item table is so full that killed units do not leave corpses. However, this also means that unconscious units do not turn into the Unconscious Unit item. The KOed unit will disappear from sight, but will still be visible as a red number and as a blue/yellow dot on overhead map. Since the unit is still a unit and not an item, you will be able to shoot it with projectile weapons and kill it. ALSO, this method enables you to raise any unit's stun bar all the way to 255, since you can still increase the stun meter, despite them already being unconscious.

===Funky Fire===
If a unit (alien or friendly) is on fire or standing in flames, an [[Incendiary]] explosion ''anywhere else on the map'' will do a small amount of damage to it, even if you just shoot an IC round at a random patch of ground.

Similarly, if a unit (friendly units only) is standing in smoke when an incendiary explodes, it will take stun damage. This makes the combination of incendiary munitions and smoke quite hazardous until such time as all troops are armored.

There is a [[Talk:Incendiary#Incendiary_Bug|working hypothesis]] for the cause of this bug, which is that each and every Incendiary explosion triggers "end of turn processing" for Smoke and Fire - including fire damage, stun damage from smoke, fire spreading checks, and possibly "catch on fire" checks for units in fire.

Note that X-Com units wearing any kind of armor are immune to fire damage and IC-induced stun damage. Xcom HWPs are immune to stun, but take 40% damage from Incendiaries and WILL get killed quite efficiently by funky fire.

=== Collectors Edition Blaster Bomb Bug ===
In the Collectors Edition of UFO, the [[Blaster Launcher]] has a bug that prevents it from going up or down on the same tile. Or in other words, you cannot change the elevation of the missile vertically on the same tile.

Instead of flying down (or up) to the next waypoint, it will instead fly directly to the south at the pivot waypoint. Relative to the screen, this would be the lower left side of the screen.

This does not happen if you plot the waypoints at an angle. Or, if the blaster bomb flies right off the map, it will reappear at the proper waypoint as long as there are additional waypoints placed after the vertical move.

This bug also applies to the [[Disruptor Pulse Launcher]] in TFTD.

===Blaster Launcher Dud Shells Bug===

Shots which have only one waypoint, or explode before reaching their first waypoint, leave the Blaster Launcher showing 0 rounds, but still containing a dud shell which must be unloaded before the launcher can be reloaded. On earlier versions of the game (pre-Win CE) this also happens with reaction fire, and with 1-waypoint shots that fly off the map.

=== The trouble with Mines in General ===

Proximity mines are strangely implemented in UFO and TFTD. While they behave as you would expect them to half of the time, the mines do not behave like conventional weapons.

First, experience attribution is awarded to the person that sets off the mine.

Secondly, the armed states for [[Proximity Grenade]]s in both UFO and TFTD are NOT stored in save games. If a proximity grenade is primed, then the game is saved and reloaded, the grenade will not only not go off as it should, but the "Prime Grenade" action will still be absent, so it's impossible to re-arm it.

=== Grenade Timer Behaviour ===

Primed grenades will not explode when it's in your inventory when the timer runs out. It will only detonate when it's on the ground. If your soldier falls unconscious or gets killed, the grenade will be counted as being on the ground. Then it will blow up, likely taking out your gear and body. This 'feature' allows for the hot potato or [[Grenade Relay]] strategy which is fairly unique to X-COM where a live grenade well past its use-by date can be passed from squad member to squad member. It could also be used against Chryssalids:
* Soldier is turned into a Zombie.
* Equipment is dropped to the ground.
* First grenade goes off, killing the Zombie (and the offending Chryssalid, if it's still around).
* Second grenade goes off, killing the newly hatched Chryssalid. (Zaimoni: assuming the second grenade is around to explode. Reportedly works better in TFTD.)

So when you enter an area with high risk of Chryssalid attacks (terror site or Terror ship/Battleship crash site), have every soldier arm a grenade which serves as a dead man's switch to eliminate Chryssalids. You lose a soldier or two, but the aliens don't gain anything and there's one less candidate for zombification (and, if you are lucky, one less Chryssalid if it was around the victim when the grenades exploded).

For a more a detailed explanation on detonation conditions, see [[Understanding Grenades]].

=== Mountain Map ===
Due to a bug in the way this tileset was created, when you shoot the ground, it doesn't burn up - it turns into a tree stump.

Because the stump is on object, as opposed to actual ground, any objects that were in the tile already (for example, UFO hulls or the landing gear of your craft) get replaced by these stumps, making it seem as if they were destroyed.

Tree stumps don't take much damage, so they often get burnt up immediately if an explosive goes off, leaving nothing but burnt ground behind. It is easier to view the effects of this bug by shooting the ground instead.

For more details, see [[Explosions#Mile-High_Madness|Mountain Madness]].

=== What just exploded? ===
In some versions of the game, a bug allows an armed proximity mine to transfer its properties to some other item in the next mission, which then may explode unexpectedly. (If the item is left on the floor of the XCOM craft, it will explode as you walk past it.) This problem can be rectified by reloading the game -- as a precaution, save before you move your first soldier.

=== Door jam ===
If a door is open when a game is saved on the Battlescape and that game is subsequently restored, the door will remain open for the remainder of that mission.

===Mind Controlled Soldiers go MIA===
If you complete a mission while a [[soldier]] is currently [[Mind Control]]led he will be listed as MIA at the end of the combat. This is quite an easy bug to fall into as on any [[Sectoid]] or [[Ethereal]] mission the only, or most powerful, psionic aliens will usually be holed up in the bridge or command centre.

===Mind Controlled Aliens Count as MIA if you Abort===
If you happen to abort a mission with any Mind-Controlled aliens under your control, who are NOT in the dropship, the computer tallies them up as "X-COM Operatives Missing In Action." Thusly, every Mind Controlled alien left behind when you dust off is -20 points to your score! If you're leaving anyways, avoid this by bringing them back to the ship or mowing them down on the way back to the ship.

In the Playstation version of the game, any aliens under Mind Control at missions end are considered captured and hence, this bug is not a factor.

===20 Proximity Grenade Limit===

The array used to denote armed [[Proximity Grenade]]s is limited to 20 entries, meaning you are limited to 20 active mines at a time. The 21st and subsequent Proximity grenades can be primed like normal and will give appropriate messages, but they will not detonate even when the normal trigger conditions are met. Note that Proximity Mines that have detonated or otherwise been destroyed are removed from the array, freeing up positions; the limit is 20 ACTIVE Proximity Grenades at one time. In normal gameplay, this is probably not a restriction, in light of the [[Known_Bugs#80-Item_Limit|80 Item Limit]], since you'd need to have more than 1/4th of the cargo space in the dropship filled with Proximity Grenades.

===Base Defense Elerium bug===

On DOS versions of UFO Defense, Elerium pods may spawn as items from the base stockpile during a Base Defense bug. Each pod represents 50 units of Elerium and will be normally collected after the mission, same as any other item such as Heavy Lasers or Blaster Bombs. HOWEVER. The program will potentially generate 1 elerium POD for every 1 UNIT of elerium in your inventory. Thus, if you had only 10 lasers and 50 Elerium listed in your Sell screen, you would see 10 lasers and 50 Elerium Crystals in your Soldier Equip Screen, which would translate to 50 Elerium pods and 10 lasers scattered around your base. This equals 2500 Elerium, BTW. You basically have the potential to multiply your elerium stocks by 50 times.

===Berserk HWP crashes the game===

Admittedly, this is unlikely to arise under normal play. But, anyhow, your HWPs can only lose morale by killing friendly units. Not much for each unit killed, either. Anyhow, a berserk HWP will crash the game. (except for the Hovertank/Launcher, which does not fire when it goes berserk.)
Likewise, if you MC a cyberdisc or Sectopod and have it kills lots of aliens, it'll go berserk and crash the game. The error happens because of an oversight from the developers: the built-in weapons of HWP are handled differently from handed weapons, no OBDATA.DAT entries exist for them. The berserking code will try to access the inexistant entry, resulting in a crash. The Celatid has yet to be tested.

===Limited Unit Slots - Battlescape Crash===
{{Stub}}

This tends to arise during Base Defence Missions. The game is was designed to be limited to 40 soldiers/hovertanks and XXXX aliens for a total of XXXX . Having a full complement of soldiers during a Superhuman difficulty base defence will max out these limits. Thus when either side starts playing around with mind control too much, something goes wrong causing the entire game to crash.
It might also be something to do with maximum items on the battlescape.
In any case, the workaround seems to be killing aliens and destroying items on the battlescape... doesn't always work, but it seems to help.
You might want to make several in-battle saves for these situations, even if you normally play Ironman mode.

== Character Inventory Bugs ==

=== Alien Inventory Stacking Bug ===

'''WARNING:''' When examining an Alien's inventory (via an Exploit), you will see that sometimes the alien will stack multiple items of equipment on the same slot - its right leg. It's not always obvious that there are multiple objects in the slot until you 'pick up' the first object and can see other objects still in the slot. Before you remove an item from the Alien's right leg, make sure you enough time units to place it somewhere else. If you run out of time units, you will likely have to force a quit and cannot save your game. It '''may''' be possible to move the item to the left leg slot for 0 TUs, '''if''' the item will fit in that slot. If not, you will have to terminate the game. (Press ALT-TAB to get to any other window, then CTRL-ALT-DEL to bring up Task Manager, and then terminate the process that corresponds to the game).

=== XComUtil Inventory Stacking Bug ===

A problem similar to the Alien Inventory Stacking Bug can also occur for X-COM Soldiers, when using XComUtil. The algorithm used to assign weapons in XComUtil MUST assign all weapons to troops, so if there are more weapons than soldiers, excess weapons are stacked onto the leg slot of the first soldier in the dropship. This was a deliberate choice by Scott Jones to make this encumbrance obvious to the player. This can be readily corrected in the "equip soldiers" screen before a mission. Else, see "Alien Inventory Bug", above.

=== Item-stacking Bug ===
It is possible to put more than one item in a given spot. When an item is stacked with a [[Stun Rod]], this can make it possible for X-COM soldiers to perform "melee" attacks. See [[Item Stacking Bug]] for more details.

===Carrying Unconscious Units===
If one of your soldiers is carrying an unconscious unit in their hands and the unit either wakes up from stun or dies, they will be removed from the Inventory display, but will still appear to be in the carrying soldier's hands in the Battlescape. Clicking on the phantom body in the Battlescape will crash the game!
This error can be easily cleared by switching to the Inventory screen and moving another item into the hand that used to be carrying the body. Even swapping the gun to the other hand will do. Refer to : [[Unconscious#Bug|Unconscious]].

===Disappearing Ammo===
Partially-used clips in alien or X-COM weapons disappear at the end of a mission. This dictates that you should try to use clips that are not full. However, in DOS versions of the game, you can unload used clips to recover them as full clips with the tradeoff of all loaded clips (used or otherwise) will count as spent and disappear (this shouldn't seem to be a problem, until you start using blasters and will find that you're running out of ammo fast). You can also use [[XcomUtil]] to recover partially used clips. Even when used clips are discarded, you will still get credit ([[Scoring|score]]) at the end of missions for recovering them.

When aborting a mission, any full clips loaded in any alien weapons brought back to the transport/access lift will not be recovered unless the clips are unloaded first. This includes [[Blaster Bomb]]s and [[Stun Bomb]]s.

===Weightless Loaded Ammo===

Ammo that is already loaded into a weapon at the start of a mission does not count towards a soldier's Encumbrance. If the weapon is subsequently unloaded and reloaded during the mission, the soldiers encumbrance will increase. This would only be noticed if the unloaded clip was not discarded (e.g. because it was not fully empty). This is due to a bug in the game's weight calculation routine that was uncovered (but not caused) by Seb76's inventory screen improvements.

== Storage and Transfer Bugs ==

=== 80-item Limit ===
When loading up your Avenger for a massive UFO assault or arming soldiers for a [[Base Defense]] from your overflowing stores, you will likely hit this limit.

You only get a max of 80 items, and you don't get to choose which ones, so you may end up with 80 clips and no rifles for the base defense.

The solution is timely housekeeping. Sell off your spare personal equipment. See our handy [[Spring Cleaning Tips]], and also [[Managing the Item Limit]] for ideas.

Another bug concerning this limit happens when there are unresearched (alien) items in your stores during a base defense mission. Even though the item cannot be used during the mission, the game still allows you to equip your soldiers with them. This rarely happens as the alien items are very low on the item list, but if your base is lean and mean with under 80 items total, everything will spawn regardless of research.

===Sticky Craft Transfer Fee glitch===
As pointed out by [[User:Zombie|Zombie]] and [[User:Danial|Danial]], transferring any craft causes '''''all subsequent transfers to have that cost added to it''''', for as long as the craft is in transit. Additional craft in transit will add additional fees. (This has also been called the Exponential Transfer Fee bug, although it's actually additive, not exponential.)

Example (all numbers are only approximations):
Cost of pistol transfer (↔ = to or from)
EU ↔ USA 80
EU ↔ Asia 100
USA ↔ Asia 120

Cost of craft transfer
EU ↔ USA 1600 ''Notice how transfer fees always work as relative percents,
EU ↔ Asia 2000 ''probably on a distance-based formula
USA ↔ Asia 2400

Cost to transfer '''pistol''', after transferring craft from EU to Asia for $2000
EU ↔ USA 1680 (80+1600)
EU ↔ Asia 2100 (100+2000)
USA ↔ Asia 2520 (120+2400)

The cost of the craft transfer "sticks" to '''all''' subsequent transfers, until the craft arrives - although it acts on a proportionate basis, which is probably distance related.

Unfortunately, this cost is '''additive'''. That is to say, if you transferred a second craft from EU to Asia while the first was still in transit, it would cost $4000 ($2000 plus $2000 - it too suffers from the glitch!), it would then cost e.g. $4100 to transfer a pistol from EU to Asia. Having even more craft in transit would add even more fees.

This only appears to happen with aircraft, although it does happen for them all. So try to transfer aircraft individually, and not transfer anything else while you do - assuming you aren't awash in money. (The bug will cost you in the low thousands of dollars per craft being transferred.)

A related problem is that, if you are in the Transfer screen, start to transfer a craft, and then cancel because you remembered you wanted to send something else first - if you then try to Transfer something on that same screen, ''it will still get the sticky craft fee added''. Try it and see. You have to back up out to the main Base screen and hit Transfer again, to get rid of the sticky fee from a canceled craft transfer.

===Fuel dump on transfer===
Transferring a craft with 100% fuel will dump it somewhere along the way. When it arrives at its destination, its fuel gauge will read empty (ie: 0% FUEL), but it will be listed as ready. If you launch your craft for a mission (any mission will do) its fuel gauge will still read empty. This can be [[ExploitsA#Infinite_Fuel|exploited]] but it's very annoying if you want to quickly turn around a troop transport for another mission. You can force a refuel by sending out the craft and immediately recalling it back to base.

===Transfer Limit cash eater===
Only 100 items can be in transit at a time. (Here, a transfer of e.g. 200 Elerium counts as one "item". Also, all soldiers are counted individually.) If you go over the limit, you will get a warning that there is no more transport capacity. If you STILL try to transport something after getting the warning, the item will stay where it is, but the transportation cost still gets deducted. Bad if you're shuffling expensive aircraft. The extra cost isn't that bad. Recovering just one alien weapon will likely cover the money you will lose to this bug over the course of a game.

{| {{stdTable}} width = "80%" align = "center"
|- {{stdTable Heading}}
| Tip
|-
| To Clarify what constitutes an item in the transfer screen, think of them as batches of X amount. For example, if you transfer 200 alien alloys now, and then decide to transfer another 50 alloys later, this will count as two items in transit. Now, when you look at your transfers, you'll now have two items. Two batches of alien alloys, one with 200 units and the other with 50 units.
|}

=== Transfer crash ===
If you transfer something to another base the game crashes right after acknowledging the transfer price.

Solution: Start UFO, select English language, finish your transfer, save game, restart with your normal language settings (http://www.xcomufo.com/x1faq.html)

===Purchase Limit===
The purchase limit for any item you buy via the purchase screen is 255 per line item, because it is a one-byte field. However, the impact of this bug is small, for if you have space remaining in your 100-item transfer queue, you can immediately order another 255 of said item as another line item.

===Storage Limit===
You can not store more than 9,999 examples of any one item in the general stores at a specific base at one time. However, the only times such a ridiculously huge pile of a given item is at all likely to accumulate is with [[Alien Alloys]] or [[Elerium-115]]. Still, consider yourself warned. If you're coming close to the limit, consider transferring the extra to other bases or even selling it, as any extra collected beyond the limit will 'disappear' and be wasted.

===Exceeding Storage Limits===

The storage capacity of a base is normally limited by the capacity of the General Stores. However this can be exceeded in a number of ways:

* By exploiting some of the Base Storage Anomalies (see below)
* By storing surplus equipment in transport aircraft (up to the 80 item limit). Note that if both the aircraft and the base are full, you can no longer move equipment between the aircraft and base (in either direction).
* Anything manufactured at the base will be stored there regardless of the base's General Stores capacity.
* Anything captured on a mission by an aircraft operating from the base will be stored at the base, regardless of the base's General Stores capacity.

These could perhaps be considered minor exploits.

===Base Storage Anomalies===

There are some quirks in how the game calculates, and displays, base storage capacity used and available. These quirks are not all consistent with each other, which leads to some strange behaviour. A typical example would be moving a set of items out of Stores, immediately trying to put the exact same set of items back into Stores, and this failing due to "insufficient space". A more detailed discussion is in [[Talk:Base Stores#Base Stores Anomalies]].

== Soldier Limits and Recruiting Bugs ==

=== Soldier Recruiting Limit ===

There is a hard limit in the game of 250 X-COM soldiers in total across all bases (not 250 per base).

The error message that pops up when you try to hire more is:

"NO MORE SOLDIERS ALLOWED"

"You have already recruited the maximum number of soldiers."

=== Soldier Recruiting Bugs ===

Also there are 3 bugs related to recruiting soldiers:

* You still get charged for Soldiers you try to purchase above the No More Soldiers limit.
* The error message that appears when you hire too many soldiers must be dismissed (click OK) once for each soldier over the limit, i.e. up to 255 times.
* You get also charged for Soldiers you try to purchase above the Transfer Limit (100 at a time).

=== Soldier Battlescape Limit ===

In the Battlescape, there is a limit of 40 X-COM soldiers that can participate in any battle. Tanks/HWPs each count as 4 soldiers against this limit. Unless you use custom-modified aircraft, you will only see this limit in a Base Defence mission. In a Base Defence mission, all tanks/HWPs will be deployed first, in preference to soldiers.

== Manufacturing and Research Bugs ==

=== Cancel Manufacturing Bug ===

If you start a project with 1 or more items to build, the required cash (and any materials) for the first item will instantly be taken from you. If you cancel the project before the job is done, or reduce the number of items to produce, you will still not be refunded the initial costs of the first item.

(Possibly this is exactly the behaviour the designers intended, and not a bug at all.)

=== Zero Unit Manufacturing Exploit ===

If you start a manufacturing project with zero items to build, close the screen, and then go back to assign staff and a non-zero build amount later, the first item is built for free. If you only build one item at a time, you can build them all for free. Obviously, this is cheating. It's also a bit tedious. It might be excusable if you're really short of money.

=== Research Rollover ===

Whenever research completes, you are given the opportunity to re-allocate your scientists' efforts onto a new topic. If the new topic is after the topic that you have just completed (further down toward the bottom of the screen), the new effort of the scientists you allocate is applied immediately, on the same day - even though they were just working on the previous project that completed.

If you have enough scientists available to complete the new project in one day, this process can be repeated indefinitely, to complete multiple topics in one day. Each new research topic must be further down the list than the previous research topic, or the bug/exploit does not work.

By the way, this means that you should not worry about "wasted" research effort due to allocating too many scientists to a project on its last day. The chances are you will gain more free research from this bug than you will lose from "wasted" research effort.

=== TFTD Research Tree Bug Avoidance Guide ===
TFTD's research problems are more of a logical design flaw than a true bug, caused by trying to make the research tree more complicated than X-Com UFO. They can be a pain when you research the wrong thing at the wrong time.

A variation of NKF's [[TRTBAG | TFTD Research Tree Bug Avoidance Guide]] will be forthcoming - free time permitting.

For now:

*ONLY research Deep One Terrorist AFTER you have completed Plastic Aqua Armor and Ion Beam Accelerators.
*You MUST have at least one "Sub Construction" in storage before completing research on Zrbite and/or Transmission Resolver.
*NEVER research the Tasoth Commander. There's no reason to - and as of the last patch, they should no longer appear on the research list. They can block the T'Leth research.
*DO NOT research M.C. Lab unless you have AT LEAST one MC Reader in storage.
*NEVER sell all of your Sonic Pistol Clips before researching it first. If you were to research the Sonic Pistol, the aliens immediately stop using that weapon (and thus, clip) so you will be unable to continue in the Sonic line of research.
Other than the MC reader one, any of the above would make it impossible to finish the game.

=== Overcrowded Engineers And Scientists ===
In the Dos version (probably the others as well) if you hire more than 255 engineers in a single base, the number of engineers in the base will read a negative number once the 257th engineer arrives. Any Engineers engaged in projects will continue to work on them, but if you cancel the project you will lose engineers until you have lost 255 of them. This bug also affects scientists. It may be exploitable to pay a negative salary at the end of the month.

If you hire exactly 256 scientists or engineers, the total rolls over to zero. You pay zero salaries, and the resulting free Manufacturing / Research is limited only by the capacity of your Factories / Laboratories. Also works in TFTD.

===Manufacturing Limit Bug===
The number of hours remaining on a [[Manufacturing_Profitability#Profit_tables|manufacturing project]] is stored in a two-byte integer. If you build enough items that the total number of Engineer Hours required for construction is above 65535 hours, it will wrap around to 0 hours and display from there. Typically this drastically understates the amount of time that will be spent working on the items, but strictly speaking, it only subtracts 65k hours (so a huge project like 120k hours would still show ~55k hours' worth of Engineer time needed).

This bug is not dependent on the number of engineers assigned to the project; it is a function of the number of engineer hours needed. You will most likely run into it when trying to build 2 Avengers at the same time or when queuing up large orders of items in bulk, such as armor or Laser Cannons. As a practical example, the number of Avengers needed to trigger the bug is 2. The number of Laser Cannons is 219. Toggle back and forth between 218 and 219 laser cannons at the beginning of a project to see the effects.

It is known with certainty that this exists as a display issue - the screen will say you need less time than you should when you go over 65536 Engineer hours. [[User:Arrow Quivershaft|Arrow Quivershaft]] is also sure he's seen it eat an Avenger... he ordered two but only got one, even though it took the time, and cost the money, for two. He's tried to replicate this and hasn't been able to, however. So it clearly is at least a superficial display issue, and may be more than that ... possibly dependent on even something else. In any event, keep an eye on projects with more than 65k Engineer hours (and report back here!)... or just avoid going that high.

===Manufacturing Completion Time Display Bug===

If you start a new manufacturing project at 00:01, and the screen displays a completion time of 5 hours, you might expect the work to complete at 05:00 or 05:01. In fact it will complete at 06:00, one hour longer than indicated.

The reason for this bug is that the time left to complete a project is decremented by the game by one hour, every hour, on the hour(XX:00).

This display behaviour is consistent with what is shown while manufacturing is in progress. For example, if time remaining is shown as 0 hours, the work will complete at the beginning of the ''next'' hour. In effect, the displayed number is the integer-truncated form of the real time remaining. In the first example given above, the real time to completion is 5 hrs 59 min, misleadingly truncated to 5 hrs.

===Manufacturing Rate Interruption Loss===

In addition, as a result of integer truncation (see previous bug, Manufacturing Completion Time Display Bug), every time production stops, you lose an hour of manufacturing. Therefore, for most efficient production, manufacture in large batches (or increase batches while they are still in progress) to keep manufacturing as continuous as possible.

===Manufacturing Rate Limit===

There is a maximum production rate of one unit of any given type per hour per base. For example, though Alien Alloys / Aqua Plastics require 100 Engineer/Technician Hours per unit, even with 250 Engineers/Technicians you can only produce 1 unit per hour.

===Manufacturing Rate Limit Bug (TFTD)===

In UFO Enemy Unknown, the Manufacturing Rate Limit is just an irritant. The game prevents you from allocating more Engineers than is useful. In Terror From The Deep, there is no such safeguard. If you allocate more Technicians than are required to produce 1 unit per hour, the excess effort is just silently wasted. The unproductive Technicians are no doubt wasting their time playing retro computer games on their engineering workstations.

===HWP Fusion Bomb Ammo Cost Bug===

The HWP Fusion Bomb ammunition type, and its TFTD equivalent the ammunition for the SWS PWT/Displacer, appear to have the wrong manufacturing costs.
The vehicle version is ''less'' portable and ''less'' powerful than the personal version (Blaster Bomb), ''less'' capable than the craft version (Fusion Bomb) - and costs ''more'' than either of the others in total cash and in materials. In particular, it makes no sense that the small missiles on the HWP/SWS use up ''more'' of both Elerium/Zrbite and Alien Alloys/Aqua Plastics than the Craft version.

To correct this error, the craft round should have the higher base price, ''and'' the material requirements that are currently assigned to the SWS/HWP round. (It's debatable whether the SWS/HWP rounds should be more expensive than the man-carried rounds.) More discussion is on the talk page of this article.

== Other Bugs ==

=== Difficulty Bug ===
The DOS version had a problem where no matter what difficulty level you chose, you were actually playing at "Beginner" level. Because of one or two incorrectly set bytes in all dos versions of the game( 1.0 through to 1.4), no matter what difficulty was selected, the difficulty bug would reset to beginner at the end of the first mission. [[XcomUtil]] corrects this problem. This bug was officially fixed in the Collectors Edition Windows port (also commonly known as UFO Gold).

=== Big Text Bug ===
There are a few bugs in XCOM, especially early versions, that can build up and make the game unstable enough that it crashes and prints out a screenful of green 40-column text, essentially debug or memory dump information useless to you.

You can also forced a crash by pressing CTRL-C at the start of a new game (DOS only). If you don't have any missions automatically saved within the [[Game_Files#Missdat_Files|MISSDAT]] folder, you will get this big text to appear. Typically it is green for Enemy Unknown, and blue for Terror From The Deep. Other colours have been observed such as pink, purple, brown and yellow.

In the dos version, the text that you see is simply a memory dump in mode-13h (the 320x200x256 colour screen resoulution) and the text colour is based off the changes to the palette that the game made. The batch file coordinating the two main programs [[Geoscape]] and [[Battlescape]] often succeeds in soldiering on after a crash. In the Windows version of the game, the game simply crashes back to the desktop, unless you're using the [[XcomUtil]] split executable variant (which uses a batchfile).

Some things which will tend to cause this problem:
* Overzealous use of Psi

At least some of the instability crashes can be fixed by replacing the DOS/4GW dos extender with a later version from another DOS game.

[http://syndicate.lubie.org/synd/html/synd_patches.php One of these], for example. Link to Syndicate fansite, instructions included.

=== Cash Rollover Bug ===

When your cash balance goes over $2,147,483,647, it will rollover and become $-2,147,483,647. Which means your game is done for, unless you use an editor. Fortunatly, by the time you accumulate this much cash, you have usually completed all necessary research to win the game.

== See Also ==

=== [[Known Bugs (TFTD)]] ===
For bugs that '''only''' affect X-COM: Terror From The Deep.

[[Category: Oddities and bugs]]

Talk:Battlescape Map Generation

2009-03-17T23:18:50Z

Knan: roswell

=Urban Roads=

I've observed a 45-50% chance of an east/west road appearing, and a 75% chance of a north/south. Both appearing at once occured 20% of the time. Only done 110 trials at the present time however.

- [[User:Bomb Bloke|Bomb Bloke]] 03:55, 10 February 2008 (PST)

----

I'm pretty sure I encountered road-less terror missions before. It's been a while since I ran random terror missions though. BTW: the max number of 20x20 modules which can happen on a Cydonian base map is 8 (including the brain room). In an alien base, it's 4 (including the command center). In both instances, the game has to create 2 green staging rooms so that your soldiers have a place to start. Therefore, the min number of small 10x10 modules (neglecting the 2 green rooms) in the Cydonian base is 2 and in an alien base it's 7. Of course, this assumes the game's map generation engine is purely random.

- [[User:Zombie|Zombie]] 22:45, 13 February 2008 (PST)

----

Can't remember ever seeing a terror map without a road... Are you certain?

What I plan to do is create a special logger and run a few thousand samples through it. That'll get the percentages that much more clear.

I'll be doing the same regarding the odds of any other module turning up in a given space. I suspect the limits as to how many large modules can appear are, as you say, solely based on how many can actually fit; but I'd like to have it nailed down for certain. :)

- [[User:Bomb Bloke|Bomb Bloke]] 23:41, 13 February 2008 (PST)

----

Like I said, I'm not 100% certain on seeing road-less terror missions, but I'm pretty sure. If the map generation engine is completely random, it guarantees the possibility. Technically, there is a 6.67% (1 of 15) chance of spawining a road in a N/S or E/W configuration and the same chance of a dual roadway. It's possible that because the roads come first in the map area, the game might be more inclined to to include them. Then again, if the game engine spawns a road section somewhere, it might have to re-work the whole map so that the road goes across. In either case, the probabilities of a N/S or E/W road configuration should be identical so perhaps more trials are needed to gain a better understanding. --[[User:Zombie|Zombie]] 00:42, 14 February 2008 (PST)

=Map Sizes=

XcomUtil may generate oddly shaped maps?

- BB

----

No, but the engine should accept rectangular maps (at least TFTD does, in the case of the ships). BladeFireLight once designed a Battlefield Generator that was supposed to allow you to create your own maps but i never quite figured it out.

- [[User:Hobbes|Hobbes]] 13:52, 13 February 2008 (PST))

----

So XcomUtil didn't generate those 60x60x2 alien bases?

UFO does support rectangular maps, and even maps more then four units high. My [http://www.strategycore.co.uk/forums/?showtopic=598&st=80#entry70168 throwing logger] generates them to spec, but the maps aren't intended for playing on.

There were also some odd issues where adding extra levels would cause all sorts of rendering artefacts... Can't quite remember how high you had to push things for that to happen.

- [[User:Bomb Bloke|Bomb Bloke]] 17:36, 13 February 2008 (PST)

----

I'm not sure about the 6x6x2 alien bases anymore, might just be my memory playing tricks on me.~

- [[User:Hobbes|Hobbes]] 12:34, 18 February 2008 (PST)

----

I guess you'll have to trust me on this one, but base assault mission are generated by code starting at 0x0044D030 ; there you can see:

.text:0044D042 mov eax, 5
.text:0044D047 add esp, 0Ch
.text:0044D04A mov pGeodata.map_xsize_10, ax
.text:0044D050 mov pGeodata.map_ysize_10, ax
.text:0044D056 mov pGeodata.map_zsize, 2
.text:0044D05F mov pGeodata.terrain_type, 4
.text:0044D068 mov pGeodata.craftsToDraw, 0
.text:0044D06F mov word ptr missionDescriptor, 3 ; 3 -> base offense

which means (if you're not fluent in x86 ;) ) that the alien assaults maps are hard coded to 5x5x2 size.

Similarly for base defense, you'll find:
.text:0044CD6B mov eax, 2
.text:0044CD70 mov ebx, 6
.text:0044CD75 mov pGeodata.map_zsize, ax
.text:0044CD7B mov word ptr missionDescriptor, ax ; 2 -> base defense
.text:0044CD81 add esp, 0Ch
.text:0044CD84 mov pGeodata.map_xsize_10, bx
.text:0044CD8B mov pGeodata.map_ysize_10, bx
.text:0044CD92 mov pGeodata.terrain_type, 3
.text:0044CD9B mov pGeodata.craftsToDraw, 0

which translates into 6x6x2 map size. [[User:Seb76|Seb76]] 14:12, 18 February 2008 (PST)

----

Arrow, please discuss here before you edit this stuff... hmm... I'm going to look for an editor, and see what happens if I hack Mutons to have 250 Health and 250 armor in all directions. If my suspicions are correct, the UPS explosion will STILL kill them... anyone know which editor can edit Muton stats and UPS explosion damage? ... I haven't seen any editors which can do that, so far... [[User:Jasonred|Jasonred]] 12:45, 17 March 2009 (EDT)

:I admit I was a bit hasty in editing; I'm fairly low on sleep. I would ask you recall to do the same on some other pages. :) IIRC, from Zombie's The UFO power source explosion actually exceeds a Blaster Bomb in power. What I think happens is that the game might respawn some aliens after the explosion in the event they're all killed by the blast, as a failsafe. If no aliens are present, the battle would never begin because the aliens would never pass the "Any units alive?" check before the beginning of Turn 1. And I have seen wounded aliens near Power Source explosions on occasion. So it is possible. [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:05, 17 March 2009 (EDT)

: I bet the Mutons survive, as I see plenty of merely damaged aliens from power plant explosions (CE Edition). -- [[User:Zaimoni|Zaimoni]], 14:21 17 Mar 2009 (CDT)

:: ... Ok... I need to either get an editor or bring in Mind-Probes to confirm this...

Ah, but there's always some aliens OUTSIDE the spaceship, right? Is it hard-coded always, or is it just very very very likely that there will be aliens outside the ship? ... hmmm... but, as I've said... the UPS explosion behaves very strangely. The inconsistant blast pattern, among other things. If you tried to SIMULATE a UPS explosion by editting Heavy Explosives, and set them off right in the center of a Medium Scout, you would get the same blast pattern every single time. A crashed Medium Scout can have anything ranging from the floor ceiling and walls being intact to a hole in the ceiling to near total annihilation with even the outer hull shredded. ... Heck, you can usually recover an intact UFO navigation from a crashed medium scout. Try firing off a Blaster Bomb in the middle of one, and see what happens...

I definitely agree with your failsafe theory... every combat MUST start with live aliens. But I think that is in ADDITION to any weird behaviour exhibited by the UPS kaboom.

Just checked... UPS blows with strength 215, but has a random modifier too... they already know that UPS boom is weird vs terrain. Let's see how weird it is vs units...

: A Medium Scout where no aliens spawn outside is rather likely to start with zero aliens. This is most common on Beginner (have seen twice in ??? missions). Saving the game is impractical as the battle ends before XCOM starts its first turn. -- [[User:Zaimoni|Zaimoni]], 14:12 17 Mar 2009 (CDT)

:: Eh... really? So you CAN start a mission with zero aliens? Interesting... what version of the game are you playing, BTW?
:: Eh... this gives me a thought for yet another crackpot theory... which is about the spawning of units for the higher difficulty levels... I tend to find quite a number of aliens inside the UFO to be much greater on Superhuman... maybe the "extra" aliens from superhuman were spawned after the UPS explosion?
:: Eh... come to think of it... if it ended so quick, how do you know the map had zero aliens? Maybe it was tactical.exe crashing and made you think the mission succeeded, but it was just the prior mission results?
[[User:Jasonred|Jasonred]] 18:22, 17 March 2009 (EDT)

::: As mentioned above: CE edition (XCOMUtil'd, as the graphics need patching to display at all; however, the only binary executable code patching XCOMUtil does is to remove the Difficulty Bug). The forked tactical.exe did not crash; the start of the turn is displayed properly, I get a brief glimpse of the BattleScape, and then the Mission Over sequence. No reaction time to speak of. -- [[User:Zaimoni|Zaimoni]], 18:10 17 Mar 2009 (CDT)

:: If the mission results says success and no aliens killed, no aliens captured, that's a pretty good hint the exe didn't crash. Your previous mission presumably had kills. No survivors happens, from time to time. [[User:Knan|Knan]] 19:18, 17 March 2009 (EDT)

== KABOOM!! ==

The game does actually feature vertical damage from explosions, and not only for UPS. I guess the reason it's believed otherwise is that the flying armor gives good protection against ground explosions. The UPS explosion being up to 250 in explosive power can destroy roof tiles, as well as a modified blaster bomb would. And I can assure you that UPS explosions use the same routine as standard explosions ;-) [[User:Seb76|Seb76]] 15:11, 17 March 2009 (EDT)

: Other than the fact that UPS does 215 +/- 35 damage to terrain? hmm... Wait, methinks me gets that part... sort of... basically, the initial strength of the explosion is randomly determined, then it henceforth behaves like a normal explosion? ... How much damage is applied to alien units nearby then? Do they get hit for the full damage or something? ... Sigh... I need to wait until my current game reaches the point where I have a full developed Psi Corps.
- : As for vertical damage from explosions, er... SORT OF. Explosions do vertical damage, but only to floor/roof tiles. Units and objects appear to be untouched. Not only flying armor, even Floaters and Ethereals will be completely untouched by an explosion occuring underneath them. I have been wondering about that, actually...

Talk:MCD

2009-03-14T21:47:20Z

Knan: /* MCDedit */

52: Footstep sound effect.

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

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

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

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

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

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

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

----
Sounds spiffy. --[[User:Danial|Danial]] 20:01, 18 Nov 2005 (PST)

----

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

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

== Offset 47 / 0x2F ==

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

== MCDedit ==

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

:It's been in StrategyCore's files section for years now. [http://www.strategycore.co.uk/files/index.php?dlid=415 Clicky]. :) --[[User:Zombie|Zombie]] 21:52, 13 March 2009 (EDT)

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

Talk:MCD

2009-03-14T01:25:29Z

Knan:

Overviews of Aliens

2008-07-20T00:28:21Z

Knan: /* Low Threat: Sectoid */

As a first step a commander should be aware of the basic details of the threat facing the Earth, to this end an '''Overview of Aliens''' can act as a first step in preparing the novice for their first clashes on the battlefield. Once the commander is conversant with this information further details can be found by looking at aliens' specific pages or [[Alien Stats]].

==Low Threat==
===Low Threat: Sectoid===
[[Image:sectoid.png|right|Sectoid]]
The Sectoids are possibly the first alien you'll see. They resemble the "Greys" spoken of by New Age types and the X-Files television show: short humanoids with pale skin, elfin features and large, almond-shaped eyes.

Sectoids are very weak in combat, with generally poor accuracy. They have mediocre mobility, no armor worth mentioning, and will easily fall under standard rifle fire, grenades, or even a glancing shot from heavier weapons. Without their more devious Sectoid Leaders, they can be overcome with minimal risk.

However, on any mission that doesn't involve a small-sized UFO ([[Small Scout]], [[Medium Scout]], or [[Large Scout]]), the Sectoids will have a Sectoid Leader in their ranks. This Leader is capable of [[Psionics|Psionic]] attacks that can panic your troops or even bring them under alien control, to be used against you. In the early game when Sectoid sightings are common, this can be devastating because X-Com has not yet researched psionics, and so is wide open to this type of warfare.

Furthermore, on any [[Mission_Types|Mission]] involving terror units, the Sectoids will be accompanied by the formidable Cyberdisc, which adds another degree of complexity to the situation.
 
See also: [[Sectoid]] | [[Overviews of Aliens#Medium Threat: Cyberdisc - Terror Unit|Medium Threat: Cyberdisc - Terror Unit]]

===Low Threat: Floater===
[[Image:floater.png|right|Floater]]
The Floaters are the other variety of aliens you'll see early in the game, possibly before Sectoids. They are purple humanoid shapes clad in capes, floating perpetually above the ground. They are more formidable in combat than the Sectoid. They have better firing accuracy and reactions, along with a modicum of armor. They have somewhat better mobility than the Sectoid, and they are capable of floating in mid-air. They use this ability only rarely (almost never on lower difficulty settings), but it does mean that, at game start, you will see them more frequently on rooftops and other elevated positions. They rarely make good use of cover while floating above ground level. Floaters may be more likely than Sectoids to throw grenades, but hard data here is lacking.

While Floaters, by themselves, are more fearsome than Sectoids, they lack the Sectoids' two advantages: Floaters have no psionic capability, and their terror unit, the Reaper, is mediocre at best. Floaters arguably make for the easiest large UFO missions, terror missions and alien base attacks due to these weaknesses.
 
See also: [[Floater]] | [[Overviews of Aliens#Low Threat: Reaper - Terror Unit|Low Threat: Reaper - Terror Unit]]

===Low Threat: Reaper - Terror Unit===
[[Image:reaper.gif|right|Reaper]]
The Reaper is the dedicated [[Terror Units|Terror Unit]] of the Floater, and will only be seen accompanying them. It is a large, furry mammalian biped of size comparable to an X-Com [[Heavy Weapons Platforms|HWP]]. It is armed only with its bite, which obviously can be used only when the alien is directly adjacent to its foe. It is arguably the least threatening alien in the game. Since they are so large, reapers are generally easy to spot and easy to hit. While they can absorb a considerable amount of damage, they are resistant only to armor-piercing fire and make a large target. They are particularly vulnerable to incendiary fire, but almost any heavy weapon fire will dispatch them without much trouble. Their only real assets are their high mobility and ability to absorb damage.
 
See also: [[Reaper]] | [[Overviews of Aliens#Low Threat: Floater|Low Threat: Floater]]

===Low Threat: Silacoid - Terror Unit===
[[Image:silacoid.gif|right|Silacoid]]
The Silacoid is one of the two varieties of terror units deployed with Mutons, and will only be seen accompanying them. It resembles a large pink rock that slowly rumbles along the ground, often leaving a trail of burnt terrain in its path. Their only combat ability is to make a moderately damaging melee attack, presumably involving the burning heat of its body. Its mobility is lacklustre, and the burnt trail it leaves makes it easy to track. They are somewhat well armored and can absorb a moderate amount of fire. Considering that they are usually only encountered in the mid- to late-game, the sight of this underwhelming combat unit comes as a pleasant surprise to Commanders accustomed to more fearsome prey.
 
See also: [[Silacoid]] | [[Overviews of Aliens#High Threat:Muton|High Threat: Muton]]

==Medium Threat==

===Medium Threat: Celatid - Terror Unit===
[[Image:celatid.gif|right|Celatid]]
The Celatid is one of the two terror unit types deployed with Mutons, and will only be seen accompanying them. It resembles a large, pink kidney bean that hovers along slowly at ground level. It attacks by spitting venom at its target, and can do so with great accuracy. This venom is extremely dangerous to unarmored units, while somewhat less threatening to armored troops and HWPs. It can only project its venom over a short range (perhaps 7 squares), and has relatively low mobility. It has negligible armor and can be destroyed with standard weapon fire, or glancing fire from heavier weapons.

The science division says that a Celatid is capable of tracking units outside of its line of sight, but there is no field evidence to confirm this. In any case, it is at home in close quarters, particularly indoors where it can pop out from around corners, and its small size can make it a somewhat difficult target to hit. However, its low mobility, short attack range and vulnerability to fire means that, with proper care taken, it is only a moderate threat on the battlefield.
 
See also: [[Celatid]] | [[Overviews of Aliens#High Threat:Muton|High Threat: Muton]]

===Medium Threat: Cyberdisc - Terror Unit===
[[Image:cyberdisc.gif|right|Cyberdisc]]
The Cyberdisc is the dedicated terror unit of the Sectoid, and will only be seen accompanying them. It is a mechanical floating disc, comparable in size to our HWP, though it has a lower profile. It has moderate mobility, and can float at any level above the ground. It attacks with a devastating plasma shot, capable of firing up to three snap shots in a round with good accuracy and reactions superior to our HWPs.

It is resistant to armor-piercing weapons, and holds up well against psionic manipulation. Its slim profile can make it a difficult target for an object of its size. Worse, when it is destroyed, it usually explodes with a ferocity comparable to [[Alien Grenade]] or worse. New commanders often have difficulty destroying it with Terran weapons; it is advised to direct as much firepower as is available against one. Alien weapon technology is far more suitable for destroying it.

Commanders should remember that any mission involving Cyberdiscs will also involve Sectoids with psionic capability. However, not all missions with psionic Sectoids will involve Cyberdiscs.
 
See Also [[Cyberdisc]] | [[Overviews of Aliens#Low Threat: Sectoid|Low Threat: Sectoid]]

===Medium Threat: Snakeman===
[[Image:snakeman.png|right|Snakeman]]
Snakemen usually won't show up for at least two or three months into the game. As their name suggests, they are reptilian, resembling snakes with arms, slithering along on their lower bodies. They have noticeably better armor than floaters or Sectoids, and are capable of absorbing significantly more fire than either. Their combat stats are at least comparable to Floaters, possibly slightly better. They seem a little more willing to use grenades than Sectoids or Floaters, too. Their key flaw, however, is low mobility. They are not able to move very quickly, slower even than Sectoids.

However, larger Snakeman missions involving Terror Units can be truly fearsome, with the inclusion of their devastating Chryssalid support units.
 
See Also [[Snakeman]] | [[Overviews of Aliens#High Threat: Chryssalid - Terror Unit|High Threat: Chryssalid - Terror Unit]]

==High Threat==
===High Threat: Chryssalid - Terror Unit===
[[Image:chryssalid.gif|right|Chryssalid]]
The Chryssalid is the dedicated [[Terror Units|Terror Unit]] of the Snakeman, and will only be seen accompanying them. One of the most feared enemies of X-Com, these creatures have shiny black exoskeletons, an insect-like look, and a toothy grin. They resemble the art of H.R. Giger. They have incredible mobility, lightning-fast reflexes, and can absorb large amounts of fire. These abilities allow them to slug it out long enough to deliver their chief threat: their infectious bite, which can penetrate even the thickest armor and can destroy HWPs.

The ability of a single specimen to turn an entire troop of X-Com operatives into a new population of Chryssalids is the stuff of a Commander's nightmares. Killing Chryssalids should be your top priority whenever they are present. Concentrate fire upon them. Don't be afraid to sacrifice any civilians or X-Com troops nearby-- if the Chryssalid doesn't die, they'll probably be infected anyway. Ensure that all Chryssalids that drop are dead, not merely unconscious. Listen for the lack of a death-cry - do not hesitate in blowing up its body to finish the job.

====Zombie====
Any X-Com trooper or civilian bitten by a Chryssalid will turn into a zombie -- a drooling humanoid that runs around and tries to launch weak physical attacks against your troops. The creature itself is easily killed. The melee attack can kill a soldier in a t-shirt in one turn. Don't let them stand next to you for long. If you can't burn it and aren't ready to concentrate firepower on the emerging Chryssalid, you should keep your distance. Your soldiers will happily zap them with reaction fire. This can be a worse disaster than just letting the zombie beat a single trooper to death.

Unless zombies are burned to death with an incendiary attack, a Chryssalid will hatch out of its corpse when is it killed. The new Chryssalid is at full strength and has all the abilities of a normal Chryssalid -- including the ability to turn more people into zombies and 100% of it's TU's. Yes, this means that a single Chryssalid can turn every human on the map into a Chryssalid.

 
See Also [[Chryssalid]] | [[Zombie]] | [[Overviews of Aliens#Medium Threat: Snakeman|Medium Threat: Snakeman]]

===High Threat: Ethereal===
[[Image:ethereal.png|right|Ethereal]]
Ethereals are the ruling caste of the Alien hordes. They will not be seen until the late in the game, but when they do, expect them to be armed with the most powerful weapons in the [[Weapons#Alien Weapons|alien arsenal]]. Their bodies are thin and emaciated, with pale, pinkish skin. However, they only appear in combat wearing billowing orange robes which make their narrow frames look more imposing.

They can endure large amounts of damage and have very good combat skills. They also have good mobility and are able to fly, which they do with little hesitation. ''Every'' Ethereal has [[Psionics|psionic]] abilities; expect psionic warfare to commence almost immediately in any combat against them. Always engage Ethereals with the greatest caution, and all knowledge of psionic combat you have at your disposal.

As if their combat skills, high mobility, resistance to fire and psionic ability were not enough, they also have one of the strongest terror units in the game-- the Sectopod.
 
See Also [[Ethereal]] | [[Overviews of Aliens#High Threat: Sectopod - Terror Unit|High Threat: Sectopod - Terror Unit]]

===High Threat: Muton===
[[Image:muton.png|right|Muton]]
Mutons are the shock troops of the Alien invasion, possibly the most skilled combatants you'll go up against. They usually won't show up until mid- to late-game, but when they do you can expect them all to be packing the most powerful weapons in the [[Weapons#Alien Weapons|alien arsenal]]. They have purple skin, but everything but their faces are covered with thick, green, skin-tight armor.

They are heavily armored and capable of absorbing heavy fire, and are especially resistant to armor-piercing rounds. They have very good reactions and mobility, and average accuracy. They will lay down heavy fire and use grenades quite freely.

They are not without their weaknesses, however. They are known for a short attention span, and will forget the presence of enemies beyond their sight more quickly than other aliens would. They are vulnerable to psionic attacks, and have no psionic talents of their own.

They are the only species in the Alien invasion with two varieties of terror unit, the Celatid and the Silacoid. However, neither of these creatures can come close to matching the Muton's combat prowess.
 
See Also [[Muton]] | [[Overviews of Aliens#Low Threat: Silacoid - Terror Unit|Low Threat: Silacoid - Terror Unit]] | [[Overviews of Aliens#Medium Threat: Celatid - Terror Unit|Medium Threat: Celatid - Terror Unit]]

===High Threat: Sectopod - Terror Unit===
[[Image:sectopod.png|right|Sectopod]]
The Sectopod is the dedicated terror unit of the Ethereal, and will only be seen accompanying them. They are large, bipedal robots comparable in size to one of our HWPs. They are the most heavily armored units of the Alien horde, resistant to almost all forms of damage including even alien weaponry, requiring heavy fire to destroy one. Its only known weakness is to Terran laser weapons, and even against those it can sustain a good degree of damage.

They attack with dual head-mounted green-laser weapon that is capable of automatic fire. They can fire with a high degree of accuracy and reactions far superior to our HWPs. They also have good mobility.

Some commanders keep special weaponry on hand exclusively to deal with them, including the [[Tank/Laser Cannon]] and even the otherwise shunned [[Heavy Laser]]. Blasters will do the job, but direct hits are usually required-- and occasionally may not be enough.
 
See Also [[Sectopod]] | [[Overviews of Aliens#High Threat: Ethereal|High Threat: Ethereal]]

==Notes==
*The leaders of the alien horde are heavily dependent on psionic combat, and have even designed their mechanical units to respond to psionic stimuli.
*Only Sectoid Leaders, Sectoid Commanders and Ethereals (of any type) are capable of psionic warfare.

==See Also==
*[[Alien Life Forms]]
*[[Terror Units]]
*[[Alien Stats]]
*[[Overviews of Aliens (TFTD)]]

User talk:Seb76

2008-07-13T00:08:06Z

Knan:

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)

Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

User talk:Seb76

2008-07-09T21:14:51Z

Knan:

User talk:Seb76

2008-07-09T19:35:37Z

Knan: