Known Bugs

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.

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 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 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. --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) bylund 00:15, January 12, 2007 (GMT+01)

Interceptions: Last Shot Always Misses

When using Cautious attack when 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 and 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 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 Grenades 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 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 Controlled 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." Thus, 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 Grenades 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 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 berserk code will try to access the nonexistent entry, resulting in a crash. The Celatid has yet to be tested.

Limited Unit Slots - Battlescape Crash

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 have 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.

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 (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 Bombs and Stun Bombs.

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 Zombie and 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 exploited, but it is 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.

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 of any one item in the general stores at a specific base at one time. However, this will likely only happen 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 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 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. 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 screen full 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 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 resolution) 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.

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. Fortunately, by the time you accumulate this much cash, you have usually completed all necessary research to win the game.

UFOPaedia Craft Weapon Hit Probability Bug

There is a bug in the in-game UFOPaedia. It mistakenly reads the damage value field when reporting the hit chance for a craft weapon. Hence:

• Cannon shows 10% not 25%
• Avalanche shows 100% not 80%
• Laser Cannon shows 70% not 35%
• Plasma Beam shows 140% not 50%
• Fusion Ball shows 230% (!!!) not 100%

Possibly the reason this bug was missed during testing is that the first weapon in the data files, Stingray, actually does have Damage equal to its hit probability.

See Also

Known Bugs (TFTD)

For bugs that only affect X-COM: Terror From The Deep.