Known Bugs

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

It is also possible to stop the 80k per month charge by hex editing the base.dat file in the save game. If you change the byte that indicates the number of days until the destroyed module from 00 to ff, you no longer pay for the dirt.

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.

Note that this also applies to facilities that have been destroyed due to battle damage in Base Defence missions. If you have lost a facility in a base defence mission and you cannot afford to replace the original facility, consider building something cheap here to keep down this bug.

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.

All these issues are also fixed by UFOextender.

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

Medic Research Bug

The array holding live alien and autopsy data to randomly provide when an alien Medic is researched is four bytes too short. What this means in practice is that if you interrogate an alien Medic before you have at least two of these topics unlocked, the game will crash. To avoid this bug, do not research any alien Medics until you have performed either: a) two alien autopsies, b) an alien autopsy and an alien interrogation, or c) two alien interrogations of different species.

Never-ending Retaliation Bug

Some times the aliens will send a battleship on a retaliation mission to the "wrong" base. F.ex: the hyper-wave decoder may report its destination as South East Asia, but the ship will actually fly to your base in North America and attack it.

Even if the battleship succeeds in getting past the base defences and its crew is subsequently defeated, the aliens won't "forget" the base's location as they normally do and instead keep sending another battleship every week or so. If your base is constructed with defendability in mind and crewed by experienced operatives this will net you heaps and heaps of alien weapons, corpses and prisoners very quickly. The downsides are, of course, playing the same base defence mission over and over again and having to maintain a garrison there at all times.

More research is needed to find out what causes this bug, but it could have something to do with mind shields being finished between the scouting and assault parts of the aliens' retaliation mission.

Early Base Defence bug

