- 1 Game Destroying Bugs
- 2 Base Construction Bugs
- 3 Geoscape Bugs
- 3.1 First Radar Detection Data bug
- 3.2 Minimized Interceptor Bug
- 3.3 Interceptions: Last Shot Always Misses
- 3.4 Elerium-fueled Craft Bug
- 3.5 Medic Research Bug
- 3.6 Never-ending Retaliation Bug
- 3.7 Great Circle Bug
- 3.8 Geoscape Intercept Bugs
- 4 Battlescape Bugs
- 4.1 Load bug after successful mission
- 4.2 Faulty Large Units
- 4.3 Unconscious Units are items
- 4.4 Funky Fire
- 4.5 Collectors Edition Blaster Bomb Bug
- 4.6 Blaster Launcher Dud Shells Bug
- 4.7 The trouble with Mines in General
- 4.8 Grenade Timer Behaviour
- 4.9 Mountain Map
- 4.10 What just exploded?
- 4.11 Door jam
- 4.12 MIA Bugs
- 4.13 20 Proximity Grenade Limit
- 4.14 Base Defense Elerium bug
- 4.15 Berserk HWP crashes the game
- 4.16 Limited Unit Slots - Battlescape Crash
- 4.17 Left arm fatal wound instead of torso (energy penalty)
- 4.18 Invisible Chryssalids
- 5 Character Inventory Bugs
- 6 Storage and Transfer Bugs
- 6.1 80-item Limit
- 6.2 Sticky Craft Transfer Fee glitch
- 6.3 Fuel dump on transfer
- 6.4 Transfer Limit cash eater
- 6.5 Transfer crash
- 6.6 Purchase Limit
- 6.7 Storage Limit
- 6.8 Exceeding Storage Limits
- 6.9 Base Storage Anomalies
- 6.10 Exceeding Storage Limits when Transferring Craft
- 6.11 50 Unit Limit for Captured Aliens[]
- 7 Soldier Limits and Recruiting Bugs
- 8 Manufacturing and Research Bugs
- 9 UFOPaedia Errors
- 10 Other Bugs
- 11 See Also
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:
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.
Note that this also applies to facilities that have been destroyed due to battle damage in Base Defense missions. If you have lost a facility in a base defense 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.
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.
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.
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
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.
Based on report from various players, the crash appears to happen with medics in general, and isn't confined just to floaters.
The portion of the code that is responsible for selecting the unresearched alien topic to provide when completing the research on a medic is the problem. The array that holds the avaiable topics, so that one can be randomly selected, is four bytes too short. If a player has never researched an alien species or performed an autopsy, the program will crash after it displays the random alien topic. This is because the portion of memory that holds the return address for the function has been overwritten by the array creation code and upon completion of this subroutine, the game is directed to an invalid memory address. This error won't occur if the player performs two autopies, alien interrorgations or a combination of both before researching a medic. Tycho 21:04, 22 June 2013 (EDT)
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.
Great Circle Bug
The shortest distance between two points on the surface of a sphere is called a Great Circle. The wayfinding algorithm used by XCom aircraft has unfortunately never heard of this. XCom aircraft tend to move toward, and then along, lines of latitude. This is inefficient in terms of time, fuel, range and time on station. The inefficiency is most evident when crossing over the poles, and least evident when moving east-west or west-east.
As a workaround, you can set manual waypoints to approximate the Great Circle route.
Note that this does not seem to affect combat interception of moving UFOs, or at least not as much. Intercept courses seem to be continually updated, and head straight toward the current position of the UFO (also not an optimum algorithm, but that's another story).
Geoscape Intercept Bugs
Side-On Intercept Bug
Unlike fighter controllers since at least the 1930s, X-Com ground controllers and/or onboard avionics are incapable of calculating a predictive course for a target that is moving, at a known course and speed, laterally relative to its bearing as seen from the intercept base (so that the bearing from the base is constantly changing). In other words, in any situation except when the alien craft is heading directly toward/away from the X-Com craft/base, a non-optimum interception course is used. Instead, X-Com craft simplistically just keep heading toward the current bearing toward the target. This results in inefficient parabolic intercept courses, rather than efficient straight line courses toward a predicted intercept point. If the alien craft is faster, parabolic courses often fail to intercept, or give very brief interception windows, that would have been avoided by a proper predictive, straight-line course.
Head-On Intercept Bug
It is not possible for a slower-moving X-Com craft to intercept a faster-moving Alien craft, even if the X-Com craft is directly ahead of the alien craft and waiting in position to intercept it. This is true whether the X-Com craft is stationary, or flying in the same heading as the alien craft and at nearly the same speed. Even if the alien craft moves right through the X-Com craft's exact position while travelling only slightly faster than the X-Com craft. Interception only occurs if the alien craft voluntary slows down for long enough for the X-Com craft to catch it.
(It's true that such interceptions would be difficult, whether attempted head-on at high closing speed - extremely brief period to fire - or tail-on at low closing speed - very easy for the alien to avoid entering X-Com craft's weapon arcs by breaking away. So it could be argued that making these interceptions impossible is just a simplification of the fact that they would be much more difficult than normal interception combat.)
Instant Getaway Bug
If you park an interception craft directly over a touched-down alien craft, the alien craft will still escape, if the alien craft has superior maximum speed. The alien craft basically seems to instantly accelerate to its maximum speed, with no concept of progressive acceleration. Interception only occurs if the alien craft voluntary slows down for long enough for the X-Com craft to catch it. This probably has the same root cause as the Head-On Intercept Bug (arguably it is a special case of the Head-On Intercept Bug).
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
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 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.
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.
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.
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.
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.
A number of bugs cause units to be unexpectedly listed as MIA. In the case of X-COM units, this also means the soldier is permanently lost from your roster, probably along with any armour/equipment carried.
Mind Controlled Soldiers go MIA
If you complete a mission successfully 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, which is the likely location of the final combat turn.
Stunned Mind Controlled Soliders go MIA
Similarly an X-COM soldier who was Mind Controlled by the aliens and then stunned (usually by X-COM), and who is still stunned at the end of the mission (victory or abort), will count as MIA. Presumably the game does not set the ownership flag on the unit back to XCom's side until the unit wakes up.
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.
Stunned, Carried, Not Dropped Soldiers are MIA on Abort
If a soldier is stunned anywhere outside the transport and then carried back to (or thrown into) the transport for an Abort, they are still considered MIA. The game considers them to be still at the location where they were stunned and picked up from. You must drop the soldier on the ground in the transport in order to recover them back to base in an Abort. Throwing into the transport does not work.
Stunned Inside, Thrown Outside Soldiers not MIA on Abort
A soldier who is stunned inside the transport and then thrown (not dropped) outside the transport prior to a mission Abort does not count as MIA, but is successfully recovered back to base. This is presumably because throwing does not reset the location of the unit.
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.
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).
In missions where these terror units are present after reloading a saved game with zombies present, the resulting Chryssalids will be invisible. This only happens when zombies are present but all Chryssalids are either dead or KO. The load game routine only loads the PCK and TAB files for active units. When chryssalids are present, the game will load 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).
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.
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.
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 soldiers 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).
Hypothetically, Displaced Weight could be exploited to overflow the Weight value of a unit and allow that unit to carry massive weight with minimal encumbrance. For example, carrying 32 rocket launchers and 32 rockets (ammo weight 256) into combat. There is not enough Equip space in the Equipment Pile to manipulate this equipment pre-combat, as the loaded weapons must be dropped, and there is only enough space for 20 rocket launchers in the Equipment pile, so the remaining manipulation would have to be done during combat time (and over more than one Battlescape square). However, it looks like the Weight subroutine and the value it returns into are both bigger than 2 byte numbers (256). There is no way to push Displaced Weight into the 32,000 or 64,000 range with using some kind of game file editing or hacking/modding.
Spike 09:06, 29 September 2012 (EDT)
Storage and Transfer Bugs
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.
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.
|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.|
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)
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.
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.
50 Unit Limit for Captured Aliens[]
You can only ever have 50 captured aliens in Alien Containment at any time, no matter how many you build, no matter what base they're in.
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
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.
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.
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.
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.
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.
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)
UFOPaedia Craft Weapon Reload Rate Bug
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)
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.
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.
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.
For bugs that only affect X-COM: Terror From The Deep.