Known Bugs

From UFOpaedia
Revision as of 17:10, 28 May 2008 by Phasma Felis (talk | contribs) (→‎Fixes for Base Construction Bugs: Linked BaseFixer to its entry on Spike's user page, instead of directly to the file)
Jump to navigation Jump to search

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.

Base Disjoint Bug

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

Xcomutil works around this problem by stripping out the walls entirely in all the base modules.

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

Facility Maintenance Costs

Although X-COM charges the right fee when you first buy base modules, the monthly maintenance fee is always wrong. It's actually based on the placement within the base grid, not the price displayed in the in-game UFOpaedia. For more information, see Base_Facilities#Facility_Maintenance_Cost_Bug. The Geo finance Graph shows a correct summary, however (LIGLOB.DAT, updated once a month). Also see the next section.

Paying For Dirt

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

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

Base Facility Dismantle-Construction Crash

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

Radar Stacking

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

Phantom Radar

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

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

Fixes for Base Construction Bugs

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

Geoscape Bugs

First Radar Detection Data bug

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

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

Minimized Interceptor Bug

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

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

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

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

Interceptions: Last Shot Always Misses

When using Cautious attack when intercepting a UFO, your craft will stay at the maximum range of your longest-range weapon. When using Standard attack, your craft will stay at the maximum range of your shortest-range weapon. (Usually players use two weapons of the same type, so Cautious and Standard attack will behave the same in this regard.)

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

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

Elerium-fueled Craft Bug

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

Floater Medic Research Bug

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

Battlescape Bugs

Faulty Large Units

This bug has been listed as a MINOR bug in exploits page. Please place it into the "Minor Bugs" section page.

this has been moved from exploits to here - NEEDS to be written when the time comes

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.

Collectors Edition Blaster Bomb Bug

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

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

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

This bug also applies to the Disrupter Pulse Launcher in TFTD.

The trouble with Mines (general)

The armed states for Proximity Grenades in both UFO and TFTD are NOT stored in savegames. More information to come.

Mountain Map

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

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

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

For more details, see Mountain Madness.

What just exploded?

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

Door jam

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

Mind Controlled Soldiers go MIA

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

Mind Controlled Aliens Count as MIA if you Abort

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

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

20 Proximity Grenade Limit

The array used to denote armed Proximity 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.

Character Inventory Bugs

Alien Inventory Stacking Bug

THis bug has been listed as a CRITICAL bug in exploits page. Please place it into the "Critical Bugs" section page.

this has been moved from exploits to here - NEEDS to be written when the time comes


WARNING: You will see that sometimes the alien will stack equipment on its right leg. If you remove an item from their right leg, make sure you enough time units to place it somewhere else. If you run out of time units, you will have to force a quit and cannot save your game. (press ALT-TAB, then CTRL-ALT-DEL, and 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

Carrying unconscious units a hand slot will crash the game if they wake up. 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.

Storage and Transfer Bugs

80-item Limit

When loading up your Avenger for a massive UFO assault or arming soldiers for a Base Defense from your overflowing stores, you will likely hit this limit.

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

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

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 cancelled craft transfer.

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.

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

Transfer crash

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

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

Purchase Limit

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

Storage Limit

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


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 250 times.
  • You get also charged for Soldiers you try to purchase above the Transfer Limit (100 at a time).

Soldier Battlescape Limit

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

Manufacturing and Research Bugs

Cancel Manufacturing Bug

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

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

Zero Unit Manufacturing Exploit

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

Research Rollover

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

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

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

TFTD Research Tree Bug Avoidance Guide

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

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

For now:

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

Other than the MC reader one, any of the above would make it impossible to finish the game.

Overcrowded Engineers (And Scientists?)

In the Dos version (probably the others as well) if you hire more than 255 engineers in a single base, the number of engineers in the base will read a negative number once the 256th 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 probably also affects scientists. It may be exploitable to pay a negative salary at the end of the month.

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.

Other Bugs

Difficulty Bug

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

Big Text Bug

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

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

In the dos version, the text that you see is simply a memory dump in mode-13h (the 320x200x256 colour screen resoulution the game uses) and the text colour is based off the changes to the pallete that the game made. The game sometimes continues with the next part of the game. The game is made of two different programs, Geoscape and Battlescape, so when one part of it crashes, the other one will not have registered that anything has gone wrong and will attempt to soldier on. In the Windows version of the game, the game simply crashes back to the desktop, unless you're using the XcomUtil split executable variant. - NKF