XBASE.DAT has 12 entries for each valid mission zone. However, the initialization routine for a new game only resets the first 8 entries. If some of these entries have leftover data from a previous game, this may spawn an alien Battleship attacking the location specified, usually your first base. This results in an unprovoked Base Defence mission, within the first two weeks of the new game! (Normally, the aliens don't try to attack your bases unless you intercept UFOs, and they have to search for a base before a Battleship can be deployed to assault it.)

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.

When the game was written, the largest unit that a programmer had available was a DWORD. The programmers did not make this unsigned (if that was possible back in the early '90s) so the largest amount that could be stored is 7FFFFFFh, which is 2147483647.Tycho (talk)

Battlescape Bugs

Load bug after successful mission

After you finish a game you have saved and load the same game file again - the alien side goes first! I think it may be caused when you succesfully complete the mission and you get a notification like that the alien has died beacuse of no alien containment. The game still thinks that it is the aliens' turn. So when I load the mission again- the aliens move first. If you load the same saved game again it will be OK. ElfKaa

Time Units Missing

Very rarely when you end your first turn and all your units are inside the Skyranger in the next turn they all only have 4 time units remaining.

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 defence 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 its 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 its 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 is that each and every Incendiary explosion triggers the "Smoke and Fire" routine: applying fire damage, applying stun damage from smoke, calculating fire and smoke spreading, and "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.

Tanks have full ammo during Base Defence

HWPs in Enemy Unknown/UFO Defense and SWS in Terror From the Deep will always have full ammunition during a Base Defence mission even if there is not enough ammunition in storage to have them fully armed.

This occurs because tanks are always initialised with full ammunition when they are spawned in the battlescape. However, the game does not make the necessary adjustments to their ammunition supplies and leaves them fully armed. Any ammunition that was in storage will be consumed normally.

After the battle, any left over ammunition will be recovered and added to stores. If a base is regularly attacked, this can be [[1]] to create large amounts of ammo for free by sending away all of the ammunition to another base after each battle (particularly for Hovertanks/Launcher and Displacers/P.W.T., since their ammunition must otherwise be manufactured from alien materials).

Note that this bug will arm a Coelacanth/Gauss in Terror From the Deep, but you will not recover any ammunition from it due to its own specific arming bug.

Collectors Edition Blaster Bomb Bug

Also known as Vertical Waypoint 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. The bug makes it impossible to fire Blaster Bombs up or down elevator shafts. Aliens are also affected by this bug.

The Blaster Bomb bug in turn permits the Elevator Shielding - Base Milking Exploit, which provides unlimited risk-free experience and ultra-low-risk booty, so fixing it is a Good Thing. Base Milking in general is a legitimate tactic, but doing Base Milking risk-free via the Elevator Shielding is just an exploit.

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

A primed explosive (Grenade, High Explosive, Alien Grenade) will not explode if it's still in your inventory (hand, belt etc) when the timer runs out. It will only detonate when it's on the ground. If your soldier falls unconscious or gets killed, the primed explosive 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.

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.

MIA Bugs

The routine which checks whether units are "Missing in Action" or not has several bugs in it. Specifically:

• Soldiers that have been mind-controlled and not yet returned to X-Com control (whether by mind-control on the final turn, or because they were stunned while mind-controlled and haven't woken up yet) will be listed as MIA and permanently lost.

• If you abort a mission while aliens are under X-COM mind-control, you will be penalised for any mind-controlled aliens outside the exit area as though they were MIA (-20 points each). In PlayStation versions of the game, this does not occur as all mind-controlled aliens at mission end are considered captured.

• The only action which resets the location of unconscious soldiers, for the purposes of the MIA algorithm, is dropping. As such, soldiers carried or thrown back into the dropship and not subsequently dropped inside will be listed as MIA and permanently lost, while soldiers stunned or dropped inside the dropship and carried or thrown outside will be recovered safely.

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 Defence Elerium bug

On DOS versions of UFO Defense, Elerium pods may spawn as items from the base stockpile during a Base Defence 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.

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.

The part about HWPs only losing morale by blue-on-blue isn't true: I had a rocket tank go berserk on me in a terror mission when a floater blew up my whole force with a single grenade in the first alien turn. The game crashed alright; I have the CE version with UFOextender.--amitakartok 08:24, 11 January 2012 (EST)

Unless my memory is playing tricks on me, I clearly remember an very bizarre incident like yours but where the rocket HWP panicked (all other X-COM units had just been killed) but the game didn't crash (I play the DOS version) and the tank shot all its rockets randomly until it ran out of ammo. I remember that its TU numbers being while firing showed 255 TUs or some other impossible value (I hadn't done any manual edits). I don't remember if it crashed at the end but it did fire! Hobbes 10:47, 11 January 2012 (EST)

And this reminds me of yet another panicked HWP incident but involving a Cannon HWP. I was expecting it to waste all its ammo (based on my previous experience) but it only fired a few shots and the TU level didn't went up crazy. Hobbes 10:47, 11 January 2012 (EST)

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.

Left arm fatal wound instead of torso (energy penalty)

According to UFO Defence manual, torso fatal wounds affect energy replenish rate, which is logical. But in the game fatal wounds of the left arm affect energy replenish rate, not the torso. Which is an obvious coding bug (though not a fatal one).

Invisible Chryssalids

After reloading a saved game with a mission where zombies are present, the resulting Chryssalids might be invisible. This only happens when zombies are present but all Chryssalids are either dead or KO. This issues occurs because the load-game routine only loads graphics files for active units. When the chryssalids' files are loaded, the game also loads the files for zombies but this is not true in reverse. Tycho (talk)

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

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.

Ammo Weight Bugs

In general, the game engine handles the weight allocation of ammo/clips loaded into weapons very badly. There was a good design to handle ammo weight, but it was not properly implemented. As a result there is a set of bugs relating to ammo/clip weight and encumbrance that share overlapping causes and effects.

Equip Phase Ammo Load Error

The game routine for placing ammo into weapons at the beginning of the equip phase does not correctly set all object and unit values. It should set the ammo as loaded into the weapon, the weapon as being held by the soldier, and the map position of the weapon and the ammo as the same as the soldier. Looks like it does not do one or more of these things. Whatever values the game doesn't set, do get set if you manually load or reload the weapon, either during the equip phase, or during the game.

Specifically, the game's auto-equip functions at the beginning of the equip phase fail to set offset 0x04 of the OBPOS.DAT record to point to the soldier who owns the ammo. These functions leave the value = 0xff, which implies "on the ground". They also leave the ammo location as being the equipment pile, rather than the location of the soldier. The other values are set correctly. Manually loading ammo into a weapon, during the equip phase or during combat, correctly sets all values. The ownership points to the soldier and the location to the soldier's location.

This bug is the cause of Weightless Loaded Ammo. Probably the only other impact of this bug is that XComUtil can't detect the fact that the ammo is loaded into the weapon, for the purpose of AutoCombat. It might have other subtle effects on any utilities that deal with equipping soldiers.

Weightless Loaded Ammo

Ammo that is automatically pre-loaded into a weapon at the start of the Equip Phase of a mission does not initially count towards any soldier's carried weight (Encumbrance). If the weapon is subsequently unloaded during the Equip Phase or later in the mission, the soldier's encumbrance will increase. This will probably 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 original weight calculation routine that was uncovered (but not caused) by Seb76's inventory screen improvements.

The Weightless Loaded Ammo bug slightly advantages X-Com. It leads to a set of relatively minor exploits. Using this bug, you can get weak soldiers to carry heavy weapons with (usually) a single clip and no TU penalty. For weapons that use multiple ammo types (which auto-equip with AP by preference), by manipulating the overall supply of ammo of different types you can to some extent persuade the auto equip algorithm to load your preferred ammo type for these weaker soldiers.

Spike 22:51, 6 September 2012 (EDT)

Displaced Ammo Weight

Guidance: Apart from weapons pre-loaded by the game, be sure to unload any weapons before dropping them. Drop, pick up and transfer ammo only when it is not loaded into a weapon.

Dropped ammo clips that are still loaded into dropped weapons are not un-assigned from the unit carrying them. The weight of the ammo / clips continues to count against the unit's Encumbrance as 'displaced weight' that can't be removed by ordinary means. This is an original game bug that only becomes apparent when using mods that display the unit's current encumbrance. The effect continues until the ammo is unloaded (either by the original holder picking up the weapon again and unloading it, or someone else picking it up and unloading it). Once the ammo is unloaded, its weight is applied to the actual current holder, only, and is released from the original holder.

This bug also applies during the Equip Phase, if one soldier loads a weapon, drops it, and another soldier picks it up.

In some senses this bug is the opposite of the Weightless Ammo Bug, and each bug has probably tended to obscure the effects of the other. For example, clips affected by the Weightless Ammo Bug (clips automatically loaded by the game) are not so obviously affected by this bug, since their displaced weight is 'carried' by the Equipment Pile rather than any specific Soldier. (In another sense, this is the same bug, with the weight displaced to the Equipment Pile rather than to another soldier.)

See this discussion for more information on this bug.

Ammo Weight Exploits

As noted above, Weightless Ammo is, in itself, a minor exploit, since it provides some extra penalty-free carrying capacity in combat.

On the face of it, the Displaced Weight Bug is not an exploit, since for every decrease in weight on one soldier there is a corresponding increase in weight on another soldier. However the Displaced Weight bug could potentially be exploited by having one soldier first load and then drop a lot of weapons, and then move away from the resulting pile to allow others to pick up. This would create a reserve of weapons where all the ammo weight was being 'carried' by this "weight sink" soldier, freeing up encumbrance for other soldiers. For example, all recon and front line soldiers required to be mobile could get reduced weight, at the expense of a single soldier having extremely reduced mobility/TUs. However, as the game's auto equip routines already load all initial weapons with weightless ammo, this would only be useful after combat had been progressing for some time, for reloads rather than initial loads, and it would require the squad to regroup around this "sink", or ferry weapons to/from the "sink". It might be most useful with Rocket Launchers (high weight, high ammo weight, one round before reload).

Storage and Transfer Bugs

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)

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.

Exceeding Storage Limits when Transferring Craft

Usually you can't transfer crafts to bases without capacity for them as you'll get an error when you press the Up arrow. However, if you press the Down arrow when the craft quantity is already at 0, the game will still think you're removing crafts from the destination base and "add capacity", so you can then press the Up arrow again to transfer the crafts without error. This doesn't work with other transferable items.

Once you've broken the limit once, you don't need to do this trick anymore as the error won't show up again (the game probably doesn't check for negative capacity). You can also exceed storage and personnel capacity this way, as Transport Crafts will carry their contents over. For example, if you press the Down arrow on a Skyranger with 14 soldiers, the game will "add capacity" for 1 craft and 14 personnel on the destination base.

You can also orphan crafts this way by removing a base with crafts but no hangars, which can cause all sorts of weird behavior.

Soldier Limits and Recruiting Bugs

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

Manufacturing and Research Bugs

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

At midnight, research projects are checked for completion in the order shown on your Projects screen (which is the same order as for picking new Projects, for RESEARCH.DAT, etc.). But X-COM does not track the effort of individual scientists, so when a project ends, its scientists can be re-assigned before the game checks the next project.

The upshot is that you can re-use scientists from completed projects as long as you put them on projects (existing or new) that are farther down the list than the one that just finished. And if you assign more scientists than projects need, you can finish multiple projects immediately!

To best use this exploit:

• If projects (new or existing) have equal priority to you, start new scientists at the top of your list (the lowest-numbered project) and work them "down" from there. This minimizes the number of times that scientists wind up at the end of the project list (where you can't exploit them).
• It works especially well later in the game if you have a full complement of scientists (practical limit of 250 at a base) and apply them to the many "fluff" alien, corpse, and alien-room projects that average less than 250 research days. You might finish a lot at once.
• If using it, you don't have to worry about "wasted" research effort due to allocating too many scientists to a project on its last day. Unless you're at the end of the project list, wasted scientists can be re-used, too - sometimes many times.

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.
NOTE: you need to make sure that not all of their projects finish at the same time. Otherwise, you would be stuck with 0 'available' workers/scientists, i.e. unable to assign them to a new project.

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.

UFOPaedia Errors

Craft Weapon hit probabilities

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.

In the CE version, this is the problem piece of code: .text 45B2CC: 0F BF 4E 06

Change the 06 to 04. The offset may not be correct for everyone but it should be close. I don't know the offset in the DOS version. Tycho 06:27, 1 April 2012 (EDT)

Craft Weapon reload rates

From empirical research it looks like the reload rates of craft weapons are not stated correctly in the UFOPaedia. For example, the rates of fire of the Laser Cannon and Plasma Cannon are actually the same as each other, and they are both about six times slower than the regular Cannon (so about 12s) - whereas the UFOPaedia entry gives the reload times (inverse of the rate of fire) as being:

Cannon       2s
Laser Cannon 4s
Plasma Beam  6s

Similarly the UFOPaedia shows the Fusion Ball as having 3/5 the rate of fire of a Stingray missile, with the Fusion Ball being slower than an Avalanche missile; but empirically the Fusion Ball and Stingray have the same rate of fire, and so the Fusion Ball is faster than the Avalanche. See the discussion in Craft Combat Mechanics - Observed Rates of Fire for more details, but keep in mind recent code digs have clarified the picture from this initial rough approximation. It seems reasonable to assume the actual reload rates are coming from a different part of the executable, different to the locations used populate these values that are displayed in the UFOPaedia. Spike 23:25, 6 September 2012 (EDT)

Alien Containment size

The UFOpaedia in-game claims that each Alien Containment module can hold 10 live aliens. This is not in fact the case; the true limit is 50 aliens in containment among all bases, regardless of how many Alien Containment modules exist (though live aliens can only be stored at bases with Alien Containment). As such, building more Alien Containment modules, or shuffling aliens around between bases, will not free up space; the only way to free up space is to research some of the captured aliens (which removes them from containment).

Radar detection chances

The UFOpaedia in-game claims that both Small Radar and Large Radar facilities have a 5% chance of detecting UFOs every 10 minutes. In fact, this is not the case; Small Radar has a 10% chance of detecting UFOs per 30 minutes (less than advertised), while Large Radar has a 20% chance of detecting UFOs per 30 minutes (more than advertised). Note also the Radar Stacking bug.

Other Bugs

Difficulty Bug

The DOS version has a problem where no matter what difficulty level you choose, it will revert to "Beginner" level after the first mission. This is caused by one incorrectly set bit in all DOS versions of the game (1.0 through to 1.4). The Collectors Edition Windows port (also commonly known as UFO Gold or CE) does not have this problem. To check your Difficulty Level:

• Look at offset 60 in IGLOB.DAT. (If this file is only 60 bytes long, you've got the bug!)
• Look at statistics for aliens in your game with a Mind Probe or Psi-Amp

To fix the Difficulty Bug, you can install XcomUtil and it will repair this bug. Alternately for those familiar with hex editing, you can fix this bug by referring to the appropriate section on the GEOSCAPE.EXE article and manually setting the incorrect byte to its proper value.

This TVTropes page has been known to state that due to the bug, players asked the developers to increase game difficulty. The rumour goes that a new bug was supposedly introduced as a result, where TFTD's difficulty would reset to Superhuman instead of Beginner. The facts of the matter are that, while the overall difficulty of the game was increased, TFTD does manage to correctly keep track of which specific mode you're supposed to be playing in.

Chrysallid / Tentaculat Difficulty Bug

Stats of Chrysallids or Tentaculats that emerge from Zombies during combat have stats that ignore the difficulty level.

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.

Losing My Favourite Game

There is a check whether the "Has X-com received a financial warning?" flag has been raised. If no, a warning is issued and the flag is raised. If yes, then the game ends, and the flag is lowered. HOWEVER, this flag is erronously not connected to any particular savegame, it is global across all savegames. This allows strange results when saving and loading games.

Celatid aim bug

The Celatid typically misses. User Tycho has identified this is due to a bug that causes the Celatid to aim at the ground, rather than the middle of the target. The bug is being fixed in UFO Extender. The same bug may apply to the same grenade-like weapon routine used in TFTD.

"Seeing the future" Graph Bug

Noticed this in EU CE version, but probably it happens in every other, probably in TFTD too. If, for any case, you have graphs data for months you did not play yet, you will see numbers like 10240, 163780 etc. next to the vertical axis, and graphs will be totally garbled. This can be fixed by hex-editing ALIEN.DAT, XCOM.DAT and UIGLOB.DAT -- just fill the 'future' with zeros.

Utility bugs

These are not bugs in X-Com itself, but in utilities often used with it. They are included for completeness.

• Small window bug

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.

See Also

Known Bugs (TFTD)

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