UFOpaedia - User contributions [en]

Talk:Known Bugs

2025-08-08T13:09:01Z

TowigOs: Add a missing space

= Classification etc =

== Bugs vs Exploits ==

Could someone comment please on the distinction between a bug and an exploit, and where to put each one? I would guess that a bug is something that undesirable and an exploit "might be" desirable, if you want to cheat. But what about exploits that happen by accident, or bugs that need to be forced to happen?

I was going to add the Research Rollover bug to the Exploits sections, but they seem to all be under construction. What's the agreed approach?

[[User:Spike|Spike]] 04:16, 15 March 2008 (PDT)

* i think that an exploit is somthing you can trigger and gain an advantage from. a bug may or may not have a known trigger, and does not give an advantage if it does.
: All exploits are bugs, either in implementation or design. When using a bug to gain advantages that bug is used as an exploit (you are exploiting the bug). [[User:FrederikHertzum|FrederikHertzum]] 13:39, 10 May 2011 (EDT)

:: IMHO, Laser Pistols Gifts to train reactions is an exploit, but it does not involve any bugs. It merely exploits the fact that laser pistols will not penetrate the front armor of Flying Suits. [[User:Jasonred|Jasonred]] 16:31, 10 May 2011 (EDT)

::: I guess the point is to differentiate if it's a bug that's being exploited to your advantage, or it it's something confined within the game mechanics that you are exploiting to your advantage (even if using it as intended). -[[User:NKF|NKF]] 02:31, 11 May 2011 (EDT)

:::: Another definition: An exploit is
::::: a) a move allowed by game interface
::::: b) that sidesteps another part of the game mechanics
::::: c) and creates inadequate advantage for the moving player in the process.
::::: An exploit is not a bug, but it can be connected with a bug, if the latter allows a move mentioned in a). Most obvious exploits render whole parts of game mechanics obsolete (see b) above), because they are always more advantageous. In games that feature equal terms for AI and the player, an exploit can be discerned simply by the fact that AI does not use it (sadly this is not true in X-COM). Clear exploit in X-COM: Transfer soldiers = no monthly payment. Suspect exploits: grenade layout. Most probably not an exploit: Sniping (although the inequality with AI is suspect). Clearly not an exploit: dropping weapons to prevent Psi mass murder (this one is made exploitable by the AI unable to pick up weapons, but is not an exploit per se).--[[User:Kyrub|kyrub]] 05:30, 11 May 2011 (EDT)

The dropping weapons sort of turns into an exploit if you do the "everyone suspect of being a psi weakling drops their weapons at the end of the turn. They all pick up their weapons again if unpsied in the next turn." The grenade layout or grenade hot potato is probably not what the game designers had in mind, but I shudder at the thought of someone who only played X-com then joined the army pulling the pin out of his grenade and then dropping it into his haversack or slinging it on his belt. [[User:Jasonred|Jasonred]] 07:43, 11 May 2011 (EDT)

: Yeah, I think we agreed somewhere that shoving live grenades in your pockets and not having them go off is madness. The relay however is not sensible but certainly possible if only a very short one (if with a live grenade), or to toss a grenade forward and prime it at the second to last person. Or more reasonably, something like a stick of dynamite with an extra long fuse. Even that's very dangerous.

: By the way, what does everyone here think of using the mind probe to check if it's safe to attack an alien while standing in full view of it, or if you're right up next to it? I've been using it a lot lately (in lieu of the psi amp), so you could say I've been exploiting the mind probe to my advantage to help me with my decision making. But is that counted as a cheat since I'm picking my moments to attack up close when the enemy cannot return fire? -[[User:NKF|NKF]] 03:30, 12 May 2011 (EDT)

:: When identifying a mechanic as an "unfair exploit" (as opposed to just a "tactic"), perhaps a simpler checklist is this (though Kyrub's is spot-on):

:: a) Is this something the developers should've expected players to do?
:: b) Is this something the developers could've easily prevented?

:: If the answer to both is "yes", then it seems fair game to me. For eg, sniping at aliens: The game KNOWS whether the soldier can see the target (you get a flashing indicator if so), and so it would've been trivial to prevent it. Is it something the regular gamer will try? Certainly; therefore it can be considered expected behaviour. Ditto for using the Mind Probe to make attacks without fear of reaction fire; those things aren't cheap, they sell for a bunch, so it stands to reason that they'd have tactical value!

:: Things like the transfer bug are clear exploits. The devs would've implemented that system so that, if you order personal near the end of the month, you don't end up paying for them twice before they ever arrive - but in the process, they forgot that "purchase" transfers are treated in the same way as "between-base" transfers. To fix one scenario without breaking the other, they'd've needed to code in some extra stuff so the game could tell the difference - they probably just figured the regular gamer would never notice, assuming they ever realised the problem existed.

:: The "dropping weapons" thing is a little trickier to work out - yes, the devs should've seen it coming, but would it've been easy to fix? Aliens could've been twigged to either ignore un-armed soldiers... but those soldiers could re-equip next turn. Aliens could also've been twigged to attack randomly... but that would make their psi powers far LESS effective! I suppose the fix, if any, would've been unarmed melee attacks, but the implementation they went with seems to be the next best thing IMO.

:: In regards to the "grenades in inventory" thing, it's probably common knowledge by now, but they DO go off in the alpha of the game. Presumably someone made a conscious decision to change that, though it could still just be an accidental bug. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:02, 12 May 2011 (EDT)

Sniping at aliens is a very bizarre case, since almost all players will fall prey to the aliens sniping at you long before they snipe the aliens. The behaviour of the aliens to step within sight radius, take one step back, then fire without fear of retaliation *looks* and *feels* like clear exploitation of the rules, but the computer can't be a cheater, can it? So we humans carry that one step further. Mind you, I think X-com would be in trouble if the aliens could snipe you from across the map once they know your positions... especially since the aliens have cheating "if I spot 1 human, I spot ALL of them" abilities. Especially on maps where the aliens get Blaster Bombs...

An interesting note about sniping and LOS: When I first played Xcom, my first mission was in the jungle. Because of all those plants, when my first soldiers spotted an alien, after he shot at him, I tried to make my 2nd soldier open fire and was informed "NO Line of Fire". I could only get my 2nd soldier to fire by positioning him in such a way that I got the flashing number. Henceforth, I assumed that you could ONLY fire at the aliens when the flashing number was there. LOL. LOF. LOS.

Transfer bug wise, I thought that the devs merely programmed the game to count how many staff were currently in the base, then deduct that from Xcom coffers? As far as ordering personnel near month end goes, you end up paying salary for them if you order them more than 48 hours from month end, right? "realistically", they should make staff draw salaries based on when they were hired, but this would be too much effort.

"dropping weapons" would have been easy enough to fix... just teach alien AI how to pick up weapons. Like they did in Apocalypse.

As far as grenade relays go, if you ever join the army, and you toss a live grenade at your squadmate, you're gonna be court martialled! lol. Xcom grenades are weird cause they presumably come with a computer console where you program them or something that takes a lot of TU, if I already have a grenade in my hand I don't think it takes long to prime it compared to throwing it...

Pretty clear exploit/bug is tossing grenades through the ceiling? That breaks all laws of realism/logic/whatever, and I'm sure the devs didn't plan for THAT to happen! [[User:Jasonred|Jasonred]] 18:18, 12 May 2011 (EDT)

: Turns out the "spot one, spot all" thing was wrong all these years. However, units can be "spotted" by sniping an alien, hitting it, but failing to outright kill it; this may have contributed to the misconception.

: The game considers the base to have the correct amount of personal as soon as you initiate a transfer - if a base has room for ten people, you can't send two groups of ten, as soon as the first is in transit the game will correctly recognise that the destination is now filled up and won't allow you to send any more. Likewise, if you hire soldiers, they'll count towards the allowance of more promotions in your ranks before they ever arrive at a base. That is to say, the payment system deals with personal counts in a different way to every other system in the game, making it look like it's intentional (if badly exploitable) behaviour. In terms of transit times, those seem to vary, I know a purchase of scientists takes 72 hours to arrive.

: Er, yes, getting aliens to pick up weapons would've indeed fixed the dropping thing. Shoulda thought of that...

: The grenade thing is indeed unrealistic however you look at it. Certainly throwing the things through ceilings is a bug, and its use is a large exploit. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 20:02, 12 May 2011 (EDT)

:: Then how do the aliens "spot" the psi weakling to target him for psi attacks? Doesn't the game ALWAYS start blasting the juiciest target, regardless of LOS? Or is it just coincidence? [[User:Jasonred|Jasonred]] 22:22, 12 May 2011 (EDT)

::: They really have to "[[UNITPOS.DAT#8|spot]]" the target before they can blast them (however, it appears that later in a campaign this rule gets broken). If they've only spotted a psi-''resistant'' trooper, they typically won't bother to make attacks at all. There's a lot of relevant information in [http://www.strategycore.co.uk/forums/Can-alien-attempt-Mind-control-Pani-t8115.html this thread]. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 23:28, 12 May 2011 (EDT)

: Your talking about your post on http://www.strategycore.co.uk/forums/Can-alien-attempt-Mind-control-Pani-t8115.html&pid=96123&mode=threaded#entry96123 ? Well, I'd just like to point out a massive flaw in your testing logic. You forgot that aliens will launch psi attacks based on chance of success, and chance of success varies based on distance from aliens. In other words, it could easily be that the aliens only attempted psi when your soldier was within sight of them because your soldier was now NEAR to them and therefore they had a strong chance of success.

: Also, as you have noted, it appears that your rule gets broken. In fact, it is not uncommon at all for the Ethereal Commander who is boxed up in the Command Center to launch psi attacks on victims who are separated from him by several layers of walls, as long as their proximity to him is near enough. [[User:Jasonred|Jasonred]] 21:19, 13 May 2011 (EDT)

:: Those are valid points. I've hence built a somewhat more robust testing scenario, which you may wish to [[:Image:Alien Psi Demonstration 1.rar|try for yourself]].

:: The save game consists of cloned Ethereal soldiers (all cranked up to 100 psi strength/skill), and many clones of a single trooper (most of whom have the same psi values). The Ethereals are all cooped up in a sealed room in the SW of the map, with a single trooper who has 140 psi strength/skill.

:: Directly outside the building is another trooper who only has 1 strength/skill. In the NE of the map, in another sealed room, is a soldier with 40 strength/skill. Before placing him there, I had him shoot one of the Ethereals just once, resetting index 8 of his UnitPos record to 0. Only he and the trooper inside the room with the Ethereals have hence been "exposed" to the aliens, but the "best chance of success" is obviously the psi-weakling directly outside the building.

:: If you load the map and end turn, the aliens will first attempt to take control of the dude on the other side of the map, then get to work on the guy in the room with them. Once they've taken these two, they'll completely ignore all other units.

:: In short, aliens can't use psi attacks on a unit UNLESS their UnitPos[8] index is set to less then that of the alien's intelligence stat. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 05:41, 14 May 2011 (EDT)

::: Good one. That test definitely proves a lot, rather conclusively. [[User:Jasonred|Jasonred]] 06:53, 14 May 2011 (EDT)

== Bugs vs Limits ==

''(Discussion continued from [[Talk:Known Bugs#Soldier Recruiting Bugs Tested|Soldier Recruiting Bugs Tested]])''

The "Soldier Recruiting Limit" is not a bug, it is a limitation of the game. Therefore, this should be removed from the page. If we want it somewhere else (like a new page such as [[Game Limitations]]), that would be appropriate. --[[User:Zombie|Zombie]] 01:42, 9 November 2008 (CST)

::Not sure that's necessarily the best idea, Zombie, since many of the entries on the Known Bugs article(as well as some entries on the Exploits pages) are limitations of the game engine. On just a brief glance through, the following caught my eye as engine limitations: Manufacturing limit, Storage limit, Purchase limit, 80-item limit, Proximity Grenade limit, Large units not waking up from stun, Interception last shot bug, Alien UFL radar blitz-through bug(Passing through the detection range of a radar before the detection check comes up), Free manufacturing, free wages, UFO Redux, point-scoring with Ctrl-C, permanent MC of chryssalids, Zombie-MC resurrection of agents, alien inventory exploits, anything involved with bad collision detection, extinguishing fire with a Smoke Grenade, and even your personal favorite, denying the aliens access to their own spawn points. So in conclusion, maybe it should just be left as it is; conversely, all of these entries could be kept where they are and also on a Game Limitations page, or we could leave the headers there and link them over to the appropriate topics on Game Limitations. What do you think? [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:21, 9 November 2008 (CST)

: I agree with AQ (great list of examples by the way - and the Smoke/Fire limit would be another). Many, if not most, of the bugs are "Limitations" but they are logically inconsistent and not what a player would expect to happen: they are imposed by (at best) memory limitations or (at worst) design/programming oversights. I think the easiest thing to do would be to change the title of the page to Known Bugs and Limitations, or put an explanatory note at the beginning of the section to explain that "Bugs" is taken to included "Limitations". [[User:Spike|Spike]] 13:16, 9 November 2008 (CST)

By the strictest sense of meaning, a "bug" is a mistake or error on the programmers part. Limitations imposed by design or memory are not the same creature as the people involved were consciously aware of the decision. I suppose that to the normal player, any type of behavior which is unexpected/unwanted is automatically dumped in the bug category because to them there is no difference. To those of us who study the game files however, the two are unequivalent. Programming oversights, yes, those are bugs.

Some of those limitations AQ mentions are (to me at least) bugs: free manufacturing, free wages, permanent MC of Cryssies (or actually any alien for that matter), Zombie resurrections and collision detection. Large aliens not waking up from stun is again, a bug. The programmers obviously had some issues when dealing with large units in general and never quite got it right. They made some progress in TFTD by trying to fix mind controlling each section of a large unit, but royally screwed it up by selecting the next 3 entries in UNITPOS.DAT no matter what they pointed to.

Perhaps it's just my background in logic which makes me want to push for a separate category for limitations. Then again, as long as everything is listed somewhere I'm happy. --[[User:Zombie|Zombie]] 22:06, 9 November 2008 (CST)

: Actually, taking a look through the page as a whole there are various other Limits described, and the distinction between Bugs and Limits is made quite rigorously throughout - not just in the Soldier Limits and Bugs section, where the Soldier Recruiting Limit is referred to as a Limit whereas other bugs (such as paying salaries for soldiers you can't recruit) are referred to as Bugs. So we maybe just need to rename the pages "Bugs and Limits" and add an explanatory note on the distinction. From a user point of view, rather than a programmer point of view, a bug is an unexpected (inconsistent or illogical) behaviour, so for that reason I think it makes sense to keep them on the same page but try to ensure they are all correctly classified as Bug or Limit.

: By the way, it could be hard to absolutely distinguish Bugs from Limits as I suspect there are going to be some grey areas where you would have to second-guess the intentions and decisions of the coders to know for sure if something was a designed-in Limit, or just an oversight (Bug). [[User:Spike|Spike]] 06:50, 10 November 2008 (CST)

::If we distinguish in this manner, I suggest the definition of "Limit" should be, "Something imposed by the game files or engine as a limitation, most likely in context to the capabilites of the then-current personal computer." More succinctly, anything that was done to allow the game to run acceptably on what was then a PC. This would include both the Soldier and 80-Item limits, the spawn limit(40 units per side), Smoke/Fire limit, and some of the others listed. (The Purchase limit was probably more of a convienence for the programmers than anything, but it is clearly an intended feature.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:11, 10 November 2008 (CST)

: I would add to this that sometimes a Limit may be imposed as a game design / gameplay decision, rather than in order to conserve a constrained resource in the platform (=PC). Also, I would suggest that ''intended'' Limits are Limits, but ''unintended'' consequences of Limits are Bugs. Obviously, making this distinction involves some guesswork. But I would guess that while the limit on total smoke/fire hexes was an intended Limit (to conserve PC resources), the ability to put out fires with smoke grenades and disperse smoke with IC rounds is probably an unintended consequence of the Limit, and so should probably be considered a Bug. Similarly, Base Defence spawn points are probably an intended limit, but the ability to flood spawn points is an unintended consequence of this, and thus a Bug (and an Exploit). (Spawn points should have been shared out 50/50, not humans-first). [[User:Spike|Spike]] 12:07, 11 November 2008 (CST)

::The limit on Soldier and Interception craft were probably more of a limit imposed because they capped the file and figured that X-COM wouldn't ever need more than 40 interception craft or 250 soldiers. (And I've never needed that many, case in point.)

::As for spawns, its actually difficult to take advantage of it in any reasonably established base. X-COM can spawn up to 40 soldiers in a base defense mission(tanks count as 4 soldiers), as a limit of LOC.DAT. Aliens have the same limit. So in order to take advantage of the bug, the base needs 40 or less spawns total. The Access Lift has 8 spawn points, General Stores(weapon-handling) has 11, Living Quarters has 8 more. This is 27 Spawns just getting soldiers in a base and armed. (Although the General Stores can be cut out if you perform the bug properly). Large Radar and HWD have 6 spawns(Small Radar has 2), and Hangar has 15. So overall, the "Spawn prevention" can be hard to take advantage of with all but the smallest bases. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:48, 11 November 2008 (CST)

Just to clarify, X-COM interception craft are not capped at 40 ships. LOC.DAT has a cap of 50 "things" on the geoscape screen at a time. This is shared between X-COM bases, X-COM ships, alien bases, seen or unseen UFO's, terror sites, crash sites, landing sites and waypoints. In a perfect game world with little alien activity and normally constructed bases, the max number of X-COM craft possible is 44: 5 bases with 8 hangars each plus one base with 4 hangars (or any combination thereof). If you illegally modify your base layout with an editor to get rid of the access lift, the max can be increased to 45 ships (9 hangars in 5 bases). Once clogged, all alien activity will cease.

The base defense limit of 40 units exists because of UNITPOS.DAT which has a cap of 80 entries total (tanks occupy 4 entries in this file). Auto-win missions in a base defense mission by clogging all the spawn points with X-COM units isn't as tough as it sounds, especially if your base is small or doesn't contain hangars. The main thing is getting your full quota of 40 units to spawn (meaning you should try not to have any tanks as they count as 4 units but only occupy one spawn point). This limits the base size to something like 5-6 modules depending on what you build. Still, even having more than 6 modules isn't bad as it forces aliens to spawn intermingled between your troops. With 40 armed guys staring in every direction, you can get positions of all the aliens in the first round and possibly even kill them all (depends on weapons and alien race of course). --[[User:Zombie|Zombie]] 20:12, 11 November 2008 (CST)

: I would say that Limits are the CAUSE of bugs... also, I feel that fire/smoke limit can be called a bug, because a player normally has no way to tell this, other than observation. Whereas the game DIRECTLY and CLEARLY informs you whenever you hit the 80 item or 250 soldier limits, which is more fair. [[User:Jasonred|Jasonred]] 15:22, 23 March 2009 (EDT)

Also IMHO it is not true that, say, 250-soldiers limit is a real game bug. In fact, it is not, it is just a rule of the game, or its limitation. And it is unimportant what its reason is (such or another way to store game data).

A bug is, by definition, an unexpected and involuntary result of programmers' work. However, we can only guess what the programmers wanted to attain, so this definition is both unpractical and impossible to be applied. It would be better to assume that a bug is a feature which has negative influence in the game. To clarify: the (un)famous 250-soldiers limitation does not harm in practice, as the number is really enough to play the game. But the even-more-unfamous 80-item limitation does harm and it has negative consequences - it is enough to recall the disappearing of bodies during some missions.

OK, there is no objective criteria to judge whether a feature of the game is a bug or just a limitation. But sometimes subjective criteria have to be enough. Otherwise, we would have to consider the 8-bases limit a bug. Does it make any sense? And if no, what is the difference between the 8-bases limit and the 250-soldiers limit? I feel neither is a bug. Because neither leads to further negative consequences.

And further, IMHO the buggy nature of some game features is quite obvious. If you cannot send more than 100 "parcels" of items at the same time, it is still not the bug. But if you must pay for an item you are trying to send but you cannot do it - it is a bug, perhaps everybody will agree. And similarly: the 255-scientists limitation is not a bug. But the strange behaviour of the game when you bought the 256th scientist is a bug. It would be just a limitation if the game did not allow to buy another scientist. But it allows while it cannot serve the 256th scientist properly, and that is why it is a bug.

So, I vote for removing the 250-soldiers limit from the bug list. If I am wrong in it, please add to the list also:
# 8-bases limit,
# maps with limited terrain (why should they be limited?),
# base area and base facilities limit (why wouldn't we be able to have 10 hangars in a base?),
# etc.

In yet other words, in my opinion it is not enough to show that the game does not allow to have more certain items or to do more certain actions. In order to count this among bugs, we should show that it really harms during playing the game, or just bears negative consequences.

[[User:Sherlock|Sherlock]] 03:52, 27 December 2012 (EST)

= Specific Bug Discussions =

== Misc Technical Bug ? ==

''(The context of this discussion seems to have been lost)''

This is a technical bug that doesn't happen to everyone and one this article wasn't really meant to chronical - but we won't turn away helping a fellow player if it can't be helped. It's just that there are so many random crash points in this game that it would take far too long to find them all or come up with solutions for them.

Certainly, the transfer crash can happen to some players, but it's not one that can be reproduced easily. It's just like the random crash that some players get when they research a floater medic. It crashes the game for some of us, but others don't seem to notice it at all.

It really depends on your hardware and OS setup, whether or not your copy of the game is damaged or your savegame is damaged, etc.

Does it happen in all games or just this one savegame?

- [[User:NKF|NKF]]

-----

== "Invisible Muton" bug ==

Upon shooting repeatedly a Muton, it sometimes plays its "death" animation without sound (as if falling unconscious) and it is no longer displayed in the screen, while remaining visible to my soldiers (I can center the screen and the cursor appears yellow over them). Under this state, they cannot be targeted by Stun Rods. They may play their death animation anytime they get shot, until they truly die, when they emit their characteristic sound and leave a corpse (along with any items carried).

I'm quite fond of laser weapons, maybe this happens more often with those.

Also, though I remember experiencing this quite often fighting Mutons, it may happen to any other high health race.--[[User:Trotsky|Trotsky]] 02:59, 2 July 2006 (PDT)

-----

Never seen that one myself. Another "unpatched game" thing maybe?

There's a (very rare) bug that allows your soldiers to live if they become stunned by an explosion that happens to kill them. Sometimes the game will register their death, and THEN register that they've been stunned. In every case I've seen this happen, however, the unit will have such a low amount of health that a single fatal wound will render it dead (again) on the next turn. I have a vague memory that other players may have been able to get a medkit to the scene on time...

I dunno if that's related to your issue at all (I doubt it, but... meh). I'd advise using a Mind Probe on the alien the next time it happens so you can check the aliens stun/health levels.

- [[User:Bomb_Bloke|Bomb Bloke]]

----

I'm pretty sure I've seen this with Mutons. Possibly Chrysallids as well, another high health, high armor creature. They were still readily killed by shooting the place they are. Good thought on the MP, BB

---[[User:MikeTheRed|MikeTheRed]] 08:51, 2 July 2006 (PDT)

----

I've been known to have a dying muton(in fire) to spin around and then switch to the female civilian death animation. With the scream and everything. Even got a civilian death registered at the end of the mission. And this didn't just happen once, but on another separate occasion.

Hmm. shape-shifting reptilians in the game! LOL! Happens alot [[User:EsTeR|EsTeR]]

Unusually enough, I once had a sectopod die and then drop a tank corpse. I was using the Lightning at the time for my troop carrier, so you can imagine my surprise.

Then there was one occasion where a floater dropped a snakeman corpse. Let's not even get into the sort of things the aliens like to stuff themselves with.

Your invisible alien bug is quite common, although there appears to be many causes for it. I think one involves a full object table when it comes to invisible aliens in bases. But it can also happen in ordinary missions as well. I'm guessing the game may have tried to do something in the wrong order, and sprite information for the unit may have been lost or corrupted along the way.

Having had an experience where all the chryssalids become invisible in one base defence mission was quite a shocker. I fixed this by saving the game, quitting and then restarting the game. If you ever get an invisible alien again, try this and see if it helps. If it doesn't, well, just keep a careful watch on your map and any alerts that pop up as you play.

There's a similar but less severe bug where a dead alien will still leave its centre-on-unit alert button, but this goes away shortly after you move or turn.

- [[User:NKF|NKF]]

----

That last bug happens when exploding Cyberdiscs kill nearby Sectoids, doesn't it?--[[User:Trotsky|Trotsky]] 23:56, 2 July 2006 (PDT)

----

This is a pretty easy one. I guess this bug occured on UFO recovery on a battleship, an alien base assault or a base defense mission? As soon as there are too many items on the map, the game saves some item slots for the equipment to be displayed (since it is more valuable and more important to research). This would also make stun weapons lethal if the stunned aliens would vanish. therefore the game has a failsafe if an alien is stunned (or badly wounded and becoming uncontious). The downed alien's stun level is set exactly on its left health points therefore resurrecting it instantly. This cycle is broken when the alien is finally killed. This means if you want to stun an alien in such a situation you have to destroy some items first.

- by tequilachef (April 4th 2007)

== Vanishing snakemen ==

I've known snakemen to become invisible when standing on a hay bale. On the first occassion I had a poor tank getting shot while spending numerous turns looking for it. On the second occasion I had an alien under Psi-control, left it on the hay bale, and couldn't find it next turn. - Egor

---

This is not limited to snakemen. Hay bale block visibility quite much when a unit is standing on it. Two possible solutions:
- Destroy the hay before entering
- Shoot at the hay. If it is destroyed any unit on it will become visible (as long as no other bales are blocking the line of sight). You might also hit the enemy directly.

I Dnt know if the aliens are affected by this diminished sight, too. My guess would be no.

- By tequilachef (April 4th, 2007)

== Blaster Bomb Bug ==

I'm currently playing through X-com UFO Defense, I have the collectors edition version. I'm in the process of trying to catch a live alien commander and the blaster bomb bug is making this very difficult. If i remember correctly a commander is always in the command center of the the alien bases. The problem is anytime i get close there is always a dude with a blaster launcher up there that tries to kill my troops. When they try to fire it down at me the bug kicks in and they blow up the whole command room and all the aliens in it because they can't figure out how to get the blaster bomb down the grav lift thing in there. This is making it very dificult to actually catch a live commander. Anyone have any ideas for tactics or anything to breach that room without the aliens trying to fire a blaster launcher up there? - eL Hector

: I can suggest two possible solutions. The first is to wait outside the command room for the alien to move closer to you. If it comes out of the room or if you know it has moved down the lift, you then burst in and stand right next to it to stop it from firing the blaster. This is risky because there could very well be a heavy plasma toting alien in there. The other is to use a small launcher and launch it up at the ceiling near where you think the alien with the blaster is standing. -[[User:NKF|NKF]]

== Disappearing Ammunition ==

I have observed that problem with X-COM 1.2, modded with XCOMUTIL. My stun bombs and heavy rocket missiles, along with clips for the auto cannon went missing.
[[User:Vagabond|Vagabond]]

------

Just run a test using my 1.4 DOS version with XComUtil but my stun bombs didn't disappear: 30 + 1 back in the base they came from, same number after I went tactical and I dusted-off immediately. Are you running XComUtil with Runxcom.bat or did you simply run Xcusetup?

[[User:Hobbes|Hobbes]] 22:12, 22 February 2007 (PST)

:Is it a case of hitting the 80-item limit?--[[User:Ethereal Cereal|Ethereal Cereal]] 12:28, 23 February 2007 (PST)

------
With runxcomw.bat, as everytime. Apologies, I retested and it seems like I was mistakened, but I could have sworn that I lost them dang stunbombs. Had to manufacture some. I will test some more, using four heavy weapons and seeing whether their ammunition disappears at all. Thanks. [[User:Vagabond|Vagabond]]

==MC at end = MIA?==

I am sure I have seen this again recently, where I won a mission with no casualties (I thought), but the last thing I killed was a Commander that had been chain MC'ing a psi-attack-magnet trooper, and that trooper was listed as MIA at the end (presumably because he was on the enemy side at the end of combat). Is this a bug, or is there another way to get MIA's on a completed mission that I might have missed?

Since then I have been waiting for the leaders to panic at the end before killing them (or waiting for a rare resist), so I can safely exit, but am I being overcautious?

--[[User:Sfnhltb|Sfnhltb]] 13:45, 27 February 2007 (PST)

If the trooper was mind controlled on the turn you killed the last alien it will be listed as MIA. No bug there :)

[[User:Hobbes|Hobbes]] 18:16, 1 March 2007 (PST)

Huh, why would that happen - your soldier should recover the very next round, why would he go MIA?

--[[User:Sfnhltb|Sfnhltb]] 18:20, 1 March 2007 (PST)

Doesn't make sense to me as well but that's how the game works.

[[User:Hobbes|Hobbes]] 15:05, 2 March 2007 (PST)

----

It seems that regaining control of units under enemy mind control works different for alien and human players. My guess: aliens under human MC are reverted to alien control AFTER THE ALIEN AND BEFORE THE HUMAN TURN while human units under alien control are reverted RIGHT AT THE BEGINNING OF THE HUMAN TURN. This explains three different phenomenons:

- The discussed MIA "bug" (he unit would be returned in the next human turn, but since it never starts it is lost. The mission is still won since no unit with a "genuine alien" marking is left)

- The fact that a mission is lost when the last human falls under MC while it is not won when this happens to the last standing alien (the aliens get their unit back before their turn starts and therefore have a unit left to pass the "anyone alive?" check, the humans would have no unit left to start a turn with. They WOULD have as soon as the turn starts, but no unit left before turn means bust)

- The fact that aliens still can see all an MCed human saw at the end of the human turn that follows the MC while this is not vice versa (The MCed human can give information to the alien side before reverted while an MCed alien is reverted too early). The result is that aliens can control a human indefinitely without having any alien seeing him until the MC is disrupted for one turn.

All confused? Then I did a good job! No seriously, this must be the explanation, I couldn't think of any other way.

- By tequilachef (April 4th, 2007)

: You're absolutely correct on the first two points. It's a sequence issue - you never get round to recovering the unit before the new turn starts, so you end without any units whatsoever. Makes senses too since the aliens would continue to continue to mind control that same unit over and over indefinitely.

: The third point however: The aliens don't need to know the location of the last MC'd unit. They know the location of all your troops whether they've seen them or not from the very start. They appear to give you a few turns of grace where they won't attack you outright (unless, from my observation, all your soldiers are incredibly weak). This is evident because all of the aliens will eventually make their way towards the nearest soldier even though their movement pattern may seem semi-random. Also, they know where you are because they can initiate psionic attacks without having seen any of your troops. They generally go after the weakest troops first.

: Just to add a semi-related point, but from the alien's perspective. If an MC'd alien unit is in the exits when you abort the mission, this alien is not recovered and in fact simply vanishes. Any equipment it was carrying is recovered, unknown artefacts or otherwise. You could possibly think of this as their version of MIA. However, the aliens differ ever so slightly in that if it's the last alien standing and under temporary mind control by the player, the mission doesn't end straight away. But I guess this is only because the player has everything under control, whereas in the other scenario, the Ai is in control.

: -[[User:NKF|NKF]]

My observations show that, at least in some versions of the game (tested with clean DOS 1.4 version, under DOSBox), the game crashes at the end of the human turn if all alien units which are still alive, are Mind-Controlled. If it was confirmed, it would be another not-listed-yet (serious) bug.

[[User:Sherlock|Sherlock]] 17:52, 26 December 2012 (EST)

== Crash Site in the atlantic ocean ==

That's right, my game generated a crash site on water. Here are the details:

- Crash Site a bit southeast of the USA (which was infiltrated a few days before by sectoids, resulting base had already been taken out), but certainly not on land.

- UFO: battleship, floater, alien harvest

- Geoscape: 8 X-Com Bases, 1 (known) Alien base, 2 other crash sites, 1 other (known) flying UFO (though almost worldwide decoder coverage), 3 X-Com Crafts out, 1 waypoint

- Date: January 2000

- Most Interesting: The Craft that downed the ship was a recently finished Firestorm (first human-alien hybrid craft I had built, I know this is lame for that date. Limited myself on 25 Scientists to improve the challenge) equipped with twin plasma. I had it built and equipped in Antarctica and then transferred to Europe. This base had no Elerium, a fact that enabled me to use the infinite fuel exploit which was in effect when downing the UFO. My craft was only slightly damaged when doing so. The battleship was the first target assigned to the craft, it came directly from my base.

- When shot down, the UFO was not targetted by any other craft.

- I had not lost or sold a single craft to that point.

- When sending a squad to the crash site the game didn't crash but generated a farm land ground combat terrain.

- I was not able to reproduce the bug from the savegame dated 2 hours before downing the UFO

Well guys, any intelligent guesses? I still have the savegames (before and after downing)! If you want to have a look, write here.

- By tequilachef (April 5th 2007)
----
: Well I'm sure you know about crash sites that are near land can sometimes actually be on water, so I'm going to assume that this site is well far away from any land mass. Could it be a weird entry in GEODATA\WORLD.DAT that has a land mass out in the ocean? Also are you sure the game didn't crash? Sometimes when it does it will load the previous mission (and usually 90% are at farm terrain). Are you sure it generated a new map and not load the last one?
:No real guesses but maybe some starting points to look at. I've probably stated some obvious situations you know about and have accounted for, but it never hurts to double check :D
- [[User:Pi Masta|Pi Masta]] 14:23, 5 April 2007 (PDT)

== Inconsistencies in MCing Cyberdiscs and Sectopods ==

I experienced, that when MCing one quadrant of a large terror unit any action it does only affects this quadrant (especially use of time units). That means, when TUs are up for one part, MC another one and continue firing. This however does not work out when moving the unit while it is not under complete control. The TUs used up by the resulting reaction fire from the rest of the unit is also deducted from the TUs "your" part has left (making it impossible for the controlled parts to return fire). This however only happens under reaction fire, not if "your" part fires on it's own. I don't know if this comes up when uncontrolled parts shoot by themselves in the alien turn, since this is hard to find out.

: That's because large units literally are made up of four separate units. They only share the same set of general stats (in unitref.dat). Unfortunately the 'under mind control flag' is unique to the four units, not the shared stats! So you in effect have multiple units under different control sharing the same stats. So if you move and it results in a reaction from the unit, it will spend the TUs you're using.
: Successful mind control automatically fills up the unit's TUs, so each mind controlled sector gets to move or attack again until there are no more sectors to mind control. Useful way of turning reapers into long range scouts!
: In TFTD, they attempted to fix this bug, but in fact made it much-much worse! The only way to mind control the unit properly is to control the upper left quadrant. Only! Any other quadrant will result in a partial (clockwise) control, and you may gain control of units other than that unit, or may even get into situations where you gain permanent 'partial control' of a large unit you haven't even sited. Wackiness all around!

:- [[User:NKF|NKF]]

== Facility Dismantle Bug ==

Boba: I've never experienced this bug myself in all my games in the Collectors Edition. It may very well vary from computer to computer.

-[[User:NKF|NKF]]
:I, however, have experienced it. I lost an entire month's worth of playtime because I couldn't solve it. [[User:Arrow Quivershaft|Arrow Quivershaft]]

::Anyone, any ideas on why it might vary from PC to PC? -[[User:MikeTheRed|MikeTheRed]]

:::I'd check other factors before blaming a given system. Assuming no mods are being used the most obvious is the order in which you initiated the construction of the modules. Then we've got which one was due to be completed first, and I'm sure there's a few other things to test out. Usually, a player won't cancel in-progress modules on a regular basis, so you wouldn't expect this bug to turn up often. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

:Easy way to reproduce: build 2 General Stores. Now delete the "second one" (see offset 16-39 in [[BASE.DAT]] for the order). Wait for the first one to complete. It'll crash immediately after the "end of construction" dialog. A fix is available [[User:Seb76#Bug_Fixes | here]]. [[User:Seb76|Seb76]] 15:52, 22 July 2008 (PDT)

== Manufacturing Limit Bug ==

Unfortunately, Mike, no you did not get it correct. It is the raw number of hours needed to complete the project, not the projected hours. I discussed this on the X-Com Forums a few months back at the following link: http://www.xcomufo.com/forums/index.php?showtopic=242027760&st=0&#entry164411

I did tests at the time in regard to the accuracy of the data given there, but I've lost the results. I'll quickly redo the tests in the next hour or so. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:00, 8 June 2007 (PDT)

:Tests complete. The breakpoints for every item were exactly where I predicted, regardless of number of engineers assigned. (I ran up a huge queue of items at my dedicated factory base on an old game, and then assigned whatever engineers would fit onto one project at a time, canceling projects as data was confirmed. This is only semi-random, but it serves our purposes.) I did run into a single issue, though. It appears that despite having 5 empty hangars at a (different!) base, the workshop there could not queue up more than 3 of any one craft at a time, thus making this bug impossible to replicate with the Firestorm or Lightning, as you must be producing more than three for the bug to occur. However, it still works with the Avenger. Later, I shall see about constructing a dedicated Hangar base with 7 hangars in order to attempt to replicate the bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:33, 8 June 2007 (PDT)

::Sounds great, Arrow. Why not post a simple example that shows how the problem works. As in, "with 1 Eng and 2 Avengers you might think X, but no, it's Y". And please delete my example. And it's a fine pleasure to meet you! Cool - [[User:MikeTheRed|MikeTheRed]]

:::When you say the usual resources are used by the "lost" resources, that includes cash, right? It sounds like if you're willing to foot the extra bill [[Buying/Selling/Transferring#Manufacturable_Prices|money/component-wise]], this could be used to build Avengers slightly faster then normal.

::: The usual time is 34000 hours. Double that and subtract 65535 and you're left with a paltry 2465 hours. Even a single workshop squad of 10 engineers will pull that off in a little over ten days. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

::::Sadly, this exploit doesn't work, because the high bit is stored SOMEWHERE. I lack a hex reader and have no code reading skills to speak of, so I'm a bit limited here. If you set up a Workshop as you described, the game would take all the time for 2 Avengers, all the resources for the same, but in the end only produce 1 Avenger. Meanwhile, I'll run more tests on the resources thing. I could swear it consumes the resources, but I'll double check.

:::::There is no need to store the high bits if the actual completion condition (assuming adequate money) is "number made is number ordered", which wouldn't reference the hours remaining at all. - [[User:Zaimoni|Zaimoni]] 01:49, 9 Oct 2007 (CDT)

::::Tests done; I was unable to replicate the 'disappearing item' trick,(Which I didn't test for last night) even with Avengers! It appears I was wrong; this still counts as a bug, though, because the wraparound is a problem.

::::Ironic that so much of this discussion centers around Avengers, because that's where I discovered this in the first place! [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:48, 9 June 2007 (PDT)

----

I'm revisiting XCOM and was working on [[Manufacturing Profitability]]... Arrow, can you (or anyone else) say a little bit more on the Known Bugs page about this [[Known_Bugs#Manufacturing_Limit_Bug]]? It's not clear to me exactly what the bug does, except that it understates hours. Is that all?... does it still take the (non-buggy) amount of time, still use all the same resources, still make the same number, etc.? It sounds like it could be a drastic bug - or is it only a very superficial one, a display bug for the hours? It sounds like you're leaning toward this latter.

Also on a semi-related note... I could swear I saw much more detailed info on the [[Known_Bugs#Facility_Maintenance_Costs]] issue... IIRC, the incorrect amount that's charged for maintenance, depends on exactly where a facility is in the base. IOW, different "rows" of the base cost different amounts. Could somebody provide a link there, and/or flesh the bug out better?

Thanks! - [[User:MikeTheRed|MikeTheRed]] 11:22, 8 October 2007 (PDT)

:I've actually seen the bug work both ways, but I've only been able to actually replicate the more superficial version of the bug. So the bug report up is about a superficial bug that drastically understates production time. If you wish to make this clearer, you have my blessings. As well, that 'different charging based on location' is dealt with here: http://ufopaedia.org/index.php?title=Talk:Base_Facilities ; however, the table has been broken with the Wikiupgrade, and I lack sufficient knowledge of HTML table code to fix it. But it should be of use to you. [[User:Arrow Quivershaft|Arrow Quivershaft]] 11:26, 8 October 2007 (PDT)

::Cool, I fixed [[Talk:Base Facilities]] but also re-organized and expanded [[Base Facilities]] so that it includes that bug in detail, as per Talk... this is an important issue that should be up front. I see that there's a separate [[Maintenance costs]] page, but I can't see having something so important (the maintenance bug explanation) all on its own page (which makes for a rather short page) rather than together with all the rest of the base facility info. If others agree (or don't care), I'll move anything remaining on Maintenance Costs to the Base Facilities page, then delete Maintenance Costs and re-route links. And if somebody does care, then please move my new section to Maintenance Costs, and move all the links, etc. Oh also I put in more words on your Manufacturing Limit Bug - how does it look? - [[User:MikeTheRed|MikeTheRed]] 16:37, 8 October 2007 (PDT)

:Looks pretty good, although it'll wrap fully; if you ask for 120000 hours, it won't be displaying 'almost no' time. The way I discovered it was when building two Avengers; I ordered two, paid for two, waited for two...and got one. But as said, haven't managed to repeat it, so until I do, we'll leave it like that. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:00, 8 October 2007 (PDT)

::I just revised and put in your specific example, because it's certainly possible some of us die-hard players will order up more than 1 Avenger at a time - and it's guaranteed it'd be a pain if 1 of them disappeared, laugh. I wasn't sure how concrete you were on that example but now I hear you say, you are sure it happened at least once. - [[User:MikeTheRed|MikeTheRed]] 18:33, 8 October 2007 (PDT)

:I have a question concerning the manufacturing "bug" which eats a craft in production due to wrap-over of the byte. Arrow (or whoever did the test), did you have a large quantity of craft already built at your bases? If so, I think this bug has more to deal with clogging up [[CRAFT.DAT]]. See, that file has a limit of 50 entries. Each craft takes up one record and each base you have built also consumes one spot. 8 bases allows 42 craft to be housed, while 6 bases allow 44. If you try to buy or manufacture craft once the file is full, nothing shows up in the game even if you have hangar space available. --[[User:Zombie|Zombie]] 19:00, 8 October 2007 (PDT)

::Huh, I never knew that. I don't see it listed on the Bugs page... I'll stick it in there. I've never approached that number, but some folks might. - [[User:MikeTheRed|MikeTheRed]] 19:07, 8 October 2007 (PDT)

:I was able to continue building other Avengers after that project, and they appeared correctly, so I do not believe that is the issue. In any event, I have a very bad case of 'archivism' and probably still have the save game and the CRAFT.DAT file around on my system; in fact, I think I was playing it a few days ago. I can see if I can find it and upload it; it created a 'hole' in the Avenger fleet numbers, where Avenger's x and x+2 were built, but x+1 was not. I'll look for it tonight and tomorrow and upload it to the wiki if I find it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:10, 8 October 2007 (PDT) EDIT: I found the file; I have 28 Avengers and 1 Skyranger in my employ. All Avenger numbers EXCEPT #2(Avenger-2) are accounted for, and I have not sacked or lost any Avengers. So this is where the hole and 'eaten' Avenger is. If anyone wants the CRAFT.DAT file from this game, I'd be happy to forward it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:20, 8 October 2007 (PDT)

::Sure, send it my way and I'll take a look at it. (Might as well send me the whole saved game as I may want to look at the other files too). I have tried to recreate this bug by manufacturing 1, 2 and 3 Avengers at a clip but all of them always show up. Don't know what else I could do to get this problem to crop up. --[[User:Zombie|Zombie]] 21:32, 8 October 2007 (PDT)

:File emailed. On the side, I've tried the same thing, and never been able to repeat the bug. It's been months since the first discovery, so I can't recall whether it was the first or the second Avenger that didn't appear. So maybe it was just a fluke. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:57, 8 October 2007 (PDT)

== Unconscious Enemy in Equipment Screen ==

The following happened to me repeatedly over the last few days.

In the last tactical Mission a live alien has been captured. When now beginning an UFO crash recovery mission this type of alien (same race and rank) appears in the equipment screen before the mission starts, meaning I can give it to any of my soldiers.
If I do so I can store the alien in the skyranger for the duration of the mission and, if it gains consciousness, kill or stun it at the end of it. A pile of equipment without a corpse will be in the UFO, indicating that the stunned alien is not some kind of duplicate but instead has been taken from the aliens of this mission. This is supported by the fact that in those missions the maximum number of crew members has not been surpassed.
If I do not do so the Alien will be placed in the crashed UFO. Whether it is unconscious or not I do not know, but the fact that it is completely disarmed when encountered in the battle suggests that it is.

So far it seems the following is necessary for the bug to occur:
# An alien has to be captured alive in the last tactical combat
# It has to be of the same race and rank as one of the aliens in the new tactical combat

So far this only worked...:
# If the new tactical combat was an UFO crash recovery of a medium scout.
# For floaters and mutons
# For soldiers and navigators
# If the alien in the last mission was stunned by normal weapon fire (although I do not think this is important) and not picked up (again, not likely to be important) or destroyed (which would mean it has to be actually captured)

It seems NOT to depend on the following:
# The type of the last mission (were, so far: Ground assault battleship, crash recovery large scout, base defense)
# Which squad or vessel was involved capturing the alien
# Where it is locked up
# If it has been transferred since capture or not

Would be interesting to know:
# What happens if the alien in the inventory screen is the only survivor
# If the alien in the invenory screen is one of the aliens randomly killed in the crash or not (it is likely to be one of the killed aliens, so far the equipment piles were always within the UFO)
# If this is not limited on crashed medium scouts: Does this work with terror units? What about large ones?

Maybe this is related to the proximity grenade bug (transfer of item properties to next tactical combat).

Additionally, in one of those mission a part of the terrain was not generated correctly. It was in farm terrain (The house on the right square, or north east square, in [[Image:Terrain-cult.gif|this pic]]). The outer wall right to the right window of the southern wall (1st Floor) was missing. Directly outside of the hole was a floor tile. I could walk a soldier through the wall, but he fell right through the tile. Dunno if this has to do with the stunned alien bug.

Version is collectors edition (the one from abandonia.com).

----------------

When a mission starts, the GeoScape engine generates the unit and object tables (in MissDat's [[OBPOSREF.DAT]], [[UNIPOS.DAT]], and [[UNIREF.DAT]]) before "shutting down". The Tactical engine then generates the maps, places the aliens on it, and blows up the UFO (if need be). Whether or not map generation and the subsequent events happen before you equip your soldiers I don't yet know.

The test would be to check the aforementioned files to see if they contain an unconcious alien, and/or the body.

Note that you can't see the bodies of large units on the ground (they count as four seperate objects covering four seperate tiles, so allowing the user to pick one up would essentially let you rip them apart).

- [[User:Bomb Bloke|Bomb Bloke]] 06:35, 5 August 2007 (PDT)

----------------

I honestly have no idea of how all those files work. But I still have a savegame in battlescape that is in one of those missions. So if anyone wants to have a look at those files...

I forgot to mention: I reloaded a geoscape savegame shortly before the battle to recreate the bug, but it seems that reloading in geoscape before the buggy battle eliminates the bug. I guess his should narrow down the possible reasons...

--------

Next time it happens, backup the aforementioned files before you start another mission. I'm afraid a savegame wouldn't be of much help.

- [[User:Bomb Bloke|Bomb Bloke]] 00:54, 7 August 2007 (PDT)

== Soldiers moved to outside of combat screen ==

Hi, I've got a DOS version of UFO:EU, and I've encountered a bug in the tactical combat. Sometimes (rarely) a X-COM soldier changes its location on the map on player's turn start and is placed on outside of the map, one tile north from the (north) border of the field. AFAIR the unit is then selectable (you get the flashing highlight when cursor is above), but is stuck outside of the field. Has anybody encountered this bug? It seems to happen randomly, but more frequently during the terror missions and on early turns (so maybe it's caused by high number of player/alien/civilian units?). --[[User:Maquina|Maquina]] 08:16, 3 September 2007 (PDT)

:I've never encountered this bug in CE of UFO. Presuming AFAIR means "As Far As I Recall," what exactly was the soldier doing? Any equipment data, location, or stat info might help us pin it down. Were afflicted soldiers always carrying a specific equipment set or weapon? Where were they on the map before they got moved? Did they get bumped a few spaces, or teleported halfway across the Battlescape? Does it happen more often on a specific difficulty?(Your theory would suggest this would happen most commonly on Superhuman) Against a certain type of alien? Best of all, if you can recreate the situation in a game, save the game and then you could upload the save file to the forums or this wiki, and the rest of us could take a look for ourselves and the code divers could root around for the cause. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:03, 3 September 2007 (PDT)

:: I've had this happen to me several times in UFO and TFTD. I don't know if it's specific to the Dos version or if it can happen in the CE as well. Sometimes the soldier ends up beyond the boundary of the map right at the start of the mission, at other times it happens after you load a game. This game is glitchy, which is the source for so many of its bugs, so your soldier's coordinates are probably getting corrupted to the point where they are -1 on either the X or Y axis of the maps's normal boundaries. For me it's commonly along the top edge of the map. I don't ever recall it happening mid-mission, only at the start or after a load. I cannot faithfully say whether it happened with or without XComutil, but that could be one of the possibly many causes for this. - [[User:NKF|NKF]]

:: I don't play UFO often, so I rely on just several campaigns played. This happens rarely (I've encountered this bug twice in my last campaign with ~80 missions played), but if you haven't seen this happen then it probably doesn't show up in the CE edition. In my experience the soldier is moved always beyond the north/top map border. I think (but I'm not sure) that this affects the first soldier from the team more commonly than others (or maybe even exclusevily?). The equipment/armor carried is probably not relevant, since the units moved this way don't have any special stuff, and this bug shows up on different stages of the gameplay (ie. sometimes when you have ordinary rifles, sometimes when all your units got heavy plasmas and power suits). --[[User:Maquina|Maquina]] 04:12, 4 September 2007 (PDT)

'''MY ramblings have been moved to my discussion page''' [[User:EsTeR|EsTeR]]

==Great Circle Route==

Should we have the Great Circle Route bug noted on this page at all? [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:33, 6 October 2007 (PDT)

: what is the great circle route? [[User:Jasonred|Jasonred]] 07:56, 31 March 2009 (EDT)

:: Pick two points on a globe, then hold a thread or string taut at those two points. That practically minimizes the length of the thread/string on the globe. You're now looking at a great circle arc (or route), the shortest distance between two points on a globe. -- [[User:Zaimoni|Zaimoni]] 11:15 March 2009 (CDT)

: Just as a line is the shortest distance between 2 points on a flat plane, a great circle is the shortest distance between 2 points on the surface of a sphere. The bug, by the way, is that aircraft in the game ''don't'' follow this shortest, "great circle" route. [[User:Spike|Spike]] 12:38, 31 March 2009 (EDT)

:: What a grand sounding name, for something so simple, lol. ... I thought you were talking about when you tell your soldiers to go from point A to point B, and for some reason they figure that Zone A and Zone B are really far apart, despite actually being side by side. (I shot a hole through a wall, clicked to walk to the other side, and my idiot soldier walked one big circle... to use the door! And got ambushed and killed by an alien. ... dum dum DUMB DUMB.)
:: Even the more modern games have problems with their pathfinding algorythms. Admittedly, games like Baldur's Gate had to do it in realtime.
:: On a semi-related note, I remember this guy called E-man, he was chasing a guided laser beam that was going to kill his girl, around the world, but he couldn't outrun it since he couldn't break the speed of light, only equal it by changing into a Laser himself. So... inspiration! He turned into a very powerful laser, and made a shortcut THROUGH THE EARTH... the straight line beats the great circle route, lol.
:: Thanks for the reply guys [[User:Jasonred|Jasonred]] 15:56, 31 March 2009 (EDT)

Added to article. [[User:Spike|Spike]] 16:41, 3 September 2012 (EDT)

==Bug not listed: Missing soldiers during base defense==

I encountered an interesting bug concerning base defense missions:
My base got attacked while about 30 soldiers and 10 HWPs were present. The usual equipment assignment screen was skipped and the mission started instantly with only the HWPs spawned at the map. Not even a single soldier bothered to show up... *sigh*
Although this turned out to be in my favor (you should have seen the puzzled Ethereals trying to panic my tanks) I´d like to avoid this bug if possible. I was able to reproduce this bug several times and with different bases.
Can anyone explain this bug and/or tell me how to avoid it?

Game version: Collectors edition. - [[User:NewJoker|NewJoker]]

-----

Well, ideally, we need to know what your base's construction was to be sure of this, but I think the most likely circumstance is that the HWPs took up all the spawn points. HWPs have maximum priority for spawning(followed by Soldiers, and then Aliens), so if you have enough of them garrisoning a base, it's entirely possible that soldiers and aliens won't spawn. However, this doesn't explain why the soldiers didn't start stealing the Alien spawn points...in any event, you might want to take the save game file, zip it up, and get ready to email it. I'm sure [[User:Zombie|Zombie]] would be quite interested. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:28, 13 November 2007 (PST)

-----

It's not the spawn points, it's a [[UNITPOS.DAT]] limitation. A maximum of forty records (out of the total of eighty) are allocated for your units, and tanks (which take up four records each) get first pick. Having ten tanks means there's no room left for anything else.

Ditch one HWP and you should see four units take it's place. - [[User:Bomb Bloke|Bomb Bloke]] 16:42, 13 November 2007 (PST)

-----

I´ll try with a decreasing number of tanks and report the results. As I wrote above having only HWPs isn´t too bad dependent on what enemy is attacking. [[User:NewJoker|NewJoker]]

----

This should be mentioned in the [[ExploitsE#Base Defence Mission Spawning Issues]] section. The Bugs/Exploits really need to be sorted and consolidated. - [[User:NinthRank|NinthRank]] 16:57, 13 November 2007 (PST)

-----

The limitation to 40 records seems to be the case; each tank I dumped got replaced by four soldiers.
So this can be used to effectively manage unit combination. Thanks for the quick replies! [[User:NewJoker|NewJoker]]

==Bug not listed: Ufo Gold (Windows Vers. abandonia.com) crashing when plasma defense is finished==

I recordnized this bug a few times now. (with hacked AND unhacked game)
If i place a plasma defense in 7 bases at the same Time and they are finished at the same Time, the game crashes sometimes.
In hacked game, it seems to crash even more when Alien containment is finished, plasma defense, shield defense...etc.
couldnt find it here...greetz

: I somehow doubt the sourcing is the issue. [You may want to fund the next XCOM series game with a Take2 re-release of UFO :)] More generally: the game only reports the construction of a given type of facility once, no matter how many bases it completes at simultaneously. I've only tested this in vivo with three-of-a-kind at once across six bases, however. It does seem reasonable that some sort of counter of undisplayed completions would "overflow" (attaining crash). -- [[User:Zaimoni|Zaimoni]] 10:05, Feb. 28 2008 CST

::I've encountered this bug myself with General Stores, actually, not just Plasma Defense(which I never build). EDIT: Some quick tests seem to show that there's a chance the game will crash any time two base facilities are done at the same time, regardless of whether they're in the same base or not or if they're the same facility.(although it seems to happen MUCH more in the event they're in different bases.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:13, 28 February 2008 (PST)

== Soldier Recruiting Bugs Tested ==

Just to note that I have positively tested and replicated the bugs listed under the new(ish) section [[Known Bugs#Soldier Recruiting Bugs|Soldier Recruiting Bugs]]. [[User:Spike|Spike]] 18:08, 19 March 2008 (PDT)

==Floater Medic Bug==

I have not thus far encountered the Floater Medic Bug; in fact, Floater Medics are often used to fill up my Rogue Gallery with interrogations. [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:50, 24 April 2008 (PDT)

Strange, it would always occur in my version. I don't remember where I got it from, but I
know it was a download from the internet. Using the XCom Hack v2.5, I viewed the alien in
the Alien Containment edit. I now have Type (race):____, and a Rank: Soldier for the
Floater Medic. It might just be corruption, but I do not have the resources to look into
it. [[User:Muton commander|Muton commander]] 19:24, 12 May 2008 (Pacific Time Zone)

I've never encountered it either. [[User:Magic9mushroom|Magic9mushroom]] 07:47, 23 July 2009 (EDT)

I think this only happens in the CE version. A disassembly of the code reveals that the stack to hold the matrix for what topics have not yet been researched is too short. It seems that those who ported the code from DOS doubled the local variable sizes blindly. There is already a problem that there are two-few bytes necessary for the entire alien organism section of the UFOpaedia, but double the expected size of the registers and it fills up quite easily unless a lot of autopsies and interrorgations have already been done. The only other situations that are handled by the same routine are the navigator revealing mission data or engineers revealing ship data, but there isn't enough topics in either section to overflow the stack variables. - [[User:Morgan525|Tycho]] 08:27, 22 June 2013 (EDT)

==Strength Overflow==

During one of my games with TFTD I noticed a really annoying thing happen during battles.
As my troops rose up the 'stat.' ladder they got better and better (as you'd expect), until they hit about 50 strentgh and completely lost the ability to throw anything.
Even trying to throw something tiny like a grenade or flare into the adjacent tile resulted in the 'Out of Range' message being displayed.

Anyone come across this before?
This was in TFTD CE.
[[User:Tifi|Tifi]] 07:55, 27 April 2008 (PDT)

:This is fairly well documented. The pathfinding algorithm for throwing objects will balk if anything is in the way of the throw and refuse to allow you to throw. What's happening is that your soldiers have become so strong that their throws are intercepting the 'ceiling' of the Battlescape(the top of L3), and as such the game thinks that the throw is blocked(because in order for the throw to complete, the object would have to be tossed up to the nonexistant L4). There's two ways around this:

:The Normal Way: Try shorter throws, throwing from lower heights, or throwing while kneeling. Beyond that, possibly get some new troops.

:The Sneaky Way: Manually edit the Strength scores of your soldiers in [[SOLDIER.DAT]] so that they're back to a usable strength level. If you set "Initial Strength" (offset 46 decimal or 2E hex) to 0 and "Strength Improvement" (offset 57 decimal or 39 hex) to a value of 50, you can permanently lock the soldiers at 50 strength. (You can lock them higher than that if you so choose, but not lower.

:Other than this, there's no workarounds I can think of offhand. [[User:Arrow Quivershaft|Arrow Quivershaft]] 08:10, 27 April 2008 (PDT)

:: There's normally no problem with the max level of 70 in open settings. However TFTD has a lot of low ceilings such as in the shipping lane missions and colonies, and the lower ceilings impairs your throwing quite a bit. In addition to shorter throws/kneeling, try moving out from under any overhangs if there is one just above you. - [[User:NKF|NKF]] 12:33, 27 April 2008 (PDT)

== Bug not listed: Sticking your head through the ceiling ==
This is something I just discovered: When you step on a small object inside of a building your soldier sticks his/her head through the ceiling and can see what's upstairs. You can even see the soldiers head coming out of the floor and that soldiers can shoot aliens upstairs. When I did this the alien I saw/shot was facing the other way, but I guess you could get shot if the alien was facing you. [[User:RedNifre|RedNifre]] 17:34, 11 May 2008 (PDT)

:That's not listed under "Bugs" because it's covered under "Exploits", right here: [[Exploiting_Collison_Detection#See_Through_A_Ceiling]] [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:26, 11 May 2008 (PDT)

:: I don't know if it was ever covered anywhere, but there's this neat trick that might sound similar to the walk-through-'wall object'-wall trick except that it involves your unit climbing slopes. They'll appear as though they've gone up a level, but are actually not on that level. They only visually appear to be there, but are really still on the bottom level.

:: It happens a lot when walking up the desert or forest slopes. I think the trick involves standing on ground level, and then ordering the unit to 'move' into the hill rather than setting the waypoint while on level 1. The soldier will move up the slope and perhaps stop on the slope or even reach the top of the slope, but will still appear when you're only viewing the ground map layer. The soldier is really still on the ground level, but will have elevation offset.

:: One really interesting way of using this trick is in the mountain region. If you can find a cliff face and a low hill nearby, you can literally have your soldier scale the cliff by standing the soldier on the hill, and then walking towards the cliff. It's ridiculous, but your soldier never quite reaches the top of the cliff tiles, so ends up walking up a slope.

:: On a side note, standing at the top of the ramp of the Skyranger is the same as standing on ground level - you're only offset a bit. This means that smoke on level 1 and the sides of the Skyranger will not provide protection when you're at the top of the ramp.

:: On another related note in relation: In TFTD (doesn't happen a lot in UFO), you might find it difficult to toss grenades onto underwater slopes. To remedy this, raise the level up by one. It might look like you're tossing at air(and you are), but it'll get the grenade where you want it. Odd, but true. I must remember to put this in the grenade explanation section. -[[User:NKF|NKF]] 23:11, 11 May 2008 (PDT)

== Base Defence bug that causes a crash? ==

Does anyone know about a bug in a base defence mission that causes the game to crash? The game keeps crashing on the 4th or 5th alien turn.

:I've encountered that myself, but it should be noted that overall, X-COM is not the most stable game and is prone to crashing often at anytime. The differences between the hardware it was designed for and the hardware we're running it on cannot be helping matters at all; it's really a small miracle it even runs without an emulator in the first place(I've got games from 1999 that will bluescreen my machine instantly). As such, I'm not sure it's worth noting as a bug, since it's a 'game feature'(albeit a detrimental one). In any case, what're you doing letting the aliens attack you anyways? ;) [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:33, 18 July 2008 (PDT)

:It sounds like an alien is in one of the outlying locations and attempting to destroy the top floor item. Possibly a radar or defense station. - [[User:Morgan525|Tycho]]

== Sources for a DOS4GW transplant ==

I was specifically thinking of the LucasArts Dark Forces demo, but I half-recall the actual source I used when testing that ~1999 was Id's DOOM. -- [[User:Zaimoni|Zaimoni]] 16:03, 7 August 2008 (CDT)

== Phantom Carried Casualty ==

You are carrying an unconscious soldier in one hand, and the soldier dies of his/her wounds. The dead soldier remains visible on the "left hand / right hand object" battlescape display, but is no longer visible in the inventory display. The problem can be fixed by moving another object into the same hand.

I've seen this bug with UFO Extender by [[User:Seb76|Seb76]] - possibly might be something to do with his manipulation of the inventory screen, rather than a general bug. I believe I've also seen this with other objects that were being carried in the hands, disappearing from the Inventory screen, but I'm not sure. I don't think it's an item limit bug, as XcomUtil shows 40 item slots free. [[User:Spike|Spike]] 08:58, 21 September 2008 (PDT)

:I think it has to do with the KO units KIA mod. Its doesn't take into account units held so when it tries to detemine where to place the corpse, there is no location. The routine doesn't undo the item-carried-sprite-ID byte for the holder. -[[User:Morgan525|Tycho]]

== Civilians As Enemies to MC'd Aliens ==

I ran across this issue a few times and just wondered if you guys experienced this. I MC'd a part of a Reaper (I always do the lower left for large aliens) on a Terror Site, then moved it a few squares. It suddenly stopped dead in it's tracks and then the alien spotted indicator increased by 1. When I clicked on the indicator to see where the enemy unit was, it brought me to L2 of the large apartment complex. However, nothing was there. When I sent a Flying-Suited soldier up there to peek in the window (eeek! A peeping tom!) he saw a female civilian standing there. This type of problem has happened numerous times to me so it's not a once-off thing. Maybe it's a LOS issue? Or maybe an alien indicator problem? Or a combination of the two? Don't know, but I'm curious if you guys have seen it. --[[User:Zombie|Zombie]] 23:40, 19 December 2008 (CST)

:There are a lot of major issues with MC'ing 4 square aliens. One of them being that you could accidentally MC an alien far off in the corner of the map, IIRC? Anyhow, maybe you should have tried MC'ing all 4 squares of the reaper and see if that changed things. -[[User:Jasonred|Jasonred]]

The long-range MC of other aliens when Mind-Controlling large aliens is only present in Terror From The Deep, due to a workaround to try and resolve the earlier bugs(and exploits) associated with controlling one square of a large unit at the time. In TFTD, successfully MC'ing part of a Large unit will also grant you control of the next three units in UNITPOS.DAT, in order. If you didn't MC the upper left portion of the large unit(the first UNITPOS entry for any large unit), you can potentially wind up in control of other aliens. So this doesn't apply to UFO. As for Zombie's issue, never seen it. And finally...Jasonred, on Talk pages, please indent your statement with colons so it differentiates from other people's comments, and sign your posts with 4 ~'s, like I will now do. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==Elerium Base Bug==

Jasonred: This bug has long since been known about. Elerium units on the Battlescape can be picked up by shooting away the power source; this one item counts as 50 units, and as such ANY elerium item spawned on any Battlescape counts as 50 Elerium. This issue with your own Elerium spawning as collectable loot in a Base Defense mission only occurs in older DOS versions, and is at the whim of the 80 item limit. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:55, 18 February 2009 (CST)

:Base defense does not seem to follow the 80 item limit in that DOS version. There are a lot of bugs that have long been known about. However this one was not included in the ufopedia for some reason.
:Also, the main thing about this bug is that it does not potentially double your elerium stores. It potentially multiplies them 50 times.
:... First time this happened to me, I was pretty flabbergasted. Here I was being conservative with my limited Elerium, refraining from blowing up UFOs when possible, when I perform a base defense and gain 3000 Elerium from it. Holy spit. -[[User:Jasonred|Jasonred]]

Alright, my error. Thanks for clarifying. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==HWP Fusion Bomb and SWS PWT Displacer Ammo Manufacturing Cost Bug==

At a cost of $15000, 400 Tech hours, 5 Zrbite, and 8 Aqua Plastics, this is the exact same cost as the HWP Fusion Bomb from X-COM EU, converted over to the equivalent TFTD resources. As such, it shouldn't be counted as a bug, since it is clearly what Mythos intended. [[User:Arrow Quivershaft|Arrow Quivershaft]] 09:55, 15 November 2008 (CST)

:Hmm, in that case maybe it should be treated as a generic game engine issue and not a TFTD specific issue - but I still think it's a design error. Can you think of any logical reason why the SWS/HWP version of the ammo should be more expensive (in cost and in materials) than both the craft ammo and the (more powerful) personal ammo? It makes no logical sense. Hence I think it's a design error. Nothing can be inferred from the fact it's unchanged from XCOM-EU, that doesn't imply any deliberate decision. It could just be the replication of an original error in XCOM-EU. [[User:Spike|Spike]] 11:17, 15 November 2008 (CST)

:: I can think of a logical reason to justify this: X-Com doesn't understand the technology as well as the aliens do (which is obvious, given the length of time each side has known the tech). Handheld Blaster/Blaster Bombs are just a copy of the alien design and therefor relatively cheap and efficient, but that can't be mounted on a turret. So X-Com has to make a new design, and they obviously didn't do that good a job as the aliens would have done. This explains Tank/Plasma being weaker than Heavy Plasma too. (Why is FBL Craft ammo cheaper than the tank ammo though? Maybe X-Com gave up on/simplified the guidance system and made it just a "dumb" cannon shell/torpedo instead which doesn't have multiple waypoints? Or maybe they just did a better job there?). [[User:Cesium|Cesium]] 04:07, 25 November 2009 (EST)

:Whilst we discuss it, I'll park my original text in here:

* ''Displacer/PWT ammo cost bug - at over $100,000 total cost per round, the ammunition for this SWS weapon is far more expensive to manufacture (both in money and rare materials) than the equivalent ammo for the Aquanaut-carried Disruptor Pulse Launcher, or the craft-based Pulse Wave Torpedo, despite being less powerful than either. This would seem to be a design mistake.''

See Also [[Talk:Displacer/PWT]]

:: I don't like the higher cost either, but I think it's a tradeoff of expense and quality for the convenience of portability. Sort of like an MP3 player to the gramophone... or maybe that's not a good comparison. -[[User:NKF|NKF]] 13:43, 15 November 2008 (CST)

A better comparison might be a desktop computer to a laptop. As a general rule, laptops are more expensive, but a similarly priced desktop gives you more power. Desktops are cheaper and offer power, laptops are more expensive and offer portability(though the gap is rapidly narrowing). [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:49, 15 November 2008 (CST)

:I think those are good analogies. But they don't apply in this case. To continue your analogies: We are paying mainframe prices for a clunky desktop that has only laptop processing power, and we're buying a mainframe for desktop prices. The vehicle version ("desktop") - is ''less'' portable and ''less'' powerful than the personal version (DPL = "laptop"), ''less'' capable than the craft version ("mainframe") - 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 SWS use up ''more'' of both Zrbite and Aqua Plastics than the Craft version. Do we really think it's logical that a tactical battlefield round, less powerful than its man-carried equivalent, takes more explosive and structural material to produce than both the more powerful man-carried version and also more than the air-to-air round that has 60km range and can take down a major alien combat craft? There is a clearly perverse bang-per-buck here, on every measure. My sincere belief is that this was an original mistake in the XCOM-EU engine that got copied into TFTD as well. The craft round should have the higher base price, but 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. But what I don't think is debatable is that is not logical for the SWS/HWP rounds to be more expensive than the craft rounds. It's clearly a mistake. Even in game balance terms, the only thing the HWP/SWS rounds have going for them is conserving "80-Item Limit" space, which I severely doubt was ever a game design consideration since it's just an awkward programming compromise. Any advantage inherent in the HWP/SWS is already reflected in the very high platform cost - there is no need to inflate the ammo costs as well. The bottom line is that a round for a (mini-)tank does not cost more, does not use more materials, than the same type of round for a long range anti-aircraft weapon that has much greater damage capacity and penetrating capacity. [[User:Spike|Spike]] 14:35, 15 November 2008 (CST)

I'm going to add this to the bug list now. [[User:Spike|Spike]] 16:06, 25 February 2009 (CST)

:Still don't think this is a bug though. Just because it's more expensive to manufacture than the hand-held or craft-mounted ammo, it doesn't mean the stats are wrong. Perhaps the programmers wanted to balance the tactical portion of the game a little more by making the ammo cost more for tanks. It doesn't have to be logical to be intended. Now if you had proof which said that the ammo was supposed to cost less but the stats were wrong, then yes, I'd agree. So if you boil it all down it comes to a disparate logic issue, not a bug.--[[User:Zombie|Zombie]] 21:31, 25 February 2009 (CST)

::I have to side with Zombie here. While the ammo may be disproportionately expensive, by the definition used on the rest of the page for bug, it doesn't fit. All the other bugs are errors in program logic or function or routines that are unintentional problems with the game, most of which are not warned of ahead of time. The ammo for the tank costs exactly what is listed and operates entirely as intended, whereas the rest of the bugs are not intended game features. Even if the numbers were entered wrong, that would be a data entry error, not a program bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:28, 26 February 2009 (CST)

:If it was a data entry error, I'd consider that a type of bug... assuming we had proof of the goof so to speak. LOL. --[[User:Zombie|Zombie]] 00:49, 26 February 2009 (CST)

:: It feels too specific an entry to be a data entry error.

:: I'm reminded of the high explosive. I know, I know - it's not an exact parallel to the FBL issue. A High Explosive is practically two grenades. Double weight, double bulk. Slightly above two times the damage. However, it costs five times the price of a standard grenade. Even though you're paying more for not-as-much, I don't think that could be considered a bug. A rip off, yes, but not a bug.

:: Here's a thought: Think about the immediate benefits each of the two controversial ammo types give back to you. Aircraft ammo = activity points. Tank ammo = loot. Yes, I know that aircraft ammo also generate crash sites, but you still have the ground combat to contend with.

:: One other thought: With careful management of your ammo, you'll probably never spend any elerium on the handheld version's ammo. Could it be the handheld that's really at issue here rather than the others? In the end I feel that it doesn't really matter. -[[User:NKF|NKF]] 03:38, 26 February 2009 (CST)

: I'm with Zombie that a data entry error is a bug (we have other examples), but also agree some proof is probably needed. And I agree with NKF that in the scheme of things, it doesn't really matter much. I don't think the HE pack is a good comparison (though the HE pack should be heavier) as it's reasonable to pay disprortionately more to get additional power at the same tech level. The fusion weapons are a case of paying more to actually get ''less'' power. I am not bothered by the handheld vs vehicle balance, not least because the game generally makes handheld weapons better than their vehicle equivalents, so I can accept that as an across-the-board design decision.

: I can also see a game balance argument ''if'' we believe that Fusion Tank ammo is more of an overall game-winning weapon than craft Fusion Bombs. But I'm not sure I agree with that statement. And even if it's true, and there's a game balance argument (in which case it would apply equally to handheld Fusion launchers), it's still illogical. The less powerful, battlefield warhead should not cost massively more in exotic materials than the much more powerful air to air warhead that brings down Battleships. I agree though that just because it's illogical does not prove it's a bug (i.e. unintended). [[User:Spike|Spike]] 07:48, 26 February 2009 (CST)

Ok we more or less seem to be in agreement that this isn't a bug, but it is very confusing/illogical. Maybe we can shift the "bug" text from the article page and roll that into the [[Hovertank/Launcher]] and [[Displacer /P. W. T.]] pages now. Feel free to combine any text from the discussion above if necessary. --[[User:Zombie|Zombie]] 09:22, 26 February 2009 (CST)

: Unless we can ''prove'' it's a data entry error (unlikely), how about calling it an "Anomaly" instead of a bug? [[User:Spike|Spike]] 10:59, 26 February 2009 (CST)

Looks like plain old game imbalance to me.
The way I see it, Hovertank Plasma and Launcher were meant to be stronger. Much much stronger. Let's look at Tank Cannon, Launcher and Laser. The logic is that it's a tank mounted weapon, so the tank can carry a much larger and more powerful version of the same weapon, right?
It's pretty stupid that a Hovertank Plasma is weaker than the Heavy Plasma... you could just mount a Heavy Plasma on a Hovertank and get them exactly equal. In fact, I suspect that the hovertanks were ALSO meant to have more powerful weapons than the man-portable versions.
Unfortunatly, the game designers then realised that this made the hovertanks far too powerful. So... the programmers nerfed the power of the hovertank weapons. BUT they forgot to lower the ammo costs. [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 11:20, 26 February 2009 (CST)

: Well you are opening up a much larger issue there. The Fusion weapons are an anomaly, an inconsistency. But handheld weapons are more powerful than equivalent vehicle weapons across the board, consistently. So that looks like a deliberate design decision, not a mistake. [[User:Spike|Spike]] 17:33, 26 February 2009 (CST)

:: There are two exceptions to the rule: Tank/Cannon: 60AP vs. Heavy Cannon 56AP. Tank/Laser: 110 Laser vs. Heavy Laser: 85 Laser. The hovertank\plasma only differs by a measly 5 (an extra 0 - 10 damage, which means a lot vs. UFO inner hull armour). I guess the trend here was to moderate the area effect tank strengths. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

I'd have to agree with you there Spike. This wasn't a mistake, however odd it may seem. It was a deliberate attempt to try and balance the game. Below is a table I created ages ago for my (now defunct) strategy guide detailing the HWP's and what handheld weapon corresponds to it. When you stick them side-by-side, it really becomes apparent that the programmers were trying to base the HWP weapons off the handheld weapons somewhat. The only thing that doesn't follow a nice and distinct scheme is the damage. That's what is the clincher. --[[User:Zombie|Zombie]] 20:26, 26 February 2009 (CST)
 
<table {{StdCenterTable}} class="sortable">
<tr {{StdDescTable_Heading}}><th align="left" width="150">Tank Type</th><th width="70">DAM</th><th width="80">Snap</th><th width="90">Aimed</th><th width="90">Aimed</th><th width="80">Snap</th><th width="70">DAM</th><th align="right" width="140">Handheld</th></tr>
<tr><th align="left">Tank/Cannon</th><td>60</td><td>60%</td><td>90%</td><td>90%</td><td>60%</td><td>561</td><th align="right">Heavy Cannon</th></tr>
<tr><th align="left">Rocket Launcher</th><td>85</td><td>55%</td><td>115%</td><td>115%</td><td>55%</td><td>87.52</td><th align="right">Rocket Launcher</th></tr>
<tr><th align="left">Laser Cannon</th><td>110</td><td>50%</td><td>85%</td><td>84%</td><td>50%</td><td>85</td><th align="right">Heavy Laser</th></tr>
<tr><th align="left">Hovertank/Plasma</th><td>110</td><td>85%</td><td>100%</td><td>100%</td><td>86%</td><td>80</td><th align="right">Plasma Rifle</th></tr>
<tr><th align="left">Hovertank/Launch</th><td>140</td><td>--%</td><td>120%</td><td>120%</td><td>--%</td><td>200</td><th align="right">Blaster Launcher</th></tr>
</table>
1AP rounds. 
2Average between the Small and Large Rocket.

: Hold up! Tank rounds do 60AP. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

So what's wrong? The table says 60 for the Tank/Cannon and 56 for HC-AP. Those are correct, no? --[[User:Zombie|Zombie]] 23:41, 26 February 2009 (CST)

: Sorry, didn't realise it was two tables side by side (or rather mirrored). Eyes only noticed the left side of the table. -[[User:NKF|NKF]] 23:53, 26 February 2009 (CST)

:: If the Hovertank Launcher did 200 damage, or worse if the Hovertank Launcher did EVEN MORE damage than the Blaster Launcher... that would make them easily the most deadly things on the map. As it is, the hovertank launcher is already pretty overpowered, even with 140 power.

I might be six years late here, but I think there could be an explanation for this in RL physics — indeed, in RL nuclear weapons programs. Incoming wall of text.

There are two sorts of nuclear reactions that produce energy: fission of large nuclei, and fusion of small nuclei. Fission can occur under normal temperatures and pressures, but involves a neutron chain reaction. As such, fission devices have to have a certain mass of fissionable material (the ''critical mass'') so that the neutrons stay in the material and cause more fission rather than escaping; this means that such devices cannot be scaled down below about suitcase or large backpack size (not all of this is actually nuclear material; rather, most of it is conventional explosives used to rapidly assemble the supercritical mass from subcritical masses). They also produce large quantities of radioactive fallout, which is problematic. Fusion, on the other hand, requires extreme temperatures and pressures, but does not necessarily require a neutron chain reaction. This means that they can theoretically be scaled down to much smaller sizes... except that the only available compact source (ie, not building-sized) of those extreme temperatures and pressures is the detonation of a fission bomb. Thus, all known fusion weapons currently in existence involve a relatively-small fission stage that detonates a much more powerful fusion stage.

The "Holy Grail" of nuclear weapons research is what's called a [[wikipedia:Pure fusion weapon|pure-fusion weapon]]. Because it has no fission stage, a pure-fusion weapon would release little fallout (note here that fallout is material that emits radiation long '''after''' the detonation; a pure-fusion weapon would emit copious amounts of deadly neutron radiation when actually used, but that would dissipate within seconds) and could be scaled down to grenade-launcher size (though it would obviously be far more powerful than a conventional grenade). They would be far easier to produce, as well; producing weapons-grade uranium and plutonium requires large and powerful isotopic separation equipment and/or a full-sized nuclear reactor, whereas deuterium can be extracted from water with trivial ease and lithium and tritium are relatively simple to obtain and make respectively. The main issue is that while the pressures required to confine the fusion material during the reaction are achievable with chemical explosives, the temperatures necessary for fusion are emphatically not. You need a stronger initiator; some material with a higher energy density even than plutonium. In RL the only initiator strong enough is antimatter — hard to produce and contain, to say the least — but the aliens in X-Com have a source that's stored far more easily... Elerium.

I posit that the "fusion" line of weapons in X-Com are exactly what they're named: tactical fusion bombs, made possible by an Elerium detonator. (A more controlled reaction on those lines — a fusion reactor with Elerium-spiked fuel — in UFO Power Sources would also explain the discrepancy between the calculations based on fuel efficiency and the lack of city-killer blasts when a Power Source's Elerium cooks off.)

Given the assumption that "fusion" weapons are indeed fusion weapons, with Elerium serving only as a detonator, the oddly high Elerium cost of the Hovertank/Launcher's ammunition is finally explainable. The HWP Fusion Bombs are, literally, smaller than Blaster Bombs and craft Fusion Balls (presumably because of size constraints in the launching mechanism in tanks). Having less explosives to compress the fuel means you need an even higher temperature to compensate — thus, more Elerium detonator — but because the actual power of the bomb is mostly from fusion and not Elerium decomposition, the yield is still lower.

I intend to remove this from the list of Known Bugs on this basis if nobody can find a hole in my logic. [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 02:03, 17 April 2015 (EDT)

:I'll have to disagree. Your argument while interesting, is just supposition and an attempt to give validation by taking ideas (that the developers probably never considered) to justify a flaw, very much in the same manner as those who try to explain why UFOs do not respond in interceptions. In truth, like many of the other bugs listed here, they are the result of issues caused by the time constraints the Gallops where under. Much of the production/buying/selling aspects of the game have game balance issues and don't make sense when cross referenced to other similar elements in the game and/or their overall effect to either combat or the strategy layer, especially in regards to the game's economics. [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]]) 05:06, 17 April 2015 (EDT)

::Why would they match up in terminology with the actual use to which any military would put Elerium by accident? Because, no shit, if a military got their hands on a substance with Elerium's properties this is literally exactly what they'd do (at least as far as explosives go). I can cite a paper talking about the superiority of antimatter-fusion weapons to pure antimatter weapons if you want; the title is "Fourth Generation Nuclear Weapons: Military effectiveness and collateral effects". [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 05:21, 17 April 2015 (EDT)

:quote all the sources you like, it still doesn't explain the waste in the manufacture process. With elerium being such a "scarce" resource, there is no logic in producing something that require more elerium and delivers less of a battlefield effect. It would be more logical and efficient to have had the platform fire regular blaster bombs, since they only require 3 elerium not 5.[[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])
::IMHO, any logic argument can be presented to why those HWP Elerium Bombs should cost less/more or be more efficient. That is not the point here. A bug is when a game feature is working improperly or/and is causing technical issues, either due to limitations, insufficient testing, whatever. Design choices are a completely different matter: the Heavy Laser is a nearly useless weapon due to its stats but no one ever considers it to be bugged due to its stats. It was a choice, that was slightly changed on TFTD with the Heavy Gauss. To consider the stats of the HWP Fusion a bug then you'd have to label a lot of choices as bugs when they are simply design choices. You may not agree with them but that doesn't make them bugs in the generally accepted definition of the term. And quoting Arrow Quivershaft on the top comment of this discussion: "At a cost of $15000, 400 Tech hours, 5 Zrbite, and 8 Aqua Plastics, this is the exact same cost as the HWP Fusion Bomb from X-COM EU, converted over to the equivalent TFTD resources. As such, it shouldn't be counted as a bug, since it is clearly what Mythos intended"[[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 19:35, 25 April 2015 (EDT)
::Also, the consensus until now expressed by several people that previously discussed this is that this is not a bug. The main supporter of the bug argument seems to be Spike at the beginning but during the discussion but halfway the discussion he says: "I agree though that just because it's illogical does not prove it's a bug (i.e. unintended)" [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 20:54, 25 April 2015 (EDT)
You don't get to claim benefit of the doubt here, Tycho. All game features are assumed to not be bugs unless there is compelling evidence presented otherwise. You claim this is a bug based on the suppositional logic that more powerful weapons should cost more and almost nothing else. The price wasn't altered (and neither was the power) in TFTD, so there's no evidence of mistake there (as an aside, the Displacer/Sonic having its power listed as 130 when it's 110 in the game engine clearly ''is'' a bug). The only bit you might be able to interpret that way would be the description of the Hovertank/Launcher's weapon as causing "immense devastation" compared to the description of the Blaster Bomb as "highly powerful" (the potential implication being that the HWP Fusion Bomb is stronger), but that's iffy at best since there's hardly a graded table of adjectives in use and on those very same pages in the UFOpaedia it lists the damage of each weapon as what it actually is.

The claim that it's a bug is based entirely on theorising about yields. I've given alternate theorising that would explain the yields (and I already explained that the semi-automatic nature of the Hovertank/Launcher and physical space for its high ammo could justify the need for a smaller round), which undercuts that claim. We can't know who's right, but the assumption should always be that the designers knew what they were doing; to assume until proven otherwise that they had no clue is extreme hubris and contempt. Moreover, you are in a minority of one or perhaps of two against a majority of several. Your claim to representing consensus is blatantly false.

Now, I'm going to wait a couple more days to see if anyone comes forward with anything substantive, as I waited a week after my reply to your original non-refutatory dismissal, and then reinstate the removal if nobody puts forward a cogent objection. [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 22:57, 25 April 2015 (EDT)
:Now that I think of it, though, an "oddities" page where we talk about this, the shitty Heavy Laser/Heavy Gauss, the No More Soldiers limit, and other not-bug things might be in order. It would help to make this page about actual bugs and not about weirdness that is nevertheless clearly as intended. Thoughts? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 23:04, 25 April 2015 (EDT)

:At the time, I didn't continue the argument as my point was that removing something based on one person's belief, no matter how cleverly thought out, wasn't good enough to warrant removing from the list. (I would have pointed out all the different theories on UFO interception AI, but I see that has already been removed.) I hadn't read all the discussions because I assumed that no consensus had been reached, similar to the Interception AI discussion. Mushroom, could have just pointed out that this issue was already settled years ago but no one bothered to removed it from the list, instead of resurrecting a "dead" discussion as though it had not been settled and just stated that the developers intended to discourage the use of this HWP by making the cost of its ammo high. I still don't agree that the HWP ammo is more efficient and thus justification for its production cost, especially since the developers would have never needed this level of justification or would have had the time to devote to so small an aspect of the game.

:I definitely agree that this page needs to be updated. Another reason I argued so strongly is because so many topics on this page do not fall into the category of bug as has been defined. I thought this page was also devoted to listing all the illogical aspects of the game due to the lack of enforcement on the definition. [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])

::If I only had a dime for each time someone proposes to change something on this wiki, everyone agrees, and then nobody ends up taking action... :) It's always better to take initiative and edit things. I agree also with an update to this page, and separating bugs from limitations. But definitely no more 'this should have been done this way' arguments to present design decisions as 'bugs' [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 17:43, 26 April 2015 (EDT)

:Okay. I'm planning to rip out the following and stick them on a separate page:

:Great Circle "bug" (this isn't really a "bug" so much as unoptimised code)
:Side-on Intercept "bug" (ditto, but given UFOs' tendency to alter course suddenly it's not even particularly unoptimised)
:Head-on Intercept "bug" (come on, this is just bitching)
:Instant Getaway "bug" (more an anomaly than a bug)
:80-item limit (intentional and the rationale is obvious to boot)
:Purchase limit (working as intended)
:Soldier recruiting limit (being charged for attempting to buy more is a bug, but the limit itself isn't)
:Soldier battlescape limit (there's a consequence of this which is a bug, the CtD with 10+ tanks, but not the limit itself)
:Manufacturing Completion Time Display "bug" (you can look at it and see what time it finishes, and it goes down at the right rate; it may seem a little unintuitive but it isn't "wrong")
:Manufacturing Rate Interruption Loss "bug" (more bitching)
:Manufacturing Rate limit (working as intended; the attempt to get around it in TFTD is bugged, but the EU behaviour isn't)
:HWP Fusion Bomb Ammo Cost "bug" (we're in agreement here it seems)

:There's plenty that need a tidyup on top of that but as far as the page split itself goes, are we agreed? Also, I'm thinking of calling the page "Anomalies and Game Limits", opinions? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 01:58, 3 May 2015 (EDT)

== DOS4GW - What the heck is it? ==

It's been ages since I had to remember this stuff, so those who remember clearer than I do, forgive me if my descriptions aren't accurate. Hopefully the general idea will come across.

Back in ye olde days of computere gamynge - and where there were more E's to go around, memory handling was a tricky beast to handle. Computer memory is divided into several different categories. Conventional, extended and I think expanded. I might be jumbling the terminologies for the last two a bit. Doesn't matter - memory was just cut up into small segments. The two most common memory types to PCs at the time were pretty small but were readily available. The third one - the most expandable (aka the chip with its massive 4 Megs of RAM you just spent your whole month's allowance on!), wasn't as easy to get at.

To get access to the higher memory that was available to the computer, special memory handlers had to be used. Drivers like HIMEM, emm386, etc were used.

DOS4GW is one such handler that lets the game access the computer's available expanded memory. Lots of games that came out at the time use this. Doom, Duke Nukem 3d, Syndicate, Ultima Underworld, X-Com UFO/TFTD, etc. LOTS of games. Any time you ran a game from the dos console and you saw the Dos4GW message flash by briefly it would be assisted by it (well, it stayed on the screen for ages back when processors were slower!).

It took the hassle out of memory handling and let the game access the available memory on the computer as one big flat block of memory to play with.

So what was meant in the article was to simply replace the dos4gw.exe with a more up-to-date version from another game. I think the way to tell its version was just in the message that it displayed. You can just run the dos4gw.exe file in a console window. It'll give an error, but the message it shows will indicate its version. UFO 1.4 uses Dos4gw 1.95, for example.

-[[User:NKF|NKF]] 01:22, 6 March 2009 (CST)
:DOS4GW also switched the processor from 16bit to 32bit mode. [[User:Seb76|Seb76]] 13:58, 6 March 2009 (CST)

== Clipping ==
I have a new bug. Its harmless. I have a savegame (EU CE - modified game) which has a sectoid within another sectoid. In the alien turn, one secturd walked off the roof and dropped down <s>onto</s> into another. (I guess there DNA is indentical afterall, so they 'become one' with the world). If you want the savegame (superhuman edited using UFOloader, UFO Mod v1, xcomed, Khor Chin WeapEdit v0.1) drop me a request on the my page somewhere. [[User:EsTeR|EsTeR]] 01:40, 18 September 2009 (EDT)

: Not something many would encounter, but definitely something that can happen. Units can occupy the same physical space, but the game cannot display them all. It'll only draw one of them. Actually saw this effect happen back in the early days of XComutil when it gained the ability to manually add new aliens into a battlescape. It did this by slotting them into the same spaces occupied by existing aliens. Then the fun would happen when you saw a couple of Mutons suddenly walk out of a sectoid. Not sure how the game determines who gets hurt when struck by a bullet. May very well depend on the order they are stored in the unitpos.dat file.

: There are a couple of ways you can replicate this in-game, but I can only provide theories on how you could do it. Such as shooting the ceiling above you and letting the unit drop through, or moving a tank off a ledge and getting its non-primary segments land directly on top of another unit. By the way, the rear end of tanks get stuck in walls if you attempt to move north or east off any ledges. -[[User:NKF|NKF]] 02:18, 18 September 2009 (EDT)

: Ok, so as long as others know about this, then all is good. I had never seen it and was doing alot of head scratching until I shot the alien.

== Berserk HWP crashes the game ==
In the article page it mentions that aliens which go berserk with their integrated weapons will crash the game. This is only true for Mind Controlled aliens (or units under X-COM control) - alien controlled units which go berserk do not crash the game. I tested an MC'd Celatid just now and it doesn't crash the game either, though it doesn't immediately go berserk - it waits another turn for some odd reason. Someone want to check this to verify my results? --[[User:Zombie|Zombie]] 20:31, 27 December 2009 (EST)

==HWP Morale Loss==

HWPs have 110 Bravery, which [[Morale#Effect_of_Bravery|normally prevents morale loss]], but I wonder if they can still lose morale due to loss of units with a morale-loss modifier. It'd depend on how the math is done. If, for, example, the -20 to morale for a dead unit is static, then multiplied by any [[Morale#Officers|morale loss modifier]], then reduced by 2 for every ten point of bravery, any officer death without another officer on the field will necessarily reduce HWP Morale.

It all depends on how the equation plays out and when modifiers are added. For sake of this post, I propose the following as the morale-loss equation: 20*(rank death modifier)-((Bravery-10)/5)*(1.00-Leadership bonus)=Morale Lost. (Rather than using 22 as a base, I'm going to assume Bravery is internally decremented by 10 for this equation as 0 Bravery is impossible without editing and it makes the math easier for the purpose of the example.)

It makes sense to me that rather than having 110 bravery hard-coded as an exception to "No morale lost", it simply works the same way in the normal equation, but is high enough that it negates most morale loss events, as even if an officer is killed, another officer is usually left on the field to help negate the penalty. That said, if a large portion of the team is wiped out at once, any surviving officers may not be able to negate it all, allowing tanks to start having noticeable morale loss.

So with the death multipliers, we can determine that every XCOM officer killed has a set death value. Rookies and Squaddies are -20, Sergeants are -24, Captains are -26, Colonels -30, and Commanders -35.

For example, under this theory, if a Sergeant is killed with no other ranked units on the field, a Squaddie with 50 Bravery would lose 16 Morale. (20*1.2-(50-10)/5*1.00=16). A HWP would, at the same time, lose 4 morale. The Sergeant's death is worth -24 Morale, and without another officer on the field to ameliorate the loss, the Tank's bravery only can 'absorb' 20 points of the morale lost. If it was instead the Commander lost, with no other officers on the field, the HWP would lose instead 15 points of morale, given that a Commander's death (20*1.75) is worth a whopping 35 points of morale loss if no other officers are present.

And if you have, say, four colonels and the Commander on rear/psi duty, and some alien flings a grenade or a blaster bomb into the back of the Skyranger and blows all three of them up and they were the only officers, the HWP has now lost 55 morale, which gives it a 10% chance of panicking/berserking on the next turn!

In the end this'll probably need to be tested for accuracy, but those are my thoughts right now.

Also, for the record, most units that berserk go to 255 TUs while still using the original TU-expenditure calculations; it's part of what makes berserk units so dangerous. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:34, 11 January 2012 (EST)

:Tested it under vanilla CE. Took a squad out containing just about every rank there is (commander + colonel + captions + sergeants), plus a tank. Blew up and killed all soldiers with a single blaster bomb shell, leaving just the tank, which lost no morale (sorry).

:I also brought a group of rookies along with a single commander + tank, and killed just the ranked unit. Tank lost no morale. A rookie with 60 bravery lost 17 (which matches the loss predicted by the formula currently on the morale page), whereas under your formula he should've lost 25.

:Still, you're on the right track. I've long had my own theory as to why tanks have been known to lose morale. Take a look at [[UNITREF.DAT#42|UNITREF.DAT[42]]] - this is the offset that stores a unit's rank. Notice something? The value gets higher as the X-COM unit's rank gets higher. Works in ''reverse'' for aliens, for whatever reason. I sorta figure it's so killing a mind controlled alien commander doesn't mess with your morale too badly, but there's a big problem with that theory and you can probably tell what it is...

:If the highest this figure gets for an X-COM unit is 5 (commander rank), then a killing a mind controlled alien ''terrorist'' with a rank value of ''7'' should net an even higher morale loss penalty. And indeed it does - I took a rookie and a tank to a terror mission, mind controlled and killed a terrorist, and the tank lost 10 morale. Guess it would've lost six if I'd taken a commander instead of a rookie, but that's still something.

:Note that the formula on the morale page does ''not'' account for this - it states that at bravery 110 the alien's death loss multiplier would always be applied to a base morale loss of 0, but that's obviously wrong. You're spot on in saying that the base morale loss figures are not totally dependant on bravery, and the "death loss" penalty is applied first. Would probably require a few more trials to determine what that penalty ''is'' for alien soldiers and terrorists though.

:Just for kicks, I edited a plasma tank to have 0 morale. It panicked in the normal way (either sitting still or charging off to the SE). When it berserked, the game crashed as soon as I dismissed the status message. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 18:54, 12 January 2012 (EST)

:: Thought I'd give it a spin. I sent a laser tank in with a squad and had it start shooting at team members. Each time it killed an ally, it would lose morale. Once it was under 50 morale, I waited until it panicked. Since I was playing the dos version, the game didn't crash but I suspect a memory leak of some sort may have occurred that would normally shut down the CE version. What would happen in CE if a soldier were to be edited and granted a tank turret, and then made to panic? Would the game crash? I'm just wondering if it's related to the weapon as opposed to the fact the tank is a treated as a large unit. -[[User:NKF|NKF]] 00:43, 13 January 2012 (EST)

::: Ah, friendly fire! Thought I'd tested for that, but obviously not...

::: Oddly enough, now that I try it, I see that the twenty point hit for killing a unit on the same side can be adjusted by the leadership bonus of the victim. Eg, kill a lone commander and his 35% penalty reduction takes the extra morale lost from 20 down to 13 (which is exactly how much a tank will lose, given that it otherwise wouldn't lose any at all).

::: Of course, this completely messes up my theory about alien soldier/terrorist ranks overriding the 110 bravery score. It doesn't. My tank "only" lost 10 morale because the alien's rank acted as a 50% leadership bonus... Though I suppose that's still interesting to know, because it suggests that keeping a simple alien soldier under mind control is more effective then risking your own commander in the field.

::: I took an otherwise unarmed rookie and assigned him a tank cannon + ammo. He could manually fire this weapon in much the same way a tank can. Forcing him to berserk crashed CE, under DOS he just spun around. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 21:20, 13 January 2012 (EST)

== 80-items limit on CE edition ==

I have the feeling that the 80-items limit does not apply to the CE edition and is instead a 110-items limit (at least during base defence). Can anyone confirm? [[User:Seb76|Seb76]] 16:24, 24 February 2010 (EST)

:I believe this limit was increased for TFTD. Maybe it was also increased for the CE edition of UFO, and only ever applied to the DOS edition of UFO?? [[User:Spike|Spike]] 20:03, 11 March 2010 (EST)

== Paying for Dirt in TFTD ==

I have the steam version of TFTD and am unable to replicate this bug. Testing with the starting base, I dismantled a few modules, added up my income and expenses, and it reconciled with my cash at the beginning of the next month. I even tried again, dismantling every module except the access lift, and once again saw no income discrepancy. Am I missing something, or is it possible this bug was actually fixed in TFTD? --[[User:Jewcifer|Jewcifer]] 12:18, 16 March 2012 (EDT)

:'twas probably fixed. It would indeed be helpful to add a small note to bugs on this page which are EU-specific but not obviously so (like this one). -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 17:14, 16 March 2012 (EDT)

::Every now and then I get the urge to test some of the more important bugs myself in my steam version of TFTD. Perhaps I will make a more complete effort and record the results somewhere on the wiki. --[[User:Jewcifer|Jewcifer]] 12:08, 21 March 2012 (EDT)

== Paying for dirt: Source of bug discovered! ==

Well, I never have read this anywhere (which kind of strikes me as odd, thinking of how obvious this one seemed to me... And i have NO programming background whatsoever), so I'll post it here, hoping that there are still some active members willing to try and verify my findings. If so, please comment here, because then I will inform bladefirelight to include this in any upcoming xcomutil release. If it had been discovered before, well then I just wasted some time here. Comment below, I will delete this entry.

As the main bug page mentions, when dismantling a facility still under construction the premium will only be paid once it would have been finished. This suggests some connection between paying the premium and building time. Looking into the infos here: [[BASE.DAT]], I quickly discovered what the problem was: When a facility is dismantled, the Bytes related to the location of base facilities are updated correctly. HOWEVER the game omits to update build time to FF (which is "will never finish", an entry only found on unused squares). If the facility is finished when it is dismantled (or destroyed during combat), then the 00 in the build time byte will stand. If it was under construction, the value indicating the remainig build time will continue to tick down towards 00 as if the facility was still there.

Now at the end of the month the following seems to happen: The game checks for ANY 00 entry in the build time bytes, and if there are 00 entries, it will look up in the location bytes the type of structure to determine the amount of maintenance for that 00-construction-time-square. When it finds "dirt", then it will charge the 80 grand (my guess would be that those are somewhere hard-coded).

This explains all phenomena related to this bug, like a dismantled hangar costing 320.000 grand or the premium only popping up after the build time of a dismantled facility that was under construction has expired.

Now the fix is pretty easy: Open the BASE.DAT in a hex-editor and change the bytes in question to FF!

== Minimized Interceptor Bug (Ufo CE) ==

Maybe this bug is not just related to saving, because I had a similar problem last night. The game didn't crash, but it kept restarting the same Battlescape mission.
One Avenger (A-3) was pacing a Battleship, while another Avenger (A-1) was sent to pick up the pieces of a Terror Ship that had been shot down by an Interceptor. Despite having no weapons (oversight on my part), A-3 wanted to attack the Battleship, but I minimized the screen, hoping it would land.
While the screen was minimized, A-1 landed at the Crash Site from the Terror Ship and started this mission. Right after finishing it, I got the message that A-3 was ready to land next to the Battleship. Happy that I'd get the loot, I started the mission.
After cleaning it out, I got the usual Loot and Promotion screens and went back to the Geoscape. A few seconds later, I was back in the equipment screen and the Battleship Mission started again. I played it once more, because - hey - additional loot, right? Err... no. At the end, I got the correct Loot screen for this attempt and the very same promotion I had gotten in the first attempt (A Rookie from another base promoted to Sergeant).
Got back to Geoscape and a few seconds later back to the Equipment screen. I aborted this mission (same Battleship again), got back to Geoscape and - you guessed it - back to the Equipment screen. After aborting this mission as well and getting back to Geoscape, I used the few seconds I had to go to 'Options' and 'Abort Game'. Maybe I could have made A-3 disengage from the Battleship since I think I saw them both on the Geoscape, a yellow diamond and a red plus, but it was pretty late by that time.
--[[User:Matzebrei|Matzebrei]] 15:06, 15 May 2012 (EDT)

This is a known bug. There is a work around. You should patrol the ship with troops and not land... Finish shooting down the other airborne ships first. Then when the ships doing the shooting are returning to base, change patrolling ship with troops to advance to downed ship in order to commence ground combat mission.
--[[User:JGF|JGF]] ([[User talk:JGF|talk]]) 07:55, 9 November 2016 (UTC)

== Activity Overflow Bug ==

This is a potentially campaign-ending bug. This was seen in the Steam distribution, DOS version (on Windows 2003 Server EE). Not sure if UFO Extender was being used - probably it was. End of Jan 1999 turn shows an extreme negative/underflow Monthly Rating score, which in turn is caused by extreme overflow of UFO Activity levels. Note that that funding "score" - the increased funding by countries - was very positive at the same time!:

[[File:dissatisfied customers.png]]

UFO Activity, by Areas and by Countries, is literally off the chart. Clearly some kind of integer overflow:

[[File:ufo-areas.png]]
[[File:ufo-countries.png]]

X-Com activity is also off the chart:

[[File:xcom-areas.png]]
[[File:xcom-countries.png]]

In addition to the likely outcome that I will lose the game in Feb 1999, it means I can't use the graphs to detect UFO activity outside of my radar coverage.

I have only seen this bug once, and (probably very unusually) I am running under Windows 2003 Server EE (!!). My hunch would be that's the cause, Windows 2003 Server is not the best games platform. :)

[[User:Spike|Spike]] 07:22, 3 September 2012 (EDT)

Further information:

I don't necessarily lose the game in Feb or March 1999. The Monthly Ratings from Feb onward are just based on the current month, not historical score to-date. However it still greatly increases the risk of suffering from the [[Known_Bugs#Losing_My_Favourite_Game|Losing My Favourite Game]] bug - which also greatly complicates doing too many controlled experiments on this Activity Overflow bug, because a few restores of the saved game quickly leads to X-Com Project termination (and humanity's doom).

Possibly the Activity Overflow bug is caused by an initial value of the score (or an array of score values) not being correctly zeroed at the start of the game. See this graph, which shows a negative score in May 1998, prior to the start of the game in Jan 1999.

[[File:Prehistoric_negative_score.png]]

[[User:Spike|Spike]] 08:48, 3 September 2012 (EDT)

I encountered the same Activity Overflow Bug in Windows 7 using Steam version, Windows option with UFOExtender latest version.

[[User:Humbe|humbe]] 2012.10.04 09:05 UTC

I encountered the same bug at end of january with latest xcomutil patched CE version (with only bug fixes patched) with ufo extender newest version running (close to default options). Got many saves from that first month. Even if loading very early save where I had done no missions yet, and just did stuff in base, graphs still show negative for various periods in 1998. Sounds more like corruption than something actually overflowing to me.

[[User:Archlight|Archlight]] 18:34, 24 September 2012 (EDT)

== Bad Paths Bug ==

I suggest to add bad paths on UFOs maps to the article, as another bug in the game.

[[User:Sherlock|Sherlock]] 09:25, 26 December 2012 (EST)
:That sounds reasonable to me. [[User:Spike|Spike]] 10:03, 26 December 2012 (EST)

==Expenditure Graph==
The economy graph for "Expenditure" neglects funds spent on new facilities. I noticed this in my current (DOS) game when I built eight Psi-Labs at the start of April and it didn't increase. I know it counts everything on the Purchase screen; I'm not yet sure whether it counts manufacturing costs.

Is this enough of a bug to be mentioned? Can anyone confirm whether or not it occurs in CE, and whether it counts manufacturing costs? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 02:40, 17 May 2016 (UTC)

==Workshop Crowding==
It seems there is a bug whereby you can allocate more projects/engineers than available workshop space. This can be triggered by setting up two concurrent manufacturing jobs, setting one of them to have 0 engineers working on it, then set the other to have as many engineers as you can assign to it, filling the workshop space. Then go to the other job with 0 engineers, and it will show a negative workshop space available, now if you assign at least one engineer to this project, you can assign the rest of your engineers however you please.

This is my first edit. I find it hard to believe I'd be the first to find this bug after so many years, can someone please confirm a reproduction and that it isn't documented somewhere I've missed? I am running the DOS version of UFO, but I'm also running XComUtil, not sure if that has an impact, or what patch level I'm on. - [[User:Uncertainty|Uncertainty]] 11:00, 20 Dec 2016 (AEDT) Update: Cannot reproduce on the CE version, still unsure of the patch level of the DOS version I'm running and don't know how to accurately determine that. - [[User:Uncertainty|Uncertainty]] 22:00, 29 Dec 2016 (AEDT)

: An easy way to check is whether you can research Magnetic Navigation after collecting one from an alien sub, or if you have to research a Lobsterman Navigator beforehand. If you can research it right away then you have v2, which is what the CE version is mostly based on. If you can't research it and must get the navigator, then it's the unpatched copy of the game. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 22:24, 29 December 2016 (UTC)

Update 2: Thanks NKF, I'm not running TFTD, but I figured out that I was running v1.2 of XCOM1. I cannot reproduce the bug on v1.4 so the bug only applies to v1.2 and has been patched in newer versions. - [[User:Uncertainty|Uncertainty]] 16:45, 31 Dec 2016 (AEDT)

= Unconfirmed bugs =

These may either be actual bugs that only exist as rumors and nobody confirmed them (yet) or stuff that may look like a bug but actually is a feature.

== Alien mission succeeds despite Ground Assault ==

Suppose aliens decide to do a mission. So they send a scout UFO. If you shoot it down, the alien mission gets derailed and the next scout becomes delayed, sometimes a little, sometimes a lot. Seems like the headquarters are waiting for the first scout to report back home or something. But eventually the second scout shows up so you shoot it down too. The third one also takes a long while to arrive and if you shoot that down too, the aliens either give up on the mission completely or send their big ships which only aimlessly fly to and fro, never land and leave soon, empty handed. This way or that way, the alien mission is a failure.

On the other hand if you wait for the scout to land, assault it with your Skyranger and win the mission, the alien's mission continues as if nothing happened. The second scout appears on time. So you ground-assault it too but the third and fourth scout also appear on time. Then the larger UFOs show up and land as if nothing happened to the scouts. You ground-assault them too, including the last Battleship that happens. But guess what? The alien mission is a SUCCESS even despite none of the UFOs making it back to base. Really annoying if the mission is an Infiltration, you can't take their juicy big UFOs because if you do, you are going to lose a country. But on the other hand all these Alien Harvests and Alien Abductions? Lots of juicy spoil and tons of points despite the aliens achieving what they wanted.

I need to add that I was playing some weird version of the game whose data was rejected by OpenXCom with "an invalid CHRYS.PCK file, please update to the latest version" message. So I don't know if this bug exists only there or is present in the latest version of the game too or even whether this is a bug or an expected behavior. - [[User:TowigOs|TowigOs]] ([[User talk:TowigOs|talk]]) 00:24, 3 August 2025 (UTC)

== Transfers can put you into debt ==

Any action you can do that consumes money will either throw a big fat "NOT ENOUGH MONEY" error (build facility; purchases, etc) or just plain hide the button to actually do it (manufacturing) if you don't have the prerequisite cash on hand. Except item transfers. You can transfer stuff around merrily even when you are tens of millions in debt and on the brink of collapse from financial mismanagement. Maybe aliens MCed the movers to skip checking for money on your bank account and just hope they will get paid, eventually. Or they might MCed your bank to lend you money behind your back, allowing to go bankrupt reorganizing the content of your bases. At least you don't have to pay interest on these unwanted loans.

Looks like someone forgot to put "if (money<invoice) then {NotEnoughMoney();return;}" somewhere into that code path.

Note: Getting into debt because your base maintenance is much higher than your income and you did not have the cash is perfectly OK. These bills have to be paid. And you will go belly up financially if you allow this to go too deep. ([[User:TowigOs|TowigOs]] ([[User talk:TowigOs|talk]]) 21:55, 4 August 2025 (UTC))

=Cleanup needed=
Hmm this whole Talk page needs a cleanup. A lot of the Not Listed bugs, should be listed, or are listed. [[User:Spike|Spike]] 10:03, 26 December 2012 (EST)

:So, before it will be made, yet three more observations.

:1. There is no possibility to give back (to stop hiring) a plane without craft weapon.

:2. Alien Reproduction is unavailable in a normal game without hacking/save editing. This is probably connected to further errors on maps. A bug/error/programmers' oversight of the some kind is present in TFTD where it is impossible to obtain Examination Room. It is so because many tiles on maps are wrongly assigned to game's objects. Namely, [[Examination Room (TFTD)]] is treated as Alien Implanter - but there is plenty of errors of this type, on various maps (perhaps also in UFO: EU).

:3. Among soldiers in UFO:EU, there are Russians. Some non-Slavs may not know that Slavic (also Russian) family names have different masculine and feminine forms. For example, Petrov, Belov, Likhachev, Gorokhov, Chukarin, Andianov, Voronin, Maleev are all masculine names; women must be called Petrova, Belova, Likhacheva, Gorokhova, Chukarina, Andianova, Voronina, Maleeva respectively (however, a rule that the feminine form is always made by adding -a is wrong, e.g. Tolstoy - Tolstaya). The soldier's name Mikhail Gorokhova (which is possible in UFO: EU) is just ridiculous (for everyone who has even little knowledge about Russian things). Tatyana Petrov is also an impossible combination. X-Com creators probably assumed that family names are the same for men and women in all languages, and, as a result, they made only mechanisms for storing masculine and feminine forms of first names, not family names. But taking reality under consideration, this is a bug.

: [[User:Sherlock|Sherlock]] 16:22, 26 December 2012 (EST)

== Common bugs vs. UFO EU specific bugs ==

I believe there is one more thing that needs to be cleaned. Namely, both EU and TFTD share the same game engine, so some bugs are common for them both. However, there exists a page with a list of TFTD bugs, and it is clear (or: should be clear) which of the bugs are specific for TFTD. I think the same should be done with EU specific bugs: to hold them apart from bugs common for both games. Some bugs exist in both games but manifest themselves differently (like problems with mind-controlling of big aliens) - they are not true common bugs.

Or even more: one could expect a clear information by each bug, in which game and in which version of the game the bug occurs. And whether a patch exists or not. Sometimes such information is given now, and sometimes it is not. And if one does not know exactly which versions are affected by the bug, it should also be mentioned clearly.

[[User:Sherlock|Sherlock]] 04:13, 27 December 2012 (EST)

== Rename page title to indicate which game this refers to? ==

I was looking for a list of bugs related to XCOM Apocalypse, and it took me a while to realize this was about a totally different game. There are 4 games (not counting the 2 opensource projecrs) here on UFOP - maybe that could be reflected in the article aswell?
[[User:Panzerlol|Panzerlol]] 20:35, 31 March 2013 (EDT)

==New "bugs" submitted directly to main page with no apparent explanation==

WakkaDakka, have you actually managed to replicate this "missing time units" bug, or was it just a one-off freak occurrence? I'm not sure it merits main-page space until we have some idea how to replicate it.

N21, how were you seeing the future to begin with? It's only a bug if it occurs in the normal course of play.

[[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 03:36, 28 May 2015 (EDT)

== Enemy Unknown 1994: Save game bug mid mission. ==

Effect : Loading saved game mid mission just displays a black screen with the cursor at the top left, whilst the music continues to play in the background.
I don't believe the game has crashed out to DOS, having tried both CLS and DIR to no avail. Your can no longer interact with the game, making you force quit the app.

[[File:Screen_shot_2016-11-07_at_19.39.31.png|thumb|left]] 

I'm using Boxer 1.40 on a Mac - which in turn is built off Dosbox 0.74.
I remember seeing this bug years ago on Windows XP too, so I don't think it is platform specific.
I'm currently running it with some of the XCOMUtil patches too - but have had the issue crop up without any of the patches.

Playing on Superhuman level, I use a Skyranger with 14 soldiers equipped with Laser Rifles.

Cause : Hard to be specific. But here are the facts.
I have my suspicions it may be do to with fog of war rendering issues.
I've had it occur frequently when going to the NW edge of a map.

I also had issue on Alien base 1. I have a save game and can suggest moving a unit and saving it in another slot - that alone causes the issue. So if someone knows how to debug this I can supply that. Not sure if the combined number of aliens and yourself casue this.. I managed to eventually work thru a series of corrupted saves that wouldn't load to one that worked again).

Here is a sample save game where the game only needs one specific movement to corrupt a game when you save after the move.

[[File:GAME_10.zip]]
I've uploaded two images to show the move for S Bradley
[[File:Screen_shot_2016-11-11_at_13.50.13.png|thumb|left]] 
and the destination square to move him too. When you complete that move and save the game it corrupts.
[[File:Screen_shot_2016-11-11_at_13.50.17.png|thumb|left]] 

Incidentally there were two downed UFO's at this time, with a second Skyranger en-route to UFO 42. This mission was for UFO 43 with another Skyranger.

The problem frequently occurs.
Ive had it occur recently on the following types of mission:
Terror, Alien Base, Supply ship, Large Scout, predominantly with Sectoids and Cyberdiscs, but also with Mutons and Floaters.
The only thing all these missions have had in common was lots of units on both sides. For example 13 Floaters on a Scout mission, 9 Cyberdiscs on a Terror mission etc.

--

Other quirky things I've seen relating to Stunned units:

1) You can't stun a unit, forcing you to shoot it to complete the mission.
The target being stunned drops to the ground in a heap, but the game says you can still see it and can re-stun unit....

2) Celatids. You stun it, then it wakes up and moves away. The unit no longer renders correctly. It's like a sheet of garbled colored/transparent dots.

3) A stunned unit, other than a Celatid wakes up, and is invisible but you get the '1' in red square for visible enemy. You can stun unit and get the animation for it falling to the ground again.

--

Teleported unit off screen (notice the yellow arrow over the unit, which alas is invisible at the split second I took screenshot - OS/X rendering crap-shoot).
[[File:Screen_shot_2016-11-12_at_14.18.07.png|thumb|left]] 
The unit was teleported from the top of the stairs in an entirely different building, rendering the unit unusable for the mission. I ended up reloading it and doing over.... - [[User:JGF|JGF]]

:Stop spamming [[Special:RecentChanges|the changelog]], please - if you're working on a page and want to see the results of your edits midway through, use the Preview button. Don't hit Save until you are ''done''.

:I can't replicate any issues with your provided save. Bradley doesn't have enough TUs to "complete" the requested move, but asking him to make the attempt anyway, then saving / reloading, works fine for me under 1.4 as well as CE. For what it's worth, as far as I'm aware the game in no way keeps track of the number of actions you've performed during a given turn; at least, I haven't been able to find any such counter embedded in the save files.

:I do suggest you leave your units with more time units - when ending turn, any agents who ''might'' spot an alien during the enemy's turn should ideally have some cover, a kneeling stance, and enough action points to defend themselves with a reaction shot. Using your full TU allocation on movement is somewhat suicidal, and even when you can get away with it, it tends to leave agents without enough energy to move when they really need to.

:Your invisible units may be related to [[Known_Bugs#Invisible_Chryssalids|this bug]] - presumably you can trigger similar behaviour by knocking out all instances of a given alien species within a map, saving / reloading, and then waiting for one of the aliens to awake. I was able to replicate it with an Ethereal, for example.

:Difficult to comment on your garbled Celatid without seeing it first-hand. Ditto for your un-stunnable target. I'd quite like to inspect them with my save editor, though, and ditto for the teleported unit. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 05:46, 13 November 2016 (UTC)

Thanks for scaling the images nice to see the wiki syntax.
It's odd to here you say he didn't have enough Time Units left, because for me the move is allowed.
Where did you get your 1.4 patch?
I applied 1.4 too and am wondering if I got a bad version.
Also did you get your original XCOM off GOG or some place like that?
I have the original CD. I think it's the US version as I used to live there.

== Time Units reset to 0 when soldier reaches 255 TUs ==

I have been playing an old version of UFO: Enemy Unknown, where there is no limit on TUs for soldiers. At certain point, two of my best soldiers reached the limit of 255 TUs, which rendered them useless at now they have 0 TUs.
I tried to reduce their TUs by editing Soldier.DAT, but it did not help. If I check soldiers from the base menu, I can see that the value has been changed, but in the battle their stats are still the same and thus they have 0 TUs and cannot be moved with.

Do any of you know, how to fix this bug? Where is the limiter located, can I change it so that is will be as in the new versions? In any case, I believe this bug should be mentioned on the page. It is mentioned here though: http://www.ufopaedia.org/index.php/Time_Units --[[User:Achernar|Achernar]] ([[User talk:Achernar|talk]]) 21:13, 9 May 2017 (UTC)

: Feel free to add the issue - the page is a hodge podge of whatever issues folks have at the time or as they come across them.

: While I'm no expert on the file structure of the executable for the first release of the game, I suspect you'll find the cause for the byte roll-over feature is that there were no stat limiters to begin with. Best way to cope with it is to either retire anyone approaching supersoldier status to base defence duty, buy more soldiers and spread the experience out more evenly, or update to 1.4 and find a sound patch to restore the original sound samples.

: For your broken soldier: I'm, assuming you edited the soldier.dat file. If you saved the game while in the battlescape, the game creates a temporary copy of the soldier stats and keeps them in unitref.dat. This is to keep track of in-battle status changes, experience, etc. You'll need to edit the current TU levels in this file as well. Or beat the mission with the soldiers that can move and you'll see your edits reflected in the next battle. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 05:45, 11 May 2017 (UTC)

== Fire rate bug & German version footsteps ==

These don't seem to be documented for some reason: (DOS Version)

The fire rate always resets to 3 if an alien or an alien mind controlled unit throws a grenade.

If German is chosen as language to play, the footsteps of all soldiers, regardless of the terrain they walk on, will sound as if they are walking on a metal surface like the inside of the Skyranger, UFO or the base. [[User:Bard|Bard]] ([[User talk:Bard|talk]]) 05:38, 8 April 2019 (CEST)

== Direct incendiary hit causing no reaction fire? ==

On the Incendiary page, it is reported that a direct hit will not cause an alien to spin around and return fire. I have tested this in OpenXcom and find that the aliens do, in fact, return fire. If this can be confirmed in original X-Com, it would be good to add to known bugs.

: It's safe to say everything you find on this wiki relating to the classic game pages were gleaned from the original games. OpenXcom, being an independently developed fan project, will have its own list of fixes and changes chronicled in its own documentation. In fact I would not be surprised that good deal of the more technical information on this wiki has been contributed by those that had some input into the OpenXcom project. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 05:16, 8 June 2021 (UTC)

:: Thanks, good to know. Would still love to know if anyone has tested this in classic game. If not, I will when I can, so it can be added to known bugs [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 22:05, 15 June 2021 (UTC)

==Alien weapon loadouts bug/anomaly==
There are actually 10 alien weapon loadout sets, not 9. The actual first set is 70% "early"/20% "mid"/10% "late". This loadout set never appears in-game, though, because the setup at game start counts as a month rollover which means that weapon loadouts (which are called when the mission occurs, not at month start when the mission is scheduled) are called from the second set during January, the third set during February, and so on. This is probably an oversight by the Gollops (note that race weights reach their final values in October; were it not for this quirk, weapon loadouts also would), but it's hard to be sure. Should this be added? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 15:02, 28 April 2025 (UTC)

Talk:Known Bugs

2025-08-08T13:06:57Z

TowigOs: Clarification on no money errors

= Classification etc =

== Bugs vs Exploits ==

Could someone comment please on the distinction between a bug and an exploit, and where to put each one? I would guess that a bug is something that undesirable and an exploit "might be" desirable, if you want to cheat. But what about exploits that happen by accident, or bugs that need to be forced to happen?

I was going to add the Research Rollover bug to the Exploits sections, but they seem to all be under construction. What's the agreed approach?

[[User:Spike|Spike]] 04:16, 15 March 2008 (PDT)

* i think that an exploit is somthing you can trigger and gain an advantage from. a bug may or may not have a known trigger, and does not give an advantage if it does.
: All exploits are bugs, either in implementation or design. When using a bug to gain advantages that bug is used as an exploit (you are exploiting the bug). [[User:FrederikHertzum|FrederikHertzum]] 13:39, 10 May 2011 (EDT)

:: IMHO, Laser Pistols Gifts to train reactions is an exploit, but it does not involve any bugs. It merely exploits the fact that laser pistols will not penetrate the front armor of Flying Suits. [[User:Jasonred|Jasonred]] 16:31, 10 May 2011 (EDT)

::: I guess the point is to differentiate if it's a bug that's being exploited to your advantage, or it it's something confined within the game mechanics that you are exploiting to your advantage (even if using it as intended). -[[User:NKF|NKF]] 02:31, 11 May 2011 (EDT)

:::: Another definition: An exploit is
::::: a) a move allowed by game interface
::::: b) that sidesteps another part of the game mechanics
::::: c) and creates inadequate advantage for the moving player in the process.
::::: An exploit is not a bug, but it can be connected with a bug, if the latter allows a move mentioned in a). Most obvious exploits render whole parts of game mechanics obsolete (see b) above), because they are always more advantageous. In games that feature equal terms for AI and the player, an exploit can be discerned simply by the fact that AI does not use it (sadly this is not true in X-COM). Clear exploit in X-COM: Transfer soldiers = no monthly payment. Suspect exploits: grenade layout. Most probably not an exploit: Sniping (although the inequality with AI is suspect). Clearly not an exploit: dropping weapons to prevent Psi mass murder (this one is made exploitable by the AI unable to pick up weapons, but is not an exploit per se).--[[User:Kyrub|kyrub]] 05:30, 11 May 2011 (EDT)

The dropping weapons sort of turns into an exploit if you do the "everyone suspect of being a psi weakling drops their weapons at the end of the turn. They all pick up their weapons again if unpsied in the next turn." The grenade layout or grenade hot potato is probably not what the game designers had in mind, but I shudder at the thought of someone who only played X-com then joined the army pulling the pin out of his grenade and then dropping it into his haversack or slinging it on his belt. [[User:Jasonred|Jasonred]] 07:43, 11 May 2011 (EDT)

: Yeah, I think we agreed somewhere that shoving live grenades in your pockets and not having them go off is madness. The relay however is not sensible but certainly possible if only a very short one (if with a live grenade), or to toss a grenade forward and prime it at the second to last person. Or more reasonably, something like a stick of dynamite with an extra long fuse. Even that's very dangerous.

: By the way, what does everyone here think of using the mind probe to check if it's safe to attack an alien while standing in full view of it, or if you're right up next to it? I've been using it a lot lately (in lieu of the psi amp), so you could say I've been exploiting the mind probe to my advantage to help me with my decision making. But is that counted as a cheat since I'm picking my moments to attack up close when the enemy cannot return fire? -[[User:NKF|NKF]] 03:30, 12 May 2011 (EDT)

:: When identifying a mechanic as an "unfair exploit" (as opposed to just a "tactic"), perhaps a simpler checklist is this (though Kyrub's is spot-on):

:: a) Is this something the developers should've expected players to do?
:: b) Is this something the developers could've easily prevented?

:: If the answer to both is "yes", then it seems fair game to me. For eg, sniping at aliens: The game KNOWS whether the soldier can see the target (you get a flashing indicator if so), and so it would've been trivial to prevent it. Is it something the regular gamer will try? Certainly; therefore it can be considered expected behaviour. Ditto for using the Mind Probe to make attacks without fear of reaction fire; those things aren't cheap, they sell for a bunch, so it stands to reason that they'd have tactical value!

:: Things like the transfer bug are clear exploits. The devs would've implemented that system so that, if you order personal near the end of the month, you don't end up paying for them twice before they ever arrive - but in the process, they forgot that "purchase" transfers are treated in the same way as "between-base" transfers. To fix one scenario without breaking the other, they'd've needed to code in some extra stuff so the game could tell the difference - they probably just figured the regular gamer would never notice, assuming they ever realised the problem existed.

:: The "dropping weapons" thing is a little trickier to work out - yes, the devs should've seen it coming, but would it've been easy to fix? Aliens could've been twigged to either ignore un-armed soldiers... but those soldiers could re-equip next turn. Aliens could also've been twigged to attack randomly... but that would make their psi powers far LESS effective! I suppose the fix, if any, would've been unarmed melee attacks, but the implementation they went with seems to be the next best thing IMO.

:: In regards to the "grenades in inventory" thing, it's probably common knowledge by now, but they DO go off in the alpha of the game. Presumably someone made a conscious decision to change that, though it could still just be an accidental bug. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:02, 12 May 2011 (EDT)

Sniping at aliens is a very bizarre case, since almost all players will fall prey to the aliens sniping at you long before they snipe the aliens. The behaviour of the aliens to step within sight radius, take one step back, then fire without fear of retaliation *looks* and *feels* like clear exploitation of the rules, but the computer can't be a cheater, can it? So we humans carry that one step further. Mind you, I think X-com would be in trouble if the aliens could snipe you from across the map once they know your positions... especially since the aliens have cheating "if I spot 1 human, I spot ALL of them" abilities. Especially on maps where the aliens get Blaster Bombs...

An interesting note about sniping and LOS: When I first played Xcom, my first mission was in the jungle. Because of all those plants, when my first soldiers spotted an alien, after he shot at him, I tried to make my 2nd soldier open fire and was informed "NO Line of Fire". I could only get my 2nd soldier to fire by positioning him in such a way that I got the flashing number. Henceforth, I assumed that you could ONLY fire at the aliens when the flashing number was there. LOL. LOF. LOS.

Transfer bug wise, I thought that the devs merely programmed the game to count how many staff were currently in the base, then deduct that from Xcom coffers? As far as ordering personnel near month end goes, you end up paying salary for them if you order them more than 48 hours from month end, right? "realistically", they should make staff draw salaries based on when they were hired, but this would be too much effort.

"dropping weapons" would have been easy enough to fix... just teach alien AI how to pick up weapons. Like they did in Apocalypse.

As far as grenade relays go, if you ever join the army, and you toss a live grenade at your squadmate, you're gonna be court martialled! lol. Xcom grenades are weird cause they presumably come with a computer console where you program them or something that takes a lot of TU, if I already have a grenade in my hand I don't think it takes long to prime it compared to throwing it...

Pretty clear exploit/bug is tossing grenades through the ceiling? That breaks all laws of realism/logic/whatever, and I'm sure the devs didn't plan for THAT to happen! [[User:Jasonred|Jasonred]] 18:18, 12 May 2011 (EDT)

: Turns out the "spot one, spot all" thing was wrong all these years. However, units can be "spotted" by sniping an alien, hitting it, but failing to outright kill it; this may have contributed to the misconception.

: The game considers the base to have the correct amount of personal as soon as you initiate a transfer - if a base has room for ten people, you can't send two groups of ten, as soon as the first is in transit the game will correctly recognise that the destination is now filled up and won't allow you to send any more. Likewise, if you hire soldiers, they'll count towards the allowance of more promotions in your ranks before they ever arrive at a base. That is to say, the payment system deals with personal counts in a different way to every other system in the game, making it look like it's intentional (if badly exploitable) behaviour. In terms of transit times, those seem to vary, I know a purchase of scientists takes 72 hours to arrive.

: Er, yes, getting aliens to pick up weapons would've indeed fixed the dropping thing. Shoulda thought of that...

: The grenade thing is indeed unrealistic however you look at it. Certainly throwing the things through ceilings is a bug, and its use is a large exploit. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 20:02, 12 May 2011 (EDT)

:: Then how do the aliens "spot" the psi weakling to target him for psi attacks? Doesn't the game ALWAYS start blasting the juiciest target, regardless of LOS? Or is it just coincidence? [[User:Jasonred|Jasonred]] 22:22, 12 May 2011 (EDT)

::: They really have to "[[UNITPOS.DAT#8|spot]]" the target before they can blast them (however, it appears that later in a campaign this rule gets broken). If they've only spotted a psi-''resistant'' trooper, they typically won't bother to make attacks at all. There's a lot of relevant information in [http://www.strategycore.co.uk/forums/Can-alien-attempt-Mind-control-Pani-t8115.html this thread]. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 23:28, 12 May 2011 (EDT)

: Your talking about your post on http://www.strategycore.co.uk/forums/Can-alien-attempt-Mind-control-Pani-t8115.html&pid=96123&mode=threaded#entry96123 ? Well, I'd just like to point out a massive flaw in your testing logic. You forgot that aliens will launch psi attacks based on chance of success, and chance of success varies based on distance from aliens. In other words, it could easily be that the aliens only attempted psi when your soldier was within sight of them because your soldier was now NEAR to them and therefore they had a strong chance of success.

: Also, as you have noted, it appears that your rule gets broken. In fact, it is not uncommon at all for the Ethereal Commander who is boxed up in the Command Center to launch psi attacks on victims who are separated from him by several layers of walls, as long as their proximity to him is near enough. [[User:Jasonred|Jasonred]] 21:19, 13 May 2011 (EDT)

:: Those are valid points. I've hence built a somewhat more robust testing scenario, which you may wish to [[:Image:Alien Psi Demonstration 1.rar|try for yourself]].

:: The save game consists of cloned Ethereal soldiers (all cranked up to 100 psi strength/skill), and many clones of a single trooper (most of whom have the same psi values). The Ethereals are all cooped up in a sealed room in the SW of the map, with a single trooper who has 140 psi strength/skill.

:: Directly outside the building is another trooper who only has 1 strength/skill. In the NE of the map, in another sealed room, is a soldier with 40 strength/skill. Before placing him there, I had him shoot one of the Ethereals just once, resetting index 8 of his UnitPos record to 0. Only he and the trooper inside the room with the Ethereals have hence been "exposed" to the aliens, but the "best chance of success" is obviously the psi-weakling directly outside the building.

:: If you load the map and end turn, the aliens will first attempt to take control of the dude on the other side of the map, then get to work on the guy in the room with them. Once they've taken these two, they'll completely ignore all other units.

:: In short, aliens can't use psi attacks on a unit UNLESS their UnitPos[8] index is set to less then that of the alien's intelligence stat. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 05:41, 14 May 2011 (EDT)

::: Good one. That test definitely proves a lot, rather conclusively. [[User:Jasonred|Jasonred]] 06:53, 14 May 2011 (EDT)

== Bugs vs Limits ==

''(Discussion continued from [[Talk:Known Bugs#Soldier Recruiting Bugs Tested|Soldier Recruiting Bugs Tested]])''

The "Soldier Recruiting Limit" is not a bug, it is a limitation of the game. Therefore, this should be removed from the page. If we want it somewhere else (like a new page such as [[Game Limitations]]), that would be appropriate. --[[User:Zombie|Zombie]] 01:42, 9 November 2008 (CST)

::Not sure that's necessarily the best idea, Zombie, since many of the entries on the Known Bugs article(as well as some entries on the Exploits pages) are limitations of the game engine. On just a brief glance through, the following caught my eye as engine limitations: Manufacturing limit, Storage limit, Purchase limit, 80-item limit, Proximity Grenade limit, Large units not waking up from stun, Interception last shot bug, Alien UFL radar blitz-through bug(Passing through the detection range of a radar before the detection check comes up), Free manufacturing, free wages, UFO Redux, point-scoring with Ctrl-C, permanent MC of chryssalids, Zombie-MC resurrection of agents, alien inventory exploits, anything involved with bad collision detection, extinguishing fire with a Smoke Grenade, and even your personal favorite, denying the aliens access to their own spawn points. So in conclusion, maybe it should just be left as it is; conversely, all of these entries could be kept where they are and also on a Game Limitations page, or we could leave the headers there and link them over to the appropriate topics on Game Limitations. What do you think? [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:21, 9 November 2008 (CST)

: I agree with AQ (great list of examples by the way - and the Smoke/Fire limit would be another). Many, if not most, of the bugs are "Limitations" but they are logically inconsistent and not what a player would expect to happen: they are imposed by (at best) memory limitations or (at worst) design/programming oversights. I think the easiest thing to do would be to change the title of the page to Known Bugs and Limitations, or put an explanatory note at the beginning of the section to explain that "Bugs" is taken to included "Limitations". [[User:Spike|Spike]] 13:16, 9 November 2008 (CST)

By the strictest sense of meaning, a "bug" is a mistake or error on the programmers part. Limitations imposed by design or memory are not the same creature as the people involved were consciously aware of the decision. I suppose that to the normal player, any type of behavior which is unexpected/unwanted is automatically dumped in the bug category because to them there is no difference. To those of us who study the game files however, the two are unequivalent. Programming oversights, yes, those are bugs.

Some of those limitations AQ mentions are (to me at least) bugs: free manufacturing, free wages, permanent MC of Cryssies (or actually any alien for that matter), Zombie resurrections and collision detection. Large aliens not waking up from stun is again, a bug. The programmers obviously had some issues when dealing with large units in general and never quite got it right. They made some progress in TFTD by trying to fix mind controlling each section of a large unit, but royally screwed it up by selecting the next 3 entries in UNITPOS.DAT no matter what they pointed to.

Perhaps it's just my background in logic which makes me want to push for a separate category for limitations. Then again, as long as everything is listed somewhere I'm happy. --[[User:Zombie|Zombie]] 22:06, 9 November 2008 (CST)

: Actually, taking a look through the page as a whole there are various other Limits described, and the distinction between Bugs and Limits is made quite rigorously throughout - not just in the Soldier Limits and Bugs section, where the Soldier Recruiting Limit is referred to as a Limit whereas other bugs (such as paying salaries for soldiers you can't recruit) are referred to as Bugs. So we maybe just need to rename the pages "Bugs and Limits" and add an explanatory note on the distinction. From a user point of view, rather than a programmer point of view, a bug is an unexpected (inconsistent or illogical) behaviour, so for that reason I think it makes sense to keep them on the same page but try to ensure they are all correctly classified as Bug or Limit.

: By the way, it could be hard to absolutely distinguish Bugs from Limits as I suspect there are going to be some grey areas where you would have to second-guess the intentions and decisions of the coders to know for sure if something was a designed-in Limit, or just an oversight (Bug). [[User:Spike|Spike]] 06:50, 10 November 2008 (CST)

::If we distinguish in this manner, I suggest the definition of "Limit" should be, "Something imposed by the game files or engine as a limitation, most likely in context to the capabilites of the then-current personal computer." More succinctly, anything that was done to allow the game to run acceptably on what was then a PC. This would include both the Soldier and 80-Item limits, the spawn limit(40 units per side), Smoke/Fire limit, and some of the others listed. (The Purchase limit was probably more of a convienence for the programmers than anything, but it is clearly an intended feature.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:11, 10 November 2008 (CST)

: I would add to this that sometimes a Limit may be imposed as a game design / gameplay decision, rather than in order to conserve a constrained resource in the platform (=PC). Also, I would suggest that ''intended'' Limits are Limits, but ''unintended'' consequences of Limits are Bugs. Obviously, making this distinction involves some guesswork. But I would guess that while the limit on total smoke/fire hexes was an intended Limit (to conserve PC resources), the ability to put out fires with smoke grenades and disperse smoke with IC rounds is probably an unintended consequence of the Limit, and so should probably be considered a Bug. Similarly, Base Defence spawn points are probably an intended limit, but the ability to flood spawn points is an unintended consequence of this, and thus a Bug (and an Exploit). (Spawn points should have been shared out 50/50, not humans-first). [[User:Spike|Spike]] 12:07, 11 November 2008 (CST)

::The limit on Soldier and Interception craft were probably more of a limit imposed because they capped the file and figured that X-COM wouldn't ever need more than 40 interception craft or 250 soldiers. (And I've never needed that many, case in point.)

::As for spawns, its actually difficult to take advantage of it in any reasonably established base. X-COM can spawn up to 40 soldiers in a base defense mission(tanks count as 4 soldiers), as a limit of LOC.DAT. Aliens have the same limit. So in order to take advantage of the bug, the base needs 40 or less spawns total. The Access Lift has 8 spawn points, General Stores(weapon-handling) has 11, Living Quarters has 8 more. This is 27 Spawns just getting soldiers in a base and armed. (Although the General Stores can be cut out if you perform the bug properly). Large Radar and HWD have 6 spawns(Small Radar has 2), and Hangar has 15. So overall, the "Spawn prevention" can be hard to take advantage of with all but the smallest bases. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:48, 11 November 2008 (CST)

Just to clarify, X-COM interception craft are not capped at 40 ships. LOC.DAT has a cap of 50 "things" on the geoscape screen at a time. This is shared between X-COM bases, X-COM ships, alien bases, seen or unseen UFO's, terror sites, crash sites, landing sites and waypoints. In a perfect game world with little alien activity and normally constructed bases, the max number of X-COM craft possible is 44: 5 bases with 8 hangars each plus one base with 4 hangars (or any combination thereof). If you illegally modify your base layout with an editor to get rid of the access lift, the max can be increased to 45 ships (9 hangars in 5 bases). Once clogged, all alien activity will cease.

The base defense limit of 40 units exists because of UNITPOS.DAT which has a cap of 80 entries total (tanks occupy 4 entries in this file). Auto-win missions in a base defense mission by clogging all the spawn points with X-COM units isn't as tough as it sounds, especially if your base is small or doesn't contain hangars. The main thing is getting your full quota of 40 units to spawn (meaning you should try not to have any tanks as they count as 4 units but only occupy one spawn point). This limits the base size to something like 5-6 modules depending on what you build. Still, even having more than 6 modules isn't bad as it forces aliens to spawn intermingled between your troops. With 40 armed guys staring in every direction, you can get positions of all the aliens in the first round and possibly even kill them all (depends on weapons and alien race of course). --[[User:Zombie|Zombie]] 20:12, 11 November 2008 (CST)

: I would say that Limits are the CAUSE of bugs... also, I feel that fire/smoke limit can be called a bug, because a player normally has no way to tell this, other than observation. Whereas the game DIRECTLY and CLEARLY informs you whenever you hit the 80 item or 250 soldier limits, which is more fair. [[User:Jasonred|Jasonred]] 15:22, 23 March 2009 (EDT)

Also IMHO it is not true that, say, 250-soldiers limit is a real game bug. In fact, it is not, it is just a rule of the game, or its limitation. And it is unimportant what its reason is (such or another way to store game data).

A bug is, by definition, an unexpected and involuntary result of programmers' work. However, we can only guess what the programmers wanted to attain, so this definition is both unpractical and impossible to be applied. It would be better to assume that a bug is a feature which has negative influence in the game. To clarify: the (un)famous 250-soldiers limitation does not harm in practice, as the number is really enough to play the game. But the even-more-unfamous 80-item limitation does harm and it has negative consequences - it is enough to recall the disappearing of bodies during some missions.

OK, there is no objective criteria to judge whether a feature of the game is a bug or just a limitation. But sometimes subjective criteria have to be enough. Otherwise, we would have to consider the 8-bases limit a bug. Does it make any sense? And if no, what is the difference between the 8-bases limit and the 250-soldiers limit? I feel neither is a bug. Because neither leads to further negative consequences.

And further, IMHO the buggy nature of some game features is quite obvious. If you cannot send more than 100 "parcels" of items at the same time, it is still not the bug. But if you must pay for an item you are trying to send but you cannot do it - it is a bug, perhaps everybody will agree. And similarly: the 255-scientists limitation is not a bug. But the strange behaviour of the game when you bought the 256th scientist is a bug. It would be just a limitation if the game did not allow to buy another scientist. But it allows while it cannot serve the 256th scientist properly, and that is why it is a bug.

So, I vote for removing the 250-soldiers limit from the bug list. If I am wrong in it, please add to the list also:
# 8-bases limit,
# maps with limited terrain (why should they be limited?),
# base area and base facilities limit (why wouldn't we be able to have 10 hangars in a base?),
# etc.

In yet other words, in my opinion it is not enough to show that the game does not allow to have more certain items or to do more certain actions. In order to count this among bugs, we should show that it really harms during playing the game, or just bears negative consequences.

[[User:Sherlock|Sherlock]] 03:52, 27 December 2012 (EST)

= Specific Bug Discussions =

== Misc Technical Bug ? ==

''(The context of this discussion seems to have been lost)''

This is a technical bug that doesn't happen to everyone and one this article wasn't really meant to chronical - but we won't turn away helping a fellow player if it can't be helped. It's just that there are so many random crash points in this game that it would take far too long to find them all or come up with solutions for them.

Certainly, the transfer crash can happen to some players, but it's not one that can be reproduced easily. It's just like the random crash that some players get when they research a floater medic. It crashes the game for some of us, but others don't seem to notice it at all.

It really depends on your hardware and OS setup, whether or not your copy of the game is damaged or your savegame is damaged, etc.

Does it happen in all games or just this one savegame?

- [[User:NKF|NKF]]

-----

== "Invisible Muton" bug ==

Upon shooting repeatedly a Muton, it sometimes plays its "death" animation without sound (as if falling unconscious) and it is no longer displayed in the screen, while remaining visible to my soldiers (I can center the screen and the cursor appears yellow over them). Under this state, they cannot be targeted by Stun Rods. They may play their death animation anytime they get shot, until they truly die, when they emit their characteristic sound and leave a corpse (along with any items carried).

I'm quite fond of laser weapons, maybe this happens more often with those.

Also, though I remember experiencing this quite often fighting Mutons, it may happen to any other high health race.--[[User:Trotsky|Trotsky]] 02:59, 2 July 2006 (PDT)

-----

Never seen that one myself. Another "unpatched game" thing maybe?

There's a (very rare) bug that allows your soldiers to live if they become stunned by an explosion that happens to kill them. Sometimes the game will register their death, and THEN register that they've been stunned. In every case I've seen this happen, however, the unit will have such a low amount of health that a single fatal wound will render it dead (again) on the next turn. I have a vague memory that other players may have been able to get a medkit to the scene on time...

I dunno if that's related to your issue at all (I doubt it, but... meh). I'd advise using a Mind Probe on the alien the next time it happens so you can check the aliens stun/health levels.

- [[User:Bomb_Bloke|Bomb Bloke]]

----

I'm pretty sure I've seen this with Mutons. Possibly Chrysallids as well, another high health, high armor creature. They were still readily killed by shooting the place they are. Good thought on the MP, BB

---[[User:MikeTheRed|MikeTheRed]] 08:51, 2 July 2006 (PDT)

----

I've been known to have a dying muton(in fire) to spin around and then switch to the female civilian death animation. With the scream and everything. Even got a civilian death registered at the end of the mission. And this didn't just happen once, but on another separate occasion.

Hmm. shape-shifting reptilians in the game! LOL! Happens alot [[User:EsTeR|EsTeR]]

Unusually enough, I once had a sectopod die and then drop a tank corpse. I was using the Lightning at the time for my troop carrier, so you can imagine my surprise.

Then there was one occasion where a floater dropped a snakeman corpse. Let's not even get into the sort of things the aliens like to stuff themselves with.

Your invisible alien bug is quite common, although there appears to be many causes for it. I think one involves a full object table when it comes to invisible aliens in bases. But it can also happen in ordinary missions as well. I'm guessing the game may have tried to do something in the wrong order, and sprite information for the unit may have been lost or corrupted along the way.

Having had an experience where all the chryssalids become invisible in one base defence mission was quite a shocker. I fixed this by saving the game, quitting and then restarting the game. If you ever get an invisible alien again, try this and see if it helps. If it doesn't, well, just keep a careful watch on your map and any alerts that pop up as you play.

There's a similar but less severe bug where a dead alien will still leave its centre-on-unit alert button, but this goes away shortly after you move or turn.

- [[User:NKF|NKF]]

----

That last bug happens when exploding Cyberdiscs kill nearby Sectoids, doesn't it?--[[User:Trotsky|Trotsky]] 23:56, 2 July 2006 (PDT)

----

This is a pretty easy one. I guess this bug occured on UFO recovery on a battleship, an alien base assault or a base defense mission? As soon as there are too many items on the map, the game saves some item slots for the equipment to be displayed (since it is more valuable and more important to research). This would also make stun weapons lethal if the stunned aliens would vanish. therefore the game has a failsafe if an alien is stunned (or badly wounded and becoming uncontious). The downed alien's stun level is set exactly on its left health points therefore resurrecting it instantly. This cycle is broken when the alien is finally killed. This means if you want to stun an alien in such a situation you have to destroy some items first.

- by tequilachef (April 4th 2007)

== Vanishing snakemen ==

I've known snakemen to become invisible when standing on a hay bale. On the first occassion I had a poor tank getting shot while spending numerous turns looking for it. On the second occasion I had an alien under Psi-control, left it on the hay bale, and couldn't find it next turn. - Egor

---

This is not limited to snakemen. Hay bale block visibility quite much when a unit is standing on it. Two possible solutions:
- Destroy the hay before entering
- Shoot at the hay. If it is destroyed any unit on it will become visible (as long as no other bales are blocking the line of sight). You might also hit the enemy directly.

I Dnt know if the aliens are affected by this diminished sight, too. My guess would be no.

- By tequilachef (April 4th, 2007)

== Blaster Bomb Bug ==

I'm currently playing through X-com UFO Defense, I have the collectors edition version. I'm in the process of trying to catch a live alien commander and the blaster bomb bug is making this very difficult. If i remember correctly a commander is always in the command center of the the alien bases. The problem is anytime i get close there is always a dude with a blaster launcher up there that tries to kill my troops. When they try to fire it down at me the bug kicks in and they blow up the whole command room and all the aliens in it because they can't figure out how to get the blaster bomb down the grav lift thing in there. This is making it very dificult to actually catch a live commander. Anyone have any ideas for tactics or anything to breach that room without the aliens trying to fire a blaster launcher up there? - eL Hector

: I can suggest two possible solutions. The first is to wait outside the command room for the alien to move closer to you. If it comes out of the room or if you know it has moved down the lift, you then burst in and stand right next to it to stop it from firing the blaster. This is risky because there could very well be a heavy plasma toting alien in there. The other is to use a small launcher and launch it up at the ceiling near where you think the alien with the blaster is standing. -[[User:NKF|NKF]]

== Disappearing Ammunition ==

I have observed that problem with X-COM 1.2, modded with XCOMUTIL. My stun bombs and heavy rocket missiles, along with clips for the auto cannon went missing.
[[User:Vagabond|Vagabond]]

------

Just run a test using my 1.4 DOS version with XComUtil but my stun bombs didn't disappear: 30 + 1 back in the base they came from, same number after I went tactical and I dusted-off immediately. Are you running XComUtil with Runxcom.bat or did you simply run Xcusetup?

[[User:Hobbes|Hobbes]] 22:12, 22 February 2007 (PST)

:Is it a case of hitting the 80-item limit?--[[User:Ethereal Cereal|Ethereal Cereal]] 12:28, 23 February 2007 (PST)

------
With runxcomw.bat, as everytime. Apologies, I retested and it seems like I was mistakened, but I could have sworn that I lost them dang stunbombs. Had to manufacture some. I will test some more, using four heavy weapons and seeing whether their ammunition disappears at all. Thanks. [[User:Vagabond|Vagabond]]

==MC at end = MIA?==

I am sure I have seen this again recently, where I won a mission with no casualties (I thought), but the last thing I killed was a Commander that had been chain MC'ing a psi-attack-magnet trooper, and that trooper was listed as MIA at the end (presumably because he was on the enemy side at the end of combat). Is this a bug, or is there another way to get MIA's on a completed mission that I might have missed?

Since then I have been waiting for the leaders to panic at the end before killing them (or waiting for a rare resist), so I can safely exit, but am I being overcautious?

--[[User:Sfnhltb|Sfnhltb]] 13:45, 27 February 2007 (PST)

If the trooper was mind controlled on the turn you killed the last alien it will be listed as MIA. No bug there :)

[[User:Hobbes|Hobbes]] 18:16, 1 March 2007 (PST)

Huh, why would that happen - your soldier should recover the very next round, why would he go MIA?

--[[User:Sfnhltb|Sfnhltb]] 18:20, 1 March 2007 (PST)

Doesn't make sense to me as well but that's how the game works.

[[User:Hobbes|Hobbes]] 15:05, 2 March 2007 (PST)

----

It seems that regaining control of units under enemy mind control works different for alien and human players. My guess: aliens under human MC are reverted to alien control AFTER THE ALIEN AND BEFORE THE HUMAN TURN while human units under alien control are reverted RIGHT AT THE BEGINNING OF THE HUMAN TURN. This explains three different phenomenons:

- The discussed MIA "bug" (he unit would be returned in the next human turn, but since it never starts it is lost. The mission is still won since no unit with a "genuine alien" marking is left)

- The fact that a mission is lost when the last human falls under MC while it is not won when this happens to the last standing alien (the aliens get their unit back before their turn starts and therefore have a unit left to pass the "anyone alive?" check, the humans would have no unit left to start a turn with. They WOULD have as soon as the turn starts, but no unit left before turn means bust)

- The fact that aliens still can see all an MCed human saw at the end of the human turn that follows the MC while this is not vice versa (The MCed human can give information to the alien side before reverted while an MCed alien is reverted too early). The result is that aliens can control a human indefinitely without having any alien seeing him until the MC is disrupted for one turn.

All confused? Then I did a good job! No seriously, this must be the explanation, I couldn't think of any other way.

- By tequilachef (April 4th, 2007)

: You're absolutely correct on the first two points. It's a sequence issue - you never get round to recovering the unit before the new turn starts, so you end without any units whatsoever. Makes senses too since the aliens would continue to continue to mind control that same unit over and over indefinitely.

: The third point however: The aliens don't need to know the location of the last MC'd unit. They know the location of all your troops whether they've seen them or not from the very start. They appear to give you a few turns of grace where they won't attack you outright (unless, from my observation, all your soldiers are incredibly weak). This is evident because all of the aliens will eventually make their way towards the nearest soldier even though their movement pattern may seem semi-random. Also, they know where you are because they can initiate psionic attacks without having seen any of your troops. They generally go after the weakest troops first.

: Just to add a semi-related point, but from the alien's perspective. If an MC'd alien unit is in the exits when you abort the mission, this alien is not recovered and in fact simply vanishes. Any equipment it was carrying is recovered, unknown artefacts or otherwise. You could possibly think of this as their version of MIA. However, the aliens differ ever so slightly in that if it's the last alien standing and under temporary mind control by the player, the mission doesn't end straight away. But I guess this is only because the player has everything under control, whereas in the other scenario, the Ai is in control.

: -[[User:NKF|NKF]]

My observations show that, at least in some versions of the game (tested with clean DOS 1.4 version, under DOSBox), the game crashes at the end of the human turn if all alien units which are still alive, are Mind-Controlled. If it was confirmed, it would be another not-listed-yet (serious) bug.

[[User:Sherlock|Sherlock]] 17:52, 26 December 2012 (EST)

== Crash Site in the atlantic ocean ==

That's right, my game generated a crash site on water. Here are the details:

- Crash Site a bit southeast of the USA (which was infiltrated a few days before by sectoids, resulting base had already been taken out), but certainly not on land.

- UFO: battleship, floater, alien harvest

- Geoscape: 8 X-Com Bases, 1 (known) Alien base, 2 other crash sites, 1 other (known) flying UFO (though almost worldwide decoder coverage), 3 X-Com Crafts out, 1 waypoint

- Date: January 2000

- Most Interesting: The Craft that downed the ship was a recently finished Firestorm (first human-alien hybrid craft I had built, I know this is lame for that date. Limited myself on 25 Scientists to improve the challenge) equipped with twin plasma. I had it built and equipped in Antarctica and then transferred to Europe. This base had no Elerium, a fact that enabled me to use the infinite fuel exploit which was in effect when downing the UFO. My craft was only slightly damaged when doing so. The battleship was the first target assigned to the craft, it came directly from my base.

- When shot down, the UFO was not targetted by any other craft.

- I had not lost or sold a single craft to that point.

- When sending a squad to the crash site the game didn't crash but generated a farm land ground combat terrain.

- I was not able to reproduce the bug from the savegame dated 2 hours before downing the UFO

Well guys, any intelligent guesses? I still have the savegames (before and after downing)! If you want to have a look, write here.

- By tequilachef (April 5th 2007)
----
: Well I'm sure you know about crash sites that are near land can sometimes actually be on water, so I'm going to assume that this site is well far away from any land mass. Could it be a weird entry in GEODATA\WORLD.DAT that has a land mass out in the ocean? Also are you sure the game didn't crash? Sometimes when it does it will load the previous mission (and usually 90% are at farm terrain). Are you sure it generated a new map and not load the last one?
:No real guesses but maybe some starting points to look at. I've probably stated some obvious situations you know about and have accounted for, but it never hurts to double check :D
- [[User:Pi Masta|Pi Masta]] 14:23, 5 April 2007 (PDT)

== Inconsistencies in MCing Cyberdiscs and Sectopods ==

I experienced, that when MCing one quadrant of a large terror unit any action it does only affects this quadrant (especially use of time units). That means, when TUs are up for one part, MC another one and continue firing. This however does not work out when moving the unit while it is not under complete control. The TUs used up by the resulting reaction fire from the rest of the unit is also deducted from the TUs "your" part has left (making it impossible for the controlled parts to return fire). This however only happens under reaction fire, not if "your" part fires on it's own. I don't know if this comes up when uncontrolled parts shoot by themselves in the alien turn, since this is hard to find out.

: That's because large units literally are made up of four separate units. They only share the same set of general stats (in unitref.dat). Unfortunately the 'under mind control flag' is unique to the four units, not the shared stats! So you in effect have multiple units under different control sharing the same stats. So if you move and it results in a reaction from the unit, it will spend the TUs you're using.
: Successful mind control automatically fills up the unit's TUs, so each mind controlled sector gets to move or attack again until there are no more sectors to mind control. Useful way of turning reapers into long range scouts!
: In TFTD, they attempted to fix this bug, but in fact made it much-much worse! The only way to mind control the unit properly is to control the upper left quadrant. Only! Any other quadrant will result in a partial (clockwise) control, and you may gain control of units other than that unit, or may even get into situations where you gain permanent 'partial control' of a large unit you haven't even sited. Wackiness all around!

:- [[User:NKF|NKF]]

== Facility Dismantle Bug ==

Boba: I've never experienced this bug myself in all my games in the Collectors Edition. It may very well vary from computer to computer.

-[[User:NKF|NKF]]
:I, however, have experienced it. I lost an entire month's worth of playtime because I couldn't solve it. [[User:Arrow Quivershaft|Arrow Quivershaft]]

::Anyone, any ideas on why it might vary from PC to PC? -[[User:MikeTheRed|MikeTheRed]]

:::I'd check other factors before blaming a given system. Assuming no mods are being used the most obvious is the order in which you initiated the construction of the modules. Then we've got which one was due to be completed first, and I'm sure there's a few other things to test out. Usually, a player won't cancel in-progress modules on a regular basis, so you wouldn't expect this bug to turn up often. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

:Easy way to reproduce: build 2 General Stores. Now delete the "second one" (see offset 16-39 in [[BASE.DAT]] for the order). Wait for the first one to complete. It'll crash immediately after the "end of construction" dialog. A fix is available [[User:Seb76#Bug_Fixes | here]]. [[User:Seb76|Seb76]] 15:52, 22 July 2008 (PDT)

== Manufacturing Limit Bug ==

Unfortunately, Mike, no you did not get it correct. It is the raw number of hours needed to complete the project, not the projected hours. I discussed this on the X-Com Forums a few months back at the following link: http://www.xcomufo.com/forums/index.php?showtopic=242027760&st=0&#entry164411

I did tests at the time in regard to the accuracy of the data given there, but I've lost the results. I'll quickly redo the tests in the next hour or so. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:00, 8 June 2007 (PDT)

:Tests complete. The breakpoints for every item were exactly where I predicted, regardless of number of engineers assigned. (I ran up a huge queue of items at my dedicated factory base on an old game, and then assigned whatever engineers would fit onto one project at a time, canceling projects as data was confirmed. This is only semi-random, but it serves our purposes.) I did run into a single issue, though. It appears that despite having 5 empty hangars at a (different!) base, the workshop there could not queue up more than 3 of any one craft at a time, thus making this bug impossible to replicate with the Firestorm or Lightning, as you must be producing more than three for the bug to occur. However, it still works with the Avenger. Later, I shall see about constructing a dedicated Hangar base with 7 hangars in order to attempt to replicate the bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:33, 8 June 2007 (PDT)

::Sounds great, Arrow. Why not post a simple example that shows how the problem works. As in, "with 1 Eng and 2 Avengers you might think X, but no, it's Y". And please delete my example. And it's a fine pleasure to meet you! Cool - [[User:MikeTheRed|MikeTheRed]]

:::When you say the usual resources are used by the "lost" resources, that includes cash, right? It sounds like if you're willing to foot the extra bill [[Buying/Selling/Transferring#Manufacturable_Prices|money/component-wise]], this could be used to build Avengers slightly faster then normal.

::: The usual time is 34000 hours. Double that and subtract 65535 and you're left with a paltry 2465 hours. Even a single workshop squad of 10 engineers will pull that off in a little over ten days. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

::::Sadly, this exploit doesn't work, because the high bit is stored SOMEWHERE. I lack a hex reader and have no code reading skills to speak of, so I'm a bit limited here. If you set up a Workshop as you described, the game would take all the time for 2 Avengers, all the resources for the same, but in the end only produce 1 Avenger. Meanwhile, I'll run more tests on the resources thing. I could swear it consumes the resources, but I'll double check.

:::::There is no need to store the high bits if the actual completion condition (assuming adequate money) is "number made is number ordered", which wouldn't reference the hours remaining at all. - [[User:Zaimoni|Zaimoni]] 01:49, 9 Oct 2007 (CDT)

::::Tests done; I was unable to replicate the 'disappearing item' trick,(Which I didn't test for last night) even with Avengers! It appears I was wrong; this still counts as a bug, though, because the wraparound is a problem.

::::Ironic that so much of this discussion centers around Avengers, because that's where I discovered this in the first place! [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:48, 9 June 2007 (PDT)

----

I'm revisiting XCOM and was working on [[Manufacturing Profitability]]... Arrow, can you (or anyone else) say a little bit more on the Known Bugs page about this [[Known_Bugs#Manufacturing_Limit_Bug]]? It's not clear to me exactly what the bug does, except that it understates hours. Is that all?... does it still take the (non-buggy) amount of time, still use all the same resources, still make the same number, etc.? It sounds like it could be a drastic bug - or is it only a very superficial one, a display bug for the hours? It sounds like you're leaning toward this latter.

Also on a semi-related note... I could swear I saw much more detailed info on the [[Known_Bugs#Facility_Maintenance_Costs]] issue... IIRC, the incorrect amount that's charged for maintenance, depends on exactly where a facility is in the base. IOW, different "rows" of the base cost different amounts. Could somebody provide a link there, and/or flesh the bug out better?

Thanks! - [[User:MikeTheRed|MikeTheRed]] 11:22, 8 October 2007 (PDT)

:I've actually seen the bug work both ways, but I've only been able to actually replicate the more superficial version of the bug. So the bug report up is about a superficial bug that drastically understates production time. If you wish to make this clearer, you have my blessings. As well, that 'different charging based on location' is dealt with here: http://ufopaedia.org/index.php?title=Talk:Base_Facilities ; however, the table has been broken with the Wikiupgrade, and I lack sufficient knowledge of HTML table code to fix it. But it should be of use to you. [[User:Arrow Quivershaft|Arrow Quivershaft]] 11:26, 8 October 2007 (PDT)

::Cool, I fixed [[Talk:Base Facilities]] but also re-organized and expanded [[Base Facilities]] so that it includes that bug in detail, as per Talk... this is an important issue that should be up front. I see that there's a separate [[Maintenance costs]] page, but I can't see having something so important (the maintenance bug explanation) all on its own page (which makes for a rather short page) rather than together with all the rest of the base facility info. If others agree (or don't care), I'll move anything remaining on Maintenance Costs to the Base Facilities page, then delete Maintenance Costs and re-route links. And if somebody does care, then please move my new section to Maintenance Costs, and move all the links, etc. Oh also I put in more words on your Manufacturing Limit Bug - how does it look? - [[User:MikeTheRed|MikeTheRed]] 16:37, 8 October 2007 (PDT)

:Looks pretty good, although it'll wrap fully; if you ask for 120000 hours, it won't be displaying 'almost no' time. The way I discovered it was when building two Avengers; I ordered two, paid for two, waited for two...and got one. But as said, haven't managed to repeat it, so until I do, we'll leave it like that. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:00, 8 October 2007 (PDT)

::I just revised and put in your specific example, because it's certainly possible some of us die-hard players will order up more than 1 Avenger at a time - and it's guaranteed it'd be a pain if 1 of them disappeared, laugh. I wasn't sure how concrete you were on that example but now I hear you say, you are sure it happened at least once. - [[User:MikeTheRed|MikeTheRed]] 18:33, 8 October 2007 (PDT)

:I have a question concerning the manufacturing "bug" which eats a craft in production due to wrap-over of the byte. Arrow (or whoever did the test), did you have a large quantity of craft already built at your bases? If so, I think this bug has more to deal with clogging up [[CRAFT.DAT]]. See, that file has a limit of 50 entries. Each craft takes up one record and each base you have built also consumes one spot. 8 bases allows 42 craft to be housed, while 6 bases allow 44. If you try to buy or manufacture craft once the file is full, nothing shows up in the game even if you have hangar space available. --[[User:Zombie|Zombie]] 19:00, 8 October 2007 (PDT)

::Huh, I never knew that. I don't see it listed on the Bugs page... I'll stick it in there. I've never approached that number, but some folks might. - [[User:MikeTheRed|MikeTheRed]] 19:07, 8 October 2007 (PDT)

:I was able to continue building other Avengers after that project, and they appeared correctly, so I do not believe that is the issue. In any event, I have a very bad case of 'archivism' and probably still have the save game and the CRAFT.DAT file around on my system; in fact, I think I was playing it a few days ago. I can see if I can find it and upload it; it created a 'hole' in the Avenger fleet numbers, where Avenger's x and x+2 were built, but x+1 was not. I'll look for it tonight and tomorrow and upload it to the wiki if I find it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:10, 8 October 2007 (PDT) EDIT: I found the file; I have 28 Avengers and 1 Skyranger in my employ. All Avenger numbers EXCEPT #2(Avenger-2) are accounted for, and I have not sacked or lost any Avengers. So this is where the hole and 'eaten' Avenger is. If anyone wants the CRAFT.DAT file from this game, I'd be happy to forward it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:20, 8 October 2007 (PDT)

::Sure, send it my way and I'll take a look at it. (Might as well send me the whole saved game as I may want to look at the other files too). I have tried to recreate this bug by manufacturing 1, 2 and 3 Avengers at a clip but all of them always show up. Don't know what else I could do to get this problem to crop up. --[[User:Zombie|Zombie]] 21:32, 8 October 2007 (PDT)

:File emailed. On the side, I've tried the same thing, and never been able to repeat the bug. It's been months since the first discovery, so I can't recall whether it was the first or the second Avenger that didn't appear. So maybe it was just a fluke. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:57, 8 October 2007 (PDT)

== Unconscious Enemy in Equipment Screen ==

The following happened to me repeatedly over the last few days.

In the last tactical Mission a live alien has been captured. When now beginning an UFO crash recovery mission this type of alien (same race and rank) appears in the equipment screen before the mission starts, meaning I can give it to any of my soldiers.
If I do so I can store the alien in the skyranger for the duration of the mission and, if it gains consciousness, kill or stun it at the end of it. A pile of equipment without a corpse will be in the UFO, indicating that the stunned alien is not some kind of duplicate but instead has been taken from the aliens of this mission. This is supported by the fact that in those missions the maximum number of crew members has not been surpassed.
If I do not do so the Alien will be placed in the crashed UFO. Whether it is unconscious or not I do not know, but the fact that it is completely disarmed when encountered in the battle suggests that it is.

So far it seems the following is necessary for the bug to occur:
# An alien has to be captured alive in the last tactical combat
# It has to be of the same race and rank as one of the aliens in the new tactical combat

So far this only worked...:
# If the new tactical combat was an UFO crash recovery of a medium scout.
# For floaters and mutons
# For soldiers and navigators
# If the alien in the last mission was stunned by normal weapon fire (although I do not think this is important) and not picked up (again, not likely to be important) or destroyed (which would mean it has to be actually captured)

It seems NOT to depend on the following:
# The type of the last mission (were, so far: Ground assault battleship, crash recovery large scout, base defense)
# Which squad or vessel was involved capturing the alien
# Where it is locked up
# If it has been transferred since capture or not

Would be interesting to know:
# What happens if the alien in the inventory screen is the only survivor
# If the alien in the invenory screen is one of the aliens randomly killed in the crash or not (it is likely to be one of the killed aliens, so far the equipment piles were always within the UFO)
# If this is not limited on crashed medium scouts: Does this work with terror units? What about large ones?

Maybe this is related to the proximity grenade bug (transfer of item properties to next tactical combat).

Additionally, in one of those mission a part of the terrain was not generated correctly. It was in farm terrain (The house on the right square, or north east square, in [[Image:Terrain-cult.gif|this pic]]). The outer wall right to the right window of the southern wall (1st Floor) was missing. Directly outside of the hole was a floor tile. I could walk a soldier through the wall, but he fell right through the tile. Dunno if this has to do with the stunned alien bug.

Version is collectors edition (the one from abandonia.com).

----------------

When a mission starts, the GeoScape engine generates the unit and object tables (in MissDat's [[OBPOSREF.DAT]], [[UNIPOS.DAT]], and [[UNIREF.DAT]]) before "shutting down". The Tactical engine then generates the maps, places the aliens on it, and blows up the UFO (if need be). Whether or not map generation and the subsequent events happen before you equip your soldiers I don't yet know.

The test would be to check the aforementioned files to see if they contain an unconcious alien, and/or the body.

Note that you can't see the bodies of large units on the ground (they count as four seperate objects covering four seperate tiles, so allowing the user to pick one up would essentially let you rip them apart).

- [[User:Bomb Bloke|Bomb Bloke]] 06:35, 5 August 2007 (PDT)

----------------

I honestly have no idea of how all those files work. But I still have a savegame in battlescape that is in one of those missions. So if anyone wants to have a look at those files...

I forgot to mention: I reloaded a geoscape savegame shortly before the battle to recreate the bug, but it seems that reloading in geoscape before the buggy battle eliminates the bug. I guess his should narrow down the possible reasons...

--------

Next time it happens, backup the aforementioned files before you start another mission. I'm afraid a savegame wouldn't be of much help.

- [[User:Bomb Bloke|Bomb Bloke]] 00:54, 7 August 2007 (PDT)

== Soldiers moved to outside of combat screen ==

Hi, I've got a DOS version of UFO:EU, and I've encountered a bug in the tactical combat. Sometimes (rarely) a X-COM soldier changes its location on the map on player's turn start and is placed on outside of the map, one tile north from the (north) border of the field. AFAIR the unit is then selectable (you get the flashing highlight when cursor is above), but is stuck outside of the field. Has anybody encountered this bug? It seems to happen randomly, but more frequently during the terror missions and on early turns (so maybe it's caused by high number of player/alien/civilian units?). --[[User:Maquina|Maquina]] 08:16, 3 September 2007 (PDT)

:I've never encountered this bug in CE of UFO. Presuming AFAIR means "As Far As I Recall," what exactly was the soldier doing? Any equipment data, location, or stat info might help us pin it down. Were afflicted soldiers always carrying a specific equipment set or weapon? Where were they on the map before they got moved? Did they get bumped a few spaces, or teleported halfway across the Battlescape? Does it happen more often on a specific difficulty?(Your theory would suggest this would happen most commonly on Superhuman) Against a certain type of alien? Best of all, if you can recreate the situation in a game, save the game and then you could upload the save file to the forums or this wiki, and the rest of us could take a look for ourselves and the code divers could root around for the cause. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:03, 3 September 2007 (PDT)

:: I've had this happen to me several times in UFO and TFTD. I don't know if it's specific to the Dos version or if it can happen in the CE as well. Sometimes the soldier ends up beyond the boundary of the map right at the start of the mission, at other times it happens after you load a game. This game is glitchy, which is the source for so many of its bugs, so your soldier's coordinates are probably getting corrupted to the point where they are -1 on either the X or Y axis of the maps's normal boundaries. For me it's commonly along the top edge of the map. I don't ever recall it happening mid-mission, only at the start or after a load. I cannot faithfully say whether it happened with or without XComutil, but that could be one of the possibly many causes for this. - [[User:NKF|NKF]]

:: I don't play UFO often, so I rely on just several campaigns played. This happens rarely (I've encountered this bug twice in my last campaign with ~80 missions played), but if you haven't seen this happen then it probably doesn't show up in the CE edition. In my experience the soldier is moved always beyond the north/top map border. I think (but I'm not sure) that this affects the first soldier from the team more commonly than others (or maybe even exclusevily?). The equipment/armor carried is probably not relevant, since the units moved this way don't have any special stuff, and this bug shows up on different stages of the gameplay (ie. sometimes when you have ordinary rifles, sometimes when all your units got heavy plasmas and power suits). --[[User:Maquina|Maquina]] 04:12, 4 September 2007 (PDT)

'''MY ramblings have been moved to my discussion page''' [[User:EsTeR|EsTeR]]

==Great Circle Route==

Should we have the Great Circle Route bug noted on this page at all? [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:33, 6 October 2007 (PDT)

: what is the great circle route? [[User:Jasonred|Jasonred]] 07:56, 31 March 2009 (EDT)

:: Pick two points on a globe, then hold a thread or string taut at those two points. That practically minimizes the length of the thread/string on the globe. You're now looking at a great circle arc (or route), the shortest distance between two points on a globe. -- [[User:Zaimoni|Zaimoni]] 11:15 March 2009 (CDT)

: Just as a line is the shortest distance between 2 points on a flat plane, a great circle is the shortest distance between 2 points on the surface of a sphere. The bug, by the way, is that aircraft in the game ''don't'' follow this shortest, "great circle" route. [[User:Spike|Spike]] 12:38, 31 March 2009 (EDT)

:: What a grand sounding name, for something so simple, lol. ... I thought you were talking about when you tell your soldiers to go from point A to point B, and for some reason they figure that Zone A and Zone B are really far apart, despite actually being side by side. (I shot a hole through a wall, clicked to walk to the other side, and my idiot soldier walked one big circle... to use the door! And got ambushed and killed by an alien. ... dum dum DUMB DUMB.)
:: Even the more modern games have problems with their pathfinding algorythms. Admittedly, games like Baldur's Gate had to do it in realtime.
:: On a semi-related note, I remember this guy called E-man, he was chasing a guided laser beam that was going to kill his girl, around the world, but he couldn't outrun it since he couldn't break the speed of light, only equal it by changing into a Laser himself. So... inspiration! He turned into a very powerful laser, and made a shortcut THROUGH THE EARTH... the straight line beats the great circle route, lol.
:: Thanks for the reply guys [[User:Jasonred|Jasonred]] 15:56, 31 March 2009 (EDT)

Added to article. [[User:Spike|Spike]] 16:41, 3 September 2012 (EDT)

==Bug not listed: Missing soldiers during base defense==

I encountered an interesting bug concerning base defense missions:
My base got attacked while about 30 soldiers and 10 HWPs were present. The usual equipment assignment screen was skipped and the mission started instantly with only the HWPs spawned at the map. Not even a single soldier bothered to show up... *sigh*
Although this turned out to be in my favor (you should have seen the puzzled Ethereals trying to panic my tanks) I´d like to avoid this bug if possible. I was able to reproduce this bug several times and with different bases.
Can anyone explain this bug and/or tell me how to avoid it?

Game version: Collectors edition. - [[User:NewJoker|NewJoker]]

-----

Well, ideally, we need to know what your base's construction was to be sure of this, but I think the most likely circumstance is that the HWPs took up all the spawn points. HWPs have maximum priority for spawning(followed by Soldiers, and then Aliens), so if you have enough of them garrisoning a base, it's entirely possible that soldiers and aliens won't spawn. However, this doesn't explain why the soldiers didn't start stealing the Alien spawn points...in any event, you might want to take the save game file, zip it up, and get ready to email it. I'm sure [[User:Zombie|Zombie]] would be quite interested. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:28, 13 November 2007 (PST)

-----

It's not the spawn points, it's a [[UNITPOS.DAT]] limitation. A maximum of forty records (out of the total of eighty) are allocated for your units, and tanks (which take up four records each) get first pick. Having ten tanks means there's no room left for anything else.

Ditch one HWP and you should see four units take it's place. - [[User:Bomb Bloke|Bomb Bloke]] 16:42, 13 November 2007 (PST)

-----

I´ll try with a decreasing number of tanks and report the results. As I wrote above having only HWPs isn´t too bad dependent on what enemy is attacking. [[User:NewJoker|NewJoker]]

----

This should be mentioned in the [[ExploitsE#Base Defence Mission Spawning Issues]] section. The Bugs/Exploits really need to be sorted and consolidated. - [[User:NinthRank|NinthRank]] 16:57, 13 November 2007 (PST)

-----

The limitation to 40 records seems to be the case; each tank I dumped got replaced by four soldiers.
So this can be used to effectively manage unit combination. Thanks for the quick replies! [[User:NewJoker|NewJoker]]

==Bug not listed: Ufo Gold (Windows Vers. abandonia.com) crashing when plasma defense is finished==

I recordnized this bug a few times now. (with hacked AND unhacked game)
If i place a plasma defense in 7 bases at the same Time and they are finished at the same Time, the game crashes sometimes.
In hacked game, it seems to crash even more when Alien containment is finished, plasma defense, shield defense...etc.
couldnt find it here...greetz

: I somehow doubt the sourcing is the issue. [You may want to fund the next XCOM series game with a Take2 re-release of UFO :)] More generally: the game only reports the construction of a given type of facility once, no matter how many bases it completes at simultaneously. I've only tested this in vivo with three-of-a-kind at once across six bases, however. It does seem reasonable that some sort of counter of undisplayed completions would "overflow" (attaining crash). -- [[User:Zaimoni|Zaimoni]] 10:05, Feb. 28 2008 CST

::I've encountered this bug myself with General Stores, actually, not just Plasma Defense(which I never build). EDIT: Some quick tests seem to show that there's a chance the game will crash any time two base facilities are done at the same time, regardless of whether they're in the same base or not or if they're the same facility.(although it seems to happen MUCH more in the event they're in different bases.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:13, 28 February 2008 (PST)

== Soldier Recruiting Bugs Tested ==

Just to note that I have positively tested and replicated the bugs listed under the new(ish) section [[Known Bugs#Soldier Recruiting Bugs|Soldier Recruiting Bugs]]. [[User:Spike|Spike]] 18:08, 19 March 2008 (PDT)

==Floater Medic Bug==

I have not thus far encountered the Floater Medic Bug; in fact, Floater Medics are often used to fill up my Rogue Gallery with interrogations. [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:50, 24 April 2008 (PDT)

Strange, it would always occur in my version. I don't remember where I got it from, but I
know it was a download from the internet. Using the XCom Hack v2.5, I viewed the alien in
the Alien Containment edit. I now have Type (race):____, and a Rank: Soldier for the
Floater Medic. It might just be corruption, but I do not have the resources to look into
it. [[User:Muton commander|Muton commander]] 19:24, 12 May 2008 (Pacific Time Zone)

I've never encountered it either. [[User:Magic9mushroom|Magic9mushroom]] 07:47, 23 July 2009 (EDT)

I think this only happens in the CE version. A disassembly of the code reveals that the stack to hold the matrix for what topics have not yet been researched is too short. It seems that those who ported the code from DOS doubled the local variable sizes blindly. There is already a problem that there are two-few bytes necessary for the entire alien organism section of the UFOpaedia, but double the expected size of the registers and it fills up quite easily unless a lot of autopsies and interrorgations have already been done. The only other situations that are handled by the same routine are the navigator revealing mission data or engineers revealing ship data, but there isn't enough topics in either section to overflow the stack variables. - [[User:Morgan525|Tycho]] 08:27, 22 June 2013 (EDT)

==Strength Overflow==

During one of my games with TFTD I noticed a really annoying thing happen during battles.
As my troops rose up the 'stat.' ladder they got better and better (as you'd expect), until they hit about 50 strentgh and completely lost the ability to throw anything.
Even trying to throw something tiny like a grenade or flare into the adjacent tile resulted in the 'Out of Range' message being displayed.

Anyone come across this before?
This was in TFTD CE.
[[User:Tifi|Tifi]] 07:55, 27 April 2008 (PDT)

:This is fairly well documented. The pathfinding algorithm for throwing objects will balk if anything is in the way of the throw and refuse to allow you to throw. What's happening is that your soldiers have become so strong that their throws are intercepting the 'ceiling' of the Battlescape(the top of L3), and as such the game thinks that the throw is blocked(because in order for the throw to complete, the object would have to be tossed up to the nonexistant L4). There's two ways around this:

:The Normal Way: Try shorter throws, throwing from lower heights, or throwing while kneeling. Beyond that, possibly get some new troops.

:The Sneaky Way: Manually edit the Strength scores of your soldiers in [[SOLDIER.DAT]] so that they're back to a usable strength level. If you set "Initial Strength" (offset 46 decimal or 2E hex) to 0 and "Strength Improvement" (offset 57 decimal or 39 hex) to a value of 50, you can permanently lock the soldiers at 50 strength. (You can lock them higher than that if you so choose, but not lower.

:Other than this, there's no workarounds I can think of offhand. [[User:Arrow Quivershaft|Arrow Quivershaft]] 08:10, 27 April 2008 (PDT)

:: There's normally no problem with the max level of 70 in open settings. However TFTD has a lot of low ceilings such as in the shipping lane missions and colonies, and the lower ceilings impairs your throwing quite a bit. In addition to shorter throws/kneeling, try moving out from under any overhangs if there is one just above you. - [[User:NKF|NKF]] 12:33, 27 April 2008 (PDT)

== Bug not listed: Sticking your head through the ceiling ==
This is something I just discovered: When you step on a small object inside of a building your soldier sticks his/her head through the ceiling and can see what's upstairs. You can even see the soldiers head coming out of the floor and that soldiers can shoot aliens upstairs. When I did this the alien I saw/shot was facing the other way, but I guess you could get shot if the alien was facing you. [[User:RedNifre|RedNifre]] 17:34, 11 May 2008 (PDT)

:That's not listed under "Bugs" because it's covered under "Exploits", right here: [[Exploiting_Collison_Detection#See_Through_A_Ceiling]] [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:26, 11 May 2008 (PDT)

:: I don't know if it was ever covered anywhere, but there's this neat trick that might sound similar to the walk-through-'wall object'-wall trick except that it involves your unit climbing slopes. They'll appear as though they've gone up a level, but are actually not on that level. They only visually appear to be there, but are really still on the bottom level.

:: It happens a lot when walking up the desert or forest slopes. I think the trick involves standing on ground level, and then ordering the unit to 'move' into the hill rather than setting the waypoint while on level 1. The soldier will move up the slope and perhaps stop on the slope or even reach the top of the slope, but will still appear when you're only viewing the ground map layer. The soldier is really still on the ground level, but will have elevation offset.

:: One really interesting way of using this trick is in the mountain region. If you can find a cliff face and a low hill nearby, you can literally have your soldier scale the cliff by standing the soldier on the hill, and then walking towards the cliff. It's ridiculous, but your soldier never quite reaches the top of the cliff tiles, so ends up walking up a slope.

:: On a side note, standing at the top of the ramp of the Skyranger is the same as standing on ground level - you're only offset a bit. This means that smoke on level 1 and the sides of the Skyranger will not provide protection when you're at the top of the ramp.

:: On another related note in relation: In TFTD (doesn't happen a lot in UFO), you might find it difficult to toss grenades onto underwater slopes. To remedy this, raise the level up by one. It might look like you're tossing at air(and you are), but it'll get the grenade where you want it. Odd, but true. I must remember to put this in the grenade explanation section. -[[User:NKF|NKF]] 23:11, 11 May 2008 (PDT)

== Base Defence bug that causes a crash? ==

Does anyone know about a bug in a base defence mission that causes the game to crash? The game keeps crashing on the 4th or 5th alien turn.

:I've encountered that myself, but it should be noted that overall, X-COM is not the most stable game and is prone to crashing often at anytime. The differences between the hardware it was designed for and the hardware we're running it on cannot be helping matters at all; it's really a small miracle it even runs without an emulator in the first place(I've got games from 1999 that will bluescreen my machine instantly). As such, I'm not sure it's worth noting as a bug, since it's a 'game feature'(albeit a detrimental one). In any case, what're you doing letting the aliens attack you anyways? ;) [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:33, 18 July 2008 (PDT)

:It sounds like an alien is in one of the outlying locations and attempting to destroy the top floor item. Possibly a radar or defense station. - [[User:Morgan525|Tycho]]

== Sources for a DOS4GW transplant ==

I was specifically thinking of the LucasArts Dark Forces demo, but I half-recall the actual source I used when testing that ~1999 was Id's DOOM. -- [[User:Zaimoni|Zaimoni]] 16:03, 7 August 2008 (CDT)

== Phantom Carried Casualty ==

You are carrying an unconscious soldier in one hand, and the soldier dies of his/her wounds. The dead soldier remains visible on the "left hand / right hand object" battlescape display, but is no longer visible in the inventory display. The problem can be fixed by moving another object into the same hand.

I've seen this bug with UFO Extender by [[User:Seb76|Seb76]] - possibly might be something to do with his manipulation of the inventory screen, rather than a general bug. I believe I've also seen this with other objects that were being carried in the hands, disappearing from the Inventory screen, but I'm not sure. I don't think it's an item limit bug, as XcomUtil shows 40 item slots free. [[User:Spike|Spike]] 08:58, 21 September 2008 (PDT)

:I think it has to do with the KO units KIA mod. Its doesn't take into account units held so when it tries to detemine where to place the corpse, there is no location. The routine doesn't undo the item-carried-sprite-ID byte for the holder. -[[User:Morgan525|Tycho]]

== Civilians As Enemies to MC'd Aliens ==

I ran across this issue a few times and just wondered if you guys experienced this. I MC'd a part of a Reaper (I always do the lower left for large aliens) on a Terror Site, then moved it a few squares. It suddenly stopped dead in it's tracks and then the alien spotted indicator increased by 1. When I clicked on the indicator to see where the enemy unit was, it brought me to L2 of the large apartment complex. However, nothing was there. When I sent a Flying-Suited soldier up there to peek in the window (eeek! A peeping tom!) he saw a female civilian standing there. This type of problem has happened numerous times to me so it's not a once-off thing. Maybe it's a LOS issue? Or maybe an alien indicator problem? Or a combination of the two? Don't know, but I'm curious if you guys have seen it. --[[User:Zombie|Zombie]] 23:40, 19 December 2008 (CST)

:There are a lot of major issues with MC'ing 4 square aliens. One of them being that you could accidentally MC an alien far off in the corner of the map, IIRC? Anyhow, maybe you should have tried MC'ing all 4 squares of the reaper and see if that changed things. -[[User:Jasonred|Jasonred]]

The long-range MC of other aliens when Mind-Controlling large aliens is only present in Terror From The Deep, due to a workaround to try and resolve the earlier bugs(and exploits) associated with controlling one square of a large unit at the time. In TFTD, successfully MC'ing part of a Large unit will also grant you control of the next three units in UNITPOS.DAT, in order. If you didn't MC the upper left portion of the large unit(the first UNITPOS entry for any large unit), you can potentially wind up in control of other aliens. So this doesn't apply to UFO. As for Zombie's issue, never seen it. And finally...Jasonred, on Talk pages, please indent your statement with colons so it differentiates from other people's comments, and sign your posts with 4 ~'s, like I will now do. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==Elerium Base Bug==

Jasonred: This bug has long since been known about. Elerium units on the Battlescape can be picked up by shooting away the power source; this one item counts as 50 units, and as such ANY elerium item spawned on any Battlescape counts as 50 Elerium. This issue with your own Elerium spawning as collectable loot in a Base Defense mission only occurs in older DOS versions, and is at the whim of the 80 item limit. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:55, 18 February 2009 (CST)

:Base defense does not seem to follow the 80 item limit in that DOS version. There are a lot of bugs that have long been known about. However this one was not included in the ufopedia for some reason.
:Also, the main thing about this bug is that it does not potentially double your elerium stores. It potentially multiplies them 50 times.
:... First time this happened to me, I was pretty flabbergasted. Here I was being conservative with my limited Elerium, refraining from blowing up UFOs when possible, when I perform a base defense and gain 3000 Elerium from it. Holy spit. -[[User:Jasonred|Jasonred]]

Alright, my error. Thanks for clarifying. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==HWP Fusion Bomb and SWS PWT Displacer Ammo Manufacturing Cost Bug==

At a cost of $15000, 400 Tech hours, 5 Zrbite, and 8 Aqua Plastics, this is the exact same cost as the HWP Fusion Bomb from X-COM EU, converted over to the equivalent TFTD resources. As such, it shouldn't be counted as a bug, since it is clearly what Mythos intended. [[User:Arrow Quivershaft|Arrow Quivershaft]] 09:55, 15 November 2008 (CST)

:Hmm, in that case maybe it should be treated as a generic game engine issue and not a TFTD specific issue - but I still think it's a design error. Can you think of any logical reason why the SWS/HWP version of the ammo should be more expensive (in cost and in materials) than both the craft ammo and the (more powerful) personal ammo? It makes no logical sense. Hence I think it's a design error. Nothing can be inferred from the fact it's unchanged from XCOM-EU, that doesn't imply any deliberate decision. It could just be the replication of an original error in XCOM-EU. [[User:Spike|Spike]] 11:17, 15 November 2008 (CST)

:: I can think of a logical reason to justify this: X-Com doesn't understand the technology as well as the aliens do (which is obvious, given the length of time each side has known the tech). Handheld Blaster/Blaster Bombs are just a copy of the alien design and therefor relatively cheap and efficient, but that can't be mounted on a turret. So X-Com has to make a new design, and they obviously didn't do that good a job as the aliens would have done. This explains Tank/Plasma being weaker than Heavy Plasma too. (Why is FBL Craft ammo cheaper than the tank ammo though? Maybe X-Com gave up on/simplified the guidance system and made it just a "dumb" cannon shell/torpedo instead which doesn't have multiple waypoints? Or maybe they just did a better job there?). [[User:Cesium|Cesium]] 04:07, 25 November 2009 (EST)

:Whilst we discuss it, I'll park my original text in here:

* ''Displacer/PWT ammo cost bug - at over $100,000 total cost per round, the ammunition for this SWS weapon is far more expensive to manufacture (both in money and rare materials) than the equivalent ammo for the Aquanaut-carried Disruptor Pulse Launcher, or the craft-based Pulse Wave Torpedo, despite being less powerful than either. This would seem to be a design mistake.''

See Also [[Talk:Displacer/PWT]]

:: I don't like the higher cost either, but I think it's a tradeoff of expense and quality for the convenience of portability. Sort of like an MP3 player to the gramophone... or maybe that's not a good comparison. -[[User:NKF|NKF]] 13:43, 15 November 2008 (CST)

A better comparison might be a desktop computer to a laptop. As a general rule, laptops are more expensive, but a similarly priced desktop gives you more power. Desktops are cheaper and offer power, laptops are more expensive and offer portability(though the gap is rapidly narrowing). [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:49, 15 November 2008 (CST)

:I think those are good analogies. But they don't apply in this case. To continue your analogies: We are paying mainframe prices for a clunky desktop that has only laptop processing power, and we're buying a mainframe for desktop prices. The vehicle version ("desktop") - is ''less'' portable and ''less'' powerful than the personal version (DPL = "laptop"), ''less'' capable than the craft version ("mainframe") - 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 SWS use up ''more'' of both Zrbite and Aqua Plastics than the Craft version. Do we really think it's logical that a tactical battlefield round, less powerful than its man-carried equivalent, takes more explosive and structural material to produce than both the more powerful man-carried version and also more than the air-to-air round that has 60km range and can take down a major alien combat craft? There is a clearly perverse bang-per-buck here, on every measure. My sincere belief is that this was an original mistake in the XCOM-EU engine that got copied into TFTD as well. The craft round should have the higher base price, but 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. But what I don't think is debatable is that is not logical for the SWS/HWP rounds to be more expensive than the craft rounds. It's clearly a mistake. Even in game balance terms, the only thing the HWP/SWS rounds have going for them is conserving "80-Item Limit" space, which I severely doubt was ever a game design consideration since it's just an awkward programming compromise. Any advantage inherent in the HWP/SWS is already reflected in the very high platform cost - there is no need to inflate the ammo costs as well. The bottom line is that a round for a (mini-)tank does not cost more, does not use more materials, than the same type of round for a long range anti-aircraft weapon that has much greater damage capacity and penetrating capacity. [[User:Spike|Spike]] 14:35, 15 November 2008 (CST)

I'm going to add this to the bug list now. [[User:Spike|Spike]] 16:06, 25 February 2009 (CST)

:Still don't think this is a bug though. Just because it's more expensive to manufacture than the hand-held or craft-mounted ammo, it doesn't mean the stats are wrong. Perhaps the programmers wanted to balance the tactical portion of the game a little more by making the ammo cost more for tanks. It doesn't have to be logical to be intended. Now if you had proof which said that the ammo was supposed to cost less but the stats were wrong, then yes, I'd agree. So if you boil it all down it comes to a disparate logic issue, not a bug.--[[User:Zombie|Zombie]] 21:31, 25 February 2009 (CST)

::I have to side with Zombie here. While the ammo may be disproportionately expensive, by the definition used on the rest of the page for bug, it doesn't fit. All the other bugs are errors in program logic or function or routines that are unintentional problems with the game, most of which are not warned of ahead of time. The ammo for the tank costs exactly what is listed and operates entirely as intended, whereas the rest of the bugs are not intended game features. Even if the numbers were entered wrong, that would be a data entry error, not a program bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:28, 26 February 2009 (CST)

:If it was a data entry error, I'd consider that a type of bug... assuming we had proof of the goof so to speak. LOL. --[[User:Zombie|Zombie]] 00:49, 26 February 2009 (CST)

:: It feels too specific an entry to be a data entry error.

:: I'm reminded of the high explosive. I know, I know - it's not an exact parallel to the FBL issue. A High Explosive is practically two grenades. Double weight, double bulk. Slightly above two times the damage. However, it costs five times the price of a standard grenade. Even though you're paying more for not-as-much, I don't think that could be considered a bug. A rip off, yes, but not a bug.

:: Here's a thought: Think about the immediate benefits each of the two controversial ammo types give back to you. Aircraft ammo = activity points. Tank ammo = loot. Yes, I know that aircraft ammo also generate crash sites, but you still have the ground combat to contend with.

:: One other thought: With careful management of your ammo, you'll probably never spend any elerium on the handheld version's ammo. Could it be the handheld that's really at issue here rather than the others? In the end I feel that it doesn't really matter. -[[User:NKF|NKF]] 03:38, 26 February 2009 (CST)

: I'm with Zombie that a data entry error is a bug (we have other examples), but also agree some proof is probably needed. And I agree with NKF that in the scheme of things, it doesn't really matter much. I don't think the HE pack is a good comparison (though the HE pack should be heavier) as it's reasonable to pay disprortionately more to get additional power at the same tech level. The fusion weapons are a case of paying more to actually get ''less'' power. I am not bothered by the handheld vs vehicle balance, not least because the game generally makes handheld weapons better than their vehicle equivalents, so I can accept that as an across-the-board design decision.

: I can also see a game balance argument ''if'' we believe that Fusion Tank ammo is more of an overall game-winning weapon than craft Fusion Bombs. But I'm not sure I agree with that statement. And even if it's true, and there's a game balance argument (in which case it would apply equally to handheld Fusion launchers), it's still illogical. The less powerful, battlefield warhead should not cost massively more in exotic materials than the much more powerful air to air warhead that brings down Battleships. I agree though that just because it's illogical does not prove it's a bug (i.e. unintended). [[User:Spike|Spike]] 07:48, 26 February 2009 (CST)

Ok we more or less seem to be in agreement that this isn't a bug, but it is very confusing/illogical. Maybe we can shift the "bug" text from the article page and roll that into the [[Hovertank/Launcher]] and [[Displacer /P. W. T.]] pages now. Feel free to combine any text from the discussion above if necessary. --[[User:Zombie|Zombie]] 09:22, 26 February 2009 (CST)

: Unless we can ''prove'' it's a data entry error (unlikely), how about calling it an "Anomaly" instead of a bug? [[User:Spike|Spike]] 10:59, 26 February 2009 (CST)

Looks like plain old game imbalance to me.
The way I see it, Hovertank Plasma and Launcher were meant to be stronger. Much much stronger. Let's look at Tank Cannon, Launcher and Laser. The logic is that it's a tank mounted weapon, so the tank can carry a much larger and more powerful version of the same weapon, right?
It's pretty stupid that a Hovertank Plasma is weaker than the Heavy Plasma... you could just mount a Heavy Plasma on a Hovertank and get them exactly equal. In fact, I suspect that the hovertanks were ALSO meant to have more powerful weapons than the man-portable versions.
Unfortunatly, the game designers then realised that this made the hovertanks far too powerful. So... the programmers nerfed the power of the hovertank weapons. BUT they forgot to lower the ammo costs. [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 11:20, 26 February 2009 (CST)

: Well you are opening up a much larger issue there. The Fusion weapons are an anomaly, an inconsistency. But handheld weapons are more powerful than equivalent vehicle weapons across the board, consistently. So that looks like a deliberate design decision, not a mistake. [[User:Spike|Spike]] 17:33, 26 February 2009 (CST)

:: There are two exceptions to the rule: Tank/Cannon: 60AP vs. Heavy Cannon 56AP. Tank/Laser: 110 Laser vs. Heavy Laser: 85 Laser. The hovertank\plasma only differs by a measly 5 (an extra 0 - 10 damage, which means a lot vs. UFO inner hull armour). I guess the trend here was to moderate the area effect tank strengths. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

I'd have to agree with you there Spike. This wasn't a mistake, however odd it may seem. It was a deliberate attempt to try and balance the game. Below is a table I created ages ago for my (now defunct) strategy guide detailing the HWP's and what handheld weapon corresponds to it. When you stick them side-by-side, it really becomes apparent that the programmers were trying to base the HWP weapons off the handheld weapons somewhat. The only thing that doesn't follow a nice and distinct scheme is the damage. That's what is the clincher. --[[User:Zombie|Zombie]] 20:26, 26 February 2009 (CST)
 
<table {{StdCenterTable}} class="sortable">
<tr {{StdDescTable_Heading}}><th align="left" width="150">Tank Type</th><th width="70">DAM</th><th width="80">Snap</th><th width="90">Aimed</th><th width="90">Aimed</th><th width="80">Snap</th><th width="70">DAM</th><th align="right" width="140">Handheld</th></tr>
<tr><th align="left">Tank/Cannon</th><td>60</td><td>60%</td><td>90%</td><td>90%</td><td>60%</td><td>561</td><th align="right">Heavy Cannon</th></tr>
<tr><th align="left">Rocket Launcher</th><td>85</td><td>55%</td><td>115%</td><td>115%</td><td>55%</td><td>87.52</td><th align="right">Rocket Launcher</th></tr>
<tr><th align="left">Laser Cannon</th><td>110</td><td>50%</td><td>85%</td><td>84%</td><td>50%</td><td>85</td><th align="right">Heavy Laser</th></tr>
<tr><th align="left">Hovertank/Plasma</th><td>110</td><td>85%</td><td>100%</td><td>100%</td><td>86%</td><td>80</td><th align="right">Plasma Rifle</th></tr>
<tr><th align="left">Hovertank/Launch</th><td>140</td><td>--%</td><td>120%</td><td>120%</td><td>--%</td><td>200</td><th align="right">Blaster Launcher</th></tr>
</table>
1AP rounds. 
2Average between the Small and Large Rocket.

: Hold up! Tank rounds do 60AP. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

So what's wrong? The table says 60 for the Tank/Cannon and 56 for HC-AP. Those are correct, no? --[[User:Zombie|Zombie]] 23:41, 26 February 2009 (CST)

: Sorry, didn't realise it was two tables side by side (or rather mirrored). Eyes only noticed the left side of the table. -[[User:NKF|NKF]] 23:53, 26 February 2009 (CST)

:: If the Hovertank Launcher did 200 damage, or worse if the Hovertank Launcher did EVEN MORE damage than the Blaster Launcher... that would make them easily the most deadly things on the map. As it is, the hovertank launcher is already pretty overpowered, even with 140 power.

I might be six years late here, but I think there could be an explanation for this in RL physics — indeed, in RL nuclear weapons programs. Incoming wall of text.

There are two sorts of nuclear reactions that produce energy: fission of large nuclei, and fusion of small nuclei. Fission can occur under normal temperatures and pressures, but involves a neutron chain reaction. As such, fission devices have to have a certain mass of fissionable material (the ''critical mass'') so that the neutrons stay in the material and cause more fission rather than escaping; this means that such devices cannot be scaled down below about suitcase or large backpack size (not all of this is actually nuclear material; rather, most of it is conventional explosives used to rapidly assemble the supercritical mass from subcritical masses). They also produce large quantities of radioactive fallout, which is problematic. Fusion, on the other hand, requires extreme temperatures and pressures, but does not necessarily require a neutron chain reaction. This means that they can theoretically be scaled down to much smaller sizes... except that the only available compact source (ie, not building-sized) of those extreme temperatures and pressures is the detonation of a fission bomb. Thus, all known fusion weapons currently in existence involve a relatively-small fission stage that detonates a much more powerful fusion stage.

The "Holy Grail" of nuclear weapons research is what's called a [[wikipedia:Pure fusion weapon|pure-fusion weapon]]. Because it has no fission stage, a pure-fusion weapon would release little fallout (note here that fallout is material that emits radiation long '''after''' the detonation; a pure-fusion weapon would emit copious amounts of deadly neutron radiation when actually used, but that would dissipate within seconds) and could be scaled down to grenade-launcher size (though it would obviously be far more powerful than a conventional grenade). They would be far easier to produce, as well; producing weapons-grade uranium and plutonium requires large and powerful isotopic separation equipment and/or a full-sized nuclear reactor, whereas deuterium can be extracted from water with trivial ease and lithium and tritium are relatively simple to obtain and make respectively. The main issue is that while the pressures required to confine the fusion material during the reaction are achievable with chemical explosives, the temperatures necessary for fusion are emphatically not. You need a stronger initiator; some material with a higher energy density even than plutonium. In RL the only initiator strong enough is antimatter — hard to produce and contain, to say the least — but the aliens in X-Com have a source that's stored far more easily... Elerium.

I posit that the "fusion" line of weapons in X-Com are exactly what they're named: tactical fusion bombs, made possible by an Elerium detonator. (A more controlled reaction on those lines — a fusion reactor with Elerium-spiked fuel — in UFO Power Sources would also explain the discrepancy between the calculations based on fuel efficiency and the lack of city-killer blasts when a Power Source's Elerium cooks off.)

Given the assumption that "fusion" weapons are indeed fusion weapons, with Elerium serving only as a detonator, the oddly high Elerium cost of the Hovertank/Launcher's ammunition is finally explainable. The HWP Fusion Bombs are, literally, smaller than Blaster Bombs and craft Fusion Balls (presumably because of size constraints in the launching mechanism in tanks). Having less explosives to compress the fuel means you need an even higher temperature to compensate — thus, more Elerium detonator — but because the actual power of the bomb is mostly from fusion and not Elerium decomposition, the yield is still lower.

I intend to remove this from the list of Known Bugs on this basis if nobody can find a hole in my logic. [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 02:03, 17 April 2015 (EDT)

:I'll have to disagree. Your argument while interesting, is just supposition and an attempt to give validation by taking ideas (that the developers probably never considered) to justify a flaw, very much in the same manner as those who try to explain why UFOs do not respond in interceptions. In truth, like many of the other bugs listed here, they are the result of issues caused by the time constraints the Gallops where under. Much of the production/buying/selling aspects of the game have game balance issues and don't make sense when cross referenced to other similar elements in the game and/or their overall effect to either combat or the strategy layer, especially in regards to the game's economics. [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]]) 05:06, 17 April 2015 (EDT)

::Why would they match up in terminology with the actual use to which any military would put Elerium by accident? Because, no shit, if a military got their hands on a substance with Elerium's properties this is literally exactly what they'd do (at least as far as explosives go). I can cite a paper talking about the superiority of antimatter-fusion weapons to pure antimatter weapons if you want; the title is "Fourth Generation Nuclear Weapons: Military effectiveness and collateral effects". [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 05:21, 17 April 2015 (EDT)

:quote all the sources you like, it still doesn't explain the waste in the manufacture process. With elerium being such a "scarce" resource, there is no logic in producing something that require more elerium and delivers less of a battlefield effect. It would be more logical and efficient to have had the platform fire regular blaster bombs, since they only require 3 elerium not 5.[[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])
::IMHO, any logic argument can be presented to why those HWP Elerium Bombs should cost less/more or be more efficient. That is not the point here. A bug is when a game feature is working improperly or/and is causing technical issues, either due to limitations, insufficient testing, whatever. Design choices are a completely different matter: the Heavy Laser is a nearly useless weapon due to its stats but no one ever considers it to be bugged due to its stats. It was a choice, that was slightly changed on TFTD with the Heavy Gauss. To consider the stats of the HWP Fusion a bug then you'd have to label a lot of choices as bugs when they are simply design choices. You may not agree with them but that doesn't make them bugs in the generally accepted definition of the term. And quoting Arrow Quivershaft on the top comment of this discussion: "At a cost of $15000, 400 Tech hours, 5 Zrbite, and 8 Aqua Plastics, this is the exact same cost as the HWP Fusion Bomb from X-COM EU, converted over to the equivalent TFTD resources. As such, it shouldn't be counted as a bug, since it is clearly what Mythos intended"[[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 19:35, 25 April 2015 (EDT)
::Also, the consensus until now expressed by several people that previously discussed this is that this is not a bug. The main supporter of the bug argument seems to be Spike at the beginning but during the discussion but halfway the discussion he says: "I agree though that just because it's illogical does not prove it's a bug (i.e. unintended)" [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 20:54, 25 April 2015 (EDT)
You don't get to claim benefit of the doubt here, Tycho. All game features are assumed to not be bugs unless there is compelling evidence presented otherwise. You claim this is a bug based on the suppositional logic that more powerful weapons should cost more and almost nothing else. The price wasn't altered (and neither was the power) in TFTD, so there's no evidence of mistake there (as an aside, the Displacer/Sonic having its power listed as 130 when it's 110 in the game engine clearly ''is'' a bug). The only bit you might be able to interpret that way would be the description of the Hovertank/Launcher's weapon as causing "immense devastation" compared to the description of the Blaster Bomb as "highly powerful" (the potential implication being that the HWP Fusion Bomb is stronger), but that's iffy at best since there's hardly a graded table of adjectives in use and on those very same pages in the UFOpaedia it lists the damage of each weapon as what it actually is.

The claim that it's a bug is based entirely on theorising about yields. I've given alternate theorising that would explain the yields (and I already explained that the semi-automatic nature of the Hovertank/Launcher and physical space for its high ammo could justify the need for a smaller round), which undercuts that claim. We can't know who's right, but the assumption should always be that the designers knew what they were doing; to assume until proven otherwise that they had no clue is extreme hubris and contempt. Moreover, you are in a minority of one or perhaps of two against a majority of several. Your claim to representing consensus is blatantly false.

Now, I'm going to wait a couple more days to see if anyone comes forward with anything substantive, as I waited a week after my reply to your original non-refutatory dismissal, and then reinstate the removal if nobody puts forward a cogent objection. [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 22:57, 25 April 2015 (EDT)
:Now that I think of it, though, an "oddities" page where we talk about this, the shitty Heavy Laser/Heavy Gauss, the No More Soldiers limit, and other not-bug things might be in order. It would help to make this page about actual bugs and not about weirdness that is nevertheless clearly as intended. Thoughts? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 23:04, 25 April 2015 (EDT)

:At the time, I didn't continue the argument as my point was that removing something based on one person's belief, no matter how cleverly thought out, wasn't good enough to warrant removing from the list. (I would have pointed out all the different theories on UFO interception AI, but I see that has already been removed.) I hadn't read all the discussions because I assumed that no consensus had been reached, similar to the Interception AI discussion. Mushroom, could have just pointed out that this issue was already settled years ago but no one bothered to removed it from the list, instead of resurrecting a "dead" discussion as though it had not been settled and just stated that the developers intended to discourage the use of this HWP by making the cost of its ammo high. I still don't agree that the HWP ammo is more efficient and thus justification for its production cost, especially since the developers would have never needed this level of justification or would have had the time to devote to so small an aspect of the game.

:I definitely agree that this page needs to be updated. Another reason I argued so strongly is because so many topics on this page do not fall into the category of bug as has been defined. I thought this page was also devoted to listing all the illogical aspects of the game due to the lack of enforcement on the definition. [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])

::If I only had a dime for each time someone proposes to change something on this wiki, everyone agrees, and then nobody ends up taking action... :) It's always better to take initiative and edit things. I agree also with an update to this page, and separating bugs from limitations. But definitely no more 'this should have been done this way' arguments to present design decisions as 'bugs' [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 17:43, 26 April 2015 (EDT)

:Okay. I'm planning to rip out the following and stick them on a separate page:

:Great Circle "bug" (this isn't really a "bug" so much as unoptimised code)
:Side-on Intercept "bug" (ditto, but given UFOs' tendency to alter course suddenly it's not even particularly unoptimised)
:Head-on Intercept "bug" (come on, this is just bitching)
:Instant Getaway "bug" (more an anomaly than a bug)
:80-item limit (intentional and the rationale is obvious to boot)
:Purchase limit (working as intended)
:Soldier recruiting limit (being charged for attempting to buy more is a bug, but the limit itself isn't)
:Soldier battlescape limit (there's a consequence of this which is a bug, the CtD with 10+ tanks, but not the limit itself)
:Manufacturing Completion Time Display "bug" (you can look at it and see what time it finishes, and it goes down at the right rate; it may seem a little unintuitive but it isn't "wrong")
:Manufacturing Rate Interruption Loss "bug" (more bitching)
:Manufacturing Rate limit (working as intended; the attempt to get around it in TFTD is bugged, but the EU behaviour isn't)
:HWP Fusion Bomb Ammo Cost "bug" (we're in agreement here it seems)

:There's plenty that need a tidyup on top of that but as far as the page split itself goes, are we agreed? Also, I'm thinking of calling the page "Anomalies and Game Limits", opinions? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 01:58, 3 May 2015 (EDT)

== DOS4GW - What the heck is it? ==

It's been ages since I had to remember this stuff, so those who remember clearer than I do, forgive me if my descriptions aren't accurate. Hopefully the general idea will come across.

Back in ye olde days of computere gamynge - and where there were more E's to go around, memory handling was a tricky beast to handle. Computer memory is divided into several different categories. Conventional, extended and I think expanded. I might be jumbling the terminologies for the last two a bit. Doesn't matter - memory was just cut up into small segments. The two most common memory types to PCs at the time were pretty small but were readily available. The third one - the most expandable (aka the chip with its massive 4 Megs of RAM you just spent your whole month's allowance on!), wasn't as easy to get at.

To get access to the higher memory that was available to the computer, special memory handlers had to be used. Drivers like HIMEM, emm386, etc were used.

DOS4GW is one such handler that lets the game access the computer's available expanded memory. Lots of games that came out at the time use this. Doom, Duke Nukem 3d, Syndicate, Ultima Underworld, X-Com UFO/TFTD, etc. LOTS of games. Any time you ran a game from the dos console and you saw the Dos4GW message flash by briefly it would be assisted by it (well, it stayed on the screen for ages back when processors were slower!).

It took the hassle out of memory handling and let the game access the available memory on the computer as one big flat block of memory to play with.

So what was meant in the article was to simply replace the dos4gw.exe with a more up-to-date version from another game. I think the way to tell its version was just in the message that it displayed. You can just run the dos4gw.exe file in a console window. It'll give an error, but the message it shows will indicate its version. UFO 1.4 uses Dos4gw 1.95, for example.

-[[User:NKF|NKF]] 01:22, 6 March 2009 (CST)
:DOS4GW also switched the processor from 16bit to 32bit mode. [[User:Seb76|Seb76]] 13:58, 6 March 2009 (CST)

== Clipping ==
I have a new bug. Its harmless. I have a savegame (EU CE - modified game) which has a sectoid within another sectoid. In the alien turn, one secturd walked off the roof and dropped down <s>onto</s> into another. (I guess there DNA is indentical afterall, so they 'become one' with the world). If you want the savegame (superhuman edited using UFOloader, UFO Mod v1, xcomed, Khor Chin WeapEdit v0.1) drop me a request on the my page somewhere. [[User:EsTeR|EsTeR]] 01:40, 18 September 2009 (EDT)

: Not something many would encounter, but definitely something that can happen. Units can occupy the same physical space, but the game cannot display them all. It'll only draw one of them. Actually saw this effect happen back in the early days of XComutil when it gained the ability to manually add new aliens into a battlescape. It did this by slotting them into the same spaces occupied by existing aliens. Then the fun would happen when you saw a couple of Mutons suddenly walk out of a sectoid. Not sure how the game determines who gets hurt when struck by a bullet. May very well depend on the order they are stored in the unitpos.dat file.

: There are a couple of ways you can replicate this in-game, but I can only provide theories on how you could do it. Such as shooting the ceiling above you and letting the unit drop through, or moving a tank off a ledge and getting its non-primary segments land directly on top of another unit. By the way, the rear end of tanks get stuck in walls if you attempt to move north or east off any ledges. -[[User:NKF|NKF]] 02:18, 18 September 2009 (EDT)

: Ok, so as long as others know about this, then all is good. I had never seen it and was doing alot of head scratching until I shot the alien.

== Berserk HWP crashes the game ==
In the article page it mentions that aliens which go berserk with their integrated weapons will crash the game. This is only true for Mind Controlled aliens (or units under X-COM control) - alien controlled units which go berserk do not crash the game. I tested an MC'd Celatid just now and it doesn't crash the game either, though it doesn't immediately go berserk - it waits another turn for some odd reason. Someone want to check this to verify my results? --[[User:Zombie|Zombie]] 20:31, 27 December 2009 (EST)

==HWP Morale Loss==

HWPs have 110 Bravery, which [[Morale#Effect_of_Bravery|normally prevents morale loss]], but I wonder if they can still lose morale due to loss of units with a morale-loss modifier. It'd depend on how the math is done. If, for, example, the -20 to morale for a dead unit is static, then multiplied by any [[Morale#Officers|morale loss modifier]], then reduced by 2 for every ten point of bravery, any officer death without another officer on the field will necessarily reduce HWP Morale.

It all depends on how the equation plays out and when modifiers are added. For sake of this post, I propose the following as the morale-loss equation: 20*(rank death modifier)-((Bravery-10)/5)*(1.00-Leadership bonus)=Morale Lost. (Rather than using 22 as a base, I'm going to assume Bravery is internally decremented by 10 for this equation as 0 Bravery is impossible without editing and it makes the math easier for the purpose of the example.)

It makes sense to me that rather than having 110 bravery hard-coded as an exception to "No morale lost", it simply works the same way in the normal equation, but is high enough that it negates most morale loss events, as even if an officer is killed, another officer is usually left on the field to help negate the penalty. That said, if a large portion of the team is wiped out at once, any surviving officers may not be able to negate it all, allowing tanks to start having noticeable morale loss.

So with the death multipliers, we can determine that every XCOM officer killed has a set death value. Rookies and Squaddies are -20, Sergeants are -24, Captains are -26, Colonels -30, and Commanders -35.

For example, under this theory, if a Sergeant is killed with no other ranked units on the field, a Squaddie with 50 Bravery would lose 16 Morale. (20*1.2-(50-10)/5*1.00=16). A HWP would, at the same time, lose 4 morale. The Sergeant's death is worth -24 Morale, and without another officer on the field to ameliorate the loss, the Tank's bravery only can 'absorb' 20 points of the morale lost. If it was instead the Commander lost, with no other officers on the field, the HWP would lose instead 15 points of morale, given that a Commander's death (20*1.75) is worth a whopping 35 points of morale loss if no other officers are present.

And if you have, say, four colonels and the Commander on rear/psi duty, and some alien flings a grenade or a blaster bomb into the back of the Skyranger and blows all three of them up and they were the only officers, the HWP has now lost 55 morale, which gives it a 10% chance of panicking/berserking on the next turn!

In the end this'll probably need to be tested for accuracy, but those are my thoughts right now.

Also, for the record, most units that berserk go to 255 TUs while still using the original TU-expenditure calculations; it's part of what makes berserk units so dangerous. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:34, 11 January 2012 (EST)

:Tested it under vanilla CE. Took a squad out containing just about every rank there is (commander + colonel + captions + sergeants), plus a tank. Blew up and killed all soldiers with a single blaster bomb shell, leaving just the tank, which lost no morale (sorry).

:I also brought a group of rookies along with a single commander + tank, and killed just the ranked unit. Tank lost no morale. A rookie with 60 bravery lost 17 (which matches the loss predicted by the formula currently on the morale page), whereas under your formula he should've lost 25.

:Still, you're on the right track. I've long had my own theory as to why tanks have been known to lose morale. Take a look at [[UNITREF.DAT#42|UNITREF.DAT[42]]] - this is the offset that stores a unit's rank. Notice something? The value gets higher as the X-COM unit's rank gets higher. Works in ''reverse'' for aliens, for whatever reason. I sorta figure it's so killing a mind controlled alien commander doesn't mess with your morale too badly, but there's a big problem with that theory and you can probably tell what it is...

:If the highest this figure gets for an X-COM unit is 5 (commander rank), then a killing a mind controlled alien ''terrorist'' with a rank value of ''7'' should net an even higher morale loss penalty. And indeed it does - I took a rookie and a tank to a terror mission, mind controlled and killed a terrorist, and the tank lost 10 morale. Guess it would've lost six if I'd taken a commander instead of a rookie, but that's still something.

:Note that the formula on the morale page does ''not'' account for this - it states that at bravery 110 the alien's death loss multiplier would always be applied to a base morale loss of 0, but that's obviously wrong. You're spot on in saying that the base morale loss figures are not totally dependant on bravery, and the "death loss" penalty is applied first. Would probably require a few more trials to determine what that penalty ''is'' for alien soldiers and terrorists though.

:Just for kicks, I edited a plasma tank to have 0 morale. It panicked in the normal way (either sitting still or charging off to the SE). When it berserked, the game crashed as soon as I dismissed the status message. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 18:54, 12 January 2012 (EST)

:: Thought I'd give it a spin. I sent a laser tank in with a squad and had it start shooting at team members. Each time it killed an ally, it would lose morale. Once it was under 50 morale, I waited until it panicked. Since I was playing the dos version, the game didn't crash but I suspect a memory leak of some sort may have occurred that would normally shut down the CE version. What would happen in CE if a soldier were to be edited and granted a tank turret, and then made to panic? Would the game crash? I'm just wondering if it's related to the weapon as opposed to the fact the tank is a treated as a large unit. -[[User:NKF|NKF]] 00:43, 13 January 2012 (EST)

::: Ah, friendly fire! Thought I'd tested for that, but obviously not...

::: Oddly enough, now that I try it, I see that the twenty point hit for killing a unit on the same side can be adjusted by the leadership bonus of the victim. Eg, kill a lone commander and his 35% penalty reduction takes the extra morale lost from 20 down to 13 (which is exactly how much a tank will lose, given that it otherwise wouldn't lose any at all).

::: Of course, this completely messes up my theory about alien soldier/terrorist ranks overriding the 110 bravery score. It doesn't. My tank "only" lost 10 morale because the alien's rank acted as a 50% leadership bonus... Though I suppose that's still interesting to know, because it suggests that keeping a simple alien soldier under mind control is more effective then risking your own commander in the field.

::: I took an otherwise unarmed rookie and assigned him a tank cannon + ammo. He could manually fire this weapon in much the same way a tank can. Forcing him to berserk crashed CE, under DOS he just spun around. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 21:20, 13 January 2012 (EST)

== 80-items limit on CE edition ==

I have the feeling that the 80-items limit does not apply to the CE edition and is instead a 110-items limit (at least during base defence). Can anyone confirm? [[User:Seb76|Seb76]] 16:24, 24 February 2010 (EST)

:I believe this limit was increased for TFTD. Maybe it was also increased for the CE edition of UFO, and only ever applied to the DOS edition of UFO?? [[User:Spike|Spike]] 20:03, 11 March 2010 (EST)

== Paying for Dirt in TFTD ==

I have the steam version of TFTD and am unable to replicate this bug. Testing with the starting base, I dismantled a few modules, added up my income and expenses, and it reconciled with my cash at the beginning of the next month. I even tried again, dismantling every module except the access lift, and once again saw no income discrepancy. Am I missing something, or is it possible this bug was actually fixed in TFTD? --[[User:Jewcifer|Jewcifer]] 12:18, 16 March 2012 (EDT)

:'twas probably fixed. It would indeed be helpful to add a small note to bugs on this page which are EU-specific but not obviously so (like this one). -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 17:14, 16 March 2012 (EDT)

::Every now and then I get the urge to test some of the more important bugs myself in my steam version of TFTD. Perhaps I will make a more complete effort and record the results somewhere on the wiki. --[[User:Jewcifer|Jewcifer]] 12:08, 21 March 2012 (EDT)

== Paying for dirt: Source of bug discovered! ==

Well, I never have read this anywhere (which kind of strikes me as odd, thinking of how obvious this one seemed to me... And i have NO programming background whatsoever), so I'll post it here, hoping that there are still some active members willing to try and verify my findings. If so, please comment here, because then I will inform bladefirelight to include this in any upcoming xcomutil release. If it had been discovered before, well then I just wasted some time here. Comment below, I will delete this entry.

As the main bug page mentions, when dismantling a facility still under construction the premium will only be paid once it would have been finished. This suggests some connection between paying the premium and building time. Looking into the infos here: [[BASE.DAT]], I quickly discovered what the problem was: When a facility is dismantled, the Bytes related to the location of base facilities are updated correctly. HOWEVER the game omits to update build time to FF (which is "will never finish", an entry only found on unused squares). If the facility is finished when it is dismantled (or destroyed during combat), then the 00 in the build time byte will stand. If it was under construction, the value indicating the remainig build time will continue to tick down towards 00 as if the facility was still there.

Now at the end of the month the following seems to happen: The game checks for ANY 00 entry in the build time bytes, and if there are 00 entries, it will look up in the location bytes the type of structure to determine the amount of maintenance for that 00-construction-time-square. When it finds "dirt", then it will charge the 80 grand (my guess would be that those are somewhere hard-coded).

This explains all phenomena related to this bug, like a dismantled hangar costing 320.000 grand or the premium only popping up after the build time of a dismantled facility that was under construction has expired.

Now the fix is pretty easy: Open the BASE.DAT in a hex-editor and change the bytes in question to FF!

== Minimized Interceptor Bug (Ufo CE) ==

Maybe this bug is not just related to saving, because I had a similar problem last night. The game didn't crash, but it kept restarting the same Battlescape mission.
One Avenger (A-3) was pacing a Battleship, while another Avenger (A-1) was sent to pick up the pieces of a Terror Ship that had been shot down by an Interceptor. Despite having no weapons (oversight on my part), A-3 wanted to attack the Battleship, but I minimized the screen, hoping it would land.
While the screen was minimized, A-1 landed at the Crash Site from the Terror Ship and started this mission. Right after finishing it, I got the message that A-3 was ready to land next to the Battleship. Happy that I'd get the loot, I started the mission.
After cleaning it out, I got the usual Loot and Promotion screens and went back to the Geoscape. A few seconds later, I was back in the equipment screen and the Battleship Mission started again. I played it once more, because - hey - additional loot, right? Err... no. At the end, I got the correct Loot screen for this attempt and the very same promotion I had gotten in the first attempt (A Rookie from another base promoted to Sergeant).
Got back to Geoscape and a few seconds later back to the Equipment screen. I aborted this mission (same Battleship again), got back to Geoscape and - you guessed it - back to the Equipment screen. After aborting this mission as well and getting back to Geoscape, I used the few seconds I had to go to 'Options' and 'Abort Game'. Maybe I could have made A-3 disengage from the Battleship since I think I saw them both on the Geoscape, a yellow diamond and a red plus, but it was pretty late by that time.
--[[User:Matzebrei|Matzebrei]] 15:06, 15 May 2012 (EDT)

This is a known bug. There is a work around. You should patrol the ship with troops and not land... Finish shooting down the other airborne ships first. Then when the ships doing the shooting are returning to base, change patrolling ship with troops to advance to downed ship in order to commence ground combat mission.
--[[User:JGF|JGF]] ([[User talk:JGF|talk]]) 07:55, 9 November 2016 (UTC)

== Activity Overflow Bug ==

This is a potentially campaign-ending bug. This was seen in the Steam distribution, DOS version (on Windows 2003 Server EE). Not sure if UFO Extender was being used - probably it was. End of Jan 1999 turn shows an extreme negative/underflow Monthly Rating score, which in turn is caused by extreme overflow of UFO Activity levels. Note that that funding "score" - the increased funding by countries - was very positive at the same time!:

[[File:dissatisfied customers.png]]

UFO Activity, by Areas and by Countries, is literally off the chart. Clearly some kind of integer overflow:

[[File:ufo-areas.png]]
[[File:ufo-countries.png]]

X-Com activity is also off the chart:

[[File:xcom-areas.png]]
[[File:xcom-countries.png]]

In addition to the likely outcome that I will lose the game in Feb 1999, it means I can't use the graphs to detect UFO activity outside of my radar coverage.

I have only seen this bug once, and (probably very unusually) I am running under Windows 2003 Server EE (!!). My hunch would be that's the cause, Windows 2003 Server is not the best games platform. :)

[[User:Spike|Spike]] 07:22, 3 September 2012 (EDT)

Further information:

I don't necessarily lose the game in Feb or March 1999. The Monthly Ratings from Feb onward are just based on the current month, not historical score to-date. However it still greatly increases the risk of suffering from the [[Known_Bugs#Losing_My_Favourite_Game|Losing My Favourite Game]] bug - which also greatly complicates doing too many controlled experiments on this Activity Overflow bug, because a few restores of the saved game quickly leads to X-Com Project termination (and humanity's doom).

Possibly the Activity Overflow bug is caused by an initial value of the score (or an array of score values) not being correctly zeroed at the start of the game. See this graph, which shows a negative score in May 1998, prior to the start of the game in Jan 1999.

[[File:Prehistoric_negative_score.png]]

[[User:Spike|Spike]] 08:48, 3 September 2012 (EDT)

I encountered the same Activity Overflow Bug in Windows 7 using Steam version, Windows option with UFOExtender latest version.

[[User:Humbe|humbe]] 2012.10.04 09:05 UTC

I encountered the same bug at end of january with latest xcomutil patched CE version (with only bug fixes patched) with ufo extender newest version running (close to default options). Got many saves from that first month. Even if loading very early save where I had done no missions yet, and just did stuff in base, graphs still show negative for various periods in 1998. Sounds more like corruption than something actually overflowing to me.

[[User:Archlight|Archlight]] 18:34, 24 September 2012 (EDT)

== Bad Paths Bug ==

I suggest to add bad paths on UFOs maps to the article, as another bug in the game.

[[User:Sherlock|Sherlock]] 09:25, 26 December 2012 (EST)
:That sounds reasonable to me. [[User:Spike|Spike]] 10:03, 26 December 2012 (EST)

==Expenditure Graph==
The economy graph for "Expenditure" neglects funds spent on new facilities. I noticed this in my current (DOS) game when I built eight Psi-Labs at the start of April and it didn't increase. I know it counts everything on the Purchase screen; I'm not yet sure whether it counts manufacturing costs.

Is this enough of a bug to be mentioned? Can anyone confirm whether or not it occurs in CE, and whether it counts manufacturing costs? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 02:40, 17 May 2016 (UTC)

==Workshop Crowding==
It seems there is a bug whereby you can allocate more projects/engineers than available workshop space. This can be triggered by setting up two concurrent manufacturing jobs, setting one of them to have 0 engineers working on it, then set the other to have as many engineers as you can assign to it, filling the workshop space. Then go to the other job with 0 engineers, and it will show a negative workshop space available, now if you assign at least one engineer to this project, you can assign the rest of your engineers however you please.

This is my first edit. I find it hard to believe I'd be the first to find this bug after so many years, can someone please confirm a reproduction and that it isn't documented somewhere I've missed? I am running the DOS version of UFO, but I'm also running XComUtil, not sure if that has an impact, or what patch level I'm on. - [[User:Uncertainty|Uncertainty]] 11:00, 20 Dec 2016 (AEDT) Update: Cannot reproduce on the CE version, still unsure of the patch level of the DOS version I'm running and don't know how to accurately determine that. - [[User:Uncertainty|Uncertainty]] 22:00, 29 Dec 2016 (AEDT)

: An easy way to check is whether you can research Magnetic Navigation after collecting one from an alien sub, or if you have to research a Lobsterman Navigator beforehand. If you can research it right away then you have v2, which is what the CE version is mostly based on. If you can't research it and must get the navigator, then it's the unpatched copy of the game. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 22:24, 29 December 2016 (UTC)

Update 2: Thanks NKF, I'm not running TFTD, but I figured out that I was running v1.2 of XCOM1. I cannot reproduce the bug on v1.4 so the bug only applies to v1.2 and has been patched in newer versions. - [[User:Uncertainty|Uncertainty]] 16:45, 31 Dec 2016 (AEDT)

= Unconfirmed bugs =

These may either be actual bugs that only exist as rumors and nobody confirmed them (yet) or stuff that may look like a bug but actually is a feature.

== Alien mission succeeds despite Ground Assault ==

Suppose aliens decide to do a mission. So they send a scout UFO. If you shoot it down, the alien mission gets derailed and the next scout becomes delayed, sometimes a little, sometimes a lot. Seems like the headquarters are waiting for the first scout to report back home or something. But eventually the second scout shows up so you shoot it down too. The third one also takes a long while to arrive and if you shoot that down too, the aliens either give up on the mission completely or send their big ships which only aimlessly fly to and fro, never land and leave soon, empty handed. This way or that way, the alien mission is a failure.

On the other hand if you wait for the scout to land, assault it with your Skyranger and win the mission, the alien's mission continues as if nothing happened. The second scout appears on time. So you ground-assault it too but the third and fourth scout also appear on time. Then the larger UFOs show up and land as if nothing happened to the scouts. You ground-assault them too, including the last Battleship that happens. But guess what? The alien mission is a SUCCESS even despite none of the UFOs making it back to base. Really annoying if the mission is an Infiltration, you can't take their juicy big UFOs because if you do, you are going to lose a country. But on the other hand all these Alien Harvests and Alien Abductions? Lots of juicy spoil and tons of points despite the aliens achieving what they wanted.

I need to add that I was playing some weird version of the game whose data was rejected by OpenXCom with "an invalid CHRYS.PCK file, please update to the latest version" message. So I don't know if this bug exists only there or is present in the latest version of the game too or even whether this is a bug or an expected behavior. - [[User:TowigOs|TowigOs]] ([[User talk:TowigOs|talk]]) 00:24, 3 August 2025 (UTC)

== Transfers can put you into debt ==

Any action you can do that consumes money will either throw a big fat "NOT ENOUGH MONEY" error (build facility; purchases, etc) or just plain hide the button to actually do it (manufacturing) if you don't have the prerequisite cash on hand. Except item transfers. You can transfer stuff around merrily even when you are tens of millions in debt and on the brink of collapse from financial mismanagement. Maybe aliens MCed the movers to skip checking for money on your bank account and just hope they will get paid, eventually. Or they might MCed your bank to lend you money behind your back, allowing to go bankrupt reorganizing the content of your bases. At least you don't have to pay interest on these unwanted loans.

Looks like someone forgot to put "if (money<invoice) then {NotEnoughMoney();return;}" somewhere into that code path.

Note: Getting into debt because your base maintenance is much higher than your income and you did not have the cash is perfectly OK. These bills have to be paid. And you will go belly up financially if you allow this to go too deep. ([[User:TowigOs|TowigOs]] ([[User talk:TowigOs|talk]]) 21:55, 4 August 2025 (UTC))

=Cleanup needed=
Hmm this whole Talk page needs a cleanup. A lot of the Not Listed bugs, should be listed, or are listed. [[User:Spike|Spike]] 10:03, 26 December 2012 (EST)

:So, before it will be made, yet three more observations.

:1. There is no possibility to give back (to stop hiring) a plane without craft weapon.

:2. Alien Reproduction is unavailable in a normal game without hacking/save editing. This is probably connected to further errors on maps. A bug/error/programmers' oversight of the some kind is present in TFTD where it is impossible to obtain Examination Room. It is so because many tiles on maps are wrongly assigned to game's objects. Namely, [[Examination Room (TFTD)]] is treated as Alien Implanter - but there is plenty of errors of this type, on various maps (perhaps also in UFO: EU).

:3. Among soldiers in UFO:EU, there are Russians. Some non-Slavs may not know that Slavic (also Russian) family names have different masculine and feminine forms. For example, Petrov, Belov, Likhachev, Gorokhov, Chukarin, Andianov, Voronin, Maleev are all masculine names; women must be called Petrova, Belova, Likhacheva, Gorokhova, Chukarina, Andianova, Voronina, Maleeva respectively (however, a rule that the feminine form is always made by adding -a is wrong, e.g. Tolstoy - Tolstaya). The soldier's name Mikhail Gorokhova (which is possible in UFO: EU) is just ridiculous (for everyone who has even little knowledge about Russian things). Tatyana Petrov is also an impossible combination. X-Com creators probably assumed that family names are the same for men and women in all languages, and, as a result, they made only mechanisms for storing masculine and feminine forms of first names, not family names. But taking reality under consideration, this is a bug.

: [[User:Sherlock|Sherlock]] 16:22, 26 December 2012 (EST)

== Common bugs vs. UFO EU specific bugs ==

I believethere is one more thing that needs to be cleaned. Namely, both EU and TFTD share the same game engine, so some bugs are common for them both. However, there exists a page with a list of TFTD bugs, and it is clear (or: should be clear) which of the bugs are specific for TFTD. I think the same should be done with EU specific bugs: to hold them apart from bugs common for both games. Some bugs exist in both games but manifest themselves differently (like problems with mind-controlling of big aliens) - they are not true common bugs.

Or even more: one could expect a clear information by each bug, in which game and in which version of the game the bug occurs. And whether a patch exists or not. Sometimes such information is given now, and sometimes it is not. And if one does not know exactly which versions are affected by the bug, it should also be mentioned clearly.

[[User:Sherlock|Sherlock]] 04:13, 27 December 2012 (EST)

== Rename page title to indicate which game this refers to? ==

I was looking for a list of bugs related to XCOM Apocalypse, and it took me a while to realize this was about a totally different game. There are 4 games (not counting the 2 opensource projecrs) here on UFOP - maybe that could be reflected in the article aswell?
[[User:Panzerlol|Panzerlol]] 20:35, 31 March 2013 (EDT)

==New "bugs" submitted directly to main page with no apparent explanation==

WakkaDakka, have you actually managed to replicate this "missing time units" bug, or was it just a one-off freak occurrence? I'm not sure it merits main-page space until we have some idea how to replicate it.

N21, how were you seeing the future to begin with? It's only a bug if it occurs in the normal course of play.

[[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 03:36, 28 May 2015 (EDT)

== Enemy Unknown 1994: Save game bug mid mission. ==

Effect : Loading saved game mid mission just displays a black screen with the cursor at the top left, whilst the music continues to play in the background.
I don't believe the game has crashed out to DOS, having tried both CLS and DIR to no avail. Your can no longer interact with the game, making you force quit the app.

[[File:Screen_shot_2016-11-07_at_19.39.31.png|thumb|left]] 

I'm using Boxer 1.40 on a Mac - which in turn is built off Dosbox 0.74.
I remember seeing this bug years ago on Windows XP too, so I don't think it is platform specific.
I'm currently running it with some of the XCOMUtil patches too - but have had the issue crop up without any of the patches.

Playing on Superhuman level, I use a Skyranger with 14 soldiers equipped with Laser Rifles.

Cause : Hard to be specific. But here are the facts.
I have my suspicions it may be do to with fog of war rendering issues.
I've had it occur frequently when going to the NW edge of a map.

I also had issue on Alien base 1. I have a save game and can suggest moving a unit and saving it in another slot - that alone causes the issue. So if someone knows how to debug this I can supply that. Not sure if the combined number of aliens and yourself casue this.. I managed to eventually work thru a series of corrupted saves that wouldn't load to one that worked again).

Here is a sample save game where the game only needs one specific movement to corrupt a game when you save after the move.

[[File:GAME_10.zip]]
I've uploaded two images to show the move for S Bradley
[[File:Screen_shot_2016-11-11_at_13.50.13.png|thumb|left]] 
and the destination square to move him too. When you complete that move and save the game it corrupts.
[[File:Screen_shot_2016-11-11_at_13.50.17.png|thumb|left]] 

Incidentally there were two downed UFO's at this time, with a second Skyranger en-route to UFO 42. This mission was for UFO 43 with another Skyranger.

The problem frequently occurs.
Ive had it occur recently on the following types of mission:
Terror, Alien Base, Supply ship, Large Scout, predominantly with Sectoids and Cyberdiscs, but also with Mutons and Floaters.
The only thing all these missions have had in common was lots of units on both sides. For example 13 Floaters on a Scout mission, 9 Cyberdiscs on a Terror mission etc.

--

Other quirky things I've seen relating to Stunned units:

1) You can't stun a unit, forcing you to shoot it to complete the mission.
The target being stunned drops to the ground in a heap, but the game says you can still see it and can re-stun unit....

2) Celatids. You stun it, then it wakes up and moves away. The unit no longer renders correctly. It's like a sheet of garbled colored/transparent dots.

3) A stunned unit, other than a Celatid wakes up, and is invisible but you get the '1' in red square for visible enemy. You can stun unit and get the animation for it falling to the ground again.

--

Teleported unit off screen (notice the yellow arrow over the unit, which alas is invisible at the split second I took screenshot - OS/X rendering crap-shoot).
[[File:Screen_shot_2016-11-12_at_14.18.07.png|thumb|left]] 
The unit was teleported from the top of the stairs in an entirely different building, rendering the unit unusable for the mission. I ended up reloading it and doing over.... - [[User:JGF|JGF]]

:Stop spamming [[Special:RecentChanges|the changelog]], please - if you're working on a page and want to see the results of your edits midway through, use the Preview button. Don't hit Save until you are ''done''.

:I can't replicate any issues with your provided save. Bradley doesn't have enough TUs to "complete" the requested move, but asking him to make the attempt anyway, then saving / reloading, works fine for me under 1.4 as well as CE. For what it's worth, as far as I'm aware the game in no way keeps track of the number of actions you've performed during a given turn; at least, I haven't been able to find any such counter embedded in the save files.

:I do suggest you leave your units with more time units - when ending turn, any agents who ''might'' spot an alien during the enemy's turn should ideally have some cover, a kneeling stance, and enough action points to defend themselves with a reaction shot. Using your full TU allocation on movement is somewhat suicidal, and even when you can get away with it, it tends to leave agents without enough energy to move when they really need to.

:Your invisible units may be related to [[Known_Bugs#Invisible_Chryssalids|this bug]] - presumably you can trigger similar behaviour by knocking out all instances of a given alien species within a map, saving / reloading, and then waiting for one of the aliens to awake. I was able to replicate it with an Ethereal, for example.

:Difficult to comment on your garbled Celatid without seeing it first-hand. Ditto for your un-stunnable target. I'd quite like to inspect them with my save editor, though, and ditto for the teleported unit. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 05:46, 13 November 2016 (UTC)

Thanks for scaling the images nice to see the wiki syntax.
It's odd to here you say he didn't have enough Time Units left, because for me the move is allowed.
Where did you get your 1.4 patch?
I applied 1.4 too and am wondering if I got a bad version.
Also did you get your original XCOM off GOG or some place like that?
I have the original CD. I think it's the US version as I used to live there.

== Time Units reset to 0 when soldier reaches 255 TUs ==

I have been playing an old version of UFO: Enemy Unknown, where there is no limit on TUs for soldiers. At certain point, two of my best soldiers reached the limit of 255 TUs, which rendered them useless at now they have 0 TUs.
I tried to reduce their TUs by editing Soldier.DAT, but it did not help. If I check soldiers from the base menu, I can see that the value has been changed, but in the battle their stats are still the same and thus they have 0 TUs and cannot be moved with.

Do any of you know, how to fix this bug? Where is the limiter located, can I change it so that is will be as in the new versions? In any case, I believe this bug should be mentioned on the page. It is mentioned here though: http://www.ufopaedia.org/index.php/Time_Units --[[User:Achernar|Achernar]] ([[User talk:Achernar|talk]]) 21:13, 9 May 2017 (UTC)

: Feel free to add the issue - the page is a hodge podge of whatever issues folks have at the time or as they come across them.

: While I'm no expert on the file structure of the executable for the first release of the game, I suspect you'll find the cause for the byte roll-over feature is that there were no stat limiters to begin with. Best way to cope with it is to either retire anyone approaching supersoldier status to base defence duty, buy more soldiers and spread the experience out more evenly, or update to 1.4 and find a sound patch to restore the original sound samples.

: For your broken soldier: I'm, assuming you edited the soldier.dat file. If you saved the game while in the battlescape, the game creates a temporary copy of the soldier stats and keeps them in unitref.dat. This is to keep track of in-battle status changes, experience, etc. You'll need to edit the current TU levels in this file as well. Or beat the mission with the soldiers that can move and you'll see your edits reflected in the next battle. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 05:45, 11 May 2017 (UTC)

== Fire rate bug & German version footsteps ==

These don't seem to be documented for some reason: (DOS Version)

The fire rate always resets to 3 if an alien or an alien mind controlled unit throws a grenade.

If German is chosen as language to play, the footsteps of all soldiers, regardless of the terrain they walk on, will sound as if they are walking on a metal surface like the inside of the Skyranger, UFO or the base. [[User:Bard|Bard]] ([[User talk:Bard|talk]]) 05:38, 8 April 2019 (CEST)

== Direct incendiary hit causing no reaction fire? ==

On the Incendiary page, it is reported that a direct hit will not cause an alien to spin around and return fire. I have tested this in OpenXcom and find that the aliens do, in fact, return fire. If this can be confirmed in original X-Com, it would be good to add to known bugs.

: It's safe to say everything you find on this wiki relating to the classic game pages were gleaned from the original games. OpenXcom, being an independently developed fan project, will have its own list of fixes and changes chronicled in its own documentation. In fact I would not be surprised that good deal of the more technical information on this wiki has been contributed by those that had some input into the OpenXcom project. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 05:16, 8 June 2021 (UTC)

:: Thanks, good to know. Would still love to know if anyone has tested this in classic game. If not, I will when I can, so it can be added to known bugs [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 22:05, 15 June 2021 (UTC)

==Alien weapon loadouts bug/anomaly==
There are actually 10 alien weapon loadout sets, not 9. The actual first set is 70% "early"/20% "mid"/10% "late". This loadout set never appears in-game, though, because the setup at game start counts as a month rollover which means that weapon loadouts (which are called when the mission occurs, not at month start when the mission is scheduled) are called from the second set during January, the third set during February, and so on. This is probably an oversight by the Gollops (note that race weights reach their final values in October; were it not for this quirk, weapon loadouts also would), but it's hard to be sure. Should this be added? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 15:02, 28 April 2025 (UTC)

Aliens Own Earth

2025-08-08T12:45:23Z

TowigOs: Tips about how to tune the difficulty of the Aliens Own Earth campaign.

=Aliens Own Earth=

==Introduction==

This article describes how to create a scenario where the game is much more challenging. The Aliens begin the game in a very dominant position in Earth. Doing this lets you play a game where the aliens already own the Earth and you have an uphill battle to get Earth back.

In order to play this game, you first need to work through a campaign specially designed to create lots of Alien bases. You then manipulate some game save files in order to move all these Alien bases 'back in time' to the start of a new game. The new game is "Aliens Own Earth".

==Pre-Game Campaign ==
To get +20 alien bases onto the surface of earth, you have to edit some things to make the gameplay go alot faster. You don't want to play the game through properly. Forget research and manufacturing, training etc. Using a savegame editor, you'd want to:
* give yourself 200mil. and build seven more bases spread around the globe.
* edit the layouts of the eight bases to contain hangers, stores, detection with alien communications decoding, alien fuel, hand weapons, armour etc.
* buy 6 fighter craft then use an editor to change all craft to Avenger/Leviathan and give them plasma/sonic weapons.
* use an editor to change hitpoints of ALL alien craft to 25, and speed to 1000. Change X-COM craft to 1000 hitpoints and 10000 speed and 500 fuel. It may help to decrease the weapon range of some of the UFO/USO.
* buy 10 soldiers for each base and change their states to 100 (or thereabouts)
* edit diplomacy so that you get 100mil per month. It will adjust naturally thereafter.
===Fast Gameplay===
The only way to get through this pre-game setup campaign quickly is to shoot and destroy (not crash land) the alien craft. Since the hitpoints of a Battleship/Dreadnaught is only 25, it will take one shot from the X-COM craft to blow it up. Also:
* if you have a UFO on a mission to scout for an alien base location, don't shoot it down. Let it go and you'll have a base building squadron appear earlier. Look for the alien base once you think its built and then you can go after the squadron.
* if you have an alien craft looking for your base, let it go until you have the VERY LARGE types appear. Shoot these down for big score bonuses.
* you are playing the game for a positive score at the end of the month. Large and Very Large ufos give the biggest scores when destroyed. You can ignore the rest. For the reason the more you shoot down the more you'll have to deal with retaliation missions later on. The objective is to survive until the next month and letting aliens build bases. You can ignore terror sites as well if your score permits this (or land & abort for smaller score hit).

===Over 20 Alien Bases===
Once you have over 20 alien bases (and under 25), go thru and sack everyone except 8 soldiers at your first base. These eight soldiers are your defending force if you miss an alien craft attacking you first base. They are not necessary, but just in case. Once you have seven undefended bases, remove the Mind/MC Shield and let the aliens destroy these bases. You might have to shoot down many more alien craft before the aliens start getting annoyed. Once you have one base left, remove the soldiers from any transport crafts and save your game and exit. Use an editor to change the craft back to terran types and replace the weapons with the default starting weapons (stingrayX6,avalanchX3 or ajaxX6,DUPX3).
 Cut CRAFT.DAT, LOC.DAT, and BASE.DAT from the savegame folder and then make a copy of these files as a backup.

==Copy Files to Create New Campaign==

Insert the [[LOC.DAT]], [[CRAFT.DAT]] and [[BASE.DAT]] files into a fresh new game savegame folder, and you'll have all the alien bases from the old game present in a new game.

NOTE: If you plan on overwriting the new with old, you must remove the soldiers from any and all transport craft before you copy the files over to the new savegame folder. Doing so will stop any 'ghost' soldiers remaining on the transport craft when you go to equip it. Alternatively, you can copy the SOLDIER.DAT file from the old location.

Start a new game and plunk your first base down anywhere. Remove the eight agents assigned to the tranport craft in this new game, then save and exit. Copy the three files into this savegame folder.

Note: It may help to make new install of the game because you have edited the previous installation, unless you want to go thru the old install and revert the editing.

==Playing the New Campaign==

Now LOAD from the savegame folder where you put the "Aliens Own Earth" files. This new game from the very start has now got 20+ aliens bases scattered over the globe. Everything else (money, technology, X-Com bases) is set to the normal starting levels. Enjoy your (short) time as an X-Com Commander!

===Dialing the difficulty down===

If you find this scenario too hard to play, you can dial the difficulty down by becoming selective about which races you permit on Earth. Floaters are arguably the easiest to deal with but their Reapers can run quite a bit. Mutons are somewhat harder because they are tougher and have more powerful terror units. Sectoids have psionics which can wreck your
starting team and their Cyberdiscs are essentially flying bombs that shoots searing hot plasma at you. Snakemen's terror unit can (and will) turn your guys to more aliens and Ethereals combine powerful psionics with indestructible mechas. By either allowing the alien base missions or shooting these scouts you can decide which aliens get to have a base and which do not.

Alternatively you can just hex-edit the resulting [[LOC.DAT]] file and put in whatever mix of alien races you desire.

===Dialing the difficulty up===

While preparing the bases, you will learn where exactly they are and who is in them. You could then use this "exploit" to find and eliminate them quickly.

To prevent this exploit from working, prepare multiple sets of alien bases. Then once you are ready to play the scenario, pick one randomly and install it. Now you have no idea where to search for these pesky things.

==Game Editors==

See [[Game Editors|this page]] for a list of tools to use to edit game files.

[[Category:Enemy Unknown/UFO Defense]]

Aliens Own Earth

2025-08-08T12:26:57Z

TowigOs: A little tip about how to skip terror sites without ignoring them

=Aliens Own Earth=

==Introduction==

This article describes how to create a scenario where the game is much more challenging. The Aliens begin the game in a very dominant position in Earth. Doing this lets you play a game where the aliens already own the Earth and you have an uphill battle to get Earth back.

In order to play this game, you first need to work through a campaign specially designed to create lots of Alien bases. You then manipulate some game save files in order to move all these Alien bases 'back in time' to the start of a new game. The new game is "Aliens Own Earth".

==Pre-Game Campaign ==
To get +20 alien bases onto the surface of earth, you have to edit some things to make the gameplay go alot faster. You don't want to play the game through properly. Forget research and manufacturing, training etc. Using a savegame editor, you'd want to:
* give yourself 200mil. and build seven more bases spread around the globe.
* edit the layouts of the eight bases to contain hangers, stores, detection with alien communications decoding, alien fuel, hand weapons, armour etc.
* buy 6 fighter craft then use an editor to change all craft to Avenger/Leviathan and give them plasma/sonic weapons.
* use an editor to change hitpoints of ALL alien craft to 25, and speed to 1000. Change X-COM craft to 1000 hitpoints and 10000 speed and 500 fuel. It may help to decrease the weapon range of some of the UFO/USO.
* buy 10 soldiers for each base and change their states to 100 (or thereabouts)
* edit diplomacy so that you get 100mil per month. It will adjust naturally thereafter.
===Fast Gameplay===
The only way to get through this pre-game setup campaign quickly is to shoot and destroy (not crash land) the alien craft. Since the hitpoints of a Battleship/Dreadnaught is only 25, it will take one shot from the X-COM craft to blow it up. Also:
* if you have a UFO on a mission to scout for an alien base location, don't shoot it down. Let it go and you'll have a base building squadron appear earlier. Look for the alien base once you think its built and then you can go after the squadron.
* if you have an alien craft looking for your base, let it go until you have the VERY LARGE types appear. Shoot these down for big score bonuses.
* you are playing the game for a positive score at the end of the month. Large and Very Large ufos give the biggest scores when destroyed. You can ignore the rest. For the reason the more you shoot down the more you'll have to deal with retaliation missions later on. The objective is to survive until the next month and letting aliens build bases. You can ignore terror sites as well if your score permits this (or land & abort for smaller score hit).

===Over 20 Alien Bases===
Once you have over 20 alien bases (and under 25), go thru and sack everyone except 8 soldiers at your first base. These eight soldiers are your defending force if you miss an alien craft attacking you first base. They are not necessary, but just in case. Once you have seven undefended bases, remove the Mind/MC Shield and let the aliens destroy these bases. You might have to shoot down many more alien craft before the aliens start getting annoyed. Once you have one base left, remove the soldiers from any transport crafts and save your game and exit. Use an editor to change the craft back to terran types and replace the weapons with the default starting weapons (stingrayX6,avalanchX3 or ajaxX6,DUPX3).
 Cut CRAFT.DAT, LOC.DAT, and BASE.DAT from the savegame folder and then make a copy of these files as a backup.

==Copy Files to Create New Campaign==

Insert the [[LOC.DAT]], [[CRAFT.DAT]] and [[BASE.DAT]] files into a fresh new game savegame folder, and you'll have all the alien bases from the old game present in a new game.

NOTE: If you plan on overwriting the new with old, you must remove the soldiers from any and all transport craft before you copy the files over to the new savegame folder. Doing so will stop any 'ghost' soldiers remaining on the transport craft when you go to equip it. Alternatively, you can copy the SOLDIER.DAT file from the old location.

Start a new game and plunk your first base down anywhere. Remove the eight agents assigned to the tranport craft in this new game, then save and exit. Copy the three files into this savegame folder.

Note: It may help to make new install of the game because you have edited the previous installation, unless you want to go thru the old install and revert the editing.

==Playing the New Campaign==

Now LOAD from the savegame folder where you put the "Aliens Own Earth" files. This new game from the very start has now got 20+ aliens bases scattered over the globe. Everything else (money, technology, X-Com bases) is set to the normal starting levels. Enjoy your (short) time as an X-Com Commander!

==Game Editors==

See [[Game Editors|this page]] for a list of tools to use to edit game files.

[[Category:Enemy Unknown/UFO Defense]]

Aliens Own Earth

2025-08-08T12:21:03Z

TowigOs: Clarify what kind of detection to get (radar/sonar is not sufficient)

=Aliens Own Earth=

==Introduction==

This article describes how to create a scenario where the game is much more challenging. The Aliens begin the game in a very dominant position in Earth. Doing this lets you play a game where the aliens already own the Earth and you have an uphill battle to get Earth back.

In order to play this game, you first need to work through a campaign specially designed to create lots of Alien bases. You then manipulate some game save files in order to move all these Alien bases 'back in time' to the start of a new game. The new game is "Aliens Own Earth".

==Pre-Game Campaign ==
To get +20 alien bases onto the surface of earth, you have to edit some things to make the gameplay go alot faster. You don't want to play the game through properly. Forget research and manufacturing, training etc. Using a savegame editor, you'd want to:
* give yourself 200mil. and build seven more bases spread around the globe.
* edit the layouts of the eight bases to contain hangers, stores, detection with alien communications decoding, alien fuel, hand weapons, armour etc.
* buy 6 fighter craft then use an editor to change all craft to Avenger/Leviathan and give them plasma/sonic weapons.
* use an editor to change hitpoints of ALL alien craft to 25, and speed to 1000. Change X-COM craft to 1000 hitpoints and 10000 speed and 500 fuel. It may help to decrease the weapon range of some of the UFO/USO.
* buy 10 soldiers for each base and change their states to 100 (or thereabouts)
* edit diplomacy so that you get 100mil per month. It will adjust naturally thereafter.
===Fast Gameplay===
The only way to get through this pre-game setup campaign quickly is to shoot and destroy (not crash land) the alien craft. Since the hitpoints of a Battleship/Dreadnaught is only 25, it will take one shot from the X-COM craft to blow it up. Also:
* if you have a UFO on a mission to scout for an alien base location, don't shoot it down. Let it go and you'll have a base building squadron appear earlier. Look for the alien base once you think its built and then you can go after the squadron.
* if you have an alien craft looking for your base, let it go until you have the VERY LARGE types appear. Shoot these down for big score bonuses.
* you are playing the game for a positive score at the end of the month. Large and Very Large ufos give the biggest scores when destroyed. You can ignore the rest. For the reason the more you shoot down the more you'll have to deal with retaliation missions later on. The objective is to survive until the next month and letting aliens build bases. You can ignore terror sites as well if your score permits this.
===Over 20 Alien Bases===
Once you have over 20 alien bases (and under 25), go thru and sack everyone except 8 soldiers at your first base. These eight soldiers are your defending force if you miss an alien craft attacking you first base. They are not necessary, but just in case. Once you have seven undefended bases, remove the Mind/MC Shield and let the aliens destroy these bases. You might have to shoot down many more alien craft before the aliens start getting annoyed. Once you have one base left, remove the soldiers from any transport crafts and save your game and exit. Use an editor to change the craft back to terran types and replace the weapons with the default starting weapons (stingrayX6,avalanchX3 or ajaxX6,DUPX3).
 Cut CRAFT.DAT, LOC.DAT, and BASE.DAT from the savegame folder and then make a copy of these files as a backup.

==Copy Files to Create New Campaign==

Insert the [[LOC.DAT]], [[CRAFT.DAT]] and [[BASE.DAT]] files into a fresh new game savegame folder, and you'll have all the alien bases from the old game present in a new game.

NOTE: If you plan on overwriting the new with old, you must remove the soldiers from any and all transport craft before you copy the files over to the new savegame folder. Doing so will stop any 'ghost' soldiers remaining on the transport craft when you go to equip it. Alternatively, you can copy the SOLDIER.DAT file from the old location.

Start a new game and plunk your first base down anywhere. Remove the eight agents assigned to the tranport craft in this new game, then save and exit. Copy the three files into this savegame folder.

Note: It may help to make new install of the game because you have edited the previous installation, unless you want to go thru the old install and revert the editing.

==Playing the New Campaign==

Now LOAD from the savegame folder where you put the "Aliens Own Earth" files. This new game from the very start has now got 20+ aliens bases scattered over the globe. Everything else (money, technology, X-Com bases) is set to the normal starting levels. Enjoy your (short) time as an X-Com Commander!

==Game Editors==

See [[Game Editors|this page]] for a list of tools to use to edit game files.

[[Category:Enemy Unknown/UFO Defense]]

Game File Exploits

2025-08-08T12:15:29Z

TowigOs: Cash Rollover Bug Fix clarification + how to hex edit it more gently.

'''THIS PAGE IS UNDER CONSTRUCTION'''

=Game File Bug Fixes and Exploits=

==Game File Bug Fixes==

===Cash Rollover Bug Fix===
If you have so much money that it all of a sudden it becomes negative (eg: $-2,168,000,000), you can delete the [[LIGLOB.DAT]] file and replace it from a new savegame. You cash becomes approx $4mil which is what is available from the new game. Your income will be preserved but the financial graph data will be trashed.

Alternatively you can use a hex editor (see [[Game_Editors#Hex_editors]] or [[HackerTools]]). Navigate to the fourth byte of the [[LIGLOB.DAT]] file and change its value to something between 0 and 127 (00 to 7Fh hex). 64 (40h) is recommended, giving you about a billion. This solution has the advantage of leaving all the other data in the savegame intact.

===Research Bug Fix===
If your research progress has become corrupted due to the bugs in the research tree of TFTD, replace the [[RESEARCH.DAT]], [[UP.DAT]], [[PROJECT.DAT]], [[PRODUCT.DAT]], [[BPROD.DAT]] with files from a new saved game if you don't want to use a hex-editor.

==Game File Exploits==

===Bottomless Money Pit===
Insert a [[LIGLOB.DAT]] file from an old game that has lots of money, into a new game. You will inherit the cash balance of the old game. Or you can copy the file from a new savegame, in which case your cash becomes approx $4mil (the amount available at the start of a new game).

===Enlightened Xcom===
The Research Bug Fix (above) can be abused by inserting old files from a completed game into the save folder of a new game. The files to insert are [[UP.DAT]], [[RESEARCH.DAT]], [[FACIL.DAT]] and [[PRODUCT.DAT]]. You can (optionally) also copy [[SOLDIER.DAT]] to transfer you old soldiers into the save as well, just be sure the number of new soldiers is equal to the number of old soldiers you are transferring from your old game or the game will crash. SOLDIER.DAT also stores the solders' equipped armour (not their inventory though, unfortunately): if you remove all their armour then then copy the SOLDIER.DAT from your old game again, you can effectively duplicate said armour.

==See Also==

===Aliens Own Earth===

Various game file manipulations are also used to setup the [[Aliens Own Earth]] scenario, a much more challenging variant of the game.

===Game Editors===

[[Game Editors|This page]] has a listing of tools for editing game files.

[[Category:Enemy Unknown/UFO Defense]]

HackerTools

2025-08-08T12:08:17Z

TowigOs:

<big>'''NOTE: A move has been made to delete this page and/or redirect it to [[Game_editors#Useful_Generic_File_Editors]] - see Talk page '''</big>

Windows 95 and beyond offer a simple but effective text editor that can be used to hex edit binary files: [[MS-Edit]].

----

Another hex editor that some folks use is Hex Workshop by [http://www.bpsoft.com www.BPSoft.com]. Hex Workshop has the nice feature that you can make a 'structure library' with the meaning (field name) of each byte, turning the file into a little database. You will see some of these definitions (.HSLs) in the game file wikis. Hex Workshop is free for 30 days and then costs $50 if you want to keep using it. While it has a number of nice features, it does have some drawbacks. Examples: 1) Its display field can't be more than 64 characters wide (unlike EDIT), so you can't do a "one row equals one record" display for e.g. SOLDIER.DAT (reclength 68) or UNITREF.DAT (reclength 124). Related to this, 2) although it's a "modern" Windows app, you can't e.g. go to some tiny font and see a lot more in your data display window (even though you probably have 1600x1200 screen rez as a L33T gamer).

If you're on a budget, EDIT is a fine little tool. I, for one, once used Hex Workshop, but now exclusively use EDIT.

'''NOTE:''' To make screen captures, see [[Info#Screenshots|this]].

----

Another VERY useful hex editing program is the Universal Game Editor (UGE). It is a hex editor which displays numbers in digits instead of hex codes. It uses templates that can store variables found in the game files, so that they can be easily edited (including variables with 1, 2, or 4 bytes, or text entries).

It can be found from a variety of locations using a search engine. The program is only about 400kb and is free to use (shareware with full capabilities, but has a reminder screen).

----

If you REALLY know what you are doing, you could also use Raihan Kibria's frhed (FRee Hex EDitor) found [https://sourceforge.net/projects/frhed here]. Unlike the above examples, this editor is completely free and open source with sources available [https://github.com/datadiode/frhed here].

----

Return to [[Game_Files]]

Open Questions

2025-08-05T16:16:31Z

TowigOs: Large UFOs on a mission don't land if their scouts got trashed

This page contains a list of gameplay mechanics which hasn't yet been entirely analyzed or discovered and other interesting stuff. One can conceive of this page as a wishlist/TODO for X-COM analysis and for UFOpaedia X-COM 1 articles. It's possible that some of the questions below have already been answered here or in other forums, or that more questions are unanswered, so edit freely!

*[[Talk:UFO Interception#Review of Air Combat Mechanics|Air Combat Mechanics]]: Control of range, attack modes. UFO damage & accuracy. Multiple attackers. Plus equivalent TFTD issues.
:UFO accuracy is a straight 60% chance. -[[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]]) 22:02, 9 December 2014 (EST)

*[[Accuracy_formula]]: How is the path for 'missed' shots calculated? Does it vary per weapon type? What is the spread per distance?

*[[Battlescape_Map_Generation]]: How X-COM equipment is placed in the case of base missions? Do map modules that contain craft have their usual nodes loaded or not?
:Maps are created like a puzzle where the UFO and Xcraft locations are placed first then the rest of the tiles are determined randomly based on the terrain variable of the site. Usually the size of each "piece" of the map is a 10x10 tiled square. Larger UFOs and some Alien Base features use a 20x20 block. So, each section only contains the one module.

*Operation of the AI is not fully understood. See [[Alien movement patterns]], [[Alien Inventory Use]], [[Wish_List_(EU)#Alien_AI]], [[Wish_List_(TFTD)#Battlescape]] (non-use of melee weapons, use of grenades, etc).

*[[Alien_Missions]]: How are Alien missions generated and how do the player's action influence the generator? Are all countries (except Russia) doomed to fall under alien influence, assuming indefinite gameplay where player downs all UFOs perfectly? We know that:

:*The mission generator assigns a Research mission to the region of the player's first base at game start, with ETA of 2.5h (unlike the usual ETA for 0/0).

:*The OSG says (per [[Difficulty Levels]] article) the Aliens are more likely to abandon or delay missions on lower difficulty.
::The OSG is wrong. Aliens don't abandon missions. The next stage of a mission will be delayed by successful interception. Difficulty plays no role in this.-[[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]]) 22:02, 9 December 2014 (EST)
:: Additionally, if you shoot down the scouts, the large UFOs will never land. They will arrive, fly around randomly, then leave without landing. At least in V1. ([[User:TowigOs|TowigOs]] ([[User talk:TowigOs|talk]]) 16:16, 5 August 2025 (UTC))

:*Scoring-wise, Alien missions are considered successful once the landed UFO takes off. Missions can succeed more than once.

:*Alien Infiltration in its final stage can't be stopped, even if all the UFOs are shot down before landing.

:*Alien Retaliation (once X-COM base is discovered) mission generation can only be stopped by letting the aliens land and defeating them. Otherwise the aliens will just send more battleships.

:*Alien Terror missions can be stopped by blowing up (or scaring away) the Terror ship.

:*Is there 100% certainty that Russia will never be subverted (has anyone seen it occuring to Russia?) Perhaps it depends on the game version?

*What are the "internal balancing mechanisms" spoken about by Julian Gollop [https://web.archive.org/web/20111126141902/https://www.next-gen.biz/features/making-x-com-enemy-unknown]? Does this have anything to do with the mission generator?

:*As your organisation becomes stronger (through research & score), more powerful aliens start to appear with larger weapons. Catch is, the stronger the aliens get, the stronger X-COM gets, so the "mechanisms" aren't all that effective once you've got your more important research projects done.

:*Quoting from [http://www.youtube.com/watch?v=LP7VjbuNEzg?t=30m45s]: "The way this worked was very simple. Basically, if you did very well in the previous three tactical missions and you absolutely trounced the aliens, the aliens would ramp up their own technology development and deployment more quickly." A very similar mechanic existed in Apocalypse, where the appearance of new alien tech was triggered by X-Com's score crossing a particular threshold. [[User:Off the Rails|Off the Rails]] 12:57, 2 April 2013 (EDT)

*Add something about the X-COM novelizations. I've been informed that they were horrendous...
:*Many years ago (about 1998?), a copy of the Diane Duane novel was passed around amongst the alt.games.x-com regulars. My memory's rather sketchy but I recall a standard pulp sci-fi with some X-Com words thrown in. The scale of the novel was much larger - I believe there was a part where hundreds oT troops stormed out of an Avenger to assault an alien base. Apart from that, I don't remember much. [[User:Off the Rails|Off the Rails]] 18:08, 2 February 2011 (EST)
:*There is a Vladimir Vasiliev book in russian. It is named "UFO: Враг неизвестен" http://fantlab.ru/work10017

[[Category:Enemy Unknown/UFO Defense]]

Talk:Known Bugs

2025-08-04T21:58:16Z

TowigOs: Add clarifying text to the "Unconfirmed bugs" section

= Classification etc =

== Bugs vs Exploits ==

Could someone comment please on the distinction between a bug and an exploit, and where to put each one? I would guess that a bug is something that undesirable and an exploit "might be" desirable, if you want to cheat. But what about exploits that happen by accident, or bugs that need to be forced to happen?

I was going to add the Research Rollover bug to the Exploits sections, but they seem to all be under construction. What's the agreed approach?

[[User:Spike|Spike]] 04:16, 15 March 2008 (PDT)

* i think that an exploit is somthing you can trigger and gain an advantage from. a bug may or may not have a known trigger, and does not give an advantage if it does.
: All exploits are bugs, either in implementation or design. When using a bug to gain advantages that bug is used as an exploit (you are exploiting the bug). [[User:FrederikHertzum|FrederikHertzum]] 13:39, 10 May 2011 (EDT)

:: IMHO, Laser Pistols Gifts to train reactions is an exploit, but it does not involve any bugs. It merely exploits the fact that laser pistols will not penetrate the front armor of Flying Suits. [[User:Jasonred|Jasonred]] 16:31, 10 May 2011 (EDT)

::: I guess the point is to differentiate if it's a bug that's being exploited to your advantage, or it it's something confined within the game mechanics that you are exploiting to your advantage (even if using it as intended). -[[User:NKF|NKF]] 02:31, 11 May 2011 (EDT)

:::: Another definition: An exploit is
::::: a) a move allowed by game interface
::::: b) that sidesteps another part of the game mechanics
::::: c) and creates inadequate advantage for the moving player in the process.
::::: An exploit is not a bug, but it can be connected with a bug, if the latter allows a move mentioned in a). Most obvious exploits render whole parts of game mechanics obsolete (see b) above), because they are always more advantageous. In games that feature equal terms for AI and the player, an exploit can be discerned simply by the fact that AI does not use it (sadly this is not true in X-COM). Clear exploit in X-COM: Transfer soldiers = no monthly payment. Suspect exploits: grenade layout. Most probably not an exploit: Sniping (although the inequality with AI is suspect). Clearly not an exploit: dropping weapons to prevent Psi mass murder (this one is made exploitable by the AI unable to pick up weapons, but is not an exploit per se).--[[User:Kyrub|kyrub]] 05:30, 11 May 2011 (EDT)

The dropping weapons sort of turns into an exploit if you do the "everyone suspect of being a psi weakling drops their weapons at the end of the turn. They all pick up their weapons again if unpsied in the next turn." The grenade layout or grenade hot potato is probably not what the game designers had in mind, but I shudder at the thought of someone who only played X-com then joined the army pulling the pin out of his grenade and then dropping it into his haversack or slinging it on his belt. [[User:Jasonred|Jasonred]] 07:43, 11 May 2011 (EDT)

: Yeah, I think we agreed somewhere that shoving live grenades in your pockets and not having them go off is madness. The relay however is not sensible but certainly possible if only a very short one (if with a live grenade), or to toss a grenade forward and prime it at the second to last person. Or more reasonably, something like a stick of dynamite with an extra long fuse. Even that's very dangerous.

: By the way, what does everyone here think of using the mind probe to check if it's safe to attack an alien while standing in full view of it, or if you're right up next to it? I've been using it a lot lately (in lieu of the psi amp), so you could say I've been exploiting the mind probe to my advantage to help me with my decision making. But is that counted as a cheat since I'm picking my moments to attack up close when the enemy cannot return fire? -[[User:NKF|NKF]] 03:30, 12 May 2011 (EDT)

:: When identifying a mechanic as an "unfair exploit" (as opposed to just a "tactic"), perhaps a simpler checklist is this (though Kyrub's is spot-on):

:: a) Is this something the developers should've expected players to do?
:: b) Is this something the developers could've easily prevented?

:: If the answer to both is "yes", then it seems fair game to me. For eg, sniping at aliens: The game KNOWS whether the soldier can see the target (you get a flashing indicator if so), and so it would've been trivial to prevent it. Is it something the regular gamer will try? Certainly; therefore it can be considered expected behaviour. Ditto for using the Mind Probe to make attacks without fear of reaction fire; those things aren't cheap, they sell for a bunch, so it stands to reason that they'd have tactical value!

:: Things like the transfer bug are clear exploits. The devs would've implemented that system so that, if you order personal near the end of the month, you don't end up paying for them twice before they ever arrive - but in the process, they forgot that "purchase" transfers are treated in the same way as "between-base" transfers. To fix one scenario without breaking the other, they'd've needed to code in some extra stuff so the game could tell the difference - they probably just figured the regular gamer would never notice, assuming they ever realised the problem existed.

:: The "dropping weapons" thing is a little trickier to work out - yes, the devs should've seen it coming, but would it've been easy to fix? Aliens could've been twigged to either ignore un-armed soldiers... but those soldiers could re-equip next turn. Aliens could also've been twigged to attack randomly... but that would make their psi powers far LESS effective! I suppose the fix, if any, would've been unarmed melee attacks, but the implementation they went with seems to be the next best thing IMO.

:: In regards to the "grenades in inventory" thing, it's probably common knowledge by now, but they DO go off in the alpha of the game. Presumably someone made a conscious decision to change that, though it could still just be an accidental bug. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:02, 12 May 2011 (EDT)

Sniping at aliens is a very bizarre case, since almost all players will fall prey to the aliens sniping at you long before they snipe the aliens. The behaviour of the aliens to step within sight radius, take one step back, then fire without fear of retaliation *looks* and *feels* like clear exploitation of the rules, but the computer can't be a cheater, can it? So we humans carry that one step further. Mind you, I think X-com would be in trouble if the aliens could snipe you from across the map once they know your positions... especially since the aliens have cheating "if I spot 1 human, I spot ALL of them" abilities. Especially on maps where the aliens get Blaster Bombs...

An interesting note about sniping and LOS: When I first played Xcom, my first mission was in the jungle. Because of all those plants, when my first soldiers spotted an alien, after he shot at him, I tried to make my 2nd soldier open fire and was informed "NO Line of Fire". I could only get my 2nd soldier to fire by positioning him in such a way that I got the flashing number. Henceforth, I assumed that you could ONLY fire at the aliens when the flashing number was there. LOL. LOF. LOS.

Transfer bug wise, I thought that the devs merely programmed the game to count how many staff were currently in the base, then deduct that from Xcom coffers? As far as ordering personnel near month end goes, you end up paying salary for them if you order them more than 48 hours from month end, right? "realistically", they should make staff draw salaries based on when they were hired, but this would be too much effort.

"dropping weapons" would have been easy enough to fix... just teach alien AI how to pick up weapons. Like they did in Apocalypse.

As far as grenade relays go, if you ever join the army, and you toss a live grenade at your squadmate, you're gonna be court martialled! lol. Xcom grenades are weird cause they presumably come with a computer console where you program them or something that takes a lot of TU, if I already have a grenade in my hand I don't think it takes long to prime it compared to throwing it...

Pretty clear exploit/bug is tossing grenades through the ceiling? That breaks all laws of realism/logic/whatever, and I'm sure the devs didn't plan for THAT to happen! [[User:Jasonred|Jasonred]] 18:18, 12 May 2011 (EDT)

: Turns out the "spot one, spot all" thing was wrong all these years. However, units can be "spotted" by sniping an alien, hitting it, but failing to outright kill it; this may have contributed to the misconception.

: The game considers the base to have the correct amount of personal as soon as you initiate a transfer - if a base has room for ten people, you can't send two groups of ten, as soon as the first is in transit the game will correctly recognise that the destination is now filled up and won't allow you to send any more. Likewise, if you hire soldiers, they'll count towards the allowance of more promotions in your ranks before they ever arrive at a base. That is to say, the payment system deals with personal counts in a different way to every other system in the game, making it look like it's intentional (if badly exploitable) behaviour. In terms of transit times, those seem to vary, I know a purchase of scientists takes 72 hours to arrive.

: Er, yes, getting aliens to pick up weapons would've indeed fixed the dropping thing. Shoulda thought of that...

: The grenade thing is indeed unrealistic however you look at it. Certainly throwing the things through ceilings is a bug, and its use is a large exploit. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 20:02, 12 May 2011 (EDT)

:: Then how do the aliens "spot" the psi weakling to target him for psi attacks? Doesn't the game ALWAYS start blasting the juiciest target, regardless of LOS? Or is it just coincidence? [[User:Jasonred|Jasonred]] 22:22, 12 May 2011 (EDT)

::: They really have to "[[UNITPOS.DAT#8|spot]]" the target before they can blast them (however, it appears that later in a campaign this rule gets broken). If they've only spotted a psi-''resistant'' trooper, they typically won't bother to make attacks at all. There's a lot of relevant information in [http://www.strategycore.co.uk/forums/Can-alien-attempt-Mind-control-Pani-t8115.html this thread]. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 23:28, 12 May 2011 (EDT)

: Your talking about your post on http://www.strategycore.co.uk/forums/Can-alien-attempt-Mind-control-Pani-t8115.html&pid=96123&mode=threaded#entry96123 ? Well, I'd just like to point out a massive flaw in your testing logic. You forgot that aliens will launch psi attacks based on chance of success, and chance of success varies based on distance from aliens. In other words, it could easily be that the aliens only attempted psi when your soldier was within sight of them because your soldier was now NEAR to them and therefore they had a strong chance of success.

: Also, as you have noted, it appears that your rule gets broken. In fact, it is not uncommon at all for the Ethereal Commander who is boxed up in the Command Center to launch psi attacks on victims who are separated from him by several layers of walls, as long as their proximity to him is near enough. [[User:Jasonred|Jasonred]] 21:19, 13 May 2011 (EDT)

:: Those are valid points. I've hence built a somewhat more robust testing scenario, which you may wish to [[:Image:Alien Psi Demonstration 1.rar|try for yourself]].

:: The save game consists of cloned Ethereal soldiers (all cranked up to 100 psi strength/skill), and many clones of a single trooper (most of whom have the same psi values). The Ethereals are all cooped up in a sealed room in the SW of the map, with a single trooper who has 140 psi strength/skill.

:: Directly outside the building is another trooper who only has 1 strength/skill. In the NE of the map, in another sealed room, is a soldier with 40 strength/skill. Before placing him there, I had him shoot one of the Ethereals just once, resetting index 8 of his UnitPos record to 0. Only he and the trooper inside the room with the Ethereals have hence been "exposed" to the aliens, but the "best chance of success" is obviously the psi-weakling directly outside the building.

:: If you load the map and end turn, the aliens will first attempt to take control of the dude on the other side of the map, then get to work on the guy in the room with them. Once they've taken these two, they'll completely ignore all other units.

:: In short, aliens can't use psi attacks on a unit UNLESS their UnitPos[8] index is set to less then that of the alien's intelligence stat. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 05:41, 14 May 2011 (EDT)

::: Good one. That test definitely proves a lot, rather conclusively. [[User:Jasonred|Jasonred]] 06:53, 14 May 2011 (EDT)

== Bugs vs Limits ==

''(Discussion continued from [[Talk:Known Bugs#Soldier Recruiting Bugs Tested|Soldier Recruiting Bugs Tested]])''

The "Soldier Recruiting Limit" is not a bug, it is a limitation of the game. Therefore, this should be removed from the page. If we want it somewhere else (like a new page such as [[Game Limitations]]), that would be appropriate. --[[User:Zombie|Zombie]] 01:42, 9 November 2008 (CST)

::Not sure that's necessarily the best idea, Zombie, since many of the entries on the Known Bugs article(as well as some entries on the Exploits pages) are limitations of the game engine. On just a brief glance through, the following caught my eye as engine limitations: Manufacturing limit, Storage limit, Purchase limit, 80-item limit, Proximity Grenade limit, Large units not waking up from stun, Interception last shot bug, Alien UFL radar blitz-through bug(Passing through the detection range of a radar before the detection check comes up), Free manufacturing, free wages, UFO Redux, point-scoring with Ctrl-C, permanent MC of chryssalids, Zombie-MC resurrection of agents, alien inventory exploits, anything involved with bad collision detection, extinguishing fire with a Smoke Grenade, and even your personal favorite, denying the aliens access to their own spawn points. So in conclusion, maybe it should just be left as it is; conversely, all of these entries could be kept where they are and also on a Game Limitations page, or we could leave the headers there and link them over to the appropriate topics on Game Limitations. What do you think? [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:21, 9 November 2008 (CST)

: I agree with AQ (great list of examples by the way - and the Smoke/Fire limit would be another). Many, if not most, of the bugs are "Limitations" but they are logically inconsistent and not what a player would expect to happen: they are imposed by (at best) memory limitations or (at worst) design/programming oversights. I think the easiest thing to do would be to change the title of the page to Known Bugs and Limitations, or put an explanatory note at the beginning of the section to explain that "Bugs" is taken to included "Limitations". [[User:Spike|Spike]] 13:16, 9 November 2008 (CST)

By the strictest sense of meaning, a "bug" is a mistake or error on the programmers part. Limitations imposed by design or memory are not the same creature as the people involved were consciously aware of the decision. I suppose that to the normal player, any type of behavior which is unexpected/unwanted is automatically dumped in the bug category because to them there is no difference. To those of us who study the game files however, the two are unequivalent. Programming oversights, yes, those are bugs.

Some of those limitations AQ mentions are (to me at least) bugs: free manufacturing, free wages, permanent MC of Cryssies (or actually any alien for that matter), Zombie resurrections and collision detection. Large aliens not waking up from stun is again, a bug. The programmers obviously had some issues when dealing with large units in general and never quite got it right. They made some progress in TFTD by trying to fix mind controlling each section of a large unit, but royally screwed it up by selecting the next 3 entries in UNITPOS.DAT no matter what they pointed to.

Perhaps it's just my background in logic which makes me want to push for a separate category for limitations. Then again, as long as everything is listed somewhere I'm happy. --[[User:Zombie|Zombie]] 22:06, 9 November 2008 (CST)

: Actually, taking a look through the page as a whole there are various other Limits described, and the distinction between Bugs and Limits is made quite rigorously throughout - not just in the Soldier Limits and Bugs section, where the Soldier Recruiting Limit is referred to as a Limit whereas other bugs (such as paying salaries for soldiers you can't recruit) are referred to as Bugs. So we maybe just need to rename the pages "Bugs and Limits" and add an explanatory note on the distinction. From a user point of view, rather than a programmer point of view, a bug is an unexpected (inconsistent or illogical) behaviour, so for that reason I think it makes sense to keep them on the same page but try to ensure they are all correctly classified as Bug or Limit.

: By the way, it could be hard to absolutely distinguish Bugs from Limits as I suspect there are going to be some grey areas where you would have to second-guess the intentions and decisions of the coders to know for sure if something was a designed-in Limit, or just an oversight (Bug). [[User:Spike|Spike]] 06:50, 10 November 2008 (CST)

::If we distinguish in this manner, I suggest the definition of "Limit" should be, "Something imposed by the game files or engine as a limitation, most likely in context to the capabilites of the then-current personal computer." More succinctly, anything that was done to allow the game to run acceptably on what was then a PC. This would include both the Soldier and 80-Item limits, the spawn limit(40 units per side), Smoke/Fire limit, and some of the others listed. (The Purchase limit was probably more of a convienence for the programmers than anything, but it is clearly an intended feature.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:11, 10 November 2008 (CST)

: I would add to this that sometimes a Limit may be imposed as a game design / gameplay decision, rather than in order to conserve a constrained resource in the platform (=PC). Also, I would suggest that ''intended'' Limits are Limits, but ''unintended'' consequences of Limits are Bugs. Obviously, making this distinction involves some guesswork. But I would guess that while the limit on total smoke/fire hexes was an intended Limit (to conserve PC resources), the ability to put out fires with smoke grenades and disperse smoke with IC rounds is probably an unintended consequence of the Limit, and so should probably be considered a Bug. Similarly, Base Defence spawn points are probably an intended limit, but the ability to flood spawn points is an unintended consequence of this, and thus a Bug (and an Exploit). (Spawn points should have been shared out 50/50, not humans-first). [[User:Spike|Spike]] 12:07, 11 November 2008 (CST)

::The limit on Soldier and Interception craft were probably more of a limit imposed because they capped the file and figured that X-COM wouldn't ever need more than 40 interception craft or 250 soldiers. (And I've never needed that many, case in point.)

::As for spawns, its actually difficult to take advantage of it in any reasonably established base. X-COM can spawn up to 40 soldiers in a base defense mission(tanks count as 4 soldiers), as a limit of LOC.DAT. Aliens have the same limit. So in order to take advantage of the bug, the base needs 40 or less spawns total. The Access Lift has 8 spawn points, General Stores(weapon-handling) has 11, Living Quarters has 8 more. This is 27 Spawns just getting soldiers in a base and armed. (Although the General Stores can be cut out if you perform the bug properly). Large Radar and HWD have 6 spawns(Small Radar has 2), and Hangar has 15. So overall, the "Spawn prevention" can be hard to take advantage of with all but the smallest bases. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:48, 11 November 2008 (CST)

Just to clarify, X-COM interception craft are not capped at 40 ships. LOC.DAT has a cap of 50 "things" on the geoscape screen at a time. This is shared between X-COM bases, X-COM ships, alien bases, seen or unseen UFO's, terror sites, crash sites, landing sites and waypoints. In a perfect game world with little alien activity and normally constructed bases, the max number of X-COM craft possible is 44: 5 bases with 8 hangars each plus one base with 4 hangars (or any combination thereof). If you illegally modify your base layout with an editor to get rid of the access lift, the max can be increased to 45 ships (9 hangars in 5 bases). Once clogged, all alien activity will cease.

The base defense limit of 40 units exists because of UNITPOS.DAT which has a cap of 80 entries total (tanks occupy 4 entries in this file). Auto-win missions in a base defense mission by clogging all the spawn points with X-COM units isn't as tough as it sounds, especially if your base is small or doesn't contain hangars. The main thing is getting your full quota of 40 units to spawn (meaning you should try not to have any tanks as they count as 4 units but only occupy one spawn point). This limits the base size to something like 5-6 modules depending on what you build. Still, even having more than 6 modules isn't bad as it forces aliens to spawn intermingled between your troops. With 40 armed guys staring in every direction, you can get positions of all the aliens in the first round and possibly even kill them all (depends on weapons and alien race of course). --[[User:Zombie|Zombie]] 20:12, 11 November 2008 (CST)

: I would say that Limits are the CAUSE of bugs... also, I feel that fire/smoke limit can be called a bug, because a player normally has no way to tell this, other than observation. Whereas the game DIRECTLY and CLEARLY informs you whenever you hit the 80 item or 250 soldier limits, which is more fair. [[User:Jasonred|Jasonred]] 15:22, 23 March 2009 (EDT)

Also IMHO it is not true that, say, 250-soldiers limit is a real game bug. In fact, it is not, it is just a rule of the game, or its limitation. And it is unimportant what its reason is (such or another way to store game data).

A bug is, by definition, an unexpected and involuntary result of programmers' work. However, we can only guess what the programmers wanted to attain, so this definition is both unpractical and impossible to be applied. It would be better to assume that a bug is a feature which has negative influence in the game. To clarify: the (un)famous 250-soldiers limitation does not harm in practice, as the number is really enough to play the game. But the even-more-unfamous 80-item limitation does harm and it has negative consequences - it is enough to recall the disappearing of bodies during some missions.

OK, there is no objective criteria to judge whether a feature of the game is a bug or just a limitation. But sometimes subjective criteria have to be enough. Otherwise, we would have to consider the 8-bases limit a bug. Does it make any sense? And if no, what is the difference between the 8-bases limit and the 250-soldiers limit? I feel neither is a bug. Because neither leads to further negative consequences.

And further, IMHO the buggy nature of some game features is quite obvious. If you cannot send more than 100 "parcels" of items at the same time, it is still not the bug. But if you must pay for an item you are trying to send but you cannot do it - it is a bug, perhaps everybody will agree. And similarly: the 255-scientists limitation is not a bug. But the strange behaviour of the game when you bought the 256th scientist is a bug. It would be just a limitation if the game did not allow to buy another scientist. But it allows while it cannot serve the 256th scientist properly, and that is why it is a bug.

So, I vote for removing the 250-soldiers limit from the bug list. If I am wrong in it, please add to the list also:
# 8-bases limit,
# maps with limited terrain (why should they be limited?),
# base area and base facilities limit (why wouldn't we be able to have 10 hangars in a base?),
# etc.

In yet other words, in my opinion it is not enough to show that the game does not allow to have more certain items or to do more certain actions. In order to count this among bugs, we should show that it really harms during playing the game, or just bears negative consequences.

[[User:Sherlock|Sherlock]] 03:52, 27 December 2012 (EST)

= Specific Bug Discussions =

== Misc Technical Bug ? ==

''(The context of this discussion seems to have been lost)''

This is a technical bug that doesn't happen to everyone and one this article wasn't really meant to chronical - but we won't turn away helping a fellow player if it can't be helped. It's just that there are so many random crash points in this game that it would take far too long to find them all or come up with solutions for them.

Certainly, the transfer crash can happen to some players, but it's not one that can be reproduced easily. It's just like the random crash that some players get when they research a floater medic. It crashes the game for some of us, but others don't seem to notice it at all.

It really depends on your hardware and OS setup, whether or not your copy of the game is damaged or your savegame is damaged, etc.

Does it happen in all games or just this one savegame?

- [[User:NKF|NKF]]

-----

== "Invisible Muton" bug ==

Upon shooting repeatedly a Muton, it sometimes plays its "death" animation without sound (as if falling unconscious) and it is no longer displayed in the screen, while remaining visible to my soldiers (I can center the screen and the cursor appears yellow over them). Under this state, they cannot be targeted by Stun Rods. They may play their death animation anytime they get shot, until they truly die, when they emit their characteristic sound and leave a corpse (along with any items carried).

I'm quite fond of laser weapons, maybe this happens more often with those.

Also, though I remember experiencing this quite often fighting Mutons, it may happen to any other high health race.--[[User:Trotsky|Trotsky]] 02:59, 2 July 2006 (PDT)

-----

Never seen that one myself. Another "unpatched game" thing maybe?

There's a (very rare) bug that allows your soldiers to live if they become stunned by an explosion that happens to kill them. Sometimes the game will register their death, and THEN register that they've been stunned. In every case I've seen this happen, however, the unit will have such a low amount of health that a single fatal wound will render it dead (again) on the next turn. I have a vague memory that other players may have been able to get a medkit to the scene on time...

I dunno if that's related to your issue at all (I doubt it, but... meh). I'd advise using a Mind Probe on the alien the next time it happens so you can check the aliens stun/health levels.

- [[User:Bomb_Bloke|Bomb Bloke]]

----

I'm pretty sure I've seen this with Mutons. Possibly Chrysallids as well, another high health, high armor creature. They were still readily killed by shooting the place they are. Good thought on the MP, BB

---[[User:MikeTheRed|MikeTheRed]] 08:51, 2 July 2006 (PDT)

----

I've been known to have a dying muton(in fire) to spin around and then switch to the female civilian death animation. With the scream and everything. Even got a civilian death registered at the end of the mission. And this didn't just happen once, but on another separate occasion.

Hmm. shape-shifting reptilians in the game! LOL! Happens alot [[User:EsTeR|EsTeR]]

Unusually enough, I once had a sectopod die and then drop a tank corpse. I was using the Lightning at the time for my troop carrier, so you can imagine my surprise.

Then there was one occasion where a floater dropped a snakeman corpse. Let's not even get into the sort of things the aliens like to stuff themselves with.

Your invisible alien bug is quite common, although there appears to be many causes for it. I think one involves a full object table when it comes to invisible aliens in bases. But it can also happen in ordinary missions as well. I'm guessing the game may have tried to do something in the wrong order, and sprite information for the unit may have been lost or corrupted along the way.

Having had an experience where all the chryssalids become invisible in one base defence mission was quite a shocker. I fixed this by saving the game, quitting and then restarting the game. If you ever get an invisible alien again, try this and see if it helps. If it doesn't, well, just keep a careful watch on your map and any alerts that pop up as you play.

There's a similar but less severe bug where a dead alien will still leave its centre-on-unit alert button, but this goes away shortly after you move or turn.

- [[User:NKF|NKF]]

----

That last bug happens when exploding Cyberdiscs kill nearby Sectoids, doesn't it?--[[User:Trotsky|Trotsky]] 23:56, 2 July 2006 (PDT)

----

This is a pretty easy one. I guess this bug occured on UFO recovery on a battleship, an alien base assault or a base defense mission? As soon as there are too many items on the map, the game saves some item slots for the equipment to be displayed (since it is more valuable and more important to research). This would also make stun weapons lethal if the stunned aliens would vanish. therefore the game has a failsafe if an alien is stunned (or badly wounded and becoming uncontious). The downed alien's stun level is set exactly on its left health points therefore resurrecting it instantly. This cycle is broken when the alien is finally killed. This means if you want to stun an alien in such a situation you have to destroy some items first.

- by tequilachef (April 4th 2007)

== Vanishing snakemen ==

I've known snakemen to become invisible when standing on a hay bale. On the first occassion I had a poor tank getting shot while spending numerous turns looking for it. On the second occasion I had an alien under Psi-control, left it on the hay bale, and couldn't find it next turn. - Egor

---

This is not limited to snakemen. Hay bale block visibility quite much when a unit is standing on it. Two possible solutions:
- Destroy the hay before entering
- Shoot at the hay. If it is destroyed any unit on it will become visible (as long as no other bales are blocking the line of sight). You might also hit the enemy directly.

I Dnt know if the aliens are affected by this diminished sight, too. My guess would be no.

- By tequilachef (April 4th, 2007)

== Blaster Bomb Bug ==

I'm currently playing through X-com UFO Defense, I have the collectors edition version. I'm in the process of trying to catch a live alien commander and the blaster bomb bug is making this very difficult. If i remember correctly a commander is always in the command center of the the alien bases. The problem is anytime i get close there is always a dude with a blaster launcher up there that tries to kill my troops. When they try to fire it down at me the bug kicks in and they blow up the whole command room and all the aliens in it because they can't figure out how to get the blaster bomb down the grav lift thing in there. This is making it very dificult to actually catch a live commander. Anyone have any ideas for tactics or anything to breach that room without the aliens trying to fire a blaster launcher up there? - eL Hector

: I can suggest two possible solutions. The first is to wait outside the command room for the alien to move closer to you. If it comes out of the room or if you know it has moved down the lift, you then burst in and stand right next to it to stop it from firing the blaster. This is risky because there could very well be a heavy plasma toting alien in there. The other is to use a small launcher and launch it up at the ceiling near where you think the alien with the blaster is standing. -[[User:NKF|NKF]]

== Disappearing Ammunition ==

I have observed that problem with X-COM 1.2, modded with XCOMUTIL. My stun bombs and heavy rocket missiles, along with clips for the auto cannon went missing.
[[User:Vagabond|Vagabond]]

------

Just run a test using my 1.4 DOS version with XComUtil but my stun bombs didn't disappear: 30 + 1 back in the base they came from, same number after I went tactical and I dusted-off immediately. Are you running XComUtil with Runxcom.bat or did you simply run Xcusetup?

[[User:Hobbes|Hobbes]] 22:12, 22 February 2007 (PST)

:Is it a case of hitting the 80-item limit?--[[User:Ethereal Cereal|Ethereal Cereal]] 12:28, 23 February 2007 (PST)

------
With runxcomw.bat, as everytime. Apologies, I retested and it seems like I was mistakened, but I could have sworn that I lost them dang stunbombs. Had to manufacture some. I will test some more, using four heavy weapons and seeing whether their ammunition disappears at all. Thanks. [[User:Vagabond|Vagabond]]

==MC at end = MIA?==

I am sure I have seen this again recently, where I won a mission with no casualties (I thought), but the last thing I killed was a Commander that had been chain MC'ing a psi-attack-magnet trooper, and that trooper was listed as MIA at the end (presumably because he was on the enemy side at the end of combat). Is this a bug, or is there another way to get MIA's on a completed mission that I might have missed?

Since then I have been waiting for the leaders to panic at the end before killing them (or waiting for a rare resist), so I can safely exit, but am I being overcautious?

--[[User:Sfnhltb|Sfnhltb]] 13:45, 27 February 2007 (PST)

If the trooper was mind controlled on the turn you killed the last alien it will be listed as MIA. No bug there :)

[[User:Hobbes|Hobbes]] 18:16, 1 March 2007 (PST)

Huh, why would that happen - your soldier should recover the very next round, why would he go MIA?

--[[User:Sfnhltb|Sfnhltb]] 18:20, 1 March 2007 (PST)

Doesn't make sense to me as well but that's how the game works.

[[User:Hobbes|Hobbes]] 15:05, 2 March 2007 (PST)

----

It seems that regaining control of units under enemy mind control works different for alien and human players. My guess: aliens under human MC are reverted to alien control AFTER THE ALIEN AND BEFORE THE HUMAN TURN while human units under alien control are reverted RIGHT AT THE BEGINNING OF THE HUMAN TURN. This explains three different phenomenons:

- The discussed MIA "bug" (he unit would be returned in the next human turn, but since it never starts it is lost. The mission is still won since no unit with a "genuine alien" marking is left)

- The fact that a mission is lost when the last human falls under MC while it is not won when this happens to the last standing alien (the aliens get their unit back before their turn starts and therefore have a unit left to pass the "anyone alive?" check, the humans would have no unit left to start a turn with. They WOULD have as soon as the turn starts, but no unit left before turn means bust)

- The fact that aliens still can see all an MCed human saw at the end of the human turn that follows the MC while this is not vice versa (The MCed human can give information to the alien side before reverted while an MCed alien is reverted too early). The result is that aliens can control a human indefinitely without having any alien seeing him until the MC is disrupted for one turn.

All confused? Then I did a good job! No seriously, this must be the explanation, I couldn't think of any other way.

- By tequilachef (April 4th, 2007)

: You're absolutely correct on the first two points. It's a sequence issue - you never get round to recovering the unit before the new turn starts, so you end without any units whatsoever. Makes senses too since the aliens would continue to continue to mind control that same unit over and over indefinitely.

: The third point however: The aliens don't need to know the location of the last MC'd unit. They know the location of all your troops whether they've seen them or not from the very start. They appear to give you a few turns of grace where they won't attack you outright (unless, from my observation, all your soldiers are incredibly weak). This is evident because all of the aliens will eventually make their way towards the nearest soldier even though their movement pattern may seem semi-random. Also, they know where you are because they can initiate psionic attacks without having seen any of your troops. They generally go after the weakest troops first.

: Just to add a semi-related point, but from the alien's perspective. If an MC'd alien unit is in the exits when you abort the mission, this alien is not recovered and in fact simply vanishes. Any equipment it was carrying is recovered, unknown artefacts or otherwise. You could possibly think of this as their version of MIA. However, the aliens differ ever so slightly in that if it's the last alien standing and under temporary mind control by the player, the mission doesn't end straight away. But I guess this is only because the player has everything under control, whereas in the other scenario, the Ai is in control.

: -[[User:NKF|NKF]]

My observations show that, at least in some versions of the game (tested with clean DOS 1.4 version, under DOSBox), the game crashes at the end of the human turn if all alien units which are still alive, are Mind-Controlled. If it was confirmed, it would be another not-listed-yet (serious) bug.

[[User:Sherlock|Sherlock]] 17:52, 26 December 2012 (EST)

== Crash Site in the atlantic ocean ==

That's right, my game generated a crash site on water. Here are the details:

- Crash Site a bit southeast of the USA (which was infiltrated a few days before by sectoids, resulting base had already been taken out), but certainly not on land.

- UFO: battleship, floater, alien harvest

- Geoscape: 8 X-Com Bases, 1 (known) Alien base, 2 other crash sites, 1 other (known) flying UFO (though almost worldwide decoder coverage), 3 X-Com Crafts out, 1 waypoint

- Date: January 2000

- Most Interesting: The Craft that downed the ship was a recently finished Firestorm (first human-alien hybrid craft I had built, I know this is lame for that date. Limited myself on 25 Scientists to improve the challenge) equipped with twin plasma. I had it built and equipped in Antarctica and then transferred to Europe. This base had no Elerium, a fact that enabled me to use the infinite fuel exploit which was in effect when downing the UFO. My craft was only slightly damaged when doing so. The battleship was the first target assigned to the craft, it came directly from my base.

- When shot down, the UFO was not targetted by any other craft.

- I had not lost or sold a single craft to that point.

- When sending a squad to the crash site the game didn't crash but generated a farm land ground combat terrain.

- I was not able to reproduce the bug from the savegame dated 2 hours before downing the UFO

Well guys, any intelligent guesses? I still have the savegames (before and after downing)! If you want to have a look, write here.

- By tequilachef (April 5th 2007)
----
: Well I'm sure you know about crash sites that are near land can sometimes actually be on water, so I'm going to assume that this site is well far away from any land mass. Could it be a weird entry in GEODATA\WORLD.DAT that has a land mass out in the ocean? Also are you sure the game didn't crash? Sometimes when it does it will load the previous mission (and usually 90% are at farm terrain). Are you sure it generated a new map and not load the last one?
:No real guesses but maybe some starting points to look at. I've probably stated some obvious situations you know about and have accounted for, but it never hurts to double check :D
- [[User:Pi Masta|Pi Masta]] 14:23, 5 April 2007 (PDT)

== Inconsistencies in MCing Cyberdiscs and Sectopods ==

I experienced, that when MCing one quadrant of a large terror unit any action it does only affects this quadrant (especially use of time units). That means, when TUs are up for one part, MC another one and continue firing. This however does not work out when moving the unit while it is not under complete control. The TUs used up by the resulting reaction fire from the rest of the unit is also deducted from the TUs "your" part has left (making it impossible for the controlled parts to return fire). This however only happens under reaction fire, not if "your" part fires on it's own. I don't know if this comes up when uncontrolled parts shoot by themselves in the alien turn, since this is hard to find out.

: That's because large units literally are made up of four separate units. They only share the same set of general stats (in unitref.dat). Unfortunately the 'under mind control flag' is unique to the four units, not the shared stats! So you in effect have multiple units under different control sharing the same stats. So if you move and it results in a reaction from the unit, it will spend the TUs you're using.
: Successful mind control automatically fills up the unit's TUs, so each mind controlled sector gets to move or attack again until there are no more sectors to mind control. Useful way of turning reapers into long range scouts!
: In TFTD, they attempted to fix this bug, but in fact made it much-much worse! The only way to mind control the unit properly is to control the upper left quadrant. Only! Any other quadrant will result in a partial (clockwise) control, and you may gain control of units other than that unit, or may even get into situations where you gain permanent 'partial control' of a large unit you haven't even sited. Wackiness all around!

:- [[User:NKF|NKF]]

== Facility Dismantle Bug ==

Boba: I've never experienced this bug myself in all my games in the Collectors Edition. It may very well vary from computer to computer.

-[[User:NKF|NKF]]
:I, however, have experienced it. I lost an entire month's worth of playtime because I couldn't solve it. [[User:Arrow Quivershaft|Arrow Quivershaft]]

::Anyone, any ideas on why it might vary from PC to PC? -[[User:MikeTheRed|MikeTheRed]]

:::I'd check other factors before blaming a given system. Assuming no mods are being used the most obvious is the order in which you initiated the construction of the modules. Then we've got which one was due to be completed first, and I'm sure there's a few other things to test out. Usually, a player won't cancel in-progress modules on a regular basis, so you wouldn't expect this bug to turn up often. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

:Easy way to reproduce: build 2 General Stores. Now delete the "second one" (see offset 16-39 in [[BASE.DAT]] for the order). Wait for the first one to complete. It'll crash immediately after the "end of construction" dialog. A fix is available [[User:Seb76#Bug_Fixes | here]]. [[User:Seb76|Seb76]] 15:52, 22 July 2008 (PDT)

== Manufacturing Limit Bug ==

Unfortunately, Mike, no you did not get it correct. It is the raw number of hours needed to complete the project, not the projected hours. I discussed this on the X-Com Forums a few months back at the following link: http://www.xcomufo.com/forums/index.php?showtopic=242027760&st=0&#entry164411

I did tests at the time in regard to the accuracy of the data given there, but I've lost the results. I'll quickly redo the tests in the next hour or so. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:00, 8 June 2007 (PDT)

:Tests complete. The breakpoints for every item were exactly where I predicted, regardless of number of engineers assigned. (I ran up a huge queue of items at my dedicated factory base on an old game, and then assigned whatever engineers would fit onto one project at a time, canceling projects as data was confirmed. This is only semi-random, but it serves our purposes.) I did run into a single issue, though. It appears that despite having 5 empty hangars at a (different!) base, the workshop there could not queue up more than 3 of any one craft at a time, thus making this bug impossible to replicate with the Firestorm or Lightning, as you must be producing more than three for the bug to occur. However, it still works with the Avenger. Later, I shall see about constructing a dedicated Hangar base with 7 hangars in order to attempt to replicate the bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:33, 8 June 2007 (PDT)

::Sounds great, Arrow. Why not post a simple example that shows how the problem works. As in, "with 1 Eng and 2 Avengers you might think X, but no, it's Y". And please delete my example. And it's a fine pleasure to meet you! Cool - [[User:MikeTheRed|MikeTheRed]]

:::When you say the usual resources are used by the "lost" resources, that includes cash, right? It sounds like if you're willing to foot the extra bill [[Buying/Selling/Transferring#Manufacturable_Prices|money/component-wise]], this could be used to build Avengers slightly faster then normal.

::: The usual time is 34000 hours. Double that and subtract 65535 and you're left with a paltry 2465 hours. Even a single workshop squad of 10 engineers will pull that off in a little over ten days. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

::::Sadly, this exploit doesn't work, because the high bit is stored SOMEWHERE. I lack a hex reader and have no code reading skills to speak of, so I'm a bit limited here. If you set up a Workshop as you described, the game would take all the time for 2 Avengers, all the resources for the same, but in the end only produce 1 Avenger. Meanwhile, I'll run more tests on the resources thing. I could swear it consumes the resources, but I'll double check.

:::::There is no need to store the high bits if the actual completion condition (assuming adequate money) is "number made is number ordered", which wouldn't reference the hours remaining at all. - [[User:Zaimoni|Zaimoni]] 01:49, 9 Oct 2007 (CDT)

::::Tests done; I was unable to replicate the 'disappearing item' trick,(Which I didn't test for last night) even with Avengers! It appears I was wrong; this still counts as a bug, though, because the wraparound is a problem.

::::Ironic that so much of this discussion centers around Avengers, because that's where I discovered this in the first place! [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:48, 9 June 2007 (PDT)

----

I'm revisiting XCOM and was working on [[Manufacturing Profitability]]... Arrow, can you (or anyone else) say a little bit more on the Known Bugs page about this [[Known_Bugs#Manufacturing_Limit_Bug]]? It's not clear to me exactly what the bug does, except that it understates hours. Is that all?... does it still take the (non-buggy) amount of time, still use all the same resources, still make the same number, etc.? It sounds like it could be a drastic bug - or is it only a very superficial one, a display bug for the hours? It sounds like you're leaning toward this latter.

Also on a semi-related note... I could swear I saw much more detailed info on the [[Known_Bugs#Facility_Maintenance_Costs]] issue... IIRC, the incorrect amount that's charged for maintenance, depends on exactly where a facility is in the base. IOW, different "rows" of the base cost different amounts. Could somebody provide a link there, and/or flesh the bug out better?

Thanks! - [[User:MikeTheRed|MikeTheRed]] 11:22, 8 October 2007 (PDT)

:I've actually seen the bug work both ways, but I've only been able to actually replicate the more superficial version of the bug. So the bug report up is about a superficial bug that drastically understates production time. If you wish to make this clearer, you have my blessings. As well, that 'different charging based on location' is dealt with here: http://ufopaedia.org/index.php?title=Talk:Base_Facilities ; however, the table has been broken with the Wikiupgrade, and I lack sufficient knowledge of HTML table code to fix it. But it should be of use to you. [[User:Arrow Quivershaft|Arrow Quivershaft]] 11:26, 8 October 2007 (PDT)

::Cool, I fixed [[Talk:Base Facilities]] but also re-organized and expanded [[Base Facilities]] so that it includes that bug in detail, as per Talk... this is an important issue that should be up front. I see that there's a separate [[Maintenance costs]] page, but I can't see having something so important (the maintenance bug explanation) all on its own page (which makes for a rather short page) rather than together with all the rest of the base facility info. If others agree (or don't care), I'll move anything remaining on Maintenance Costs to the Base Facilities page, then delete Maintenance Costs and re-route links. And if somebody does care, then please move my new section to Maintenance Costs, and move all the links, etc. Oh also I put in more words on your Manufacturing Limit Bug - how does it look? - [[User:MikeTheRed|MikeTheRed]] 16:37, 8 October 2007 (PDT)

:Looks pretty good, although it'll wrap fully; if you ask for 120000 hours, it won't be displaying 'almost no' time. The way I discovered it was when building two Avengers; I ordered two, paid for two, waited for two...and got one. But as said, haven't managed to repeat it, so until I do, we'll leave it like that. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:00, 8 October 2007 (PDT)

::I just revised and put in your specific example, because it's certainly possible some of us die-hard players will order up more than 1 Avenger at a time - and it's guaranteed it'd be a pain if 1 of them disappeared, laugh. I wasn't sure how concrete you were on that example but now I hear you say, you are sure it happened at least once. - [[User:MikeTheRed|MikeTheRed]] 18:33, 8 October 2007 (PDT)

:I have a question concerning the manufacturing "bug" which eats a craft in production due to wrap-over of the byte. Arrow (or whoever did the test), did you have a large quantity of craft already built at your bases? If so, I think this bug has more to deal with clogging up [[CRAFT.DAT]]. See, that file has a limit of 50 entries. Each craft takes up one record and each base you have built also consumes one spot. 8 bases allows 42 craft to be housed, while 6 bases allow 44. If you try to buy or manufacture craft once the file is full, nothing shows up in the game even if you have hangar space available. --[[User:Zombie|Zombie]] 19:00, 8 October 2007 (PDT)

::Huh, I never knew that. I don't see it listed on the Bugs page... I'll stick it in there. I've never approached that number, but some folks might. - [[User:MikeTheRed|MikeTheRed]] 19:07, 8 October 2007 (PDT)

:I was able to continue building other Avengers after that project, and they appeared correctly, so I do not believe that is the issue. In any event, I have a very bad case of 'archivism' and probably still have the save game and the CRAFT.DAT file around on my system; in fact, I think I was playing it a few days ago. I can see if I can find it and upload it; it created a 'hole' in the Avenger fleet numbers, where Avenger's x and x+2 were built, but x+1 was not. I'll look for it tonight and tomorrow and upload it to the wiki if I find it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:10, 8 October 2007 (PDT) EDIT: I found the file; I have 28 Avengers and 1 Skyranger in my employ. All Avenger numbers EXCEPT #2(Avenger-2) are accounted for, and I have not sacked or lost any Avengers. So this is where the hole and 'eaten' Avenger is. If anyone wants the CRAFT.DAT file from this game, I'd be happy to forward it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:20, 8 October 2007 (PDT)

::Sure, send it my way and I'll take a look at it. (Might as well send me the whole saved game as I may want to look at the other files too). I have tried to recreate this bug by manufacturing 1, 2 and 3 Avengers at a clip but all of them always show up. Don't know what else I could do to get this problem to crop up. --[[User:Zombie|Zombie]] 21:32, 8 October 2007 (PDT)

:File emailed. On the side, I've tried the same thing, and never been able to repeat the bug. It's been months since the first discovery, so I can't recall whether it was the first or the second Avenger that didn't appear. So maybe it was just a fluke. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:57, 8 October 2007 (PDT)

== Unconscious Enemy in Equipment Screen ==

The following happened to me repeatedly over the last few days.

In the last tactical Mission a live alien has been captured. When now beginning an UFO crash recovery mission this type of alien (same race and rank) appears in the equipment screen before the mission starts, meaning I can give it to any of my soldiers.
If I do so I can store the alien in the skyranger for the duration of the mission and, if it gains consciousness, kill or stun it at the end of it. A pile of equipment without a corpse will be in the UFO, indicating that the stunned alien is not some kind of duplicate but instead has been taken from the aliens of this mission. This is supported by the fact that in those missions the maximum number of crew members has not been surpassed.
If I do not do so the Alien will be placed in the crashed UFO. Whether it is unconscious or not I do not know, but the fact that it is completely disarmed when encountered in the battle suggests that it is.

So far it seems the following is necessary for the bug to occur:
# An alien has to be captured alive in the last tactical combat
# It has to be of the same race and rank as one of the aliens in the new tactical combat

So far this only worked...:
# If the new tactical combat was an UFO crash recovery of a medium scout.
# For floaters and mutons
# For soldiers and navigators
# If the alien in the last mission was stunned by normal weapon fire (although I do not think this is important) and not picked up (again, not likely to be important) or destroyed (which would mean it has to be actually captured)

It seems NOT to depend on the following:
# The type of the last mission (were, so far: Ground assault battleship, crash recovery large scout, base defense)
# Which squad or vessel was involved capturing the alien
# Where it is locked up
# If it has been transferred since capture or not

Would be interesting to know:
# What happens if the alien in the inventory screen is the only survivor
# If the alien in the invenory screen is one of the aliens randomly killed in the crash or not (it is likely to be one of the killed aliens, so far the equipment piles were always within the UFO)
# If this is not limited on crashed medium scouts: Does this work with terror units? What about large ones?

Maybe this is related to the proximity grenade bug (transfer of item properties to next tactical combat).

Additionally, in one of those mission a part of the terrain was not generated correctly. It was in farm terrain (The house on the right square, or north east square, in [[Image:Terrain-cult.gif|this pic]]). The outer wall right to the right window of the southern wall (1st Floor) was missing. Directly outside of the hole was a floor tile. I could walk a soldier through the wall, but he fell right through the tile. Dunno if this has to do with the stunned alien bug.

Version is collectors edition (the one from abandonia.com).

----------------

When a mission starts, the GeoScape engine generates the unit and object tables (in MissDat's [[OBPOSREF.DAT]], [[UNIPOS.DAT]], and [[UNIREF.DAT]]) before "shutting down". The Tactical engine then generates the maps, places the aliens on it, and blows up the UFO (if need be). Whether or not map generation and the subsequent events happen before you equip your soldiers I don't yet know.

The test would be to check the aforementioned files to see if they contain an unconcious alien, and/or the body.

Note that you can't see the bodies of large units on the ground (they count as four seperate objects covering four seperate tiles, so allowing the user to pick one up would essentially let you rip them apart).

- [[User:Bomb Bloke|Bomb Bloke]] 06:35, 5 August 2007 (PDT)

----------------

I honestly have no idea of how all those files work. But I still have a savegame in battlescape that is in one of those missions. So if anyone wants to have a look at those files...

I forgot to mention: I reloaded a geoscape savegame shortly before the battle to recreate the bug, but it seems that reloading in geoscape before the buggy battle eliminates the bug. I guess his should narrow down the possible reasons...

--------

Next time it happens, backup the aforementioned files before you start another mission. I'm afraid a savegame wouldn't be of much help.

- [[User:Bomb Bloke|Bomb Bloke]] 00:54, 7 August 2007 (PDT)

== Soldiers moved to outside of combat screen ==

Hi, I've got a DOS version of UFO:EU, and I've encountered a bug in the tactical combat. Sometimes (rarely) a X-COM soldier changes its location on the map on player's turn start and is placed on outside of the map, one tile north from the (north) border of the field. AFAIR the unit is then selectable (you get the flashing highlight when cursor is above), but is stuck outside of the field. Has anybody encountered this bug? It seems to happen randomly, but more frequently during the terror missions and on early turns (so maybe it's caused by high number of player/alien/civilian units?). --[[User:Maquina|Maquina]] 08:16, 3 September 2007 (PDT)

:I've never encountered this bug in CE of UFO. Presuming AFAIR means "As Far As I Recall," what exactly was the soldier doing? Any equipment data, location, or stat info might help us pin it down. Were afflicted soldiers always carrying a specific equipment set or weapon? Where were they on the map before they got moved? Did they get bumped a few spaces, or teleported halfway across the Battlescape? Does it happen more often on a specific difficulty?(Your theory would suggest this would happen most commonly on Superhuman) Against a certain type of alien? Best of all, if you can recreate the situation in a game, save the game and then you could upload the save file to the forums or this wiki, and the rest of us could take a look for ourselves and the code divers could root around for the cause. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:03, 3 September 2007 (PDT)

:: I've had this happen to me several times in UFO and TFTD. I don't know if it's specific to the Dos version or if it can happen in the CE as well. Sometimes the soldier ends up beyond the boundary of the map right at the start of the mission, at other times it happens after you load a game. This game is glitchy, which is the source for so many of its bugs, so your soldier's coordinates are probably getting corrupted to the point where they are -1 on either the X or Y axis of the maps's normal boundaries. For me it's commonly along the top edge of the map. I don't ever recall it happening mid-mission, only at the start or after a load. I cannot faithfully say whether it happened with or without XComutil, but that could be one of the possibly many causes for this. - [[User:NKF|NKF]]

:: I don't play UFO often, so I rely on just several campaigns played. This happens rarely (I've encountered this bug twice in my last campaign with ~80 missions played), but if you haven't seen this happen then it probably doesn't show up in the CE edition. In my experience the soldier is moved always beyond the north/top map border. I think (but I'm not sure) that this affects the first soldier from the team more commonly than others (or maybe even exclusevily?). The equipment/armor carried is probably not relevant, since the units moved this way don't have any special stuff, and this bug shows up on different stages of the gameplay (ie. sometimes when you have ordinary rifles, sometimes when all your units got heavy plasmas and power suits). --[[User:Maquina|Maquina]] 04:12, 4 September 2007 (PDT)

'''MY ramblings have been moved to my discussion page''' [[User:EsTeR|EsTeR]]

==Great Circle Route==

Should we have the Great Circle Route bug noted on this page at all? [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:33, 6 October 2007 (PDT)

: what is the great circle route? [[User:Jasonred|Jasonred]] 07:56, 31 March 2009 (EDT)

:: Pick two points on a globe, then hold a thread or string taut at those two points. That practically minimizes the length of the thread/string on the globe. You're now looking at a great circle arc (or route), the shortest distance between two points on a globe. -- [[User:Zaimoni|Zaimoni]] 11:15 March 2009 (CDT)

: Just as a line is the shortest distance between 2 points on a flat plane, a great circle is the shortest distance between 2 points on the surface of a sphere. The bug, by the way, is that aircraft in the game ''don't'' follow this shortest, "great circle" route. [[User:Spike|Spike]] 12:38, 31 March 2009 (EDT)

:: What a grand sounding name, for something so simple, lol. ... I thought you were talking about when you tell your soldiers to go from point A to point B, and for some reason they figure that Zone A and Zone B are really far apart, despite actually being side by side. (I shot a hole through a wall, clicked to walk to the other side, and my idiot soldier walked one big circle... to use the door! And got ambushed and killed by an alien. ... dum dum DUMB DUMB.)
:: Even the more modern games have problems with their pathfinding algorythms. Admittedly, games like Baldur's Gate had to do it in realtime.
:: On a semi-related note, I remember this guy called E-man, he was chasing a guided laser beam that was going to kill his girl, around the world, but he couldn't outrun it since he couldn't break the speed of light, only equal it by changing into a Laser himself. So... inspiration! He turned into a very powerful laser, and made a shortcut THROUGH THE EARTH... the straight line beats the great circle route, lol.
:: Thanks for the reply guys [[User:Jasonred|Jasonred]] 15:56, 31 March 2009 (EDT)

Added to article. [[User:Spike|Spike]] 16:41, 3 September 2012 (EDT)

==Bug not listed: Missing soldiers during base defense==

I encountered an interesting bug concerning base defense missions:
My base got attacked while about 30 soldiers and 10 HWPs were present. The usual equipment assignment screen was skipped and the mission started instantly with only the HWPs spawned at the map. Not even a single soldier bothered to show up... *sigh*
Although this turned out to be in my favor (you should have seen the puzzled Ethereals trying to panic my tanks) I´d like to avoid this bug if possible. I was able to reproduce this bug several times and with different bases.
Can anyone explain this bug and/or tell me how to avoid it?

Game version: Collectors edition. - [[User:NewJoker|NewJoker]]

-----

Well, ideally, we need to know what your base's construction was to be sure of this, but I think the most likely circumstance is that the HWPs took up all the spawn points. HWPs have maximum priority for spawning(followed by Soldiers, and then Aliens), so if you have enough of them garrisoning a base, it's entirely possible that soldiers and aliens won't spawn. However, this doesn't explain why the soldiers didn't start stealing the Alien spawn points...in any event, you might want to take the save game file, zip it up, and get ready to email it. I'm sure [[User:Zombie|Zombie]] would be quite interested. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:28, 13 November 2007 (PST)

-----

It's not the spawn points, it's a [[UNITPOS.DAT]] limitation. A maximum of forty records (out of the total of eighty) are allocated for your units, and tanks (which take up four records each) get first pick. Having ten tanks means there's no room left for anything else.

Ditch one HWP and you should see four units take it's place. - [[User:Bomb Bloke|Bomb Bloke]] 16:42, 13 November 2007 (PST)

-----

I´ll try with a decreasing number of tanks and report the results. As I wrote above having only HWPs isn´t too bad dependent on what enemy is attacking. [[User:NewJoker|NewJoker]]

----

This should be mentioned in the [[ExploitsE#Base Defence Mission Spawning Issues]] section. The Bugs/Exploits really need to be sorted and consolidated. - [[User:NinthRank|NinthRank]] 16:57, 13 November 2007 (PST)

-----

The limitation to 40 records seems to be the case; each tank I dumped got replaced by four soldiers.
So this can be used to effectively manage unit combination. Thanks for the quick replies! [[User:NewJoker|NewJoker]]

==Bug not listed: Ufo Gold (Windows Vers. abandonia.com) crashing when plasma defense is finished==

I recordnized this bug a few times now. (with hacked AND unhacked game)
If i place a plasma defense in 7 bases at the same Time and they are finished at the same Time, the game crashes sometimes.
In hacked game, it seems to crash even more when Alien containment is finished, plasma defense, shield defense...etc.
couldnt find it here...greetz

: I somehow doubt the sourcing is the issue. [You may want to fund the next XCOM series game with a Take2 re-release of UFO :)] More generally: the game only reports the construction of a given type of facility once, no matter how many bases it completes at simultaneously. I've only tested this in vivo with three-of-a-kind at once across six bases, however. It does seem reasonable that some sort of counter of undisplayed completions would "overflow" (attaining crash). -- [[User:Zaimoni|Zaimoni]] 10:05, Feb. 28 2008 CST

::I've encountered this bug myself with General Stores, actually, not just Plasma Defense(which I never build). EDIT: Some quick tests seem to show that there's a chance the game will crash any time two base facilities are done at the same time, regardless of whether they're in the same base or not or if they're the same facility.(although it seems to happen MUCH more in the event they're in different bases.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:13, 28 February 2008 (PST)

== Soldier Recruiting Bugs Tested ==

Just to note that I have positively tested and replicated the bugs listed under the new(ish) section [[Known Bugs#Soldier Recruiting Bugs|Soldier Recruiting Bugs]]. [[User:Spike|Spike]] 18:08, 19 March 2008 (PDT)

==Floater Medic Bug==

I have not thus far encountered the Floater Medic Bug; in fact, Floater Medics are often used to fill up my Rogue Gallery with interrogations. [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:50, 24 April 2008 (PDT)

Strange, it would always occur in my version. I don't remember where I got it from, but I
know it was a download from the internet. Using the XCom Hack v2.5, I viewed the alien in
the Alien Containment edit. I now have Type (race):____, and a Rank: Soldier for the
Floater Medic. It might just be corruption, but I do not have the resources to look into
it. [[User:Muton commander|Muton commander]] 19:24, 12 May 2008 (Pacific Time Zone)

I've never encountered it either. [[User:Magic9mushroom|Magic9mushroom]] 07:47, 23 July 2009 (EDT)

I think this only happens in the CE version. A disassembly of the code reveals that the stack to hold the matrix for what topics have not yet been researched is too short. It seems that those who ported the code from DOS doubled the local variable sizes blindly. There is already a problem that there are two-few bytes necessary for the entire alien organism section of the UFOpaedia, but double the expected size of the registers and it fills up quite easily unless a lot of autopsies and interrorgations have already been done. The only other situations that are handled by the same routine are the navigator revealing mission data or engineers revealing ship data, but there isn't enough topics in either section to overflow the stack variables. - [[User:Morgan525|Tycho]] 08:27, 22 June 2013 (EDT)

==Strength Overflow==

During one of my games with TFTD I noticed a really annoying thing happen during battles.
As my troops rose up the 'stat.' ladder they got better and better (as you'd expect), until they hit about 50 strentgh and completely lost the ability to throw anything.
Even trying to throw something tiny like a grenade or flare into the adjacent tile resulted in the 'Out of Range' message being displayed.

Anyone come across this before?
This was in TFTD CE.
[[User:Tifi|Tifi]] 07:55, 27 April 2008 (PDT)

:This is fairly well documented. The pathfinding algorithm for throwing objects will balk if anything is in the way of the throw and refuse to allow you to throw. What's happening is that your soldiers have become so strong that their throws are intercepting the 'ceiling' of the Battlescape(the top of L3), and as such the game thinks that the throw is blocked(because in order for the throw to complete, the object would have to be tossed up to the nonexistant L4). There's two ways around this:

:The Normal Way: Try shorter throws, throwing from lower heights, or throwing while kneeling. Beyond that, possibly get some new troops.

:The Sneaky Way: Manually edit the Strength scores of your soldiers in [[SOLDIER.DAT]] so that they're back to a usable strength level. If you set "Initial Strength" (offset 46 decimal or 2E hex) to 0 and "Strength Improvement" (offset 57 decimal or 39 hex) to a value of 50, you can permanently lock the soldiers at 50 strength. (You can lock them higher than that if you so choose, but not lower.

:Other than this, there's no workarounds I can think of offhand. [[User:Arrow Quivershaft|Arrow Quivershaft]] 08:10, 27 April 2008 (PDT)

:: There's normally no problem with the max level of 70 in open settings. However TFTD has a lot of low ceilings such as in the shipping lane missions and colonies, and the lower ceilings impairs your throwing quite a bit. In addition to shorter throws/kneeling, try moving out from under any overhangs if there is one just above you. - [[User:NKF|NKF]] 12:33, 27 April 2008 (PDT)

== Bug not listed: Sticking your head through the ceiling ==
This is something I just discovered: When you step on a small object inside of a building your soldier sticks his/her head through the ceiling and can see what's upstairs. You can even see the soldiers head coming out of the floor and that soldiers can shoot aliens upstairs. When I did this the alien I saw/shot was facing the other way, but I guess you could get shot if the alien was facing you. [[User:RedNifre|RedNifre]] 17:34, 11 May 2008 (PDT)

:That's not listed under "Bugs" because it's covered under "Exploits", right here: [[Exploiting_Collison_Detection#See_Through_A_Ceiling]] [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:26, 11 May 2008 (PDT)

:: I don't know if it was ever covered anywhere, but there's this neat trick that might sound similar to the walk-through-'wall object'-wall trick except that it involves your unit climbing slopes. They'll appear as though they've gone up a level, but are actually not on that level. They only visually appear to be there, but are really still on the bottom level.

:: It happens a lot when walking up the desert or forest slopes. I think the trick involves standing on ground level, and then ordering the unit to 'move' into the hill rather than setting the waypoint while on level 1. The soldier will move up the slope and perhaps stop on the slope or even reach the top of the slope, but will still appear when you're only viewing the ground map layer. The soldier is really still on the ground level, but will have elevation offset.

:: One really interesting way of using this trick is in the mountain region. If you can find a cliff face and a low hill nearby, you can literally have your soldier scale the cliff by standing the soldier on the hill, and then walking towards the cliff. It's ridiculous, but your soldier never quite reaches the top of the cliff tiles, so ends up walking up a slope.

:: On a side note, standing at the top of the ramp of the Skyranger is the same as standing on ground level - you're only offset a bit. This means that smoke on level 1 and the sides of the Skyranger will not provide protection when you're at the top of the ramp.

:: On another related note in relation: In TFTD (doesn't happen a lot in UFO), you might find it difficult to toss grenades onto underwater slopes. To remedy this, raise the level up by one. It might look like you're tossing at air(and you are), but it'll get the grenade where you want it. Odd, but true. I must remember to put this in the grenade explanation section. -[[User:NKF|NKF]] 23:11, 11 May 2008 (PDT)

== Base Defence bug that causes a crash? ==

Does anyone know about a bug in a base defence mission that causes the game to crash? The game keeps crashing on the 4th or 5th alien turn.

:I've encountered that myself, but it should be noted that overall, X-COM is not the most stable game and is prone to crashing often at anytime. The differences between the hardware it was designed for and the hardware we're running it on cannot be helping matters at all; it's really a small miracle it even runs without an emulator in the first place(I've got games from 1999 that will bluescreen my machine instantly). As such, I'm not sure it's worth noting as a bug, since it's a 'game feature'(albeit a detrimental one). In any case, what're you doing letting the aliens attack you anyways? ;) [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:33, 18 July 2008 (PDT)

:It sounds like an alien is in one of the outlying locations and attempting to destroy the top floor item. Possibly a radar or defense station. - [[User:Morgan525|Tycho]]

== Sources for a DOS4GW transplant ==

I was specifically thinking of the LucasArts Dark Forces demo, but I half-recall the actual source I used when testing that ~1999 was Id's DOOM. -- [[User:Zaimoni|Zaimoni]] 16:03, 7 August 2008 (CDT)

== Phantom Carried Casualty ==

You are carrying an unconscious soldier in one hand, and the soldier dies of his/her wounds. The dead soldier remains visible on the "left hand / right hand object" battlescape display, but is no longer visible in the inventory display. The problem can be fixed by moving another object into the same hand.

I've seen this bug with UFO Extender by [[User:Seb76|Seb76]] - possibly might be something to do with his manipulation of the inventory screen, rather than a general bug. I believe I've also seen this with other objects that were being carried in the hands, disappearing from the Inventory screen, but I'm not sure. I don't think it's an item limit bug, as XcomUtil shows 40 item slots free. [[User:Spike|Spike]] 08:58, 21 September 2008 (PDT)

:I think it has to do with the KO units KIA mod. Its doesn't take into account units held so when it tries to detemine where to place the corpse, there is no location. The routine doesn't undo the item-carried-sprite-ID byte for the holder. -[[User:Morgan525|Tycho]]

== Civilians As Enemies to MC'd Aliens ==

I ran across this issue a few times and just wondered if you guys experienced this. I MC'd a part of a Reaper (I always do the lower left for large aliens) on a Terror Site, then moved it a few squares. It suddenly stopped dead in it's tracks and then the alien spotted indicator increased by 1. When I clicked on the indicator to see where the enemy unit was, it brought me to L2 of the large apartment complex. However, nothing was there. When I sent a Flying-Suited soldier up there to peek in the window (eeek! A peeping tom!) he saw a female civilian standing there. This type of problem has happened numerous times to me so it's not a once-off thing. Maybe it's a LOS issue? Or maybe an alien indicator problem? Or a combination of the two? Don't know, but I'm curious if you guys have seen it. --[[User:Zombie|Zombie]] 23:40, 19 December 2008 (CST)

:There are a lot of major issues with MC'ing 4 square aliens. One of them being that you could accidentally MC an alien far off in the corner of the map, IIRC? Anyhow, maybe you should have tried MC'ing all 4 squares of the reaper and see if that changed things. -[[User:Jasonred|Jasonred]]

The long-range MC of other aliens when Mind-Controlling large aliens is only present in Terror From The Deep, due to a workaround to try and resolve the earlier bugs(and exploits) associated with controlling one square of a large unit at the time. In TFTD, successfully MC'ing part of a Large unit will also grant you control of the next three units in UNITPOS.DAT, in order. If you didn't MC the upper left portion of the large unit(the first UNITPOS entry for any large unit), you can potentially wind up in control of other aliens. So this doesn't apply to UFO. As for Zombie's issue, never seen it. And finally...Jasonred, on Talk pages, please indent your statement with colons so it differentiates from other people's comments, and sign your posts with 4 ~'s, like I will now do. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==Elerium Base Bug==

Jasonred: This bug has long since been known about. Elerium units on the Battlescape can be picked up by shooting away the power source; this one item counts as 50 units, and as such ANY elerium item spawned on any Battlescape counts as 50 Elerium. This issue with your own Elerium spawning as collectable loot in a Base Defense mission only occurs in older DOS versions, and is at the whim of the 80 item limit. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:55, 18 February 2009 (CST)

:Base defense does not seem to follow the 80 item limit in that DOS version. There are a lot of bugs that have long been known about. However this one was not included in the ufopedia for some reason.
:Also, the main thing about this bug is that it does not potentially double your elerium stores. It potentially multiplies them 50 times.
:... First time this happened to me, I was pretty flabbergasted. Here I was being conservative with my limited Elerium, refraining from blowing up UFOs when possible, when I perform a base defense and gain 3000 Elerium from it. Holy spit. -[[User:Jasonred|Jasonred]]

Alright, my error. Thanks for clarifying. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==HWP Fusion Bomb and SWS PWT Displacer Ammo Manufacturing Cost Bug==

At a cost of $15000, 400 Tech hours, 5 Zrbite, and 8 Aqua Plastics, this is the exact same cost as the HWP Fusion Bomb from X-COM EU, converted over to the equivalent TFTD resources. As such, it shouldn't be counted as a bug, since it is clearly what Mythos intended. [[User:Arrow Quivershaft|Arrow Quivershaft]] 09:55, 15 November 2008 (CST)

:Hmm, in that case maybe it should be treated as a generic game engine issue and not a TFTD specific issue - but I still think it's a design error. Can you think of any logical reason why the SWS/HWP version of the ammo should be more expensive (in cost and in materials) than both the craft ammo and the (more powerful) personal ammo? It makes no logical sense. Hence I think it's a design error. Nothing can be inferred from the fact it's unchanged from XCOM-EU, that doesn't imply any deliberate decision. It could just be the replication of an original error in XCOM-EU. [[User:Spike|Spike]] 11:17, 15 November 2008 (CST)

:: I can think of a logical reason to justify this: X-Com doesn't understand the technology as well as the aliens do (which is obvious, given the length of time each side has known the tech). Handheld Blaster/Blaster Bombs are just a copy of the alien design and therefor relatively cheap and efficient, but that can't be mounted on a turret. So X-Com has to make a new design, and they obviously didn't do that good a job as the aliens would have done. This explains Tank/Plasma being weaker than Heavy Plasma too. (Why is FBL Craft ammo cheaper than the tank ammo though? Maybe X-Com gave up on/simplified the guidance system and made it just a "dumb" cannon shell/torpedo instead which doesn't have multiple waypoints? Or maybe they just did a better job there?). [[User:Cesium|Cesium]] 04:07, 25 November 2009 (EST)

:Whilst we discuss it, I'll park my original text in here:

* ''Displacer/PWT ammo cost bug - at over $100,000 total cost per round, the ammunition for this SWS weapon is far more expensive to manufacture (both in money and rare materials) than the equivalent ammo for the Aquanaut-carried Disruptor Pulse Launcher, or the craft-based Pulse Wave Torpedo, despite being less powerful than either. This would seem to be a design mistake.''

See Also [[Talk:Displacer/PWT]]

:: I don't like the higher cost either, but I think it's a tradeoff of expense and quality for the convenience of portability. Sort of like an MP3 player to the gramophone... or maybe that's not a good comparison. -[[User:NKF|NKF]] 13:43, 15 November 2008 (CST)

A better comparison might be a desktop computer to a laptop. As a general rule, laptops are more expensive, but a similarly priced desktop gives you more power. Desktops are cheaper and offer power, laptops are more expensive and offer portability(though the gap is rapidly narrowing). [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:49, 15 November 2008 (CST)

:I think those are good analogies. But they don't apply in this case. To continue your analogies: We are paying mainframe prices for a clunky desktop that has only laptop processing power, and we're buying a mainframe for desktop prices. The vehicle version ("desktop") - is ''less'' portable and ''less'' powerful than the personal version (DPL = "laptop"), ''less'' capable than the craft version ("mainframe") - 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 SWS use up ''more'' of both Zrbite and Aqua Plastics than the Craft version. Do we really think it's logical that a tactical battlefield round, less powerful than its man-carried equivalent, takes more explosive and structural material to produce than both the more powerful man-carried version and also more than the air-to-air round that has 60km range and can take down a major alien combat craft? There is a clearly perverse bang-per-buck here, on every measure. My sincere belief is that this was an original mistake in the XCOM-EU engine that got copied into TFTD as well. The craft round should have the higher base price, but 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. But what I don't think is debatable is that is not logical for the SWS/HWP rounds to be more expensive than the craft rounds. It's clearly a mistake. Even in game balance terms, the only thing the HWP/SWS rounds have going for them is conserving "80-Item Limit" space, which I severely doubt was ever a game design consideration since it's just an awkward programming compromise. Any advantage inherent in the HWP/SWS is already reflected in the very high platform cost - there is no need to inflate the ammo costs as well. The bottom line is that a round for a (mini-)tank does not cost more, does not use more materials, than the same type of round for a long range anti-aircraft weapon that has much greater damage capacity and penetrating capacity. [[User:Spike|Spike]] 14:35, 15 November 2008 (CST)

I'm going to add this to the bug list now. [[User:Spike|Spike]] 16:06, 25 February 2009 (CST)

:Still don't think this is a bug though. Just because it's more expensive to manufacture than the hand-held or craft-mounted ammo, it doesn't mean the stats are wrong. Perhaps the programmers wanted to balance the tactical portion of the game a little more by making the ammo cost more for tanks. It doesn't have to be logical to be intended. Now if you had proof which said that the ammo was supposed to cost less but the stats were wrong, then yes, I'd agree. So if you boil it all down it comes to a disparate logic issue, not a bug.--[[User:Zombie|Zombie]] 21:31, 25 February 2009 (CST)

::I have to side with Zombie here. While the ammo may be disproportionately expensive, by the definition used on the rest of the page for bug, it doesn't fit. All the other bugs are errors in program logic or function or routines that are unintentional problems with the game, most of which are not warned of ahead of time. The ammo for the tank costs exactly what is listed and operates entirely as intended, whereas the rest of the bugs are not intended game features. Even if the numbers were entered wrong, that would be a data entry error, not a program bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:28, 26 February 2009 (CST)

:If it was a data entry error, I'd consider that a type of bug... assuming we had proof of the goof so to speak. LOL. --[[User:Zombie|Zombie]] 00:49, 26 February 2009 (CST)

:: It feels too specific an entry to be a data entry error.

:: I'm reminded of the high explosive. I know, I know - it's not an exact parallel to the FBL issue. A High Explosive is practically two grenades. Double weight, double bulk. Slightly above two times the damage. However, it costs five times the price of a standard grenade. Even though you're paying more for not-as-much, I don't think that could be considered a bug. A rip off, yes, but not a bug.

:: Here's a thought: Think about the immediate benefits each of the two controversial ammo types give back to you. Aircraft ammo = activity points. Tank ammo = loot. Yes, I know that aircraft ammo also generate crash sites, but you still have the ground combat to contend with.

:: One other thought: With careful management of your ammo, you'll probably never spend any elerium on the handheld version's ammo. Could it be the handheld that's really at issue here rather than the others? In the end I feel that it doesn't really matter. -[[User:NKF|NKF]] 03:38, 26 February 2009 (CST)

: I'm with Zombie that a data entry error is a bug (we have other examples), but also agree some proof is probably needed. And I agree with NKF that in the scheme of things, it doesn't really matter much. I don't think the HE pack is a good comparison (though the HE pack should be heavier) as it's reasonable to pay disprortionately more to get additional power at the same tech level. The fusion weapons are a case of paying more to actually get ''less'' power. I am not bothered by the handheld vs vehicle balance, not least because the game generally makes handheld weapons better than their vehicle equivalents, so I can accept that as an across-the-board design decision.

: I can also see a game balance argument ''if'' we believe that Fusion Tank ammo is more of an overall game-winning weapon than craft Fusion Bombs. But I'm not sure I agree with that statement. And even if it's true, and there's a game balance argument (in which case it would apply equally to handheld Fusion launchers), it's still illogical. The less powerful, battlefield warhead should not cost massively more in exotic materials than the much more powerful air to air warhead that brings down Battleships. I agree though that just because it's illogical does not prove it's a bug (i.e. unintended). [[User:Spike|Spike]] 07:48, 26 February 2009 (CST)

Ok we more or less seem to be in agreement that this isn't a bug, but it is very confusing/illogical. Maybe we can shift the "bug" text from the article page and roll that into the [[Hovertank/Launcher]] and [[Displacer /P. W. T.]] pages now. Feel free to combine any text from the discussion above if necessary. --[[User:Zombie|Zombie]] 09:22, 26 February 2009 (CST)

: Unless we can ''prove'' it's a data entry error (unlikely), how about calling it an "Anomaly" instead of a bug? [[User:Spike|Spike]] 10:59, 26 February 2009 (CST)

Looks like plain old game imbalance to me.
The way I see it, Hovertank Plasma and Launcher were meant to be stronger. Much much stronger. Let's look at Tank Cannon, Launcher and Laser. The logic is that it's a tank mounted weapon, so the tank can carry a much larger and more powerful version of the same weapon, right?
It's pretty stupid that a Hovertank Plasma is weaker than the Heavy Plasma... you could just mount a Heavy Plasma on a Hovertank and get them exactly equal. In fact, I suspect that the hovertanks were ALSO meant to have more powerful weapons than the man-portable versions.
Unfortunatly, the game designers then realised that this made the hovertanks far too powerful. So... the programmers nerfed the power of the hovertank weapons. BUT they forgot to lower the ammo costs. [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 11:20, 26 February 2009 (CST)

: Well you are opening up a much larger issue there. The Fusion weapons are an anomaly, an inconsistency. But handheld weapons are more powerful than equivalent vehicle weapons across the board, consistently. So that looks like a deliberate design decision, not a mistake. [[User:Spike|Spike]] 17:33, 26 February 2009 (CST)

:: There are two exceptions to the rule: Tank/Cannon: 60AP vs. Heavy Cannon 56AP. Tank/Laser: 110 Laser vs. Heavy Laser: 85 Laser. The hovertank\plasma only differs by a measly 5 (an extra 0 - 10 damage, which means a lot vs. UFO inner hull armour). I guess the trend here was to moderate the area effect tank strengths. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

I'd have to agree with you there Spike. This wasn't a mistake, however odd it may seem. It was a deliberate attempt to try and balance the game. Below is a table I created ages ago for my (now defunct) strategy guide detailing the HWP's and what handheld weapon corresponds to it. When you stick them side-by-side, it really becomes apparent that the programmers were trying to base the HWP weapons off the handheld weapons somewhat. The only thing that doesn't follow a nice and distinct scheme is the damage. That's what is the clincher. --[[User:Zombie|Zombie]] 20:26, 26 February 2009 (CST)
 
<table {{StdCenterTable}} class="sortable">
<tr {{StdDescTable_Heading}}><th align="left" width="150">Tank Type</th><th width="70">DAM</th><th width="80">Snap</th><th width="90">Aimed</th><th width="90">Aimed</th><th width="80">Snap</th><th width="70">DAM</th><th align="right" width="140">Handheld</th></tr>
<tr><th align="left">Tank/Cannon</th><td>60</td><td>60%</td><td>90%</td><td>90%</td><td>60%</td><td>561</td><th align="right">Heavy Cannon</th></tr>
<tr><th align="left">Rocket Launcher</th><td>85</td><td>55%</td><td>115%</td><td>115%</td><td>55%</td><td>87.52</td><th align="right">Rocket Launcher</th></tr>
<tr><th align="left">Laser Cannon</th><td>110</td><td>50%</td><td>85%</td><td>84%</td><td>50%</td><td>85</td><th align="right">Heavy Laser</th></tr>
<tr><th align="left">Hovertank/Plasma</th><td>110</td><td>85%</td><td>100%</td><td>100%</td><td>86%</td><td>80</td><th align="right">Plasma Rifle</th></tr>
<tr><th align="left">Hovertank/Launch</th><td>140</td><td>--%</td><td>120%</td><td>120%</td><td>--%</td><td>200</td><th align="right">Blaster Launcher</th></tr>
</table>
1AP rounds. 
2Average between the Small and Large Rocket.

: Hold up! Tank rounds do 60AP. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

So what's wrong? The table says 60 for the Tank/Cannon and 56 for HC-AP. Those are correct, no? --[[User:Zombie|Zombie]] 23:41, 26 February 2009 (CST)

: Sorry, didn't realise it was two tables side by side (or rather mirrored). Eyes only noticed the left side of the table. -[[User:NKF|NKF]] 23:53, 26 February 2009 (CST)

:: If the Hovertank Launcher did 200 damage, or worse if the Hovertank Launcher did EVEN MORE damage than the Blaster Launcher... that would make them easily the most deadly things on the map. As it is, the hovertank launcher is already pretty overpowered, even with 140 power.

I might be six years late here, but I think there could be an explanation for this in RL physics — indeed, in RL nuclear weapons programs. Incoming wall of text.

There are two sorts of nuclear reactions that produce energy: fission of large nuclei, and fusion of small nuclei. Fission can occur under normal temperatures and pressures, but involves a neutron chain reaction. As such, fission devices have to have a certain mass of fissionable material (the ''critical mass'') so that the neutrons stay in the material and cause more fission rather than escaping; this means that such devices cannot be scaled down below about suitcase or large backpack size (not all of this is actually nuclear material; rather, most of it is conventional explosives used to rapidly assemble the supercritical mass from subcritical masses). They also produce large quantities of radioactive fallout, which is problematic. Fusion, on the other hand, requires extreme temperatures and pressures, but does not necessarily require a neutron chain reaction. This means that they can theoretically be scaled down to much smaller sizes... except that the only available compact source (ie, not building-sized) of those extreme temperatures and pressures is the detonation of a fission bomb. Thus, all known fusion weapons currently in existence involve a relatively-small fission stage that detonates a much more powerful fusion stage.

The "Holy Grail" of nuclear weapons research is what's called a [[wikipedia:Pure fusion weapon|pure-fusion weapon]]. Because it has no fission stage, a pure-fusion weapon would release little fallout (note here that fallout is material that emits radiation long '''after''' the detonation; a pure-fusion weapon would emit copious amounts of deadly neutron radiation when actually used, but that would dissipate within seconds) and could be scaled down to grenade-launcher size (though it would obviously be far more powerful than a conventional grenade). They would be far easier to produce, as well; producing weapons-grade uranium and plutonium requires large and powerful isotopic separation equipment and/or a full-sized nuclear reactor, whereas deuterium can be extracted from water with trivial ease and lithium and tritium are relatively simple to obtain and make respectively. The main issue is that while the pressures required to confine the fusion material during the reaction are achievable with chemical explosives, the temperatures necessary for fusion are emphatically not. You need a stronger initiator; some material with a higher energy density even than plutonium. In RL the only initiator strong enough is antimatter — hard to produce and contain, to say the least — but the aliens in X-Com have a source that's stored far more easily... Elerium.

I posit that the "fusion" line of weapons in X-Com are exactly what they're named: tactical fusion bombs, made possible by an Elerium detonator. (A more controlled reaction on those lines — a fusion reactor with Elerium-spiked fuel — in UFO Power Sources would also explain the discrepancy between the calculations based on fuel efficiency and the lack of city-killer blasts when a Power Source's Elerium cooks off.)

Given the assumption that "fusion" weapons are indeed fusion weapons, with Elerium serving only as a detonator, the oddly high Elerium cost of the Hovertank/Launcher's ammunition is finally explainable. The HWP Fusion Bombs are, literally, smaller than Blaster Bombs and craft Fusion Balls (presumably because of size constraints in the launching mechanism in tanks). Having less explosives to compress the fuel means you need an even higher temperature to compensate — thus, more Elerium detonator — but because the actual power of the bomb is mostly from fusion and not Elerium decomposition, the yield is still lower.

I intend to remove this from the list of Known Bugs on this basis if nobody can find a hole in my logic. [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 02:03, 17 April 2015 (EDT)

:I'll have to disagree. Your argument while interesting, is just supposition and an attempt to give validation by taking ideas (that the developers probably never considered) to justify a flaw, very much in the same manner as those who try to explain why UFOs do not respond in interceptions. In truth, like many of the other bugs listed here, they are the result of issues caused by the time constraints the Gallops where under. Much of the production/buying/selling aspects of the game have game balance issues and don't make sense when cross referenced to other similar elements in the game and/or their overall effect to either combat or the strategy layer, especially in regards to the game's economics. [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]]) 05:06, 17 April 2015 (EDT)

::Why would they match up in terminology with the actual use to which any military would put Elerium by accident? Because, no shit, if a military got their hands on a substance with Elerium's properties this is literally exactly what they'd do (at least as far as explosives go). I can cite a paper talking about the superiority of antimatter-fusion weapons to pure antimatter weapons if you want; the title is "Fourth Generation Nuclear Weapons: Military effectiveness and collateral effects". [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 05:21, 17 April 2015 (EDT)

:quote all the sources you like, it still doesn't explain the waste in the manufacture process. With elerium being such a "scarce" resource, there is no logic in producing something that require more elerium and delivers less of a battlefield effect. It would be more logical and efficient to have had the platform fire regular blaster bombs, since they only require 3 elerium not 5.[[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])
::IMHO, any logic argument can be presented to why those HWP Elerium Bombs should cost less/more or be more efficient. That is not the point here. A bug is when a game feature is working improperly or/and is causing technical issues, either due to limitations, insufficient testing, whatever. Design choices are a completely different matter: the Heavy Laser is a nearly useless weapon due to its stats but no one ever considers it to be bugged due to its stats. It was a choice, that was slightly changed on TFTD with the Heavy Gauss. To consider the stats of the HWP Fusion a bug then you'd have to label a lot of choices as bugs when they are simply design choices. You may not agree with them but that doesn't make them bugs in the generally accepted definition of the term. And quoting Arrow Quivershaft on the top comment of this discussion: "At a cost of $15000, 400 Tech hours, 5 Zrbite, and 8 Aqua Plastics, this is the exact same cost as the HWP Fusion Bomb from X-COM EU, converted over to the equivalent TFTD resources. As such, it shouldn't be counted as a bug, since it is clearly what Mythos intended"[[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 19:35, 25 April 2015 (EDT)
::Also, the consensus until now expressed by several people that previously discussed this is that this is not a bug. The main supporter of the bug argument seems to be Spike at the beginning but during the discussion but halfway the discussion he says: "I agree though that just because it's illogical does not prove it's a bug (i.e. unintended)" [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 20:54, 25 April 2015 (EDT)
You don't get to claim benefit of the doubt here, Tycho. All game features are assumed to not be bugs unless there is compelling evidence presented otherwise. You claim this is a bug based on the suppositional logic that more powerful weapons should cost more and almost nothing else. The price wasn't altered (and neither was the power) in TFTD, so there's no evidence of mistake there (as an aside, the Displacer/Sonic having its power listed as 130 when it's 110 in the game engine clearly ''is'' a bug). The only bit you might be able to interpret that way would be the description of the Hovertank/Launcher's weapon as causing "immense devastation" compared to the description of the Blaster Bomb as "highly powerful" (the potential implication being that the HWP Fusion Bomb is stronger), but that's iffy at best since there's hardly a graded table of adjectives in use and on those very same pages in the UFOpaedia it lists the damage of each weapon as what it actually is.

The claim that it's a bug is based entirely on theorising about yields. I've given alternate theorising that would explain the yields (and I already explained that the semi-automatic nature of the Hovertank/Launcher and physical space for its high ammo could justify the need for a smaller round), which undercuts that claim. We can't know who's right, but the assumption should always be that the designers knew what they were doing; to assume until proven otherwise that they had no clue is extreme hubris and contempt. Moreover, you are in a minority of one or perhaps of two against a majority of several. Your claim to representing consensus is blatantly false.

Now, I'm going to wait a couple more days to see if anyone comes forward with anything substantive, as I waited a week after my reply to your original non-refutatory dismissal, and then reinstate the removal if nobody puts forward a cogent objection. [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 22:57, 25 April 2015 (EDT)
:Now that I think of it, though, an "oddities" page where we talk about this, the shitty Heavy Laser/Heavy Gauss, the No More Soldiers limit, and other not-bug things might be in order. It would help to make this page about actual bugs and not about weirdness that is nevertheless clearly as intended. Thoughts? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 23:04, 25 April 2015 (EDT)

:At the time, I didn't continue the argument as my point was that removing something based on one person's belief, no matter how cleverly thought out, wasn't good enough to warrant removing from the list. (I would have pointed out all the different theories on UFO interception AI, but I see that has already been removed.) I hadn't read all the discussions because I assumed that no consensus had been reached, similar to the Interception AI discussion. Mushroom, could have just pointed out that this issue was already settled years ago but no one bothered to removed it from the list, instead of resurrecting a "dead" discussion as though it had not been settled and just stated that the developers intended to discourage the use of this HWP by making the cost of its ammo high. I still don't agree that the HWP ammo is more efficient and thus justification for its production cost, especially since the developers would have never needed this level of justification or would have had the time to devote to so small an aspect of the game.

:I definitely agree that this page needs to be updated. Another reason I argued so strongly is because so many topics on this page do not fall into the category of bug as has been defined. I thought this page was also devoted to listing all the illogical aspects of the game due to the lack of enforcement on the definition. [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])

::If I only had a dime for each time someone proposes to change something on this wiki, everyone agrees, and then nobody ends up taking action... :) It's always better to take initiative and edit things. I agree also with an update to this page, and separating bugs from limitations. But definitely no more 'this should have been done this way' arguments to present design decisions as 'bugs' [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 17:43, 26 April 2015 (EDT)

:Okay. I'm planning to rip out the following and stick them on a separate page:

:Great Circle "bug" (this isn't really a "bug" so much as unoptimised code)
:Side-on Intercept "bug" (ditto, but given UFOs' tendency to alter course suddenly it's not even particularly unoptimised)
:Head-on Intercept "bug" (come on, this is just bitching)
:Instant Getaway "bug" (more an anomaly than a bug)
:80-item limit (intentional and the rationale is obvious to boot)
:Purchase limit (working as intended)
:Soldier recruiting limit (being charged for attempting to buy more is a bug, but the limit itself isn't)
:Soldier battlescape limit (there's a consequence of this which is a bug, the CtD with 10+ tanks, but not the limit itself)
:Manufacturing Completion Time Display "bug" (you can look at it and see what time it finishes, and it goes down at the right rate; it may seem a little unintuitive but it isn't "wrong")
:Manufacturing Rate Interruption Loss "bug" (more bitching)
:Manufacturing Rate limit (working as intended; the attempt to get around it in TFTD is bugged, but the EU behaviour isn't)
:HWP Fusion Bomb Ammo Cost "bug" (we're in agreement here it seems)

:There's plenty that need a tidyup on top of that but as far as the page split itself goes, are we agreed? Also, I'm thinking of calling the page "Anomalies and Game Limits", opinions? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 01:58, 3 May 2015 (EDT)

== DOS4GW - What the heck is it? ==

It's been ages since I had to remember this stuff, so those who remember clearer than I do, forgive me if my descriptions aren't accurate. Hopefully the general idea will come across.

Back in ye olde days of computere gamynge - and where there were more E's to go around, memory handling was a tricky beast to handle. Computer memory is divided into several different categories. Conventional, extended and I think expanded. I might be jumbling the terminologies for the last two a bit. Doesn't matter - memory was just cut up into small segments. The two most common memory types to PCs at the time were pretty small but were readily available. The third one - the most expandable (aka the chip with its massive 4 Megs of RAM you just spent your whole month's allowance on!), wasn't as easy to get at.

To get access to the higher memory that was available to the computer, special memory handlers had to be used. Drivers like HIMEM, emm386, etc were used.

DOS4GW is one such handler that lets the game access the computer's available expanded memory. Lots of games that came out at the time use this. Doom, Duke Nukem 3d, Syndicate, Ultima Underworld, X-Com UFO/TFTD, etc. LOTS of games. Any time you ran a game from the dos console and you saw the Dos4GW message flash by briefly it would be assisted by it (well, it stayed on the screen for ages back when processors were slower!).

It took the hassle out of memory handling and let the game access the available memory on the computer as one big flat block of memory to play with.

So what was meant in the article was to simply replace the dos4gw.exe with a more up-to-date version from another game. I think the way to tell its version was just in the message that it displayed. You can just run the dos4gw.exe file in a console window. It'll give an error, but the message it shows will indicate its version. UFO 1.4 uses Dos4gw 1.95, for example.

-[[User:NKF|NKF]] 01:22, 6 March 2009 (CST)
:DOS4GW also switched the processor from 16bit to 32bit mode. [[User:Seb76|Seb76]] 13:58, 6 March 2009 (CST)

== Clipping ==
I have a new bug. Its harmless. I have a savegame (EU CE - modified game) which has a sectoid within another sectoid. In the alien turn, one secturd walked off the roof and dropped down <s>onto</s> into another. (I guess there DNA is indentical afterall, so they 'become one' with the world). If you want the savegame (superhuman edited using UFOloader, UFO Mod v1, xcomed, Khor Chin WeapEdit v0.1) drop me a request on the my page somewhere. [[User:EsTeR|EsTeR]] 01:40, 18 September 2009 (EDT)

: Not something many would encounter, but definitely something that can happen. Units can occupy the same physical space, but the game cannot display them all. It'll only draw one of them. Actually saw this effect happen back in the early days of XComutil when it gained the ability to manually add new aliens into a battlescape. It did this by slotting them into the same spaces occupied by existing aliens. Then the fun would happen when you saw a couple of Mutons suddenly walk out of a sectoid. Not sure how the game determines who gets hurt when struck by a bullet. May very well depend on the order they are stored in the unitpos.dat file.

: There are a couple of ways you can replicate this in-game, but I can only provide theories on how you could do it. Such as shooting the ceiling above you and letting the unit drop through, or moving a tank off a ledge and getting its non-primary segments land directly on top of another unit. By the way, the rear end of tanks get stuck in walls if you attempt to move north or east off any ledges. -[[User:NKF|NKF]] 02:18, 18 September 2009 (EDT)

: Ok, so as long as others know about this, then all is good. I had never seen it and was doing alot of head scratching until I shot the alien.

== Berserk HWP crashes the game ==
In the article page it mentions that aliens which go berserk with their integrated weapons will crash the game. This is only true for Mind Controlled aliens (or units under X-COM control) - alien controlled units which go berserk do not crash the game. I tested an MC'd Celatid just now and it doesn't crash the game either, though it doesn't immediately go berserk - it waits another turn for some odd reason. Someone want to check this to verify my results? --[[User:Zombie|Zombie]] 20:31, 27 December 2009 (EST)

==HWP Morale Loss==

HWPs have 110 Bravery, which [[Morale#Effect_of_Bravery|normally prevents morale loss]], but I wonder if they can still lose morale due to loss of units with a morale-loss modifier. It'd depend on how the math is done. If, for, example, the -20 to morale for a dead unit is static, then multiplied by any [[Morale#Officers|morale loss modifier]], then reduced by 2 for every ten point of bravery, any officer death without another officer on the field will necessarily reduce HWP Morale.

It all depends on how the equation plays out and when modifiers are added. For sake of this post, I propose the following as the morale-loss equation: 20*(rank death modifier)-((Bravery-10)/5)*(1.00-Leadership bonus)=Morale Lost. (Rather than using 22 as a base, I'm going to assume Bravery is internally decremented by 10 for this equation as 0 Bravery is impossible without editing and it makes the math easier for the purpose of the example.)

It makes sense to me that rather than having 110 bravery hard-coded as an exception to "No morale lost", it simply works the same way in the normal equation, but is high enough that it negates most morale loss events, as even if an officer is killed, another officer is usually left on the field to help negate the penalty. That said, if a large portion of the team is wiped out at once, any surviving officers may not be able to negate it all, allowing tanks to start having noticeable morale loss.

So with the death multipliers, we can determine that every XCOM officer killed has a set death value. Rookies and Squaddies are -20, Sergeants are -24, Captains are -26, Colonels -30, and Commanders -35.

For example, under this theory, if a Sergeant is killed with no other ranked units on the field, a Squaddie with 50 Bravery would lose 16 Morale. (20*1.2-(50-10)/5*1.00=16). A HWP would, at the same time, lose 4 morale. The Sergeant's death is worth -24 Morale, and without another officer on the field to ameliorate the loss, the Tank's bravery only can 'absorb' 20 points of the morale lost. If it was instead the Commander lost, with no other officers on the field, the HWP would lose instead 15 points of morale, given that a Commander's death (20*1.75) is worth a whopping 35 points of morale loss if no other officers are present.

And if you have, say, four colonels and the Commander on rear/psi duty, and some alien flings a grenade or a blaster bomb into the back of the Skyranger and blows all three of them up and they were the only officers, the HWP has now lost 55 morale, which gives it a 10% chance of panicking/berserking on the next turn!

In the end this'll probably need to be tested for accuracy, but those are my thoughts right now.

Also, for the record, most units that berserk go to 255 TUs while still using the original TU-expenditure calculations; it's part of what makes berserk units so dangerous. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:34, 11 January 2012 (EST)

:Tested it under vanilla CE. Took a squad out containing just about every rank there is (commander + colonel + captions + sergeants), plus a tank. Blew up and killed all soldiers with a single blaster bomb shell, leaving just the tank, which lost no morale (sorry).

:I also brought a group of rookies along with a single commander + tank, and killed just the ranked unit. Tank lost no morale. A rookie with 60 bravery lost 17 (which matches the loss predicted by the formula currently on the morale page), whereas under your formula he should've lost 25.

:Still, you're on the right track. I've long had my own theory as to why tanks have been known to lose morale. Take a look at [[UNITREF.DAT#42|UNITREF.DAT[42]]] - this is the offset that stores a unit's rank. Notice something? The value gets higher as the X-COM unit's rank gets higher. Works in ''reverse'' for aliens, for whatever reason. I sorta figure it's so killing a mind controlled alien commander doesn't mess with your morale too badly, but there's a big problem with that theory and you can probably tell what it is...

:If the highest this figure gets for an X-COM unit is 5 (commander rank), then a killing a mind controlled alien ''terrorist'' with a rank value of ''7'' should net an even higher morale loss penalty. And indeed it does - I took a rookie and a tank to a terror mission, mind controlled and killed a terrorist, and the tank lost 10 morale. Guess it would've lost six if I'd taken a commander instead of a rookie, but that's still something.

:Note that the formula on the morale page does ''not'' account for this - it states that at bravery 110 the alien's death loss multiplier would always be applied to a base morale loss of 0, but that's obviously wrong. You're spot on in saying that the base morale loss figures are not totally dependant on bravery, and the "death loss" penalty is applied first. Would probably require a few more trials to determine what that penalty ''is'' for alien soldiers and terrorists though.

:Just for kicks, I edited a plasma tank to have 0 morale. It panicked in the normal way (either sitting still or charging off to the SE). When it berserked, the game crashed as soon as I dismissed the status message. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 18:54, 12 January 2012 (EST)

:: Thought I'd give it a spin. I sent a laser tank in with a squad and had it start shooting at team members. Each time it killed an ally, it would lose morale. Once it was under 50 morale, I waited until it panicked. Since I was playing the dos version, the game didn't crash but I suspect a memory leak of some sort may have occurred that would normally shut down the CE version. What would happen in CE if a soldier were to be edited and granted a tank turret, and then made to panic? Would the game crash? I'm just wondering if it's related to the weapon as opposed to the fact the tank is a treated as a large unit. -[[User:NKF|NKF]] 00:43, 13 January 2012 (EST)

::: Ah, friendly fire! Thought I'd tested for that, but obviously not...

::: Oddly enough, now that I try it, I see that the twenty point hit for killing a unit on the same side can be adjusted by the leadership bonus of the victim. Eg, kill a lone commander and his 35% penalty reduction takes the extra morale lost from 20 down to 13 (which is exactly how much a tank will lose, given that it otherwise wouldn't lose any at all).

::: Of course, this completely messes up my theory about alien soldier/terrorist ranks overriding the 110 bravery score. It doesn't. My tank "only" lost 10 morale because the alien's rank acted as a 50% leadership bonus... Though I suppose that's still interesting to know, because it suggests that keeping a simple alien soldier under mind control is more effective then risking your own commander in the field.

::: I took an otherwise unarmed rookie and assigned him a tank cannon + ammo. He could manually fire this weapon in much the same way a tank can. Forcing him to berserk crashed CE, under DOS he just spun around. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 21:20, 13 January 2012 (EST)

== 80-items limit on CE edition ==

I have the feeling that the 80-items limit does not apply to the CE edition and is instead a 110-items limit (at least during base defence). Can anyone confirm? [[User:Seb76|Seb76]] 16:24, 24 February 2010 (EST)

:I believe this limit was increased for TFTD. Maybe it was also increased for the CE edition of UFO, and only ever applied to the DOS edition of UFO?? [[User:Spike|Spike]] 20:03, 11 March 2010 (EST)

== Paying for Dirt in TFTD ==

I have the steam version of TFTD and am unable to replicate this bug. Testing with the starting base, I dismantled a few modules, added up my income and expenses, and it reconciled with my cash at the beginning of the next month. I even tried again, dismantling every module except the access lift, and once again saw no income discrepancy. Am I missing something, or is it possible this bug was actually fixed in TFTD? --[[User:Jewcifer|Jewcifer]] 12:18, 16 March 2012 (EDT)

:'twas probably fixed. It would indeed be helpful to add a small note to bugs on this page which are EU-specific but not obviously so (like this one). -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 17:14, 16 March 2012 (EDT)

::Every now and then I get the urge to test some of the more important bugs myself in my steam version of TFTD. Perhaps I will make a more complete effort and record the results somewhere on the wiki. --[[User:Jewcifer|Jewcifer]] 12:08, 21 March 2012 (EDT)

== Paying for dirt: Source of bug discovered! ==

Well, I never have read this anywhere (which kind of strikes me as odd, thinking of how obvious this one seemed to me... And i have NO programming background whatsoever), so I'll post it here, hoping that there are still some active members willing to try and verify my findings. If so, please comment here, because then I will inform bladefirelight to include this in any upcoming xcomutil release. If it had been discovered before, well then I just wasted some time here. Comment below, I will delete this entry.

As the main bug page mentions, when dismantling a facility still under construction the premium will only be paid once it would have been finished. This suggests some connection between paying the premium and building time. Looking into the infos here: [[BASE.DAT]], I quickly discovered what the problem was: When a facility is dismantled, the Bytes related to the location of base facilities are updated correctly. HOWEVER the game omits to update build time to FF (which is "will never finish", an entry only found on unused squares). If the facility is finished when it is dismantled (or destroyed during combat), then the 00 in the build time byte will stand. If it was under construction, the value indicating the remainig build time will continue to tick down towards 00 as if the facility was still there.

Now at the end of the month the following seems to happen: The game checks for ANY 00 entry in the build time bytes, and if there are 00 entries, it will look up in the location bytes the type of structure to determine the amount of maintenance for that 00-construction-time-square. When it finds "dirt", then it will charge the 80 grand (my guess would be that those are somewhere hard-coded).

This explains all phenomena related to this bug, like a dismantled hangar costing 320.000 grand or the premium only popping up after the build time of a dismantled facility that was under construction has expired.

Now the fix is pretty easy: Open the BASE.DAT in a hex-editor and change the bytes in question to FF!

== Minimized Interceptor Bug (Ufo CE) ==

Maybe this bug is not just related to saving, because I had a similar problem last night. The game didn't crash, but it kept restarting the same Battlescape mission.
One Avenger (A-3) was pacing a Battleship, while another Avenger (A-1) was sent to pick up the pieces of a Terror Ship that had been shot down by an Interceptor. Despite having no weapons (oversight on my part), A-3 wanted to attack the Battleship, but I minimized the screen, hoping it would land.
While the screen was minimized, A-1 landed at the Crash Site from the Terror Ship and started this mission. Right after finishing it, I got the message that A-3 was ready to land next to the Battleship. Happy that I'd get the loot, I started the mission.
After cleaning it out, I got the usual Loot and Promotion screens and went back to the Geoscape. A few seconds later, I was back in the equipment screen and the Battleship Mission started again. I played it once more, because - hey - additional loot, right? Err... no. At the end, I got the correct Loot screen for this attempt and the very same promotion I had gotten in the first attempt (A Rookie from another base promoted to Sergeant).
Got back to Geoscape and a few seconds later back to the Equipment screen. I aborted this mission (same Battleship again), got back to Geoscape and - you guessed it - back to the Equipment screen. After aborting this mission as well and getting back to Geoscape, I used the few seconds I had to go to 'Options' and 'Abort Game'. Maybe I could have made A-3 disengage from the Battleship since I think I saw them both on the Geoscape, a yellow diamond and a red plus, but it was pretty late by that time.
--[[User:Matzebrei|Matzebrei]] 15:06, 15 May 2012 (EDT)

This is a known bug. There is a work around. You should patrol the ship with troops and not land... Finish shooting down the other airborne ships first. Then when the ships doing the shooting are returning to base, change patrolling ship with troops to advance to downed ship in order to commence ground combat mission.
--[[User:JGF|JGF]] ([[User talk:JGF|talk]]) 07:55, 9 November 2016 (UTC)

== Activity Overflow Bug ==

This is a potentially campaign-ending bug. This was seen in the Steam distribution, DOS version (on Windows 2003 Server EE). Not sure if UFO Extender was being used - probably it was. End of Jan 1999 turn shows an extreme negative/underflow Monthly Rating score, which in turn is caused by extreme overflow of UFO Activity levels. Note that that funding "score" - the increased funding by countries - was very positive at the same time!:

[[File:dissatisfied customers.png]]

UFO Activity, by Areas and by Countries, is literally off the chart. Clearly some kind of integer overflow:

[[File:ufo-areas.png]]
[[File:ufo-countries.png]]

X-Com activity is also off the chart:

[[File:xcom-areas.png]]
[[File:xcom-countries.png]]

In addition to the likely outcome that I will lose the game in Feb 1999, it means I can't use the graphs to detect UFO activity outside of my radar coverage.

I have only seen this bug once, and (probably very unusually) I am running under Windows 2003 Server EE (!!). My hunch would be that's the cause, Windows 2003 Server is not the best games platform. :)

[[User:Spike|Spike]] 07:22, 3 September 2012 (EDT)

Further information:

I don't necessarily lose the game in Feb or March 1999. The Monthly Ratings from Feb onward are just based on the current month, not historical score to-date. However it still greatly increases the risk of suffering from the [[Known_Bugs#Losing_My_Favourite_Game|Losing My Favourite Game]] bug - which also greatly complicates doing too many controlled experiments on this Activity Overflow bug, because a few restores of the saved game quickly leads to X-Com Project termination (and humanity's doom).

Possibly the Activity Overflow bug is caused by an initial value of the score (or an array of score values) not being correctly zeroed at the start of the game. See this graph, which shows a negative score in May 1998, prior to the start of the game in Jan 1999.

[[File:Prehistoric_negative_score.png]]

[[User:Spike|Spike]] 08:48, 3 September 2012 (EDT)

I encountered the same Activity Overflow Bug in Windows 7 using Steam version, Windows option with UFOExtender latest version.

[[User:Humbe|humbe]] 2012.10.04 09:05 UTC

I encountered the same bug at end of january with latest xcomutil patched CE version (with only bug fixes patched) with ufo extender newest version running (close to default options). Got many saves from that first month. Even if loading very early save where I had done no missions yet, and just did stuff in base, graphs still show negative for various periods in 1998. Sounds more like corruption than something actually overflowing to me.

[[User:Archlight|Archlight]] 18:34, 24 September 2012 (EDT)

== Bad Paths Bug ==

I suggest to add bad paths on UFOs maps to the article, as another bug in the game.

[[User:Sherlock|Sherlock]] 09:25, 26 December 2012 (EST)
:That sounds reasonable to me. [[User:Spike|Spike]] 10:03, 26 December 2012 (EST)

==Expenditure Graph==
The economy graph for "Expenditure" neglects funds spent on new facilities. I noticed this in my current (DOS) game when I built eight Psi-Labs at the start of April and it didn't increase. I know it counts everything on the Purchase screen; I'm not yet sure whether it counts manufacturing costs.

Is this enough of a bug to be mentioned? Can anyone confirm whether or not it occurs in CE, and whether it counts manufacturing costs? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 02:40, 17 May 2016 (UTC)

==Workshop Crowding==
It seems there is a bug whereby you can allocate more projects/engineers than available workshop space. This can be triggered by setting up two concurrent manufacturing jobs, setting one of them to have 0 engineers working on it, then set the other to have as many engineers as you can assign to it, filling the workshop space. Then go to the other job with 0 engineers, and it will show a negative workshop space available, now if you assign at least one engineer to this project, you can assign the rest of your engineers however you please.

This is my first edit. I find it hard to believe I'd be the first to find this bug after so many years, can someone please confirm a reproduction and that it isn't documented somewhere I've missed? I am running the DOS version of UFO, but I'm also running XComUtil, not sure if that has an impact, or what patch level I'm on. - [[User:Uncertainty|Uncertainty]] 11:00, 20 Dec 2016 (AEDT) Update: Cannot reproduce on the CE version, still unsure of the patch level of the DOS version I'm running and don't know how to accurately determine that. - [[User:Uncertainty|Uncertainty]] 22:00, 29 Dec 2016 (AEDT)

: An easy way to check is whether you can research Magnetic Navigation after collecting one from an alien sub, or if you have to research a Lobsterman Navigator beforehand. If you can research it right away then you have v2, which is what the CE version is mostly based on. If you can't research it and must get the navigator, then it's the unpatched copy of the game. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 22:24, 29 December 2016 (UTC)

Update 2: Thanks NKF, I'm not running TFTD, but I figured out that I was running v1.2 of XCOM1. I cannot reproduce the bug on v1.4 so the bug only applies to v1.2 and has been patched in newer versions. - [[User:Uncertainty|Uncertainty]] 16:45, 31 Dec 2016 (AEDT)

= Unconfirmed bugs =

These may either be actual bugs that only exist as rumors and nobody confirmed them (yet) or stuff that may look like a bug but actually is a feature.

== Alien mission succeeds despite Ground Assault ==

Suppose aliens decide to do a mission. So they send a scout UFO. If you shoot it down, the alien mission gets derailed and the next scout becomes delayed, sometimes a little, sometimes a lot. Seems like the headquarters are waiting for the first scout to report back home or something. But eventually the second scout shows up so you shoot it down too. The third one also takes a long while to arrive and if you shoot that down too, the aliens either give up on the mission completely or send their big ships which only aimlessly fly to and fro, never land and leave soon, empty handed. This way or that way, the alien mission is a failure.

On the other hand if you wait for the scout to land, assault it with your Skyranger and win the mission, the alien's mission continues as if nothing happened. The second scout appears on time. So you ground-assault it too but the third and fourth scout also appear on time. Then the larger UFOs show up and land as if nothing happened to the scouts. You ground-assault them too, including the last Battleship that happens. But guess what? The alien mission is a SUCCESS even despite none of the UFOs making it back to base. Really annoying if the mission is an Infiltration, you can't take their juicy big UFOs because if you do, you are going to lose a country. But on the other hand all these Alien Harvests and Alien Abductions? Lots of juicy spoil and tons of points despite the aliens achieving what they wanted.

I need to add that I was playing some weird version of the game whose data was rejected by OpenXCom with "an invalid CHRYS.PCK file, please update to the latest version" message. So I don't know if this bug exists only there or is present in the latest version of the game too or even whether this is a bug or an expected behavior. - [[User:TowigOs|TowigOs]] ([[User talk:TowigOs|talk]]) 00:24, 3 August 2025 (UTC)

== Transfers can put you into debt ==

Any action you can do that consumes money will throw a big fat "NOT ENOUGH MONEY" error if you don't have the prerequisite cash on hand. Except item transfers. You can transfer stuff around merrily even when you are tens of millions in debt and on the brink of collapse from financial mismanagement. Maybe aliens MCed the movers to skip checking for money on your bank account and just hope they will get paid, eventually. Or they might MCed your bank to lend you money behind your back, allowing to go bankrupt reorganizing the content of your bases. At least you don't have to pay interest on these unwanted loans.

Looks like someone forgot to put "if (money<invoice) then {NotEnoughMoney();return;}" somewhere into that code path.

Note: Getting into debt because your base maintenance is much higher than your income and you did not have the cash is perfectly OK. These bills have to be paid. And you will go belly up financially if you allow this to go too deep. ([[User:TowigOs|TowigOs]] ([[User talk:TowigOs|talk]]) 21:55, 4 August 2025 (UTC))

=Cleanup needed=
Hmm this whole Talk page needs a cleanup. A lot of the Not Listed bugs, should be listed, or are listed. [[User:Spike|Spike]] 10:03, 26 December 2012 (EST)

:So, before it will be made, yet three more observations.

:1. There is no possibility to give back (to stop hiring) a plane without craft weapon.

:2. Alien Reproduction is unavailable in a normal game without hacking/save editing. This is probably connected to further errors on maps. A bug/error/programmers' oversight of the some kind is present in TFTD where it is impossible to obtain Examination Room. It is so because many tiles on maps are wrongly assigned to game's objects. Namely, [[Examination Room (TFTD)]] is treated as Alien Implanter - but there is plenty of errors of this type, on various maps (perhaps also in UFO: EU).

:3. Among soldiers in UFO:EU, there are Russians. Some non-Slavs may not know that Slavic (also Russian) family names have different masculine and feminine forms. For example, Petrov, Belov, Likhachev, Gorokhov, Chukarin, Andianov, Voronin, Maleev are all masculine names; women must be called Petrova, Belova, Likhacheva, Gorokhova, Chukarina, Andianova, Voronina, Maleeva respectively (however, a rule that the feminine form is always made by adding -a is wrong, e.g. Tolstoy - Tolstaya). The soldier's name Mikhail Gorokhova (which is possible in UFO: EU) is just ridiculous (for everyone who has even little knowledge about Russian things). Tatyana Petrov is also an impossible combination. X-Com creators probably assumed that family names are the same for men and women in all languages, and, as a result, they made only mechanisms for storing masculine and feminine forms of first names, not family names. But taking reality under consideration, this is a bug.

: [[User:Sherlock|Sherlock]] 16:22, 26 December 2012 (EST)

== Common bugs vs. UFO EU specific bugs ==

I believethere is one more thing that needs to be cleaned. Namely, both EU and TFTD share the same game engine, so some bugs are common for them both. However, there exists a page with a list of TFTD bugs, and it is clear (or: should be clear) which of the bugs are specific for TFTD. I think the same should be done with EU specific bugs: to hold them apart from bugs common for both games. Some bugs exist in both games but manifest themselves differently (like problems with mind-controlling of big aliens) - they are not true common bugs.

Or even more: one could expect a clear information by each bug, in which game and in which version of the game the bug occurs. And whether a patch exists or not. Sometimes such information is given now, and sometimes it is not. And if one does not know exactly which versions are affected by the bug, it should also be mentioned clearly.

[[User:Sherlock|Sherlock]] 04:13, 27 December 2012 (EST)

== Rename page title to indicate which game this refers to? ==

I was looking for a list of bugs related to XCOM Apocalypse, and it took me a while to realize this was about a totally different game. There are 4 games (not counting the 2 opensource projecrs) here on UFOP - maybe that could be reflected in the article aswell?
[[User:Panzerlol|Panzerlol]] 20:35, 31 March 2013 (EDT)

==New "bugs" submitted directly to main page with no apparent explanation==

WakkaDakka, have you actually managed to replicate this "missing time units" bug, or was it just a one-off freak occurrence? I'm not sure it merits main-page space until we have some idea how to replicate it.

N21, how were you seeing the future to begin with? It's only a bug if it occurs in the normal course of play.

[[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 03:36, 28 May 2015 (EDT)

== Enemy Unknown 1994: Save game bug mid mission. ==

Effect : Loading saved game mid mission just displays a black screen with the cursor at the top left, whilst the music continues to play in the background.
I don't believe the game has crashed out to DOS, having tried both CLS and DIR to no avail. Your can no longer interact with the game, making you force quit the app.

[[File:Screen_shot_2016-11-07_at_19.39.31.png|thumb|left]] 

I'm using Boxer 1.40 on a Mac - which in turn is built off Dosbox 0.74.
I remember seeing this bug years ago on Windows XP too, so I don't think it is platform specific.
I'm currently running it with some of the XCOMUtil patches too - but have had the issue crop up without any of the patches.

Playing on Superhuman level, I use a Skyranger with 14 soldiers equipped with Laser Rifles.

Cause : Hard to be specific. But here are the facts.
I have my suspicions it may be do to with fog of war rendering issues.
I've had it occur frequently when going to the NW edge of a map.

I also had issue on Alien base 1. I have a save game and can suggest moving a unit and saving it in another slot - that alone causes the issue. So if someone knows how to debug this I can supply that. Not sure if the combined number of aliens and yourself casue this.. I managed to eventually work thru a series of corrupted saves that wouldn't load to one that worked again).

Here is a sample save game where the game only needs one specific movement to corrupt a game when you save after the move.

[[File:GAME_10.zip]]
I've uploaded two images to show the move for S Bradley
[[File:Screen_shot_2016-11-11_at_13.50.13.png|thumb|left]] 
and the destination square to move him too. When you complete that move and save the game it corrupts.
[[File:Screen_shot_2016-11-11_at_13.50.17.png|thumb|left]] 

Incidentally there were two downed UFO's at this time, with a second Skyranger en-route to UFO 42. This mission was for UFO 43 with another Skyranger.

The problem frequently occurs.
Ive had it occur recently on the following types of mission:
Terror, Alien Base, Supply ship, Large Scout, predominantly with Sectoids and Cyberdiscs, but also with Mutons and Floaters.
The only thing all these missions have had in common was lots of units on both sides. For example 13 Floaters on a Scout mission, 9 Cyberdiscs on a Terror mission etc.

--

Other quirky things I've seen relating to Stunned units:

1) You can't stun a unit, forcing you to shoot it to complete the mission.
The target being stunned drops to the ground in a heap, but the game says you can still see it and can re-stun unit....

2) Celatids. You stun it, then it wakes up and moves away. The unit no longer renders correctly. It's like a sheet of garbled colored/transparent dots.

3) A stunned unit, other than a Celatid wakes up, and is invisible but you get the '1' in red square for visible enemy. You can stun unit and get the animation for it falling to the ground again.

--

Teleported unit off screen (notice the yellow arrow over the unit, which alas is invisible at the split second I took screenshot - OS/X rendering crap-shoot).
[[File:Screen_shot_2016-11-12_at_14.18.07.png|thumb|left]] 
The unit was teleported from the top of the stairs in an entirely different building, rendering the unit unusable for the mission. I ended up reloading it and doing over.... - [[User:JGF|JGF]]

:Stop spamming [[Special:RecentChanges|the changelog]], please - if you're working on a page and want to see the results of your edits midway through, use the Preview button. Don't hit Save until you are ''done''.

:I can't replicate any issues with your provided save. Bradley doesn't have enough TUs to "complete" the requested move, but asking him to make the attempt anyway, then saving / reloading, works fine for me under 1.4 as well as CE. For what it's worth, as far as I'm aware the game in no way keeps track of the number of actions you've performed during a given turn; at least, I haven't been able to find any such counter embedded in the save files.

:I do suggest you leave your units with more time units - when ending turn, any agents who ''might'' spot an alien during the enemy's turn should ideally have some cover, a kneeling stance, and enough action points to defend themselves with a reaction shot. Using your full TU allocation on movement is somewhat suicidal, and even when you can get away with it, it tends to leave agents without enough energy to move when they really need to.

:Your invisible units may be related to [[Known_Bugs#Invisible_Chryssalids|this bug]] - presumably you can trigger similar behaviour by knocking out all instances of a given alien species within a map, saving / reloading, and then waiting for one of the aliens to awake. I was able to replicate it with an Ethereal, for example.

:Difficult to comment on your garbled Celatid without seeing it first-hand. Ditto for your un-stunnable target. I'd quite like to inspect them with my save editor, though, and ditto for the teleported unit. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 05:46, 13 November 2016 (UTC)

Thanks for scaling the images nice to see the wiki syntax.
It's odd to here you say he didn't have enough Time Units left, because for me the move is allowed.
Where did you get your 1.4 patch?
I applied 1.4 too and am wondering if I got a bad version.
Also did you get your original XCOM off GOG or some place like that?
I have the original CD. I think it's the US version as I used to live there.

== Time Units reset to 0 when soldier reaches 255 TUs ==

I have been playing an old version of UFO: Enemy Unknown, where there is no limit on TUs for soldiers. At certain point, two of my best soldiers reached the limit of 255 TUs, which rendered them useless at now they have 0 TUs.
I tried to reduce their TUs by editing Soldier.DAT, but it did not help. If I check soldiers from the base menu, I can see that the value has been changed, but in the battle their stats are still the same and thus they have 0 TUs and cannot be moved with.

Do any of you know, how to fix this bug? Where is the limiter located, can I change it so that is will be as in the new versions? In any case, I believe this bug should be mentioned on the page. It is mentioned here though: http://www.ufopaedia.org/index.php/Time_Units --[[User:Achernar|Achernar]] ([[User talk:Achernar|talk]]) 21:13, 9 May 2017 (UTC)

: Feel free to add the issue - the page is a hodge podge of whatever issues folks have at the time or as they come across them.

: While I'm no expert on the file structure of the executable for the first release of the game, I suspect you'll find the cause for the byte roll-over feature is that there were no stat limiters to begin with. Best way to cope with it is to either retire anyone approaching supersoldier status to base defence duty, buy more soldiers and spread the experience out more evenly, or update to 1.4 and find a sound patch to restore the original sound samples.

: For your broken soldier: I'm, assuming you edited the soldier.dat file. If you saved the game while in the battlescape, the game creates a temporary copy of the soldier stats and keeps them in unitref.dat. This is to keep track of in-battle status changes, experience, etc. You'll need to edit the current TU levels in this file as well. Or beat the mission with the soldiers that can move and you'll see your edits reflected in the next battle. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 05:45, 11 May 2017 (UTC)

== Fire rate bug & German version footsteps ==

These don't seem to be documented for some reason: (DOS Version)

The fire rate always resets to 3 if an alien or an alien mind controlled unit throws a grenade.

If German is chosen as language to play, the footsteps of all soldiers, regardless of the terrain they walk on, will sound as if they are walking on a metal surface like the inside of the Skyranger, UFO or the base. [[User:Bard|Bard]] ([[User talk:Bard|talk]]) 05:38, 8 April 2019 (CEST)

== Direct incendiary hit causing no reaction fire? ==

On the Incendiary page, it is reported that a direct hit will not cause an alien to spin around and return fire. I have tested this in OpenXcom and find that the aliens do, in fact, return fire. If this can be confirmed in original X-Com, it would be good to add to known bugs.

: It's safe to say everything you find on this wiki relating to the classic game pages were gleaned from the original games. OpenXcom, being an independently developed fan project, will have its own list of fixes and changes chronicled in its own documentation. In fact I would not be surprised that good deal of the more technical information on this wiki has been contributed by those that had some input into the OpenXcom project. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 05:16, 8 June 2021 (UTC)

:: Thanks, good to know. Would still love to know if anyone has tested this in classic game. If not, I will when I can, so it can be added to known bugs [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 22:05, 15 June 2021 (UTC)

==Alien weapon loadouts bug/anomaly==
There are actually 10 alien weapon loadout sets, not 9. The actual first set is 70% "early"/20% "mid"/10% "late". This loadout set never appears in-game, though, because the setup at game start counts as a month rollover which means that weapon loadouts (which are called when the mission occurs, not at month start when the mission is scheduled) are called from the second set during January, the third set during February, and so on. This is probably an oversight by the Gollops (note that race weights reach their final values in October; were it not for this quirk, weapon loadouts also would), but it's hard to be sure. Should this be added? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 15:02, 28 April 2025 (UTC)

Talk:Known Bugs

2025-08-04T21:55:48Z

TowigOs: Forgot signature

= Classification etc =

== Bugs vs Exploits ==

Could someone comment please on the distinction between a bug and an exploit, and where to put each one? I would guess that a bug is something that undesirable and an exploit "might be" desirable, if you want to cheat. But what about exploits that happen by accident, or bugs that need to be forced to happen?

I was going to add the Research Rollover bug to the Exploits sections, but they seem to all be under construction. What's the agreed approach?

[[User:Spike|Spike]] 04:16, 15 March 2008 (PDT)

* i think that an exploit is somthing you can trigger and gain an advantage from. a bug may or may not have a known trigger, and does not give an advantage if it does.
: All exploits are bugs, either in implementation or design. When using a bug to gain advantages that bug is used as an exploit (you are exploiting the bug). [[User:FrederikHertzum|FrederikHertzum]] 13:39, 10 May 2011 (EDT)

:: IMHO, Laser Pistols Gifts to train reactions is an exploit, but it does not involve any bugs. It merely exploits the fact that laser pistols will not penetrate the front armor of Flying Suits. [[User:Jasonred|Jasonred]] 16:31, 10 May 2011 (EDT)

::: I guess the point is to differentiate if it's a bug that's being exploited to your advantage, or it it's something confined within the game mechanics that you are exploiting to your advantage (even if using it as intended). -[[User:NKF|NKF]] 02:31, 11 May 2011 (EDT)

:::: Another definition: An exploit is
::::: a) a move allowed by game interface
::::: b) that sidesteps another part of the game mechanics
::::: c) and creates inadequate advantage for the moving player in the process.
::::: An exploit is not a bug, but it can be connected with a bug, if the latter allows a move mentioned in a). Most obvious exploits render whole parts of game mechanics obsolete (see b) above), because they are always more advantageous. In games that feature equal terms for AI and the player, an exploit can be discerned simply by the fact that AI does not use it (sadly this is not true in X-COM). Clear exploit in X-COM: Transfer soldiers = no monthly payment. Suspect exploits: grenade layout. Most probably not an exploit: Sniping (although the inequality with AI is suspect). Clearly not an exploit: dropping weapons to prevent Psi mass murder (this one is made exploitable by the AI unable to pick up weapons, but is not an exploit per se).--[[User:Kyrub|kyrub]] 05:30, 11 May 2011 (EDT)

The dropping weapons sort of turns into an exploit if you do the "everyone suspect of being a psi weakling drops their weapons at the end of the turn. They all pick up their weapons again if unpsied in the next turn." The grenade layout or grenade hot potato is probably not what the game designers had in mind, but I shudder at the thought of someone who only played X-com then joined the army pulling the pin out of his grenade and then dropping it into his haversack or slinging it on his belt. [[User:Jasonred|Jasonred]] 07:43, 11 May 2011 (EDT)

: Yeah, I think we agreed somewhere that shoving live grenades in your pockets and not having them go off is madness. The relay however is not sensible but certainly possible if only a very short one (if with a live grenade), or to toss a grenade forward and prime it at the second to last person. Or more reasonably, something like a stick of dynamite with an extra long fuse. Even that's very dangerous.

: By the way, what does everyone here think of using the mind probe to check if it's safe to attack an alien while standing in full view of it, or if you're right up next to it? I've been using it a lot lately (in lieu of the psi amp), so you could say I've been exploiting the mind probe to my advantage to help me with my decision making. But is that counted as a cheat since I'm picking my moments to attack up close when the enemy cannot return fire? -[[User:NKF|NKF]] 03:30, 12 May 2011 (EDT)

:: When identifying a mechanic as an "unfair exploit" (as opposed to just a "tactic"), perhaps a simpler checklist is this (though Kyrub's is spot-on):

:: a) Is this something the developers should've expected players to do?
:: b) Is this something the developers could've easily prevented?

:: If the answer to both is "yes", then it seems fair game to me. For eg, sniping at aliens: The game KNOWS whether the soldier can see the target (you get a flashing indicator if so), and so it would've been trivial to prevent it. Is it something the regular gamer will try? Certainly; therefore it can be considered expected behaviour. Ditto for using the Mind Probe to make attacks without fear of reaction fire; those things aren't cheap, they sell for a bunch, so it stands to reason that they'd have tactical value!

:: Things like the transfer bug are clear exploits. The devs would've implemented that system so that, if you order personal near the end of the month, you don't end up paying for them twice before they ever arrive - but in the process, they forgot that "purchase" transfers are treated in the same way as "between-base" transfers. To fix one scenario without breaking the other, they'd've needed to code in some extra stuff so the game could tell the difference - they probably just figured the regular gamer would never notice, assuming they ever realised the problem existed.

:: The "dropping weapons" thing is a little trickier to work out - yes, the devs should've seen it coming, but would it've been easy to fix? Aliens could've been twigged to either ignore un-armed soldiers... but those soldiers could re-equip next turn. Aliens could also've been twigged to attack randomly... but that would make their psi powers far LESS effective! I suppose the fix, if any, would've been unarmed melee attacks, but the implementation they went with seems to be the next best thing IMO.

:: In regards to the "grenades in inventory" thing, it's probably common knowledge by now, but they DO go off in the alpha of the game. Presumably someone made a conscious decision to change that, though it could still just be an accidental bug. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:02, 12 May 2011 (EDT)

Sniping at aliens is a very bizarre case, since almost all players will fall prey to the aliens sniping at you long before they snipe the aliens. The behaviour of the aliens to step within sight radius, take one step back, then fire without fear of retaliation *looks* and *feels* like clear exploitation of the rules, but the computer can't be a cheater, can it? So we humans carry that one step further. Mind you, I think X-com would be in trouble if the aliens could snipe you from across the map once they know your positions... especially since the aliens have cheating "if I spot 1 human, I spot ALL of them" abilities. Especially on maps where the aliens get Blaster Bombs...

An interesting note about sniping and LOS: When I first played Xcom, my first mission was in the jungle. Because of all those plants, when my first soldiers spotted an alien, after he shot at him, I tried to make my 2nd soldier open fire and was informed "NO Line of Fire". I could only get my 2nd soldier to fire by positioning him in such a way that I got the flashing number. Henceforth, I assumed that you could ONLY fire at the aliens when the flashing number was there. LOL. LOF. LOS.

Transfer bug wise, I thought that the devs merely programmed the game to count how many staff were currently in the base, then deduct that from Xcom coffers? As far as ordering personnel near month end goes, you end up paying salary for them if you order them more than 48 hours from month end, right? "realistically", they should make staff draw salaries based on when they were hired, but this would be too much effort.

"dropping weapons" would have been easy enough to fix... just teach alien AI how to pick up weapons. Like they did in Apocalypse.

As far as grenade relays go, if you ever join the army, and you toss a live grenade at your squadmate, you're gonna be court martialled! lol. Xcom grenades are weird cause they presumably come with a computer console where you program them or something that takes a lot of TU, if I already have a grenade in my hand I don't think it takes long to prime it compared to throwing it...

Pretty clear exploit/bug is tossing grenades through the ceiling? That breaks all laws of realism/logic/whatever, and I'm sure the devs didn't plan for THAT to happen! [[User:Jasonred|Jasonred]] 18:18, 12 May 2011 (EDT)

: Turns out the "spot one, spot all" thing was wrong all these years. However, units can be "spotted" by sniping an alien, hitting it, but failing to outright kill it; this may have contributed to the misconception.

: The game considers the base to have the correct amount of personal as soon as you initiate a transfer - if a base has room for ten people, you can't send two groups of ten, as soon as the first is in transit the game will correctly recognise that the destination is now filled up and won't allow you to send any more. Likewise, if you hire soldiers, they'll count towards the allowance of more promotions in your ranks before they ever arrive at a base. That is to say, the payment system deals with personal counts in a different way to every other system in the game, making it look like it's intentional (if badly exploitable) behaviour. In terms of transit times, those seem to vary, I know a purchase of scientists takes 72 hours to arrive.

: Er, yes, getting aliens to pick up weapons would've indeed fixed the dropping thing. Shoulda thought of that...

: The grenade thing is indeed unrealistic however you look at it. Certainly throwing the things through ceilings is a bug, and its use is a large exploit. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 20:02, 12 May 2011 (EDT)

:: Then how do the aliens "spot" the psi weakling to target him for psi attacks? Doesn't the game ALWAYS start blasting the juiciest target, regardless of LOS? Or is it just coincidence? [[User:Jasonred|Jasonred]] 22:22, 12 May 2011 (EDT)

::: They really have to "[[UNITPOS.DAT#8|spot]]" the target before they can blast them (however, it appears that later in a campaign this rule gets broken). If they've only spotted a psi-''resistant'' trooper, they typically won't bother to make attacks at all. There's a lot of relevant information in [http://www.strategycore.co.uk/forums/Can-alien-attempt-Mind-control-Pani-t8115.html this thread]. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 23:28, 12 May 2011 (EDT)

: Your talking about your post on http://www.strategycore.co.uk/forums/Can-alien-attempt-Mind-control-Pani-t8115.html&pid=96123&mode=threaded#entry96123 ? Well, I'd just like to point out a massive flaw in your testing logic. You forgot that aliens will launch psi attacks based on chance of success, and chance of success varies based on distance from aliens. In other words, it could easily be that the aliens only attempted psi when your soldier was within sight of them because your soldier was now NEAR to them and therefore they had a strong chance of success.

: Also, as you have noted, it appears that your rule gets broken. In fact, it is not uncommon at all for the Ethereal Commander who is boxed up in the Command Center to launch psi attacks on victims who are separated from him by several layers of walls, as long as their proximity to him is near enough. [[User:Jasonred|Jasonred]] 21:19, 13 May 2011 (EDT)

:: Those are valid points. I've hence built a somewhat more robust testing scenario, which you may wish to [[:Image:Alien Psi Demonstration 1.rar|try for yourself]].

:: The save game consists of cloned Ethereal soldiers (all cranked up to 100 psi strength/skill), and many clones of a single trooper (most of whom have the same psi values). The Ethereals are all cooped up in a sealed room in the SW of the map, with a single trooper who has 140 psi strength/skill.

:: Directly outside the building is another trooper who only has 1 strength/skill. In the NE of the map, in another sealed room, is a soldier with 40 strength/skill. Before placing him there, I had him shoot one of the Ethereals just once, resetting index 8 of his UnitPos record to 0. Only he and the trooper inside the room with the Ethereals have hence been "exposed" to the aliens, but the "best chance of success" is obviously the psi-weakling directly outside the building.

:: If you load the map and end turn, the aliens will first attempt to take control of the dude on the other side of the map, then get to work on the guy in the room with them. Once they've taken these two, they'll completely ignore all other units.

:: In short, aliens can't use psi attacks on a unit UNLESS their UnitPos[8] index is set to less then that of the alien's intelligence stat. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 05:41, 14 May 2011 (EDT)

::: Good one. That test definitely proves a lot, rather conclusively. [[User:Jasonred|Jasonred]] 06:53, 14 May 2011 (EDT)

== Bugs vs Limits ==

''(Discussion continued from [[Talk:Known Bugs#Soldier Recruiting Bugs Tested|Soldier Recruiting Bugs Tested]])''

The "Soldier Recruiting Limit" is not a bug, it is a limitation of the game. Therefore, this should be removed from the page. If we want it somewhere else (like a new page such as [[Game Limitations]]), that would be appropriate. --[[User:Zombie|Zombie]] 01:42, 9 November 2008 (CST)

::Not sure that's necessarily the best idea, Zombie, since many of the entries on the Known Bugs article(as well as some entries on the Exploits pages) are limitations of the game engine. On just a brief glance through, the following caught my eye as engine limitations: Manufacturing limit, Storage limit, Purchase limit, 80-item limit, Proximity Grenade limit, Large units not waking up from stun, Interception last shot bug, Alien UFL radar blitz-through bug(Passing through the detection range of a radar before the detection check comes up), Free manufacturing, free wages, UFO Redux, point-scoring with Ctrl-C, permanent MC of chryssalids, Zombie-MC resurrection of agents, alien inventory exploits, anything involved with bad collision detection, extinguishing fire with a Smoke Grenade, and even your personal favorite, denying the aliens access to their own spawn points. So in conclusion, maybe it should just be left as it is; conversely, all of these entries could be kept where they are and also on a Game Limitations page, or we could leave the headers there and link them over to the appropriate topics on Game Limitations. What do you think? [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:21, 9 November 2008 (CST)

: I agree with AQ (great list of examples by the way - and the Smoke/Fire limit would be another). Many, if not most, of the bugs are "Limitations" but they are logically inconsistent and not what a player would expect to happen: they are imposed by (at best) memory limitations or (at worst) design/programming oversights. I think the easiest thing to do would be to change the title of the page to Known Bugs and Limitations, or put an explanatory note at the beginning of the section to explain that "Bugs" is taken to included "Limitations". [[User:Spike|Spike]] 13:16, 9 November 2008 (CST)

By the strictest sense of meaning, a "bug" is a mistake or error on the programmers part. Limitations imposed by design or memory are not the same creature as the people involved were consciously aware of the decision. I suppose that to the normal player, any type of behavior which is unexpected/unwanted is automatically dumped in the bug category because to them there is no difference. To those of us who study the game files however, the two are unequivalent. Programming oversights, yes, those are bugs.

Some of those limitations AQ mentions are (to me at least) bugs: free manufacturing, free wages, permanent MC of Cryssies (or actually any alien for that matter), Zombie resurrections and collision detection. Large aliens not waking up from stun is again, a bug. The programmers obviously had some issues when dealing with large units in general and never quite got it right. They made some progress in TFTD by trying to fix mind controlling each section of a large unit, but royally screwed it up by selecting the next 3 entries in UNITPOS.DAT no matter what they pointed to.

Perhaps it's just my background in logic which makes me want to push for a separate category for limitations. Then again, as long as everything is listed somewhere I'm happy. --[[User:Zombie|Zombie]] 22:06, 9 November 2008 (CST)

: Actually, taking a look through the page as a whole there are various other Limits described, and the distinction between Bugs and Limits is made quite rigorously throughout - not just in the Soldier Limits and Bugs section, where the Soldier Recruiting Limit is referred to as a Limit whereas other bugs (such as paying salaries for soldiers you can't recruit) are referred to as Bugs. So we maybe just need to rename the pages "Bugs and Limits" and add an explanatory note on the distinction. From a user point of view, rather than a programmer point of view, a bug is an unexpected (inconsistent or illogical) behaviour, so for that reason I think it makes sense to keep them on the same page but try to ensure they are all correctly classified as Bug or Limit.

: By the way, it could be hard to absolutely distinguish Bugs from Limits as I suspect there are going to be some grey areas where you would have to second-guess the intentions and decisions of the coders to know for sure if something was a designed-in Limit, or just an oversight (Bug). [[User:Spike|Spike]] 06:50, 10 November 2008 (CST)

::If we distinguish in this manner, I suggest the definition of "Limit" should be, "Something imposed by the game files or engine as a limitation, most likely in context to the capabilites of the then-current personal computer." More succinctly, anything that was done to allow the game to run acceptably on what was then a PC. This would include both the Soldier and 80-Item limits, the spawn limit(40 units per side), Smoke/Fire limit, and some of the others listed. (The Purchase limit was probably more of a convienence for the programmers than anything, but it is clearly an intended feature.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:11, 10 November 2008 (CST)

: I would add to this that sometimes a Limit may be imposed as a game design / gameplay decision, rather than in order to conserve a constrained resource in the platform (=PC). Also, I would suggest that ''intended'' Limits are Limits, but ''unintended'' consequences of Limits are Bugs. Obviously, making this distinction involves some guesswork. But I would guess that while the limit on total smoke/fire hexes was an intended Limit (to conserve PC resources), the ability to put out fires with smoke grenades and disperse smoke with IC rounds is probably an unintended consequence of the Limit, and so should probably be considered a Bug. Similarly, Base Defence spawn points are probably an intended limit, but the ability to flood spawn points is an unintended consequence of this, and thus a Bug (and an Exploit). (Spawn points should have been shared out 50/50, not humans-first). [[User:Spike|Spike]] 12:07, 11 November 2008 (CST)

::The limit on Soldier and Interception craft were probably more of a limit imposed because they capped the file and figured that X-COM wouldn't ever need more than 40 interception craft or 250 soldiers. (And I've never needed that many, case in point.)

::As for spawns, its actually difficult to take advantage of it in any reasonably established base. X-COM can spawn up to 40 soldiers in a base defense mission(tanks count as 4 soldiers), as a limit of LOC.DAT. Aliens have the same limit. So in order to take advantage of the bug, the base needs 40 or less spawns total. The Access Lift has 8 spawn points, General Stores(weapon-handling) has 11, Living Quarters has 8 more. This is 27 Spawns just getting soldiers in a base and armed. (Although the General Stores can be cut out if you perform the bug properly). Large Radar and HWD have 6 spawns(Small Radar has 2), and Hangar has 15. So overall, the "Spawn prevention" can be hard to take advantage of with all but the smallest bases. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:48, 11 November 2008 (CST)

Just to clarify, X-COM interception craft are not capped at 40 ships. LOC.DAT has a cap of 50 "things" on the geoscape screen at a time. This is shared between X-COM bases, X-COM ships, alien bases, seen or unseen UFO's, terror sites, crash sites, landing sites and waypoints. In a perfect game world with little alien activity and normally constructed bases, the max number of X-COM craft possible is 44: 5 bases with 8 hangars each plus one base with 4 hangars (or any combination thereof). If you illegally modify your base layout with an editor to get rid of the access lift, the max can be increased to 45 ships (9 hangars in 5 bases). Once clogged, all alien activity will cease.

The base defense limit of 40 units exists because of UNITPOS.DAT which has a cap of 80 entries total (tanks occupy 4 entries in this file). Auto-win missions in a base defense mission by clogging all the spawn points with X-COM units isn't as tough as it sounds, especially if your base is small or doesn't contain hangars. The main thing is getting your full quota of 40 units to spawn (meaning you should try not to have any tanks as they count as 4 units but only occupy one spawn point). This limits the base size to something like 5-6 modules depending on what you build. Still, even having more than 6 modules isn't bad as it forces aliens to spawn intermingled between your troops. With 40 armed guys staring in every direction, you can get positions of all the aliens in the first round and possibly even kill them all (depends on weapons and alien race of course). --[[User:Zombie|Zombie]] 20:12, 11 November 2008 (CST)

: I would say that Limits are the CAUSE of bugs... also, I feel that fire/smoke limit can be called a bug, because a player normally has no way to tell this, other than observation. Whereas the game DIRECTLY and CLEARLY informs you whenever you hit the 80 item or 250 soldier limits, which is more fair. [[User:Jasonred|Jasonred]] 15:22, 23 March 2009 (EDT)

Also IMHO it is not true that, say, 250-soldiers limit is a real game bug. In fact, it is not, it is just a rule of the game, or its limitation. And it is unimportant what its reason is (such or another way to store game data).

A bug is, by definition, an unexpected and involuntary result of programmers' work. However, we can only guess what the programmers wanted to attain, so this definition is both unpractical and impossible to be applied. It would be better to assume that a bug is a feature which has negative influence in the game. To clarify: the (un)famous 250-soldiers limitation does not harm in practice, as the number is really enough to play the game. But the even-more-unfamous 80-item limitation does harm and it has negative consequences - it is enough to recall the disappearing of bodies during some missions.

OK, there is no objective criteria to judge whether a feature of the game is a bug or just a limitation. But sometimes subjective criteria have to be enough. Otherwise, we would have to consider the 8-bases limit a bug. Does it make any sense? And if no, what is the difference between the 8-bases limit and the 250-soldiers limit? I feel neither is a bug. Because neither leads to further negative consequences.

And further, IMHO the buggy nature of some game features is quite obvious. If you cannot send more than 100 "parcels" of items at the same time, it is still not the bug. But if you must pay for an item you are trying to send but you cannot do it - it is a bug, perhaps everybody will agree. And similarly: the 255-scientists limitation is not a bug. But the strange behaviour of the game when you bought the 256th scientist is a bug. It would be just a limitation if the game did not allow to buy another scientist. But it allows while it cannot serve the 256th scientist properly, and that is why it is a bug.

So, I vote for removing the 250-soldiers limit from the bug list. If I am wrong in it, please add to the list also:
# 8-bases limit,
# maps with limited terrain (why should they be limited?),
# base area and base facilities limit (why wouldn't we be able to have 10 hangars in a base?),
# etc.

In yet other words, in my opinion it is not enough to show that the game does not allow to have more certain items or to do more certain actions. In order to count this among bugs, we should show that it really harms during playing the game, or just bears negative consequences.

[[User:Sherlock|Sherlock]] 03:52, 27 December 2012 (EST)

= Specific Bug Discussions =

== Misc Technical Bug ? ==

''(The context of this discussion seems to have been lost)''

This is a technical bug that doesn't happen to everyone and one this article wasn't really meant to chronical - but we won't turn away helping a fellow player if it can't be helped. It's just that there are so many random crash points in this game that it would take far too long to find them all or come up with solutions for them.

Certainly, the transfer crash can happen to some players, but it's not one that can be reproduced easily. It's just like the random crash that some players get when they research a floater medic. It crashes the game for some of us, but others don't seem to notice it at all.

It really depends on your hardware and OS setup, whether or not your copy of the game is damaged or your savegame is damaged, etc.

Does it happen in all games or just this one savegame?

- [[User:NKF|NKF]]

-----

== "Invisible Muton" bug ==

Upon shooting repeatedly a Muton, it sometimes plays its "death" animation without sound (as if falling unconscious) and it is no longer displayed in the screen, while remaining visible to my soldiers (I can center the screen and the cursor appears yellow over them). Under this state, they cannot be targeted by Stun Rods. They may play their death animation anytime they get shot, until they truly die, when they emit their characteristic sound and leave a corpse (along with any items carried).

I'm quite fond of laser weapons, maybe this happens more often with those.

Also, though I remember experiencing this quite often fighting Mutons, it may happen to any other high health race.--[[User:Trotsky|Trotsky]] 02:59, 2 July 2006 (PDT)

-----

Never seen that one myself. Another "unpatched game" thing maybe?

There's a (very rare) bug that allows your soldiers to live if they become stunned by an explosion that happens to kill them. Sometimes the game will register their death, and THEN register that they've been stunned. In every case I've seen this happen, however, the unit will have such a low amount of health that a single fatal wound will render it dead (again) on the next turn. I have a vague memory that other players may have been able to get a medkit to the scene on time...

I dunno if that's related to your issue at all (I doubt it, but... meh). I'd advise using a Mind Probe on the alien the next time it happens so you can check the aliens stun/health levels.

- [[User:Bomb_Bloke|Bomb Bloke]]

----

I'm pretty sure I've seen this with Mutons. Possibly Chrysallids as well, another high health, high armor creature. They were still readily killed by shooting the place they are. Good thought on the MP, BB

---[[User:MikeTheRed|MikeTheRed]] 08:51, 2 July 2006 (PDT)

----

I've been known to have a dying muton(in fire) to spin around and then switch to the female civilian death animation. With the scream and everything. Even got a civilian death registered at the end of the mission. And this didn't just happen once, but on another separate occasion.

Hmm. shape-shifting reptilians in the game! LOL! Happens alot [[User:EsTeR|EsTeR]]

Unusually enough, I once had a sectopod die and then drop a tank corpse. I was using the Lightning at the time for my troop carrier, so you can imagine my surprise.

Then there was one occasion where a floater dropped a snakeman corpse. Let's not even get into the sort of things the aliens like to stuff themselves with.

Your invisible alien bug is quite common, although there appears to be many causes for it. I think one involves a full object table when it comes to invisible aliens in bases. But it can also happen in ordinary missions as well. I'm guessing the game may have tried to do something in the wrong order, and sprite information for the unit may have been lost or corrupted along the way.

Having had an experience where all the chryssalids become invisible in one base defence mission was quite a shocker. I fixed this by saving the game, quitting and then restarting the game. If you ever get an invisible alien again, try this and see if it helps. If it doesn't, well, just keep a careful watch on your map and any alerts that pop up as you play.

There's a similar but less severe bug where a dead alien will still leave its centre-on-unit alert button, but this goes away shortly after you move or turn.

- [[User:NKF|NKF]]

----

That last bug happens when exploding Cyberdiscs kill nearby Sectoids, doesn't it?--[[User:Trotsky|Trotsky]] 23:56, 2 July 2006 (PDT)

----

This is a pretty easy one. I guess this bug occured on UFO recovery on a battleship, an alien base assault or a base defense mission? As soon as there are too many items on the map, the game saves some item slots for the equipment to be displayed (since it is more valuable and more important to research). This would also make stun weapons lethal if the stunned aliens would vanish. therefore the game has a failsafe if an alien is stunned (or badly wounded and becoming uncontious). The downed alien's stun level is set exactly on its left health points therefore resurrecting it instantly. This cycle is broken when the alien is finally killed. This means if you want to stun an alien in such a situation you have to destroy some items first.

- by tequilachef (April 4th 2007)

== Vanishing snakemen ==

I've known snakemen to become invisible when standing on a hay bale. On the first occassion I had a poor tank getting shot while spending numerous turns looking for it. On the second occasion I had an alien under Psi-control, left it on the hay bale, and couldn't find it next turn. - Egor

---

This is not limited to snakemen. Hay bale block visibility quite much when a unit is standing on it. Two possible solutions:
- Destroy the hay before entering
- Shoot at the hay. If it is destroyed any unit on it will become visible (as long as no other bales are blocking the line of sight). You might also hit the enemy directly.

I Dnt know if the aliens are affected by this diminished sight, too. My guess would be no.

- By tequilachef (April 4th, 2007)

== Blaster Bomb Bug ==

I'm currently playing through X-com UFO Defense, I have the collectors edition version. I'm in the process of trying to catch a live alien commander and the blaster bomb bug is making this very difficult. If i remember correctly a commander is always in the command center of the the alien bases. The problem is anytime i get close there is always a dude with a blaster launcher up there that tries to kill my troops. When they try to fire it down at me the bug kicks in and they blow up the whole command room and all the aliens in it because they can't figure out how to get the blaster bomb down the grav lift thing in there. This is making it very dificult to actually catch a live commander. Anyone have any ideas for tactics or anything to breach that room without the aliens trying to fire a blaster launcher up there? - eL Hector

: I can suggest two possible solutions. The first is to wait outside the command room for the alien to move closer to you. If it comes out of the room or if you know it has moved down the lift, you then burst in and stand right next to it to stop it from firing the blaster. This is risky because there could very well be a heavy plasma toting alien in there. The other is to use a small launcher and launch it up at the ceiling near where you think the alien with the blaster is standing. -[[User:NKF|NKF]]

== Disappearing Ammunition ==

I have observed that problem with X-COM 1.2, modded with XCOMUTIL. My stun bombs and heavy rocket missiles, along with clips for the auto cannon went missing.
[[User:Vagabond|Vagabond]]

------

Just run a test using my 1.4 DOS version with XComUtil but my stun bombs didn't disappear: 30 + 1 back in the base they came from, same number after I went tactical and I dusted-off immediately. Are you running XComUtil with Runxcom.bat or did you simply run Xcusetup?

[[User:Hobbes|Hobbes]] 22:12, 22 February 2007 (PST)

:Is it a case of hitting the 80-item limit?--[[User:Ethereal Cereal|Ethereal Cereal]] 12:28, 23 February 2007 (PST)

------
With runxcomw.bat, as everytime. Apologies, I retested and it seems like I was mistakened, but I could have sworn that I lost them dang stunbombs. Had to manufacture some. I will test some more, using four heavy weapons and seeing whether their ammunition disappears at all. Thanks. [[User:Vagabond|Vagabond]]

==MC at end = MIA?==

I am sure I have seen this again recently, where I won a mission with no casualties (I thought), but the last thing I killed was a Commander that had been chain MC'ing a psi-attack-magnet trooper, and that trooper was listed as MIA at the end (presumably because he was on the enemy side at the end of combat). Is this a bug, or is there another way to get MIA's on a completed mission that I might have missed?

Since then I have been waiting for the leaders to panic at the end before killing them (or waiting for a rare resist), so I can safely exit, but am I being overcautious?

--[[User:Sfnhltb|Sfnhltb]] 13:45, 27 February 2007 (PST)

If the trooper was mind controlled on the turn you killed the last alien it will be listed as MIA. No bug there :)

[[User:Hobbes|Hobbes]] 18:16, 1 March 2007 (PST)

Huh, why would that happen - your soldier should recover the very next round, why would he go MIA?

--[[User:Sfnhltb|Sfnhltb]] 18:20, 1 March 2007 (PST)

Doesn't make sense to me as well but that's how the game works.

[[User:Hobbes|Hobbes]] 15:05, 2 March 2007 (PST)

----

It seems that regaining control of units under enemy mind control works different for alien and human players. My guess: aliens under human MC are reverted to alien control AFTER THE ALIEN AND BEFORE THE HUMAN TURN while human units under alien control are reverted RIGHT AT THE BEGINNING OF THE HUMAN TURN. This explains three different phenomenons:

- The discussed MIA "bug" (he unit would be returned in the next human turn, but since it never starts it is lost. The mission is still won since no unit with a "genuine alien" marking is left)

- The fact that a mission is lost when the last human falls under MC while it is not won when this happens to the last standing alien (the aliens get their unit back before their turn starts and therefore have a unit left to pass the "anyone alive?" check, the humans would have no unit left to start a turn with. They WOULD have as soon as the turn starts, but no unit left before turn means bust)

- The fact that aliens still can see all an MCed human saw at the end of the human turn that follows the MC while this is not vice versa (The MCed human can give information to the alien side before reverted while an MCed alien is reverted too early). The result is that aliens can control a human indefinitely without having any alien seeing him until the MC is disrupted for one turn.

All confused? Then I did a good job! No seriously, this must be the explanation, I couldn't think of any other way.

- By tequilachef (April 4th, 2007)

: You're absolutely correct on the first two points. It's a sequence issue - you never get round to recovering the unit before the new turn starts, so you end without any units whatsoever. Makes senses too since the aliens would continue to continue to mind control that same unit over and over indefinitely.

: The third point however: The aliens don't need to know the location of the last MC'd unit. They know the location of all your troops whether they've seen them or not from the very start. They appear to give you a few turns of grace where they won't attack you outright (unless, from my observation, all your soldiers are incredibly weak). This is evident because all of the aliens will eventually make their way towards the nearest soldier even though their movement pattern may seem semi-random. Also, they know where you are because they can initiate psionic attacks without having seen any of your troops. They generally go after the weakest troops first.

: Just to add a semi-related point, but from the alien's perspective. If an MC'd alien unit is in the exits when you abort the mission, this alien is not recovered and in fact simply vanishes. Any equipment it was carrying is recovered, unknown artefacts or otherwise. You could possibly think of this as their version of MIA. However, the aliens differ ever so slightly in that if it's the last alien standing and under temporary mind control by the player, the mission doesn't end straight away. But I guess this is only because the player has everything under control, whereas in the other scenario, the Ai is in control.

: -[[User:NKF|NKF]]

My observations show that, at least in some versions of the game (tested with clean DOS 1.4 version, under DOSBox), the game crashes at the end of the human turn if all alien units which are still alive, are Mind-Controlled. If it was confirmed, it would be another not-listed-yet (serious) bug.

[[User:Sherlock|Sherlock]] 17:52, 26 December 2012 (EST)

== Crash Site in the atlantic ocean ==

That's right, my game generated a crash site on water. Here are the details:

- Crash Site a bit southeast of the USA (which was infiltrated a few days before by sectoids, resulting base had already been taken out), but certainly not on land.

- UFO: battleship, floater, alien harvest

- Geoscape: 8 X-Com Bases, 1 (known) Alien base, 2 other crash sites, 1 other (known) flying UFO (though almost worldwide decoder coverage), 3 X-Com Crafts out, 1 waypoint

- Date: January 2000

- Most Interesting: The Craft that downed the ship was a recently finished Firestorm (first human-alien hybrid craft I had built, I know this is lame for that date. Limited myself on 25 Scientists to improve the challenge) equipped with twin plasma. I had it built and equipped in Antarctica and then transferred to Europe. This base had no Elerium, a fact that enabled me to use the infinite fuel exploit which was in effect when downing the UFO. My craft was only slightly damaged when doing so. The battleship was the first target assigned to the craft, it came directly from my base.

- When shot down, the UFO was not targetted by any other craft.

- I had not lost or sold a single craft to that point.

- When sending a squad to the crash site the game didn't crash but generated a farm land ground combat terrain.

- I was not able to reproduce the bug from the savegame dated 2 hours before downing the UFO

Well guys, any intelligent guesses? I still have the savegames (before and after downing)! If you want to have a look, write here.

- By tequilachef (April 5th 2007)
----
: Well I'm sure you know about crash sites that are near land can sometimes actually be on water, so I'm going to assume that this site is well far away from any land mass. Could it be a weird entry in GEODATA\WORLD.DAT that has a land mass out in the ocean? Also are you sure the game didn't crash? Sometimes when it does it will load the previous mission (and usually 90% are at farm terrain). Are you sure it generated a new map and not load the last one?
:No real guesses but maybe some starting points to look at. I've probably stated some obvious situations you know about and have accounted for, but it never hurts to double check :D
- [[User:Pi Masta|Pi Masta]] 14:23, 5 April 2007 (PDT)

== Inconsistencies in MCing Cyberdiscs and Sectopods ==

I experienced, that when MCing one quadrant of a large terror unit any action it does only affects this quadrant (especially use of time units). That means, when TUs are up for one part, MC another one and continue firing. This however does not work out when moving the unit while it is not under complete control. The TUs used up by the resulting reaction fire from the rest of the unit is also deducted from the TUs "your" part has left (making it impossible for the controlled parts to return fire). This however only happens under reaction fire, not if "your" part fires on it's own. I don't know if this comes up when uncontrolled parts shoot by themselves in the alien turn, since this is hard to find out.

: That's because large units literally are made up of four separate units. They only share the same set of general stats (in unitref.dat). Unfortunately the 'under mind control flag' is unique to the four units, not the shared stats! So you in effect have multiple units under different control sharing the same stats. So if you move and it results in a reaction from the unit, it will spend the TUs you're using.
: Successful mind control automatically fills up the unit's TUs, so each mind controlled sector gets to move or attack again until there are no more sectors to mind control. Useful way of turning reapers into long range scouts!
: In TFTD, they attempted to fix this bug, but in fact made it much-much worse! The only way to mind control the unit properly is to control the upper left quadrant. Only! Any other quadrant will result in a partial (clockwise) control, and you may gain control of units other than that unit, or may even get into situations where you gain permanent 'partial control' of a large unit you haven't even sited. Wackiness all around!

:- [[User:NKF|NKF]]

== Facility Dismantle Bug ==

Boba: I've never experienced this bug myself in all my games in the Collectors Edition. It may very well vary from computer to computer.

-[[User:NKF|NKF]]
:I, however, have experienced it. I lost an entire month's worth of playtime because I couldn't solve it. [[User:Arrow Quivershaft|Arrow Quivershaft]]

::Anyone, any ideas on why it might vary from PC to PC? -[[User:MikeTheRed|MikeTheRed]]

:::I'd check other factors before blaming a given system. Assuming no mods are being used the most obvious is the order in which you initiated the construction of the modules. Then we've got which one was due to be completed first, and I'm sure there's a few other things to test out. Usually, a player won't cancel in-progress modules on a regular basis, so you wouldn't expect this bug to turn up often. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

:Easy way to reproduce: build 2 General Stores. Now delete the "second one" (see offset 16-39 in [[BASE.DAT]] for the order). Wait for the first one to complete. It'll crash immediately after the "end of construction" dialog. A fix is available [[User:Seb76#Bug_Fixes | here]]. [[User:Seb76|Seb76]] 15:52, 22 July 2008 (PDT)

== Manufacturing Limit Bug ==

Unfortunately, Mike, no you did not get it correct. It is the raw number of hours needed to complete the project, not the projected hours. I discussed this on the X-Com Forums a few months back at the following link: http://www.xcomufo.com/forums/index.php?showtopic=242027760&st=0&#entry164411

I did tests at the time in regard to the accuracy of the data given there, but I've lost the results. I'll quickly redo the tests in the next hour or so. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:00, 8 June 2007 (PDT)

:Tests complete. The breakpoints for every item were exactly where I predicted, regardless of number of engineers assigned. (I ran up a huge queue of items at my dedicated factory base on an old game, and then assigned whatever engineers would fit onto one project at a time, canceling projects as data was confirmed. This is only semi-random, but it serves our purposes.) I did run into a single issue, though. It appears that despite having 5 empty hangars at a (different!) base, the workshop there could not queue up more than 3 of any one craft at a time, thus making this bug impossible to replicate with the Firestorm or Lightning, as you must be producing more than three for the bug to occur. However, it still works with the Avenger. Later, I shall see about constructing a dedicated Hangar base with 7 hangars in order to attempt to replicate the bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:33, 8 June 2007 (PDT)

::Sounds great, Arrow. Why not post a simple example that shows how the problem works. As in, "with 1 Eng and 2 Avengers you might think X, but no, it's Y". And please delete my example. And it's a fine pleasure to meet you! Cool - [[User:MikeTheRed|MikeTheRed]]

:::When you say the usual resources are used by the "lost" resources, that includes cash, right? It sounds like if you're willing to foot the extra bill [[Buying/Selling/Transferring#Manufacturable_Prices|money/component-wise]], this could be used to build Avengers slightly faster then normal.

::: The usual time is 34000 hours. Double that and subtract 65535 and you're left with a paltry 2465 hours. Even a single workshop squad of 10 engineers will pull that off in a little over ten days. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

::::Sadly, this exploit doesn't work, because the high bit is stored SOMEWHERE. I lack a hex reader and have no code reading skills to speak of, so I'm a bit limited here. If you set up a Workshop as you described, the game would take all the time for 2 Avengers, all the resources for the same, but in the end only produce 1 Avenger. Meanwhile, I'll run more tests on the resources thing. I could swear it consumes the resources, but I'll double check.

:::::There is no need to store the high bits if the actual completion condition (assuming adequate money) is "number made is number ordered", which wouldn't reference the hours remaining at all. - [[User:Zaimoni|Zaimoni]] 01:49, 9 Oct 2007 (CDT)

::::Tests done; I was unable to replicate the 'disappearing item' trick,(Which I didn't test for last night) even with Avengers! It appears I was wrong; this still counts as a bug, though, because the wraparound is a problem.

::::Ironic that so much of this discussion centers around Avengers, because that's where I discovered this in the first place! [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:48, 9 June 2007 (PDT)

----

I'm revisiting XCOM and was working on [[Manufacturing Profitability]]... Arrow, can you (or anyone else) say a little bit more on the Known Bugs page about this [[Known_Bugs#Manufacturing_Limit_Bug]]? It's not clear to me exactly what the bug does, except that it understates hours. Is that all?... does it still take the (non-buggy) amount of time, still use all the same resources, still make the same number, etc.? It sounds like it could be a drastic bug - or is it only a very superficial one, a display bug for the hours? It sounds like you're leaning toward this latter.

Also on a semi-related note... I could swear I saw much more detailed info on the [[Known_Bugs#Facility_Maintenance_Costs]] issue... IIRC, the incorrect amount that's charged for maintenance, depends on exactly where a facility is in the base. IOW, different "rows" of the base cost different amounts. Could somebody provide a link there, and/or flesh the bug out better?

Thanks! - [[User:MikeTheRed|MikeTheRed]] 11:22, 8 October 2007 (PDT)

:I've actually seen the bug work both ways, but I've only been able to actually replicate the more superficial version of the bug. So the bug report up is about a superficial bug that drastically understates production time. If you wish to make this clearer, you have my blessings. As well, that 'different charging based on location' is dealt with here: http://ufopaedia.org/index.php?title=Talk:Base_Facilities ; however, the table has been broken with the Wikiupgrade, and I lack sufficient knowledge of HTML table code to fix it. But it should be of use to you. [[User:Arrow Quivershaft|Arrow Quivershaft]] 11:26, 8 October 2007 (PDT)

::Cool, I fixed [[Talk:Base Facilities]] but also re-organized and expanded [[Base Facilities]] so that it includes that bug in detail, as per Talk... this is an important issue that should be up front. I see that there's a separate [[Maintenance costs]] page, but I can't see having something so important (the maintenance bug explanation) all on its own page (which makes for a rather short page) rather than together with all the rest of the base facility info. If others agree (or don't care), I'll move anything remaining on Maintenance Costs to the Base Facilities page, then delete Maintenance Costs and re-route links. And if somebody does care, then please move my new section to Maintenance Costs, and move all the links, etc. Oh also I put in more words on your Manufacturing Limit Bug - how does it look? - [[User:MikeTheRed|MikeTheRed]] 16:37, 8 October 2007 (PDT)

:Looks pretty good, although it'll wrap fully; if you ask for 120000 hours, it won't be displaying 'almost no' time. The way I discovered it was when building two Avengers; I ordered two, paid for two, waited for two...and got one. But as said, haven't managed to repeat it, so until I do, we'll leave it like that. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:00, 8 October 2007 (PDT)

::I just revised and put in your specific example, because it's certainly possible some of us die-hard players will order up more than 1 Avenger at a time - and it's guaranteed it'd be a pain if 1 of them disappeared, laugh. I wasn't sure how concrete you were on that example but now I hear you say, you are sure it happened at least once. - [[User:MikeTheRed|MikeTheRed]] 18:33, 8 October 2007 (PDT)

:I have a question concerning the manufacturing "bug" which eats a craft in production due to wrap-over of the byte. Arrow (or whoever did the test), did you have a large quantity of craft already built at your bases? If so, I think this bug has more to deal with clogging up [[CRAFT.DAT]]. See, that file has a limit of 50 entries. Each craft takes up one record and each base you have built also consumes one spot. 8 bases allows 42 craft to be housed, while 6 bases allow 44. If you try to buy or manufacture craft once the file is full, nothing shows up in the game even if you have hangar space available. --[[User:Zombie|Zombie]] 19:00, 8 October 2007 (PDT)

::Huh, I never knew that. I don't see it listed on the Bugs page... I'll stick it in there. I've never approached that number, but some folks might. - [[User:MikeTheRed|MikeTheRed]] 19:07, 8 October 2007 (PDT)

:I was able to continue building other Avengers after that project, and they appeared correctly, so I do not believe that is the issue. In any event, I have a very bad case of 'archivism' and probably still have the save game and the CRAFT.DAT file around on my system; in fact, I think I was playing it a few days ago. I can see if I can find it and upload it; it created a 'hole' in the Avenger fleet numbers, where Avenger's x and x+2 were built, but x+1 was not. I'll look for it tonight and tomorrow and upload it to the wiki if I find it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:10, 8 October 2007 (PDT) EDIT: I found the file; I have 28 Avengers and 1 Skyranger in my employ. All Avenger numbers EXCEPT #2(Avenger-2) are accounted for, and I have not sacked or lost any Avengers. So this is where the hole and 'eaten' Avenger is. If anyone wants the CRAFT.DAT file from this game, I'd be happy to forward it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:20, 8 October 2007 (PDT)

::Sure, send it my way and I'll take a look at it. (Might as well send me the whole saved game as I may want to look at the other files too). I have tried to recreate this bug by manufacturing 1, 2 and 3 Avengers at a clip but all of them always show up. Don't know what else I could do to get this problem to crop up. --[[User:Zombie|Zombie]] 21:32, 8 October 2007 (PDT)

:File emailed. On the side, I've tried the same thing, and never been able to repeat the bug. It's been months since the first discovery, so I can't recall whether it was the first or the second Avenger that didn't appear. So maybe it was just a fluke. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:57, 8 October 2007 (PDT)

== Unconscious Enemy in Equipment Screen ==

The following happened to me repeatedly over the last few days.

In the last tactical Mission a live alien has been captured. When now beginning an UFO crash recovery mission this type of alien (same race and rank) appears in the equipment screen before the mission starts, meaning I can give it to any of my soldiers.
If I do so I can store the alien in the skyranger for the duration of the mission and, if it gains consciousness, kill or stun it at the end of it. A pile of equipment without a corpse will be in the UFO, indicating that the stunned alien is not some kind of duplicate but instead has been taken from the aliens of this mission. This is supported by the fact that in those missions the maximum number of crew members has not been surpassed.
If I do not do so the Alien will be placed in the crashed UFO. Whether it is unconscious or not I do not know, but the fact that it is completely disarmed when encountered in the battle suggests that it is.

So far it seems the following is necessary for the bug to occur:
# An alien has to be captured alive in the last tactical combat
# It has to be of the same race and rank as one of the aliens in the new tactical combat

So far this only worked...:
# If the new tactical combat was an UFO crash recovery of a medium scout.
# For floaters and mutons
# For soldiers and navigators
# If the alien in the last mission was stunned by normal weapon fire (although I do not think this is important) and not picked up (again, not likely to be important) or destroyed (which would mean it has to be actually captured)

It seems NOT to depend on the following:
# The type of the last mission (were, so far: Ground assault battleship, crash recovery large scout, base defense)
# Which squad or vessel was involved capturing the alien
# Where it is locked up
# If it has been transferred since capture or not

Would be interesting to know:
# What happens if the alien in the inventory screen is the only survivor
# If the alien in the invenory screen is one of the aliens randomly killed in the crash or not (it is likely to be one of the killed aliens, so far the equipment piles were always within the UFO)
# If this is not limited on crashed medium scouts: Does this work with terror units? What about large ones?

Maybe this is related to the proximity grenade bug (transfer of item properties to next tactical combat).

Additionally, in one of those mission a part of the terrain was not generated correctly. It was in farm terrain (The house on the right square, or north east square, in [[Image:Terrain-cult.gif|this pic]]). The outer wall right to the right window of the southern wall (1st Floor) was missing. Directly outside of the hole was a floor tile. I could walk a soldier through the wall, but he fell right through the tile. Dunno if this has to do with the stunned alien bug.

Version is collectors edition (the one from abandonia.com).

----------------

When a mission starts, the GeoScape engine generates the unit and object tables (in MissDat's [[OBPOSREF.DAT]], [[UNIPOS.DAT]], and [[UNIREF.DAT]]) before "shutting down". The Tactical engine then generates the maps, places the aliens on it, and blows up the UFO (if need be). Whether or not map generation and the subsequent events happen before you equip your soldiers I don't yet know.

The test would be to check the aforementioned files to see if they contain an unconcious alien, and/or the body.

Note that you can't see the bodies of large units on the ground (they count as four seperate objects covering four seperate tiles, so allowing the user to pick one up would essentially let you rip them apart).

- [[User:Bomb Bloke|Bomb Bloke]] 06:35, 5 August 2007 (PDT)

----------------

I honestly have no idea of how all those files work. But I still have a savegame in battlescape that is in one of those missions. So if anyone wants to have a look at those files...

I forgot to mention: I reloaded a geoscape savegame shortly before the battle to recreate the bug, but it seems that reloading in geoscape before the buggy battle eliminates the bug. I guess his should narrow down the possible reasons...

--------

Next time it happens, backup the aforementioned files before you start another mission. I'm afraid a savegame wouldn't be of much help.

- [[User:Bomb Bloke|Bomb Bloke]] 00:54, 7 August 2007 (PDT)

== Soldiers moved to outside of combat screen ==

Hi, I've got a DOS version of UFO:EU, and I've encountered a bug in the tactical combat. Sometimes (rarely) a X-COM soldier changes its location on the map on player's turn start and is placed on outside of the map, one tile north from the (north) border of the field. AFAIR the unit is then selectable (you get the flashing highlight when cursor is above), but is stuck outside of the field. Has anybody encountered this bug? It seems to happen randomly, but more frequently during the terror missions and on early turns (so maybe it's caused by high number of player/alien/civilian units?). --[[User:Maquina|Maquina]] 08:16, 3 September 2007 (PDT)

:I've never encountered this bug in CE of UFO. Presuming AFAIR means "As Far As I Recall," what exactly was the soldier doing? Any equipment data, location, or stat info might help us pin it down. Were afflicted soldiers always carrying a specific equipment set or weapon? Where were they on the map before they got moved? Did they get bumped a few spaces, or teleported halfway across the Battlescape? Does it happen more often on a specific difficulty?(Your theory would suggest this would happen most commonly on Superhuman) Against a certain type of alien? Best of all, if you can recreate the situation in a game, save the game and then you could upload the save file to the forums or this wiki, and the rest of us could take a look for ourselves and the code divers could root around for the cause. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:03, 3 September 2007 (PDT)

:: I've had this happen to me several times in UFO and TFTD. I don't know if it's specific to the Dos version or if it can happen in the CE as well. Sometimes the soldier ends up beyond the boundary of the map right at the start of the mission, at other times it happens after you load a game. This game is glitchy, which is the source for so many of its bugs, so your soldier's coordinates are probably getting corrupted to the point where they are -1 on either the X or Y axis of the maps's normal boundaries. For me it's commonly along the top edge of the map. I don't ever recall it happening mid-mission, only at the start or after a load. I cannot faithfully say whether it happened with or without XComutil, but that could be one of the possibly many causes for this. - [[User:NKF|NKF]]

:: I don't play UFO often, so I rely on just several campaigns played. This happens rarely (I've encountered this bug twice in my last campaign with ~80 missions played), but if you haven't seen this happen then it probably doesn't show up in the CE edition. In my experience the soldier is moved always beyond the north/top map border. I think (but I'm not sure) that this affects the first soldier from the team more commonly than others (or maybe even exclusevily?). The equipment/armor carried is probably not relevant, since the units moved this way don't have any special stuff, and this bug shows up on different stages of the gameplay (ie. sometimes when you have ordinary rifles, sometimes when all your units got heavy plasmas and power suits). --[[User:Maquina|Maquina]] 04:12, 4 September 2007 (PDT)

'''MY ramblings have been moved to my discussion page''' [[User:EsTeR|EsTeR]]

==Great Circle Route==

Should we have the Great Circle Route bug noted on this page at all? [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:33, 6 October 2007 (PDT)

: what is the great circle route? [[User:Jasonred|Jasonred]] 07:56, 31 March 2009 (EDT)

:: Pick two points on a globe, then hold a thread or string taut at those two points. That practically minimizes the length of the thread/string on the globe. You're now looking at a great circle arc (or route), the shortest distance between two points on a globe. -- [[User:Zaimoni|Zaimoni]] 11:15 March 2009 (CDT)

: Just as a line is the shortest distance between 2 points on a flat plane, a great circle is the shortest distance between 2 points on the surface of a sphere. The bug, by the way, is that aircraft in the game ''don't'' follow this shortest, "great circle" route. [[User:Spike|Spike]] 12:38, 31 March 2009 (EDT)

:: What a grand sounding name, for something so simple, lol. ... I thought you were talking about when you tell your soldiers to go from point A to point B, and for some reason they figure that Zone A and Zone B are really far apart, despite actually being side by side. (I shot a hole through a wall, clicked to walk to the other side, and my idiot soldier walked one big circle... to use the door! And got ambushed and killed by an alien. ... dum dum DUMB DUMB.)
:: Even the more modern games have problems with their pathfinding algorythms. Admittedly, games like Baldur's Gate had to do it in realtime.
:: On a semi-related note, I remember this guy called E-man, he was chasing a guided laser beam that was going to kill his girl, around the world, but he couldn't outrun it since he couldn't break the speed of light, only equal it by changing into a Laser himself. So... inspiration! He turned into a very powerful laser, and made a shortcut THROUGH THE EARTH... the straight line beats the great circle route, lol.
:: Thanks for the reply guys [[User:Jasonred|Jasonred]] 15:56, 31 March 2009 (EDT)

Added to article. [[User:Spike|Spike]] 16:41, 3 September 2012 (EDT)

==Bug not listed: Missing soldiers during base defense==

I encountered an interesting bug concerning base defense missions:
My base got attacked while about 30 soldiers and 10 HWPs were present. The usual equipment assignment screen was skipped and the mission started instantly with only the HWPs spawned at the map. Not even a single soldier bothered to show up... *sigh*
Although this turned out to be in my favor (you should have seen the puzzled Ethereals trying to panic my tanks) I´d like to avoid this bug if possible. I was able to reproduce this bug several times and with different bases.
Can anyone explain this bug and/or tell me how to avoid it?

Game version: Collectors edition. - [[User:NewJoker|NewJoker]]

-----

Well, ideally, we need to know what your base's construction was to be sure of this, but I think the most likely circumstance is that the HWPs took up all the spawn points. HWPs have maximum priority for spawning(followed by Soldiers, and then Aliens), so if you have enough of them garrisoning a base, it's entirely possible that soldiers and aliens won't spawn. However, this doesn't explain why the soldiers didn't start stealing the Alien spawn points...in any event, you might want to take the save game file, zip it up, and get ready to email it. I'm sure [[User:Zombie|Zombie]] would be quite interested. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:28, 13 November 2007 (PST)

-----

It's not the spawn points, it's a [[UNITPOS.DAT]] limitation. A maximum of forty records (out of the total of eighty) are allocated for your units, and tanks (which take up four records each) get first pick. Having ten tanks means there's no room left for anything else.

Ditch one HWP and you should see four units take it's place. - [[User:Bomb Bloke|Bomb Bloke]] 16:42, 13 November 2007 (PST)

-----

I´ll try with a decreasing number of tanks and report the results. As I wrote above having only HWPs isn´t too bad dependent on what enemy is attacking. [[User:NewJoker|NewJoker]]

----

This should be mentioned in the [[ExploitsE#Base Defence Mission Spawning Issues]] section. The Bugs/Exploits really need to be sorted and consolidated. - [[User:NinthRank|NinthRank]] 16:57, 13 November 2007 (PST)

-----

The limitation to 40 records seems to be the case; each tank I dumped got replaced by four soldiers.
So this can be used to effectively manage unit combination. Thanks for the quick replies! [[User:NewJoker|NewJoker]]

==Bug not listed: Ufo Gold (Windows Vers. abandonia.com) crashing when plasma defense is finished==

I recordnized this bug a few times now. (with hacked AND unhacked game)
If i place a plasma defense in 7 bases at the same Time and they are finished at the same Time, the game crashes sometimes.
In hacked game, it seems to crash even more when Alien containment is finished, plasma defense, shield defense...etc.
couldnt find it here...greetz

: I somehow doubt the sourcing is the issue. [You may want to fund the next XCOM series game with a Take2 re-release of UFO :)] More generally: the game only reports the construction of a given type of facility once, no matter how many bases it completes at simultaneously. I've only tested this in vivo with three-of-a-kind at once across six bases, however. It does seem reasonable that some sort of counter of undisplayed completions would "overflow" (attaining crash). -- [[User:Zaimoni|Zaimoni]] 10:05, Feb. 28 2008 CST

::I've encountered this bug myself with General Stores, actually, not just Plasma Defense(which I never build). EDIT: Some quick tests seem to show that there's a chance the game will crash any time two base facilities are done at the same time, regardless of whether they're in the same base or not or if they're the same facility.(although it seems to happen MUCH more in the event they're in different bases.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:13, 28 February 2008 (PST)

== Soldier Recruiting Bugs Tested ==

Just to note that I have positively tested and replicated the bugs listed under the new(ish) section [[Known Bugs#Soldier Recruiting Bugs|Soldier Recruiting Bugs]]. [[User:Spike|Spike]] 18:08, 19 March 2008 (PDT)

==Floater Medic Bug==

I have not thus far encountered the Floater Medic Bug; in fact, Floater Medics are often used to fill up my Rogue Gallery with interrogations. [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:50, 24 April 2008 (PDT)

Strange, it would always occur in my version. I don't remember where I got it from, but I
know it was a download from the internet. Using the XCom Hack v2.5, I viewed the alien in
the Alien Containment edit. I now have Type (race):____, and a Rank: Soldier for the
Floater Medic. It might just be corruption, but I do not have the resources to look into
it. [[User:Muton commander|Muton commander]] 19:24, 12 May 2008 (Pacific Time Zone)

I've never encountered it either. [[User:Magic9mushroom|Magic9mushroom]] 07:47, 23 July 2009 (EDT)

I think this only happens in the CE version. A disassembly of the code reveals that the stack to hold the matrix for what topics have not yet been researched is too short. It seems that those who ported the code from DOS doubled the local variable sizes blindly. There is already a problem that there are two-few bytes necessary for the entire alien organism section of the UFOpaedia, but double the expected size of the registers and it fills up quite easily unless a lot of autopsies and interrorgations have already been done. The only other situations that are handled by the same routine are the navigator revealing mission data or engineers revealing ship data, but there isn't enough topics in either section to overflow the stack variables. - [[User:Morgan525|Tycho]] 08:27, 22 June 2013 (EDT)

==Strength Overflow==

During one of my games with TFTD I noticed a really annoying thing happen during battles.
As my troops rose up the 'stat.' ladder they got better and better (as you'd expect), until they hit about 50 strentgh and completely lost the ability to throw anything.
Even trying to throw something tiny like a grenade or flare into the adjacent tile resulted in the 'Out of Range' message being displayed.

Anyone come across this before?
This was in TFTD CE.
[[User:Tifi|Tifi]] 07:55, 27 April 2008 (PDT)

:This is fairly well documented. The pathfinding algorithm for throwing objects will balk if anything is in the way of the throw and refuse to allow you to throw. What's happening is that your soldiers have become so strong that their throws are intercepting the 'ceiling' of the Battlescape(the top of L3), and as such the game thinks that the throw is blocked(because in order for the throw to complete, the object would have to be tossed up to the nonexistant L4). There's two ways around this:

:The Normal Way: Try shorter throws, throwing from lower heights, or throwing while kneeling. Beyond that, possibly get some new troops.

:The Sneaky Way: Manually edit the Strength scores of your soldiers in [[SOLDIER.DAT]] so that they're back to a usable strength level. If you set "Initial Strength" (offset 46 decimal or 2E hex) to 0 and "Strength Improvement" (offset 57 decimal or 39 hex) to a value of 50, you can permanently lock the soldiers at 50 strength. (You can lock them higher than that if you so choose, but not lower.

:Other than this, there's no workarounds I can think of offhand. [[User:Arrow Quivershaft|Arrow Quivershaft]] 08:10, 27 April 2008 (PDT)

:: There's normally no problem with the max level of 70 in open settings. However TFTD has a lot of low ceilings such as in the shipping lane missions and colonies, and the lower ceilings impairs your throwing quite a bit. In addition to shorter throws/kneeling, try moving out from under any overhangs if there is one just above you. - [[User:NKF|NKF]] 12:33, 27 April 2008 (PDT)

== Bug not listed: Sticking your head through the ceiling ==
This is something I just discovered: When you step on a small object inside of a building your soldier sticks his/her head through the ceiling and can see what's upstairs. You can even see the soldiers head coming out of the floor and that soldiers can shoot aliens upstairs. When I did this the alien I saw/shot was facing the other way, but I guess you could get shot if the alien was facing you. [[User:RedNifre|RedNifre]] 17:34, 11 May 2008 (PDT)

:That's not listed under "Bugs" because it's covered under "Exploits", right here: [[Exploiting_Collison_Detection#See_Through_A_Ceiling]] [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:26, 11 May 2008 (PDT)

:: I don't know if it was ever covered anywhere, but there's this neat trick that might sound similar to the walk-through-'wall object'-wall trick except that it involves your unit climbing slopes. They'll appear as though they've gone up a level, but are actually not on that level. They only visually appear to be there, but are really still on the bottom level.

:: It happens a lot when walking up the desert or forest slopes. I think the trick involves standing on ground level, and then ordering the unit to 'move' into the hill rather than setting the waypoint while on level 1. The soldier will move up the slope and perhaps stop on the slope or even reach the top of the slope, but will still appear when you're only viewing the ground map layer. The soldier is really still on the ground level, but will have elevation offset.

:: One really interesting way of using this trick is in the mountain region. If you can find a cliff face and a low hill nearby, you can literally have your soldier scale the cliff by standing the soldier on the hill, and then walking towards the cliff. It's ridiculous, but your soldier never quite reaches the top of the cliff tiles, so ends up walking up a slope.

:: On a side note, standing at the top of the ramp of the Skyranger is the same as standing on ground level - you're only offset a bit. This means that smoke on level 1 and the sides of the Skyranger will not provide protection when you're at the top of the ramp.

:: On another related note in relation: In TFTD (doesn't happen a lot in UFO), you might find it difficult to toss grenades onto underwater slopes. To remedy this, raise the level up by one. It might look like you're tossing at air(and you are), but it'll get the grenade where you want it. Odd, but true. I must remember to put this in the grenade explanation section. -[[User:NKF|NKF]] 23:11, 11 May 2008 (PDT)

== Base Defence bug that causes a crash? ==

Does anyone know about a bug in a base defence mission that causes the game to crash? The game keeps crashing on the 4th or 5th alien turn.

:I've encountered that myself, but it should be noted that overall, X-COM is not the most stable game and is prone to crashing often at anytime. The differences between the hardware it was designed for and the hardware we're running it on cannot be helping matters at all; it's really a small miracle it even runs without an emulator in the first place(I've got games from 1999 that will bluescreen my machine instantly). As such, I'm not sure it's worth noting as a bug, since it's a 'game feature'(albeit a detrimental one). In any case, what're you doing letting the aliens attack you anyways? ;) [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:33, 18 July 2008 (PDT)

:It sounds like an alien is in one of the outlying locations and attempting to destroy the top floor item. Possibly a radar or defense station. - [[User:Morgan525|Tycho]]

== Sources for a DOS4GW transplant ==

I was specifically thinking of the LucasArts Dark Forces demo, but I half-recall the actual source I used when testing that ~1999 was Id's DOOM. -- [[User:Zaimoni|Zaimoni]] 16:03, 7 August 2008 (CDT)

== Phantom Carried Casualty ==

You are carrying an unconscious soldier in one hand, and the soldier dies of his/her wounds. The dead soldier remains visible on the "left hand / right hand object" battlescape display, but is no longer visible in the inventory display. The problem can be fixed by moving another object into the same hand.

I've seen this bug with UFO Extender by [[User:Seb76|Seb76]] - possibly might be something to do with his manipulation of the inventory screen, rather than a general bug. I believe I've also seen this with other objects that were being carried in the hands, disappearing from the Inventory screen, but I'm not sure. I don't think it's an item limit bug, as XcomUtil shows 40 item slots free. [[User:Spike|Spike]] 08:58, 21 September 2008 (PDT)

:I think it has to do with the KO units KIA mod. Its doesn't take into account units held so when it tries to detemine where to place the corpse, there is no location. The routine doesn't undo the item-carried-sprite-ID byte for the holder. -[[User:Morgan525|Tycho]]

== Civilians As Enemies to MC'd Aliens ==

I ran across this issue a few times and just wondered if you guys experienced this. I MC'd a part of a Reaper (I always do the lower left for large aliens) on a Terror Site, then moved it a few squares. It suddenly stopped dead in it's tracks and then the alien spotted indicator increased by 1. When I clicked on the indicator to see where the enemy unit was, it brought me to L2 of the large apartment complex. However, nothing was there. When I sent a Flying-Suited soldier up there to peek in the window (eeek! A peeping tom!) he saw a female civilian standing there. This type of problem has happened numerous times to me so it's not a once-off thing. Maybe it's a LOS issue? Or maybe an alien indicator problem? Or a combination of the two? Don't know, but I'm curious if you guys have seen it. --[[User:Zombie|Zombie]] 23:40, 19 December 2008 (CST)

:There are a lot of major issues with MC'ing 4 square aliens. One of them being that you could accidentally MC an alien far off in the corner of the map, IIRC? Anyhow, maybe you should have tried MC'ing all 4 squares of the reaper and see if that changed things. -[[User:Jasonred|Jasonred]]

The long-range MC of other aliens when Mind-Controlling large aliens is only present in Terror From The Deep, due to a workaround to try and resolve the earlier bugs(and exploits) associated with controlling one square of a large unit at the time. In TFTD, successfully MC'ing part of a Large unit will also grant you control of the next three units in UNITPOS.DAT, in order. If you didn't MC the upper left portion of the large unit(the first UNITPOS entry for any large unit), you can potentially wind up in control of other aliens. So this doesn't apply to UFO. As for Zombie's issue, never seen it. And finally...Jasonred, on Talk pages, please indent your statement with colons so it differentiates from other people's comments, and sign your posts with 4 ~'s, like I will now do. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==Elerium Base Bug==

Jasonred: This bug has long since been known about. Elerium units on the Battlescape can be picked up by shooting away the power source; this one item counts as 50 units, and as such ANY elerium item spawned on any Battlescape counts as 50 Elerium. This issue with your own Elerium spawning as collectable loot in a Base Defense mission only occurs in older DOS versions, and is at the whim of the 80 item limit. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:55, 18 February 2009 (CST)

:Base defense does not seem to follow the 80 item limit in that DOS version. There are a lot of bugs that have long been known about. However this one was not included in the ufopedia for some reason.
:Also, the main thing about this bug is that it does not potentially double your elerium stores. It potentially multiplies them 50 times.
:... First time this happened to me, I was pretty flabbergasted. Here I was being conservative with my limited Elerium, refraining from blowing up UFOs when possible, when I perform a base defense and gain 3000 Elerium from it. Holy spit. -[[User:Jasonred|Jasonred]]

Alright, my error. Thanks for clarifying. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==HWP Fusion Bomb and SWS PWT Displacer Ammo Manufacturing Cost Bug==

At a cost of $15000, 400 Tech hours, 5 Zrbite, and 8 Aqua Plastics, this is the exact same cost as the HWP Fusion Bomb from X-COM EU, converted over to the equivalent TFTD resources. As such, it shouldn't be counted as a bug, since it is clearly what Mythos intended. [[User:Arrow Quivershaft|Arrow Quivershaft]] 09:55, 15 November 2008 (CST)

:Hmm, in that case maybe it should be treated as a generic game engine issue and not a TFTD specific issue - but I still think it's a design error. Can you think of any logical reason why the SWS/HWP version of the ammo should be more expensive (in cost and in materials) than both the craft ammo and the (more powerful) personal ammo? It makes no logical sense. Hence I think it's a design error. Nothing can be inferred from the fact it's unchanged from XCOM-EU, that doesn't imply any deliberate decision. It could just be the replication of an original error in XCOM-EU. [[User:Spike|Spike]] 11:17, 15 November 2008 (CST)

:: I can think of a logical reason to justify this: X-Com doesn't understand the technology as well as the aliens do (which is obvious, given the length of time each side has known the tech). Handheld Blaster/Blaster Bombs are just a copy of the alien design and therefor relatively cheap and efficient, but that can't be mounted on a turret. So X-Com has to make a new design, and they obviously didn't do that good a job as the aliens would have done. This explains Tank/Plasma being weaker than Heavy Plasma too. (Why is FBL Craft ammo cheaper than the tank ammo though? Maybe X-Com gave up on/simplified the guidance system and made it just a "dumb" cannon shell/torpedo instead which doesn't have multiple waypoints? Or maybe they just did a better job there?). [[User:Cesium|Cesium]] 04:07, 25 November 2009 (EST)

:Whilst we discuss it, I'll park my original text in here:

* ''Displacer/PWT ammo cost bug - at over $100,000 total cost per round, the ammunition for this SWS weapon is far more expensive to manufacture (both in money and rare materials) than the equivalent ammo for the Aquanaut-carried Disruptor Pulse Launcher, or the craft-based Pulse Wave Torpedo, despite being less powerful than either. This would seem to be a design mistake.''

See Also [[Talk:Displacer/PWT]]

:: I don't like the higher cost either, but I think it's a tradeoff of expense and quality for the convenience of portability. Sort of like an MP3 player to the gramophone... or maybe that's not a good comparison. -[[User:NKF|NKF]] 13:43, 15 November 2008 (CST)

A better comparison might be a desktop computer to a laptop. As a general rule, laptops are more expensive, but a similarly priced desktop gives you more power. Desktops are cheaper and offer power, laptops are more expensive and offer portability(though the gap is rapidly narrowing). [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:49, 15 November 2008 (CST)

:I think those are good analogies. But they don't apply in this case. To continue your analogies: We are paying mainframe prices for a clunky desktop that has only laptop processing power, and we're buying a mainframe for desktop prices. The vehicle version ("desktop") - is ''less'' portable and ''less'' powerful than the personal version (DPL = "laptop"), ''less'' capable than the craft version ("mainframe") - 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 SWS use up ''more'' of both Zrbite and Aqua Plastics than the Craft version. Do we really think it's logical that a tactical battlefield round, less powerful than its man-carried equivalent, takes more explosive and structural material to produce than both the more powerful man-carried version and also more than the air-to-air round that has 60km range and can take down a major alien combat craft? There is a clearly perverse bang-per-buck here, on every measure. My sincere belief is that this was an original mistake in the XCOM-EU engine that got copied into TFTD as well. The craft round should have the higher base price, but 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. But what I don't think is debatable is that is not logical for the SWS/HWP rounds to be more expensive than the craft rounds. It's clearly a mistake. Even in game balance terms, the only thing the HWP/SWS rounds have going for them is conserving "80-Item Limit" space, which I severely doubt was ever a game design consideration since it's just an awkward programming compromise. Any advantage inherent in the HWP/SWS is already reflected in the very high platform cost - there is no need to inflate the ammo costs as well. The bottom line is that a round for a (mini-)tank does not cost more, does not use more materials, than the same type of round for a long range anti-aircraft weapon that has much greater damage capacity and penetrating capacity. [[User:Spike|Spike]] 14:35, 15 November 2008 (CST)

I'm going to add this to the bug list now. [[User:Spike|Spike]] 16:06, 25 February 2009 (CST)

:Still don't think this is a bug though. Just because it's more expensive to manufacture than the hand-held or craft-mounted ammo, it doesn't mean the stats are wrong. Perhaps the programmers wanted to balance the tactical portion of the game a little more by making the ammo cost more for tanks. It doesn't have to be logical to be intended. Now if you had proof which said that the ammo was supposed to cost less but the stats were wrong, then yes, I'd agree. So if you boil it all down it comes to a disparate logic issue, not a bug.--[[User:Zombie|Zombie]] 21:31, 25 February 2009 (CST)

::I have to side with Zombie here. While the ammo may be disproportionately expensive, by the definition used on the rest of the page for bug, it doesn't fit. All the other bugs are errors in program logic or function or routines that are unintentional problems with the game, most of which are not warned of ahead of time. The ammo for the tank costs exactly what is listed and operates entirely as intended, whereas the rest of the bugs are not intended game features. Even if the numbers were entered wrong, that would be a data entry error, not a program bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:28, 26 February 2009 (CST)

:If it was a data entry error, I'd consider that a type of bug... assuming we had proof of the goof so to speak. LOL. --[[User:Zombie|Zombie]] 00:49, 26 February 2009 (CST)

:: It feels too specific an entry to be a data entry error.

:: I'm reminded of the high explosive. I know, I know - it's not an exact parallel to the FBL issue. A High Explosive is practically two grenades. Double weight, double bulk. Slightly above two times the damage. However, it costs five times the price of a standard grenade. Even though you're paying more for not-as-much, I don't think that could be considered a bug. A rip off, yes, but not a bug.

:: Here's a thought: Think about the immediate benefits each of the two controversial ammo types give back to you. Aircraft ammo = activity points. Tank ammo = loot. Yes, I know that aircraft ammo also generate crash sites, but you still have the ground combat to contend with.

:: One other thought: With careful management of your ammo, you'll probably never spend any elerium on the handheld version's ammo. Could it be the handheld that's really at issue here rather than the others? In the end I feel that it doesn't really matter. -[[User:NKF|NKF]] 03:38, 26 February 2009 (CST)

: I'm with Zombie that a data entry error is a bug (we have other examples), but also agree some proof is probably needed. And I agree with NKF that in the scheme of things, it doesn't really matter much. I don't think the HE pack is a good comparison (though the HE pack should be heavier) as it's reasonable to pay disprortionately more to get additional power at the same tech level. The fusion weapons are a case of paying more to actually get ''less'' power. I am not bothered by the handheld vs vehicle balance, not least because the game generally makes handheld weapons better than their vehicle equivalents, so I can accept that as an across-the-board design decision.

: I can also see a game balance argument ''if'' we believe that Fusion Tank ammo is more of an overall game-winning weapon than craft Fusion Bombs. But I'm not sure I agree with that statement. And even if it's true, and there's a game balance argument (in which case it would apply equally to handheld Fusion launchers), it's still illogical. The less powerful, battlefield warhead should not cost massively more in exotic materials than the much more powerful air to air warhead that brings down Battleships. I agree though that just because it's illogical does not prove it's a bug (i.e. unintended). [[User:Spike|Spike]] 07:48, 26 February 2009 (CST)

Ok we more or less seem to be in agreement that this isn't a bug, but it is very confusing/illogical. Maybe we can shift the "bug" text from the article page and roll that into the [[Hovertank/Launcher]] and [[Displacer /P. W. T.]] pages now. Feel free to combine any text from the discussion above if necessary. --[[User:Zombie|Zombie]] 09:22, 26 February 2009 (CST)

: Unless we can ''prove'' it's a data entry error (unlikely), how about calling it an "Anomaly" instead of a bug? [[User:Spike|Spike]] 10:59, 26 February 2009 (CST)

Looks like plain old game imbalance to me.
The way I see it, Hovertank Plasma and Launcher were meant to be stronger. Much much stronger. Let's look at Tank Cannon, Launcher and Laser. The logic is that it's a tank mounted weapon, so the tank can carry a much larger and more powerful version of the same weapon, right?
It's pretty stupid that a Hovertank Plasma is weaker than the Heavy Plasma... you could just mount a Heavy Plasma on a Hovertank and get them exactly equal. In fact, I suspect that the hovertanks were ALSO meant to have more powerful weapons than the man-portable versions.
Unfortunatly, the game designers then realised that this made the hovertanks far too powerful. So... the programmers nerfed the power of the hovertank weapons. BUT they forgot to lower the ammo costs. [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 11:20, 26 February 2009 (CST)

: Well you are opening up a much larger issue there. The Fusion weapons are an anomaly, an inconsistency. But handheld weapons are more powerful than equivalent vehicle weapons across the board, consistently. So that looks like a deliberate design decision, not a mistake. [[User:Spike|Spike]] 17:33, 26 February 2009 (CST)

:: There are two exceptions to the rule: Tank/Cannon: 60AP vs. Heavy Cannon 56AP. Tank/Laser: 110 Laser vs. Heavy Laser: 85 Laser. The hovertank\plasma only differs by a measly 5 (an extra 0 - 10 damage, which means a lot vs. UFO inner hull armour). I guess the trend here was to moderate the area effect tank strengths. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

I'd have to agree with you there Spike. This wasn't a mistake, however odd it may seem. It was a deliberate attempt to try and balance the game. Below is a table I created ages ago for my (now defunct) strategy guide detailing the HWP's and what handheld weapon corresponds to it. When you stick them side-by-side, it really becomes apparent that the programmers were trying to base the HWP weapons off the handheld weapons somewhat. The only thing that doesn't follow a nice and distinct scheme is the damage. That's what is the clincher. --[[User:Zombie|Zombie]] 20:26, 26 February 2009 (CST)
 
<table {{StdCenterTable}} class="sortable">
<tr {{StdDescTable_Heading}}><th align="left" width="150">Tank Type</th><th width="70">DAM</th><th width="80">Snap</th><th width="90">Aimed</th><th width="90">Aimed</th><th width="80">Snap</th><th width="70">DAM</th><th align="right" width="140">Handheld</th></tr>
<tr><th align="left">Tank/Cannon</th><td>60</td><td>60%</td><td>90%</td><td>90%</td><td>60%</td><td>561</td><th align="right">Heavy Cannon</th></tr>
<tr><th align="left">Rocket Launcher</th><td>85</td><td>55%</td><td>115%</td><td>115%</td><td>55%</td><td>87.52</td><th align="right">Rocket Launcher</th></tr>
<tr><th align="left">Laser Cannon</th><td>110</td><td>50%</td><td>85%</td><td>84%</td><td>50%</td><td>85</td><th align="right">Heavy Laser</th></tr>
<tr><th align="left">Hovertank/Plasma</th><td>110</td><td>85%</td><td>100%</td><td>100%</td><td>86%</td><td>80</td><th align="right">Plasma Rifle</th></tr>
<tr><th align="left">Hovertank/Launch</th><td>140</td><td>--%</td><td>120%</td><td>120%</td><td>--%</td><td>200</td><th align="right">Blaster Launcher</th></tr>
</table>
1AP rounds. 
2Average between the Small and Large Rocket.

: Hold up! Tank rounds do 60AP. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

So what's wrong? The table says 60 for the Tank/Cannon and 56 for HC-AP. Those are correct, no? --[[User:Zombie|Zombie]] 23:41, 26 February 2009 (CST)

: Sorry, didn't realise it was two tables side by side (or rather mirrored). Eyes only noticed the left side of the table. -[[User:NKF|NKF]] 23:53, 26 February 2009 (CST)

:: If the Hovertank Launcher did 200 damage, or worse if the Hovertank Launcher did EVEN MORE damage than the Blaster Launcher... that would make them easily the most deadly things on the map. As it is, the hovertank launcher is already pretty overpowered, even with 140 power.

I might be six years late here, but I think there could be an explanation for this in RL physics — indeed, in RL nuclear weapons programs. Incoming wall of text.

There are two sorts of nuclear reactions that produce energy: fission of large nuclei, and fusion of small nuclei. Fission can occur under normal temperatures and pressures, but involves a neutron chain reaction. As such, fission devices have to have a certain mass of fissionable material (the ''critical mass'') so that the neutrons stay in the material and cause more fission rather than escaping; this means that such devices cannot be scaled down below about suitcase or large backpack size (not all of this is actually nuclear material; rather, most of it is conventional explosives used to rapidly assemble the supercritical mass from subcritical masses). They also produce large quantities of radioactive fallout, which is problematic. Fusion, on the other hand, requires extreme temperatures and pressures, but does not necessarily require a neutron chain reaction. This means that they can theoretically be scaled down to much smaller sizes... except that the only available compact source (ie, not building-sized) of those extreme temperatures and pressures is the detonation of a fission bomb. Thus, all known fusion weapons currently in existence involve a relatively-small fission stage that detonates a much more powerful fusion stage.

The "Holy Grail" of nuclear weapons research is what's called a [[wikipedia:Pure fusion weapon|pure-fusion weapon]]. Because it has no fission stage, a pure-fusion weapon would release little fallout (note here that fallout is material that emits radiation long '''after''' the detonation; a pure-fusion weapon would emit copious amounts of deadly neutron radiation when actually used, but that would dissipate within seconds) and could be scaled down to grenade-launcher size (though it would obviously be far more powerful than a conventional grenade). They would be far easier to produce, as well; producing weapons-grade uranium and plutonium requires large and powerful isotopic separation equipment and/or a full-sized nuclear reactor, whereas deuterium can be extracted from water with trivial ease and lithium and tritium are relatively simple to obtain and make respectively. The main issue is that while the pressures required to confine the fusion material during the reaction are achievable with chemical explosives, the temperatures necessary for fusion are emphatically not. You need a stronger initiator; some material with a higher energy density even than plutonium. In RL the only initiator strong enough is antimatter — hard to produce and contain, to say the least — but the aliens in X-Com have a source that's stored far more easily... Elerium.

I posit that the "fusion" line of weapons in X-Com are exactly what they're named: tactical fusion bombs, made possible by an Elerium detonator. (A more controlled reaction on those lines — a fusion reactor with Elerium-spiked fuel — in UFO Power Sources would also explain the discrepancy between the calculations based on fuel efficiency and the lack of city-killer blasts when a Power Source's Elerium cooks off.)

Given the assumption that "fusion" weapons are indeed fusion weapons, with Elerium serving only as a detonator, the oddly high Elerium cost of the Hovertank/Launcher's ammunition is finally explainable. The HWP Fusion Bombs are, literally, smaller than Blaster Bombs and craft Fusion Balls (presumably because of size constraints in the launching mechanism in tanks). Having less explosives to compress the fuel means you need an even higher temperature to compensate — thus, more Elerium detonator — but because the actual power of the bomb is mostly from fusion and not Elerium decomposition, the yield is still lower.

I intend to remove this from the list of Known Bugs on this basis if nobody can find a hole in my logic. [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 02:03, 17 April 2015 (EDT)

:I'll have to disagree. Your argument while interesting, is just supposition and an attempt to give validation by taking ideas (that the developers probably never considered) to justify a flaw, very much in the same manner as those who try to explain why UFOs do not respond in interceptions. In truth, like many of the other bugs listed here, they are the result of issues caused by the time constraints the Gallops where under. Much of the production/buying/selling aspects of the game have game balance issues and don't make sense when cross referenced to other similar elements in the game and/or their overall effect to either combat or the strategy layer, especially in regards to the game's economics. [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]]) 05:06, 17 April 2015 (EDT)

::Why would they match up in terminology with the actual use to which any military would put Elerium by accident? Because, no shit, if a military got their hands on a substance with Elerium's properties this is literally exactly what they'd do (at least as far as explosives go). I can cite a paper talking about the superiority of antimatter-fusion weapons to pure antimatter weapons if you want; the title is "Fourth Generation Nuclear Weapons: Military effectiveness and collateral effects". [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 05:21, 17 April 2015 (EDT)

:quote all the sources you like, it still doesn't explain the waste in the manufacture process. With elerium being such a "scarce" resource, there is no logic in producing something that require more elerium and delivers less of a battlefield effect. It would be more logical and efficient to have had the platform fire regular blaster bombs, since they only require 3 elerium not 5.[[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])
::IMHO, any logic argument can be presented to why those HWP Elerium Bombs should cost less/more or be more efficient. That is not the point here. A bug is when a game feature is working improperly or/and is causing technical issues, either due to limitations, insufficient testing, whatever. Design choices are a completely different matter: the Heavy Laser is a nearly useless weapon due to its stats but no one ever considers it to be bugged due to its stats. It was a choice, that was slightly changed on TFTD with the Heavy Gauss. To consider the stats of the HWP Fusion a bug then you'd have to label a lot of choices as bugs when they are simply design choices. You may not agree with them but that doesn't make them bugs in the generally accepted definition of the term. And quoting Arrow Quivershaft on the top comment of this discussion: "At a cost of $15000, 400 Tech hours, 5 Zrbite, and 8 Aqua Plastics, this is the exact same cost as the HWP Fusion Bomb from X-COM EU, converted over to the equivalent TFTD resources. As such, it shouldn't be counted as a bug, since it is clearly what Mythos intended"[[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 19:35, 25 April 2015 (EDT)
::Also, the consensus until now expressed by several people that previously discussed this is that this is not a bug. The main supporter of the bug argument seems to be Spike at the beginning but during the discussion but halfway the discussion he says: "I agree though that just because it's illogical does not prove it's a bug (i.e. unintended)" [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 20:54, 25 April 2015 (EDT)
You don't get to claim benefit of the doubt here, Tycho. All game features are assumed to not be bugs unless there is compelling evidence presented otherwise. You claim this is a bug based on the suppositional logic that more powerful weapons should cost more and almost nothing else. The price wasn't altered (and neither was the power) in TFTD, so there's no evidence of mistake there (as an aside, the Displacer/Sonic having its power listed as 130 when it's 110 in the game engine clearly ''is'' a bug). The only bit you might be able to interpret that way would be the description of the Hovertank/Launcher's weapon as causing "immense devastation" compared to the description of the Blaster Bomb as "highly powerful" (the potential implication being that the HWP Fusion Bomb is stronger), but that's iffy at best since there's hardly a graded table of adjectives in use and on those very same pages in the UFOpaedia it lists the damage of each weapon as what it actually is.

The claim that it's a bug is based entirely on theorising about yields. I've given alternate theorising that would explain the yields (and I already explained that the semi-automatic nature of the Hovertank/Launcher and physical space for its high ammo could justify the need for a smaller round), which undercuts that claim. We can't know who's right, but the assumption should always be that the designers knew what they were doing; to assume until proven otherwise that they had no clue is extreme hubris and contempt. Moreover, you are in a minority of one or perhaps of two against a majority of several. Your claim to representing consensus is blatantly false.

Now, I'm going to wait a couple more days to see if anyone comes forward with anything substantive, as I waited a week after my reply to your original non-refutatory dismissal, and then reinstate the removal if nobody puts forward a cogent objection. [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 22:57, 25 April 2015 (EDT)
:Now that I think of it, though, an "oddities" page where we talk about this, the shitty Heavy Laser/Heavy Gauss, the No More Soldiers limit, and other not-bug things might be in order. It would help to make this page about actual bugs and not about weirdness that is nevertheless clearly as intended. Thoughts? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 23:04, 25 April 2015 (EDT)

:At the time, I didn't continue the argument as my point was that removing something based on one person's belief, no matter how cleverly thought out, wasn't good enough to warrant removing from the list. (I would have pointed out all the different theories on UFO interception AI, but I see that has already been removed.) I hadn't read all the discussions because I assumed that no consensus had been reached, similar to the Interception AI discussion. Mushroom, could have just pointed out that this issue was already settled years ago but no one bothered to removed it from the list, instead of resurrecting a "dead" discussion as though it had not been settled and just stated that the developers intended to discourage the use of this HWP by making the cost of its ammo high. I still don't agree that the HWP ammo is more efficient and thus justification for its production cost, especially since the developers would have never needed this level of justification or would have had the time to devote to so small an aspect of the game.

:I definitely agree that this page needs to be updated. Another reason I argued so strongly is because so many topics on this page do not fall into the category of bug as has been defined. I thought this page was also devoted to listing all the illogical aspects of the game due to the lack of enforcement on the definition. [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])

::If I only had a dime for each time someone proposes to change something on this wiki, everyone agrees, and then nobody ends up taking action... :) It's always better to take initiative and edit things. I agree also with an update to this page, and separating bugs from limitations. But definitely no more 'this should have been done this way' arguments to present design decisions as 'bugs' [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 17:43, 26 April 2015 (EDT)

:Okay. I'm planning to rip out the following and stick them on a separate page:

:Great Circle "bug" (this isn't really a "bug" so much as unoptimised code)
:Side-on Intercept "bug" (ditto, but given UFOs' tendency to alter course suddenly it's not even particularly unoptimised)
:Head-on Intercept "bug" (come on, this is just bitching)
:Instant Getaway "bug" (more an anomaly than a bug)
:80-item limit (intentional and the rationale is obvious to boot)
:Purchase limit (working as intended)
:Soldier recruiting limit (being charged for attempting to buy more is a bug, but the limit itself isn't)
:Soldier battlescape limit (there's a consequence of this which is a bug, the CtD with 10+ tanks, but not the limit itself)
:Manufacturing Completion Time Display "bug" (you can look at it and see what time it finishes, and it goes down at the right rate; it may seem a little unintuitive but it isn't "wrong")
:Manufacturing Rate Interruption Loss "bug" (more bitching)
:Manufacturing Rate limit (working as intended; the attempt to get around it in TFTD is bugged, but the EU behaviour isn't)
:HWP Fusion Bomb Ammo Cost "bug" (we're in agreement here it seems)

:There's plenty that need a tidyup on top of that but as far as the page split itself goes, are we agreed? Also, I'm thinking of calling the page "Anomalies and Game Limits", opinions? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 01:58, 3 May 2015 (EDT)

== DOS4GW - What the heck is it? ==

It's been ages since I had to remember this stuff, so those who remember clearer than I do, forgive me if my descriptions aren't accurate. Hopefully the general idea will come across.

Back in ye olde days of computere gamynge - and where there were more E's to go around, memory handling was a tricky beast to handle. Computer memory is divided into several different categories. Conventional, extended and I think expanded. I might be jumbling the terminologies for the last two a bit. Doesn't matter - memory was just cut up into small segments. The two most common memory types to PCs at the time were pretty small but were readily available. The third one - the most expandable (aka the chip with its massive 4 Megs of RAM you just spent your whole month's allowance on!), wasn't as easy to get at.

To get access to the higher memory that was available to the computer, special memory handlers had to be used. Drivers like HIMEM, emm386, etc were used.

DOS4GW is one such handler that lets the game access the computer's available expanded memory. Lots of games that came out at the time use this. Doom, Duke Nukem 3d, Syndicate, Ultima Underworld, X-Com UFO/TFTD, etc. LOTS of games. Any time you ran a game from the dos console and you saw the Dos4GW message flash by briefly it would be assisted by it (well, it stayed on the screen for ages back when processors were slower!).

It took the hassle out of memory handling and let the game access the available memory on the computer as one big flat block of memory to play with.

So what was meant in the article was to simply replace the dos4gw.exe with a more up-to-date version from another game. I think the way to tell its version was just in the message that it displayed. You can just run the dos4gw.exe file in a console window. It'll give an error, but the message it shows will indicate its version. UFO 1.4 uses Dos4gw 1.95, for example.

-[[User:NKF|NKF]] 01:22, 6 March 2009 (CST)
:DOS4GW also switched the processor from 16bit to 32bit mode. [[User:Seb76|Seb76]] 13:58, 6 March 2009 (CST)

== Clipping ==
I have a new bug. Its harmless. I have a savegame (EU CE - modified game) which has a sectoid within another sectoid. In the alien turn, one secturd walked off the roof and dropped down <s>onto</s> into another. (I guess there DNA is indentical afterall, so they 'become one' with the world). If you want the savegame (superhuman edited using UFOloader, UFO Mod v1, xcomed, Khor Chin WeapEdit v0.1) drop me a request on the my page somewhere. [[User:EsTeR|EsTeR]] 01:40, 18 September 2009 (EDT)

: Not something many would encounter, but definitely something that can happen. Units can occupy the same physical space, but the game cannot display them all. It'll only draw one of them. Actually saw this effect happen back in the early days of XComutil when it gained the ability to manually add new aliens into a battlescape. It did this by slotting them into the same spaces occupied by existing aliens. Then the fun would happen when you saw a couple of Mutons suddenly walk out of a sectoid. Not sure how the game determines who gets hurt when struck by a bullet. May very well depend on the order they are stored in the unitpos.dat file.

: There are a couple of ways you can replicate this in-game, but I can only provide theories on how you could do it. Such as shooting the ceiling above you and letting the unit drop through, or moving a tank off a ledge and getting its non-primary segments land directly on top of another unit. By the way, the rear end of tanks get stuck in walls if you attempt to move north or east off any ledges. -[[User:NKF|NKF]] 02:18, 18 September 2009 (EDT)

: Ok, so as long as others know about this, then all is good. I had never seen it and was doing alot of head scratching until I shot the alien.

== Berserk HWP crashes the game ==
In the article page it mentions that aliens which go berserk with their integrated weapons will crash the game. This is only true for Mind Controlled aliens (or units under X-COM control) - alien controlled units which go berserk do not crash the game. I tested an MC'd Celatid just now and it doesn't crash the game either, though it doesn't immediately go berserk - it waits another turn for some odd reason. Someone want to check this to verify my results? --[[User:Zombie|Zombie]] 20:31, 27 December 2009 (EST)

==HWP Morale Loss==

HWPs have 110 Bravery, which [[Morale#Effect_of_Bravery|normally prevents morale loss]], but I wonder if they can still lose morale due to loss of units with a morale-loss modifier. It'd depend on how the math is done. If, for, example, the -20 to morale for a dead unit is static, then multiplied by any [[Morale#Officers|morale loss modifier]], then reduced by 2 for every ten point of bravery, any officer death without another officer on the field will necessarily reduce HWP Morale.

It all depends on how the equation plays out and when modifiers are added. For sake of this post, I propose the following as the morale-loss equation: 20*(rank death modifier)-((Bravery-10)/5)*(1.00-Leadership bonus)=Morale Lost. (Rather than using 22 as a base, I'm going to assume Bravery is internally decremented by 10 for this equation as 0 Bravery is impossible without editing and it makes the math easier for the purpose of the example.)

It makes sense to me that rather than having 110 bravery hard-coded as an exception to "No morale lost", it simply works the same way in the normal equation, but is high enough that it negates most morale loss events, as even if an officer is killed, another officer is usually left on the field to help negate the penalty. That said, if a large portion of the team is wiped out at once, any surviving officers may not be able to negate it all, allowing tanks to start having noticeable morale loss.

So with the death multipliers, we can determine that every XCOM officer killed has a set death value. Rookies and Squaddies are -20, Sergeants are -24, Captains are -26, Colonels -30, and Commanders -35.

For example, under this theory, if a Sergeant is killed with no other ranked units on the field, a Squaddie with 50 Bravery would lose 16 Morale. (20*1.2-(50-10)/5*1.00=16). A HWP would, at the same time, lose 4 morale. The Sergeant's death is worth -24 Morale, and without another officer on the field to ameliorate the loss, the Tank's bravery only can 'absorb' 20 points of the morale lost. If it was instead the Commander lost, with no other officers on the field, the HWP would lose instead 15 points of morale, given that a Commander's death (20*1.75) is worth a whopping 35 points of morale loss if no other officers are present.

And if you have, say, four colonels and the Commander on rear/psi duty, and some alien flings a grenade or a blaster bomb into the back of the Skyranger and blows all three of them up and they were the only officers, the HWP has now lost 55 morale, which gives it a 10% chance of panicking/berserking on the next turn!

In the end this'll probably need to be tested for accuracy, but those are my thoughts right now.

Also, for the record, most units that berserk go to 255 TUs while still using the original TU-expenditure calculations; it's part of what makes berserk units so dangerous. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:34, 11 January 2012 (EST)

:Tested it under vanilla CE. Took a squad out containing just about every rank there is (commander + colonel + captions + sergeants), plus a tank. Blew up and killed all soldiers with a single blaster bomb shell, leaving just the tank, which lost no morale (sorry).

:I also brought a group of rookies along with a single commander + tank, and killed just the ranked unit. Tank lost no morale. A rookie with 60 bravery lost 17 (which matches the loss predicted by the formula currently on the morale page), whereas under your formula he should've lost 25.

:Still, you're on the right track. I've long had my own theory as to why tanks have been known to lose morale. Take a look at [[UNITREF.DAT#42|UNITREF.DAT[42]]] - this is the offset that stores a unit's rank. Notice something? The value gets higher as the X-COM unit's rank gets higher. Works in ''reverse'' for aliens, for whatever reason. I sorta figure it's so killing a mind controlled alien commander doesn't mess with your morale too badly, but there's a big problem with that theory and you can probably tell what it is...

:If the highest this figure gets for an X-COM unit is 5 (commander rank), then a killing a mind controlled alien ''terrorist'' with a rank value of ''7'' should net an even higher morale loss penalty. And indeed it does - I took a rookie and a tank to a terror mission, mind controlled and killed a terrorist, and the tank lost 10 morale. Guess it would've lost six if I'd taken a commander instead of a rookie, but that's still something.

:Note that the formula on the morale page does ''not'' account for this - it states that at bravery 110 the alien's death loss multiplier would always be applied to a base morale loss of 0, but that's obviously wrong. You're spot on in saying that the base morale loss figures are not totally dependant on bravery, and the "death loss" penalty is applied first. Would probably require a few more trials to determine what that penalty ''is'' for alien soldiers and terrorists though.

:Just for kicks, I edited a plasma tank to have 0 morale. It panicked in the normal way (either sitting still or charging off to the SE). When it berserked, the game crashed as soon as I dismissed the status message. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 18:54, 12 January 2012 (EST)

:: Thought I'd give it a spin. I sent a laser tank in with a squad and had it start shooting at team members. Each time it killed an ally, it would lose morale. Once it was under 50 morale, I waited until it panicked. Since I was playing the dos version, the game didn't crash but I suspect a memory leak of some sort may have occurred that would normally shut down the CE version. What would happen in CE if a soldier were to be edited and granted a tank turret, and then made to panic? Would the game crash? I'm just wondering if it's related to the weapon as opposed to the fact the tank is a treated as a large unit. -[[User:NKF|NKF]] 00:43, 13 January 2012 (EST)

::: Ah, friendly fire! Thought I'd tested for that, but obviously not...

::: Oddly enough, now that I try it, I see that the twenty point hit for killing a unit on the same side can be adjusted by the leadership bonus of the victim. Eg, kill a lone commander and his 35% penalty reduction takes the extra morale lost from 20 down to 13 (which is exactly how much a tank will lose, given that it otherwise wouldn't lose any at all).

::: Of course, this completely messes up my theory about alien soldier/terrorist ranks overriding the 110 bravery score. It doesn't. My tank "only" lost 10 morale because the alien's rank acted as a 50% leadership bonus... Though I suppose that's still interesting to know, because it suggests that keeping a simple alien soldier under mind control is more effective then risking your own commander in the field.

::: I took an otherwise unarmed rookie and assigned him a tank cannon + ammo. He could manually fire this weapon in much the same way a tank can. Forcing him to berserk crashed CE, under DOS he just spun around. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 21:20, 13 January 2012 (EST)

== 80-items limit on CE edition ==

I have the feeling that the 80-items limit does not apply to the CE edition and is instead a 110-items limit (at least during base defence). Can anyone confirm? [[User:Seb76|Seb76]] 16:24, 24 February 2010 (EST)

:I believe this limit was increased for TFTD. Maybe it was also increased for the CE edition of UFO, and only ever applied to the DOS edition of UFO?? [[User:Spike|Spike]] 20:03, 11 March 2010 (EST)

== Paying for Dirt in TFTD ==

I have the steam version of TFTD and am unable to replicate this bug. Testing with the starting base, I dismantled a few modules, added up my income and expenses, and it reconciled with my cash at the beginning of the next month. I even tried again, dismantling every module except the access lift, and once again saw no income discrepancy. Am I missing something, or is it possible this bug was actually fixed in TFTD? --[[User:Jewcifer|Jewcifer]] 12:18, 16 March 2012 (EDT)

:'twas probably fixed. It would indeed be helpful to add a small note to bugs on this page which are EU-specific but not obviously so (like this one). -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 17:14, 16 March 2012 (EDT)

::Every now and then I get the urge to test some of the more important bugs myself in my steam version of TFTD. Perhaps I will make a more complete effort and record the results somewhere on the wiki. --[[User:Jewcifer|Jewcifer]] 12:08, 21 March 2012 (EDT)

== Paying for dirt: Source of bug discovered! ==

Well, I never have read this anywhere (which kind of strikes me as odd, thinking of how obvious this one seemed to me... And i have NO programming background whatsoever), so I'll post it here, hoping that there are still some active members willing to try and verify my findings. If so, please comment here, because then I will inform bladefirelight to include this in any upcoming xcomutil release. If it had been discovered before, well then I just wasted some time here. Comment below, I will delete this entry.

As the main bug page mentions, when dismantling a facility still under construction the premium will only be paid once it would have been finished. This suggests some connection between paying the premium and building time. Looking into the infos here: [[BASE.DAT]], I quickly discovered what the problem was: When a facility is dismantled, the Bytes related to the location of base facilities are updated correctly. HOWEVER the game omits to update build time to FF (which is "will never finish", an entry only found on unused squares). If the facility is finished when it is dismantled (or destroyed during combat), then the 00 in the build time byte will stand. If it was under construction, the value indicating the remainig build time will continue to tick down towards 00 as if the facility was still there.

Now at the end of the month the following seems to happen: The game checks for ANY 00 entry in the build time bytes, and if there are 00 entries, it will look up in the location bytes the type of structure to determine the amount of maintenance for that 00-construction-time-square. When it finds "dirt", then it will charge the 80 grand (my guess would be that those are somewhere hard-coded).

This explains all phenomena related to this bug, like a dismantled hangar costing 320.000 grand or the premium only popping up after the build time of a dismantled facility that was under construction has expired.

Now the fix is pretty easy: Open the BASE.DAT in a hex-editor and change the bytes in question to FF!

== Minimized Interceptor Bug (Ufo CE) ==

Maybe this bug is not just related to saving, because I had a similar problem last night. The game didn't crash, but it kept restarting the same Battlescape mission.
One Avenger (A-3) was pacing a Battleship, while another Avenger (A-1) was sent to pick up the pieces of a Terror Ship that had been shot down by an Interceptor. Despite having no weapons (oversight on my part), A-3 wanted to attack the Battleship, but I minimized the screen, hoping it would land.
While the screen was minimized, A-1 landed at the Crash Site from the Terror Ship and started this mission. Right after finishing it, I got the message that A-3 was ready to land next to the Battleship. Happy that I'd get the loot, I started the mission.
After cleaning it out, I got the usual Loot and Promotion screens and went back to the Geoscape. A few seconds later, I was back in the equipment screen and the Battleship Mission started again. I played it once more, because - hey - additional loot, right? Err... no. At the end, I got the correct Loot screen for this attempt and the very same promotion I had gotten in the first attempt (A Rookie from another base promoted to Sergeant).
Got back to Geoscape and a few seconds later back to the Equipment screen. I aborted this mission (same Battleship again), got back to Geoscape and - you guessed it - back to the Equipment screen. After aborting this mission as well and getting back to Geoscape, I used the few seconds I had to go to 'Options' and 'Abort Game'. Maybe I could have made A-3 disengage from the Battleship since I think I saw them both on the Geoscape, a yellow diamond and a red plus, but it was pretty late by that time.
--[[User:Matzebrei|Matzebrei]] 15:06, 15 May 2012 (EDT)

This is a known bug. There is a work around. You should patrol the ship with troops and not land... Finish shooting down the other airborne ships first. Then when the ships doing the shooting are returning to base, change patrolling ship with troops to advance to downed ship in order to commence ground combat mission.
--[[User:JGF|JGF]] ([[User talk:JGF|talk]]) 07:55, 9 November 2016 (UTC)

== Activity Overflow Bug ==

This is a potentially campaign-ending bug. This was seen in the Steam distribution, DOS version (on Windows 2003 Server EE). Not sure if UFO Extender was being used - probably it was. End of Jan 1999 turn shows an extreme negative/underflow Monthly Rating score, which in turn is caused by extreme overflow of UFO Activity levels. Note that that funding "score" - the increased funding by countries - was very positive at the same time!:

[[File:dissatisfied customers.png]]

UFO Activity, by Areas and by Countries, is literally off the chart. Clearly some kind of integer overflow:

[[File:ufo-areas.png]]
[[File:ufo-countries.png]]

X-Com activity is also off the chart:

[[File:xcom-areas.png]]
[[File:xcom-countries.png]]

In addition to the likely outcome that I will lose the game in Feb 1999, it means I can't use the graphs to detect UFO activity outside of my radar coverage.

I have only seen this bug once, and (probably very unusually) I am running under Windows 2003 Server EE (!!). My hunch would be that's the cause, Windows 2003 Server is not the best games platform. :)

[[User:Spike|Spike]] 07:22, 3 September 2012 (EDT)

Further information:

I don't necessarily lose the game in Feb or March 1999. The Monthly Ratings from Feb onward are just based on the current month, not historical score to-date. However it still greatly increases the risk of suffering from the [[Known_Bugs#Losing_My_Favourite_Game|Losing My Favourite Game]] bug - which also greatly complicates doing too many controlled experiments on this Activity Overflow bug, because a few restores of the saved game quickly leads to X-Com Project termination (and humanity's doom).

Possibly the Activity Overflow bug is caused by an initial value of the score (or an array of score values) not being correctly zeroed at the start of the game. See this graph, which shows a negative score in May 1998, prior to the start of the game in Jan 1999.

[[File:Prehistoric_negative_score.png]]

[[User:Spike|Spike]] 08:48, 3 September 2012 (EDT)

I encountered the same Activity Overflow Bug in Windows 7 using Steam version, Windows option with UFOExtender latest version.

[[User:Humbe|humbe]] 2012.10.04 09:05 UTC

I encountered the same bug at end of january with latest xcomutil patched CE version (with only bug fixes patched) with ufo extender newest version running (close to default options). Got many saves from that first month. Even if loading very early save where I had done no missions yet, and just did stuff in base, graphs still show negative for various periods in 1998. Sounds more like corruption than something actually overflowing to me.

[[User:Archlight|Archlight]] 18:34, 24 September 2012 (EDT)

== Bad Paths Bug ==

I suggest to add bad paths on UFOs maps to the article, as another bug in the game.

[[User:Sherlock|Sherlock]] 09:25, 26 December 2012 (EST)
:That sounds reasonable to me. [[User:Spike|Spike]] 10:03, 26 December 2012 (EST)

==Expenditure Graph==
The economy graph for "Expenditure" neglects funds spent on new facilities. I noticed this in my current (DOS) game when I built eight Psi-Labs at the start of April and it didn't increase. I know it counts everything on the Purchase screen; I'm not yet sure whether it counts manufacturing costs.

Is this enough of a bug to be mentioned? Can anyone confirm whether or not it occurs in CE, and whether it counts manufacturing costs? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 02:40, 17 May 2016 (UTC)

==Workshop Crowding==
It seems there is a bug whereby you can allocate more projects/engineers than available workshop space. This can be triggered by setting up two concurrent manufacturing jobs, setting one of them to have 0 engineers working on it, then set the other to have as many engineers as you can assign to it, filling the workshop space. Then go to the other job with 0 engineers, and it will show a negative workshop space available, now if you assign at least one engineer to this project, you can assign the rest of your engineers however you please.

This is my first edit. I find it hard to believe I'd be the first to find this bug after so many years, can someone please confirm a reproduction and that it isn't documented somewhere I've missed? I am running the DOS version of UFO, but I'm also running XComUtil, not sure if that has an impact, or what patch level I'm on. - [[User:Uncertainty|Uncertainty]] 11:00, 20 Dec 2016 (AEDT) Update: Cannot reproduce on the CE version, still unsure of the patch level of the DOS version I'm running and don't know how to accurately determine that. - [[User:Uncertainty|Uncertainty]] 22:00, 29 Dec 2016 (AEDT)

: An easy way to check is whether you can research Magnetic Navigation after collecting one from an alien sub, or if you have to research a Lobsterman Navigator beforehand. If you can research it right away then you have v2, which is what the CE version is mostly based on. If you can't research it and must get the navigator, then it's the unpatched copy of the game. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 22:24, 29 December 2016 (UTC)

Update 2: Thanks NKF, I'm not running TFTD, but I figured out that I was running v1.2 of XCOM1. I cannot reproduce the bug on v1.4 so the bug only applies to v1.2 and has been patched in newer versions. - [[User:Uncertainty|Uncertainty]] 16:45, 31 Dec 2016 (AEDT)

= Unconfirmed bugs =

== Alien mission succeeds despite Ground Assault ==

Suppose aliens decide to do a mission. So they send a scout UFO. If you shoot it down, the alien mission gets derailed and the next scout becomes delayed, sometimes a little, sometimes a lot. Seems like the headquarters are waiting for the first scout to report back home or something. But eventually the second scout shows up so you shoot it down too. The third one also takes a long while to arrive and if you shoot that down too, the aliens either give up on the mission completely or send their big ships which only aimlessly fly to and fro, never land and leave soon, empty handed. This way or that way, the alien mission is a failure.

On the other hand if you wait for the scout to land, assault it with your Skyranger and win the mission, the alien's mission continues as if nothing happened. The second scout appears on time. So you ground-assault it too but the third and fourth scout also appear on time. Then the larger UFOs show up and land as if nothing happened to the scouts. You ground-assault them too, including the last Battleship that happens. But guess what? The alien mission is a SUCCESS even despite none of the UFOs making it back to base. Really annoying if the mission is an Infiltration, you can't take their juicy big UFOs because if you do, you are going to lose a country. But on the other hand all these Alien Harvests and Alien Abductions? Lots of juicy spoil and tons of points despite the aliens achieving what they wanted.

I need to add that I was playing some weird version of the game whose data was rejected by OpenXCom with "an invalid CHRYS.PCK file, please update to the latest version" message. So I don't know if this bug exists only there or is present in the latest version of the game too or even whether this is a bug or an expected behavior. - [[User:TowigOs|TowigOs]] ([[User talk:TowigOs|talk]]) 00:24, 3 August 2025 (UTC)

== Transfers can put you into debt ==

Any action you can do that consumes money will throw a big fat "NOT ENOUGH MONEY" error if you don't have the prerequisite cash on hand. Except item transfers. You can transfer stuff around merrily even when you are tens of millions in debt and on the brink of collapse from financial mismanagement. Maybe aliens MCed the movers to skip checking for money on your bank account and just hope they will get paid, eventually. Or they might MCed your bank to lend you money behind your back, allowing to go bankrupt reorganizing the content of your bases. At least you don't have to pay interest on these unwanted loans.

Looks like someone forgot to put "if (money<invoice) then {NotEnoughMoney();return;}" somewhere into that code path.

Note: Getting into debt because your base maintenance is much higher than your income and you did not have the cash is perfectly OK. These bills have to be paid. And you will go belly up financially if you allow this to go too deep. ([[User:TowigOs|TowigOs]] ([[User talk:TowigOs|talk]]) 21:55, 4 August 2025 (UTC))

=Cleanup needed=
Hmm this whole Talk page needs a cleanup. A lot of the Not Listed bugs, should be listed, or are listed. [[User:Spike|Spike]] 10:03, 26 December 2012 (EST)

:So, before it will be made, yet three more observations.

:1. There is no possibility to give back (to stop hiring) a plane without craft weapon.

:2. Alien Reproduction is unavailable in a normal game without hacking/save editing. This is probably connected to further errors on maps. A bug/error/programmers' oversight of the some kind is present in TFTD where it is impossible to obtain Examination Room. It is so because many tiles on maps are wrongly assigned to game's objects. Namely, [[Examination Room (TFTD)]] is treated as Alien Implanter - but there is plenty of errors of this type, on various maps (perhaps also in UFO: EU).

:3. Among soldiers in UFO:EU, there are Russians. Some non-Slavs may not know that Slavic (also Russian) family names have different masculine and feminine forms. For example, Petrov, Belov, Likhachev, Gorokhov, Chukarin, Andianov, Voronin, Maleev are all masculine names; women must be called Petrova, Belova, Likhacheva, Gorokhova, Chukarina, Andianova, Voronina, Maleeva respectively (however, a rule that the feminine form is always made by adding -a is wrong, e.g. Tolstoy - Tolstaya). The soldier's name Mikhail Gorokhova (which is possible in UFO: EU) is just ridiculous (for everyone who has even little knowledge about Russian things). Tatyana Petrov is also an impossible combination. X-Com creators probably assumed that family names are the same for men and women in all languages, and, as a result, they made only mechanisms for storing masculine and feminine forms of first names, not family names. But taking reality under consideration, this is a bug.

: [[User:Sherlock|Sherlock]] 16:22, 26 December 2012 (EST)

== Common bugs vs. UFO EU specific bugs ==

I believethere is one more thing that needs to be cleaned. Namely, both EU and TFTD share the same game engine, so some bugs are common for them both. However, there exists a page with a list of TFTD bugs, and it is clear (or: should be clear) which of the bugs are specific for TFTD. I think the same should be done with EU specific bugs: to hold them apart from bugs common for both games. Some bugs exist in both games but manifest themselves differently (like problems with mind-controlling of big aliens) - they are not true common bugs.

Or even more: one could expect a clear information by each bug, in which game and in which version of the game the bug occurs. And whether a patch exists or not. Sometimes such information is given now, and sometimes it is not. And if one does not know exactly which versions are affected by the bug, it should also be mentioned clearly.

[[User:Sherlock|Sherlock]] 04:13, 27 December 2012 (EST)

== Rename page title to indicate which game this refers to? ==

I was looking for a list of bugs related to XCOM Apocalypse, and it took me a while to realize this was about a totally different game. There are 4 games (not counting the 2 opensource projecrs) here on UFOP - maybe that could be reflected in the article aswell?
[[User:Panzerlol|Panzerlol]] 20:35, 31 March 2013 (EDT)

==New "bugs" submitted directly to main page with no apparent explanation==

WakkaDakka, have you actually managed to replicate this "missing time units" bug, or was it just a one-off freak occurrence? I'm not sure it merits main-page space until we have some idea how to replicate it.

N21, how were you seeing the future to begin with? It's only a bug if it occurs in the normal course of play.

[[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 03:36, 28 May 2015 (EDT)

== Enemy Unknown 1994: Save game bug mid mission. ==

Effect : Loading saved game mid mission just displays a black screen with the cursor at the top left, whilst the music continues to play in the background.
I don't believe the game has crashed out to DOS, having tried both CLS and DIR to no avail. Your can no longer interact with the game, making you force quit the app.

[[File:Screen_shot_2016-11-07_at_19.39.31.png|thumb|left]] 

I'm using Boxer 1.40 on a Mac - which in turn is built off Dosbox 0.74.
I remember seeing this bug years ago on Windows XP too, so I don't think it is platform specific.
I'm currently running it with some of the XCOMUtil patches too - but have had the issue crop up without any of the patches.

Playing on Superhuman level, I use a Skyranger with 14 soldiers equipped with Laser Rifles.

Cause : Hard to be specific. But here are the facts.
I have my suspicions it may be do to with fog of war rendering issues.
I've had it occur frequently when going to the NW edge of a map.

I also had issue on Alien base 1. I have a save game and can suggest moving a unit and saving it in another slot - that alone causes the issue. So if someone knows how to debug this I can supply that. Not sure if the combined number of aliens and yourself casue this.. I managed to eventually work thru a series of corrupted saves that wouldn't load to one that worked again).

Here is a sample save game where the game only needs one specific movement to corrupt a game when you save after the move.

[[File:GAME_10.zip]]
I've uploaded two images to show the move for S Bradley
[[File:Screen_shot_2016-11-11_at_13.50.13.png|thumb|left]] 
and the destination square to move him too. When you complete that move and save the game it corrupts.
[[File:Screen_shot_2016-11-11_at_13.50.17.png|thumb|left]] 

Incidentally there were two downed UFO's at this time, with a second Skyranger en-route to UFO 42. This mission was for UFO 43 with another Skyranger.

The problem frequently occurs.
Ive had it occur recently on the following types of mission:
Terror, Alien Base, Supply ship, Large Scout, predominantly with Sectoids and Cyberdiscs, but also with Mutons and Floaters.
The only thing all these missions have had in common was lots of units on both sides. For example 13 Floaters on a Scout mission, 9 Cyberdiscs on a Terror mission etc.

--

Other quirky things I've seen relating to Stunned units:

1) You can't stun a unit, forcing you to shoot it to complete the mission.
The target being stunned drops to the ground in a heap, but the game says you can still see it and can re-stun unit....

2) Celatids. You stun it, then it wakes up and moves away. The unit no longer renders correctly. It's like a sheet of garbled colored/transparent dots.

3) A stunned unit, other than a Celatid wakes up, and is invisible but you get the '1' in red square for visible enemy. You can stun unit and get the animation for it falling to the ground again.

--

Teleported unit off screen (notice the yellow arrow over the unit, which alas is invisible at the split second I took screenshot - OS/X rendering crap-shoot).
[[File:Screen_shot_2016-11-12_at_14.18.07.png|thumb|left]] 
The unit was teleported from the top of the stairs in an entirely different building, rendering the unit unusable for the mission. I ended up reloading it and doing over.... - [[User:JGF|JGF]]

:Stop spamming [[Special:RecentChanges|the changelog]], please - if you're working on a page and want to see the results of your edits midway through, use the Preview button. Don't hit Save until you are ''done''.

:I can't replicate any issues with your provided save. Bradley doesn't have enough TUs to "complete" the requested move, but asking him to make the attempt anyway, then saving / reloading, works fine for me under 1.4 as well as CE. For what it's worth, as far as I'm aware the game in no way keeps track of the number of actions you've performed during a given turn; at least, I haven't been able to find any such counter embedded in the save files.

:I do suggest you leave your units with more time units - when ending turn, any agents who ''might'' spot an alien during the enemy's turn should ideally have some cover, a kneeling stance, and enough action points to defend themselves with a reaction shot. Using your full TU allocation on movement is somewhat suicidal, and even when you can get away with it, it tends to leave agents without enough energy to move when they really need to.

:Your invisible units may be related to [[Known_Bugs#Invisible_Chryssalids|this bug]] - presumably you can trigger similar behaviour by knocking out all instances of a given alien species within a map, saving / reloading, and then waiting for one of the aliens to awake. I was able to replicate it with an Ethereal, for example.

:Difficult to comment on your garbled Celatid without seeing it first-hand. Ditto for your un-stunnable target. I'd quite like to inspect them with my save editor, though, and ditto for the teleported unit. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 05:46, 13 November 2016 (UTC)

Thanks for scaling the images nice to see the wiki syntax.
It's odd to here you say he didn't have enough Time Units left, because for me the move is allowed.
Where did you get your 1.4 patch?
I applied 1.4 too and am wondering if I got a bad version.
Also did you get your original XCOM off GOG or some place like that?
I have the original CD. I think it's the US version as I used to live there.

== Time Units reset to 0 when soldier reaches 255 TUs ==

I have been playing an old version of UFO: Enemy Unknown, where there is no limit on TUs for soldiers. At certain point, two of my best soldiers reached the limit of 255 TUs, which rendered them useless at now they have 0 TUs.
I tried to reduce their TUs by editing Soldier.DAT, but it did not help. If I check soldiers from the base menu, I can see that the value has been changed, but in the battle their stats are still the same and thus they have 0 TUs and cannot be moved with.

Do any of you know, how to fix this bug? Where is the limiter located, can I change it so that is will be as in the new versions? In any case, I believe this bug should be mentioned on the page. It is mentioned here though: http://www.ufopaedia.org/index.php/Time_Units --[[User:Achernar|Achernar]] ([[User talk:Achernar|talk]]) 21:13, 9 May 2017 (UTC)

: Feel free to add the issue - the page is a hodge podge of whatever issues folks have at the time or as they come across them.

: While I'm no expert on the file structure of the executable for the first release of the game, I suspect you'll find the cause for the byte roll-over feature is that there were no stat limiters to begin with. Best way to cope with it is to either retire anyone approaching supersoldier status to base defence duty, buy more soldiers and spread the experience out more evenly, or update to 1.4 and find a sound patch to restore the original sound samples.

: For your broken soldier: I'm, assuming you edited the soldier.dat file. If you saved the game while in the battlescape, the game creates a temporary copy of the soldier stats and keeps them in unitref.dat. This is to keep track of in-battle status changes, experience, etc. You'll need to edit the current TU levels in this file as well. Or beat the mission with the soldiers that can move and you'll see your edits reflected in the next battle. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 05:45, 11 May 2017 (UTC)

== Fire rate bug & German version footsteps ==

These don't seem to be documented for some reason: (DOS Version)

The fire rate always resets to 3 if an alien or an alien mind controlled unit throws a grenade.

If German is chosen as language to play, the footsteps of all soldiers, regardless of the terrain they walk on, will sound as if they are walking on a metal surface like the inside of the Skyranger, UFO or the base. [[User:Bard|Bard]] ([[User talk:Bard|talk]]) 05:38, 8 April 2019 (CEST)

== Direct incendiary hit causing no reaction fire? ==

On the Incendiary page, it is reported that a direct hit will not cause an alien to spin around and return fire. I have tested this in OpenXcom and find that the aliens do, in fact, return fire. If this can be confirmed in original X-Com, it would be good to add to known bugs.

: It's safe to say everything you find on this wiki relating to the classic game pages were gleaned from the original games. OpenXcom, being an independently developed fan project, will have its own list of fixes and changes chronicled in its own documentation. In fact I would not be surprised that good deal of the more technical information on this wiki has been contributed by those that had some input into the OpenXcom project. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 05:16, 8 June 2021 (UTC)

:: Thanks, good to know. Would still love to know if anyone has tested this in classic game. If not, I will when I can, so it can be added to known bugs [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 22:05, 15 June 2021 (UTC)

==Alien weapon loadouts bug/anomaly==
There are actually 10 alien weapon loadout sets, not 9. The actual first set is 70% "early"/20% "mid"/10% "late". This loadout set never appears in-game, though, because the setup at game start counts as a month rollover which means that weapon loadouts (which are called when the mission occurs, not at month start when the mission is scheduled) are called from the second set during January, the third set during February, and so on. This is probably an oversight by the Gollops (note that race weights reach their final values in October; were it not for this quirk, weapon loadouts also would), but it's hard to be sure. Should this be added? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 15:02, 28 April 2025 (UTC)

Talk:Known Bugs

2025-08-04T21:55:21Z

TowigOs: Transfers can put you into debt bug

= Classification etc =

== Bugs vs Exploits ==

Could someone comment please on the distinction between a bug and an exploit, and where to put each one? I would guess that a bug is something that undesirable and an exploit "might be" desirable, if you want to cheat. But what about exploits that happen by accident, or bugs that need to be forced to happen?

I was going to add the Research Rollover bug to the Exploits sections, but they seem to all be under construction. What's the agreed approach?

[[User:Spike|Spike]] 04:16, 15 March 2008 (PDT)

* i think that an exploit is somthing you can trigger and gain an advantage from. a bug may or may not have a known trigger, and does not give an advantage if it does.
: All exploits are bugs, either in implementation or design. When using a bug to gain advantages that bug is used as an exploit (you are exploiting the bug). [[User:FrederikHertzum|FrederikHertzum]] 13:39, 10 May 2011 (EDT)

:: IMHO, Laser Pistols Gifts to train reactions is an exploit, but it does not involve any bugs. It merely exploits the fact that laser pistols will not penetrate the front armor of Flying Suits. [[User:Jasonred|Jasonred]] 16:31, 10 May 2011 (EDT)

::: I guess the point is to differentiate if it's a bug that's being exploited to your advantage, or it it's something confined within the game mechanics that you are exploiting to your advantage (even if using it as intended). -[[User:NKF|NKF]] 02:31, 11 May 2011 (EDT)

:::: Another definition: An exploit is
::::: a) a move allowed by game interface
::::: b) that sidesteps another part of the game mechanics
::::: c) and creates inadequate advantage for the moving player in the process.
::::: An exploit is not a bug, but it can be connected with a bug, if the latter allows a move mentioned in a). Most obvious exploits render whole parts of game mechanics obsolete (see b) above), because they are always more advantageous. In games that feature equal terms for AI and the player, an exploit can be discerned simply by the fact that AI does not use it (sadly this is not true in X-COM). Clear exploit in X-COM: Transfer soldiers = no monthly payment. Suspect exploits: grenade layout. Most probably not an exploit: Sniping (although the inequality with AI is suspect). Clearly not an exploit: dropping weapons to prevent Psi mass murder (this one is made exploitable by the AI unable to pick up weapons, but is not an exploit per se).--[[User:Kyrub|kyrub]] 05:30, 11 May 2011 (EDT)

The dropping weapons sort of turns into an exploit if you do the "everyone suspect of being a psi weakling drops their weapons at the end of the turn. They all pick up their weapons again if unpsied in the next turn." The grenade layout or grenade hot potato is probably not what the game designers had in mind, but I shudder at the thought of someone who only played X-com then joined the army pulling the pin out of his grenade and then dropping it into his haversack or slinging it on his belt. [[User:Jasonred|Jasonred]] 07:43, 11 May 2011 (EDT)

: Yeah, I think we agreed somewhere that shoving live grenades in your pockets and not having them go off is madness. The relay however is not sensible but certainly possible if only a very short one (if with a live grenade), or to toss a grenade forward and prime it at the second to last person. Or more reasonably, something like a stick of dynamite with an extra long fuse. Even that's very dangerous.

: By the way, what does everyone here think of using the mind probe to check if it's safe to attack an alien while standing in full view of it, or if you're right up next to it? I've been using it a lot lately (in lieu of the psi amp), so you could say I've been exploiting the mind probe to my advantage to help me with my decision making. But is that counted as a cheat since I'm picking my moments to attack up close when the enemy cannot return fire? -[[User:NKF|NKF]] 03:30, 12 May 2011 (EDT)

:: When identifying a mechanic as an "unfair exploit" (as opposed to just a "tactic"), perhaps a simpler checklist is this (though Kyrub's is spot-on):

:: a) Is this something the developers should've expected players to do?
:: b) Is this something the developers could've easily prevented?

:: If the answer to both is "yes", then it seems fair game to me. For eg, sniping at aliens: The game KNOWS whether the soldier can see the target (you get a flashing indicator if so), and so it would've been trivial to prevent it. Is it something the regular gamer will try? Certainly; therefore it can be considered expected behaviour. Ditto for using the Mind Probe to make attacks without fear of reaction fire; those things aren't cheap, they sell for a bunch, so it stands to reason that they'd have tactical value!

:: Things like the transfer bug are clear exploits. The devs would've implemented that system so that, if you order personal near the end of the month, you don't end up paying for them twice before they ever arrive - but in the process, they forgot that "purchase" transfers are treated in the same way as "between-base" transfers. To fix one scenario without breaking the other, they'd've needed to code in some extra stuff so the game could tell the difference - they probably just figured the regular gamer would never notice, assuming they ever realised the problem existed.

:: The "dropping weapons" thing is a little trickier to work out - yes, the devs should've seen it coming, but would it've been easy to fix? Aliens could've been twigged to either ignore un-armed soldiers... but those soldiers could re-equip next turn. Aliens could also've been twigged to attack randomly... but that would make their psi powers far LESS effective! I suppose the fix, if any, would've been unarmed melee attacks, but the implementation they went with seems to be the next best thing IMO.

:: In regards to the "grenades in inventory" thing, it's probably common knowledge by now, but they DO go off in the alpha of the game. Presumably someone made a conscious decision to change that, though it could still just be an accidental bug. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:02, 12 May 2011 (EDT)

Sniping at aliens is a very bizarre case, since almost all players will fall prey to the aliens sniping at you long before they snipe the aliens. The behaviour of the aliens to step within sight radius, take one step back, then fire without fear of retaliation *looks* and *feels* like clear exploitation of the rules, but the computer can't be a cheater, can it? So we humans carry that one step further. Mind you, I think X-com would be in trouble if the aliens could snipe you from across the map once they know your positions... especially since the aliens have cheating "if I spot 1 human, I spot ALL of them" abilities. Especially on maps where the aliens get Blaster Bombs...

An interesting note about sniping and LOS: When I first played Xcom, my first mission was in the jungle. Because of all those plants, when my first soldiers spotted an alien, after he shot at him, I tried to make my 2nd soldier open fire and was informed "NO Line of Fire". I could only get my 2nd soldier to fire by positioning him in such a way that I got the flashing number. Henceforth, I assumed that you could ONLY fire at the aliens when the flashing number was there. LOL. LOF. LOS.

Transfer bug wise, I thought that the devs merely programmed the game to count how many staff were currently in the base, then deduct that from Xcom coffers? As far as ordering personnel near month end goes, you end up paying salary for them if you order them more than 48 hours from month end, right? "realistically", they should make staff draw salaries based on when they were hired, but this would be too much effort.

"dropping weapons" would have been easy enough to fix... just teach alien AI how to pick up weapons. Like they did in Apocalypse.

As far as grenade relays go, if you ever join the army, and you toss a live grenade at your squadmate, you're gonna be court martialled! lol. Xcom grenades are weird cause they presumably come with a computer console where you program them or something that takes a lot of TU, if I already have a grenade in my hand I don't think it takes long to prime it compared to throwing it...

Pretty clear exploit/bug is tossing grenades through the ceiling? That breaks all laws of realism/logic/whatever, and I'm sure the devs didn't plan for THAT to happen! [[User:Jasonred|Jasonred]] 18:18, 12 May 2011 (EDT)

: Turns out the "spot one, spot all" thing was wrong all these years. However, units can be "spotted" by sniping an alien, hitting it, but failing to outright kill it; this may have contributed to the misconception.

: The game considers the base to have the correct amount of personal as soon as you initiate a transfer - if a base has room for ten people, you can't send two groups of ten, as soon as the first is in transit the game will correctly recognise that the destination is now filled up and won't allow you to send any more. Likewise, if you hire soldiers, they'll count towards the allowance of more promotions in your ranks before they ever arrive at a base. That is to say, the payment system deals with personal counts in a different way to every other system in the game, making it look like it's intentional (if badly exploitable) behaviour. In terms of transit times, those seem to vary, I know a purchase of scientists takes 72 hours to arrive.

: Er, yes, getting aliens to pick up weapons would've indeed fixed the dropping thing. Shoulda thought of that...

: The grenade thing is indeed unrealistic however you look at it. Certainly throwing the things through ceilings is a bug, and its use is a large exploit. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 20:02, 12 May 2011 (EDT)

:: Then how do the aliens "spot" the psi weakling to target him for psi attacks? Doesn't the game ALWAYS start blasting the juiciest target, regardless of LOS? Or is it just coincidence? [[User:Jasonred|Jasonred]] 22:22, 12 May 2011 (EDT)

::: They really have to "[[UNITPOS.DAT#8|spot]]" the target before they can blast them (however, it appears that later in a campaign this rule gets broken). If they've only spotted a psi-''resistant'' trooper, they typically won't bother to make attacks at all. There's a lot of relevant information in [http://www.strategycore.co.uk/forums/Can-alien-attempt-Mind-control-Pani-t8115.html this thread]. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 23:28, 12 May 2011 (EDT)

: Your talking about your post on http://www.strategycore.co.uk/forums/Can-alien-attempt-Mind-control-Pani-t8115.html&pid=96123&mode=threaded#entry96123 ? Well, I'd just like to point out a massive flaw in your testing logic. You forgot that aliens will launch psi attacks based on chance of success, and chance of success varies based on distance from aliens. In other words, it could easily be that the aliens only attempted psi when your soldier was within sight of them because your soldier was now NEAR to them and therefore they had a strong chance of success.

: Also, as you have noted, it appears that your rule gets broken. In fact, it is not uncommon at all for the Ethereal Commander who is boxed up in the Command Center to launch psi attacks on victims who are separated from him by several layers of walls, as long as their proximity to him is near enough. [[User:Jasonred|Jasonred]] 21:19, 13 May 2011 (EDT)

:: Those are valid points. I've hence built a somewhat more robust testing scenario, which you may wish to [[:Image:Alien Psi Demonstration 1.rar|try for yourself]].

:: The save game consists of cloned Ethereal soldiers (all cranked up to 100 psi strength/skill), and many clones of a single trooper (most of whom have the same psi values). The Ethereals are all cooped up in a sealed room in the SW of the map, with a single trooper who has 140 psi strength/skill.

:: Directly outside the building is another trooper who only has 1 strength/skill. In the NE of the map, in another sealed room, is a soldier with 40 strength/skill. Before placing him there, I had him shoot one of the Ethereals just once, resetting index 8 of his UnitPos record to 0. Only he and the trooper inside the room with the Ethereals have hence been "exposed" to the aliens, but the "best chance of success" is obviously the psi-weakling directly outside the building.

:: If you load the map and end turn, the aliens will first attempt to take control of the dude on the other side of the map, then get to work on the guy in the room with them. Once they've taken these two, they'll completely ignore all other units.

:: In short, aliens can't use psi attacks on a unit UNLESS their UnitPos[8] index is set to less then that of the alien's intelligence stat. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 05:41, 14 May 2011 (EDT)

::: Good one. That test definitely proves a lot, rather conclusively. [[User:Jasonred|Jasonred]] 06:53, 14 May 2011 (EDT)

== Bugs vs Limits ==

''(Discussion continued from [[Talk:Known Bugs#Soldier Recruiting Bugs Tested|Soldier Recruiting Bugs Tested]])''

The "Soldier Recruiting Limit" is not a bug, it is a limitation of the game. Therefore, this should be removed from the page. If we want it somewhere else (like a new page such as [[Game Limitations]]), that would be appropriate. --[[User:Zombie|Zombie]] 01:42, 9 November 2008 (CST)

::Not sure that's necessarily the best idea, Zombie, since many of the entries on the Known Bugs article(as well as some entries on the Exploits pages) are limitations of the game engine. On just a brief glance through, the following caught my eye as engine limitations: Manufacturing limit, Storage limit, Purchase limit, 80-item limit, Proximity Grenade limit, Large units not waking up from stun, Interception last shot bug, Alien UFL radar blitz-through bug(Passing through the detection range of a radar before the detection check comes up), Free manufacturing, free wages, UFO Redux, point-scoring with Ctrl-C, permanent MC of chryssalids, Zombie-MC resurrection of agents, alien inventory exploits, anything involved with bad collision detection, extinguishing fire with a Smoke Grenade, and even your personal favorite, denying the aliens access to their own spawn points. So in conclusion, maybe it should just be left as it is; conversely, all of these entries could be kept where they are and also on a Game Limitations page, or we could leave the headers there and link them over to the appropriate topics on Game Limitations. What do you think? [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:21, 9 November 2008 (CST)

: I agree with AQ (great list of examples by the way - and the Smoke/Fire limit would be another). Many, if not most, of the bugs are "Limitations" but they are logically inconsistent and not what a player would expect to happen: they are imposed by (at best) memory limitations or (at worst) design/programming oversights. I think the easiest thing to do would be to change the title of the page to Known Bugs and Limitations, or put an explanatory note at the beginning of the section to explain that "Bugs" is taken to included "Limitations". [[User:Spike|Spike]] 13:16, 9 November 2008 (CST)

By the strictest sense of meaning, a "bug" is a mistake or error on the programmers part. Limitations imposed by design or memory are not the same creature as the people involved were consciously aware of the decision. I suppose that to the normal player, any type of behavior which is unexpected/unwanted is automatically dumped in the bug category because to them there is no difference. To those of us who study the game files however, the two are unequivalent. Programming oversights, yes, those are bugs.

Some of those limitations AQ mentions are (to me at least) bugs: free manufacturing, free wages, permanent MC of Cryssies (or actually any alien for that matter), Zombie resurrections and collision detection. Large aliens not waking up from stun is again, a bug. The programmers obviously had some issues when dealing with large units in general and never quite got it right. They made some progress in TFTD by trying to fix mind controlling each section of a large unit, but royally screwed it up by selecting the next 3 entries in UNITPOS.DAT no matter what they pointed to.

Perhaps it's just my background in logic which makes me want to push for a separate category for limitations. Then again, as long as everything is listed somewhere I'm happy. --[[User:Zombie|Zombie]] 22:06, 9 November 2008 (CST)

: Actually, taking a look through the page as a whole there are various other Limits described, and the distinction between Bugs and Limits is made quite rigorously throughout - not just in the Soldier Limits and Bugs section, where the Soldier Recruiting Limit is referred to as a Limit whereas other bugs (such as paying salaries for soldiers you can't recruit) are referred to as Bugs. So we maybe just need to rename the pages "Bugs and Limits" and add an explanatory note on the distinction. From a user point of view, rather than a programmer point of view, a bug is an unexpected (inconsistent or illogical) behaviour, so for that reason I think it makes sense to keep them on the same page but try to ensure they are all correctly classified as Bug or Limit.

: By the way, it could be hard to absolutely distinguish Bugs from Limits as I suspect there are going to be some grey areas where you would have to second-guess the intentions and decisions of the coders to know for sure if something was a designed-in Limit, or just an oversight (Bug). [[User:Spike|Spike]] 06:50, 10 November 2008 (CST)

::If we distinguish in this manner, I suggest the definition of "Limit" should be, "Something imposed by the game files or engine as a limitation, most likely in context to the capabilites of the then-current personal computer." More succinctly, anything that was done to allow the game to run acceptably on what was then a PC. This would include both the Soldier and 80-Item limits, the spawn limit(40 units per side), Smoke/Fire limit, and some of the others listed. (The Purchase limit was probably more of a convienence for the programmers than anything, but it is clearly an intended feature.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:11, 10 November 2008 (CST)

: I would add to this that sometimes a Limit may be imposed as a game design / gameplay decision, rather than in order to conserve a constrained resource in the platform (=PC). Also, I would suggest that ''intended'' Limits are Limits, but ''unintended'' consequences of Limits are Bugs. Obviously, making this distinction involves some guesswork. But I would guess that while the limit on total smoke/fire hexes was an intended Limit (to conserve PC resources), the ability to put out fires with smoke grenades and disperse smoke with IC rounds is probably an unintended consequence of the Limit, and so should probably be considered a Bug. Similarly, Base Defence spawn points are probably an intended limit, but the ability to flood spawn points is an unintended consequence of this, and thus a Bug (and an Exploit). (Spawn points should have been shared out 50/50, not humans-first). [[User:Spike|Spike]] 12:07, 11 November 2008 (CST)

::The limit on Soldier and Interception craft were probably more of a limit imposed because they capped the file and figured that X-COM wouldn't ever need more than 40 interception craft or 250 soldiers. (And I've never needed that many, case in point.)

::As for spawns, its actually difficult to take advantage of it in any reasonably established base. X-COM can spawn up to 40 soldiers in a base defense mission(tanks count as 4 soldiers), as a limit of LOC.DAT. Aliens have the same limit. So in order to take advantage of the bug, the base needs 40 or less spawns total. The Access Lift has 8 spawn points, General Stores(weapon-handling) has 11, Living Quarters has 8 more. This is 27 Spawns just getting soldiers in a base and armed. (Although the General Stores can be cut out if you perform the bug properly). Large Radar and HWD have 6 spawns(Small Radar has 2), and Hangar has 15. So overall, the "Spawn prevention" can be hard to take advantage of with all but the smallest bases. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:48, 11 November 2008 (CST)

Just to clarify, X-COM interception craft are not capped at 40 ships. LOC.DAT has a cap of 50 "things" on the geoscape screen at a time. This is shared between X-COM bases, X-COM ships, alien bases, seen or unseen UFO's, terror sites, crash sites, landing sites and waypoints. In a perfect game world with little alien activity and normally constructed bases, the max number of X-COM craft possible is 44: 5 bases with 8 hangars each plus one base with 4 hangars (or any combination thereof). If you illegally modify your base layout with an editor to get rid of the access lift, the max can be increased to 45 ships (9 hangars in 5 bases). Once clogged, all alien activity will cease.

The base defense limit of 40 units exists because of UNITPOS.DAT which has a cap of 80 entries total (tanks occupy 4 entries in this file). Auto-win missions in a base defense mission by clogging all the spawn points with X-COM units isn't as tough as it sounds, especially if your base is small or doesn't contain hangars. The main thing is getting your full quota of 40 units to spawn (meaning you should try not to have any tanks as they count as 4 units but only occupy one spawn point). This limits the base size to something like 5-6 modules depending on what you build. Still, even having more than 6 modules isn't bad as it forces aliens to spawn intermingled between your troops. With 40 armed guys staring in every direction, you can get positions of all the aliens in the first round and possibly even kill them all (depends on weapons and alien race of course). --[[User:Zombie|Zombie]] 20:12, 11 November 2008 (CST)

: I would say that Limits are the CAUSE of bugs... also, I feel that fire/smoke limit can be called a bug, because a player normally has no way to tell this, other than observation. Whereas the game DIRECTLY and CLEARLY informs you whenever you hit the 80 item or 250 soldier limits, which is more fair. [[User:Jasonred|Jasonred]] 15:22, 23 March 2009 (EDT)

Also IMHO it is not true that, say, 250-soldiers limit is a real game bug. In fact, it is not, it is just a rule of the game, or its limitation. And it is unimportant what its reason is (such or another way to store game data).

A bug is, by definition, an unexpected and involuntary result of programmers' work. However, we can only guess what the programmers wanted to attain, so this definition is both unpractical and impossible to be applied. It would be better to assume that a bug is a feature which has negative influence in the game. To clarify: the (un)famous 250-soldiers limitation does not harm in practice, as the number is really enough to play the game. But the even-more-unfamous 80-item limitation does harm and it has negative consequences - it is enough to recall the disappearing of bodies during some missions.

OK, there is no objective criteria to judge whether a feature of the game is a bug or just a limitation. But sometimes subjective criteria have to be enough. Otherwise, we would have to consider the 8-bases limit a bug. Does it make any sense? And if no, what is the difference between the 8-bases limit and the 250-soldiers limit? I feel neither is a bug. Because neither leads to further negative consequences.

And further, IMHO the buggy nature of some game features is quite obvious. If you cannot send more than 100 "parcels" of items at the same time, it is still not the bug. But if you must pay for an item you are trying to send but you cannot do it - it is a bug, perhaps everybody will agree. And similarly: the 255-scientists limitation is not a bug. But the strange behaviour of the game when you bought the 256th scientist is a bug. It would be just a limitation if the game did not allow to buy another scientist. But it allows while it cannot serve the 256th scientist properly, and that is why it is a bug.

So, I vote for removing the 250-soldiers limit from the bug list. If I am wrong in it, please add to the list also:
# 8-bases limit,
# maps with limited terrain (why should they be limited?),
# base area and base facilities limit (why wouldn't we be able to have 10 hangars in a base?),
# etc.

In yet other words, in my opinion it is not enough to show that the game does not allow to have more certain items or to do more certain actions. In order to count this among bugs, we should show that it really harms during playing the game, or just bears negative consequences.

[[User:Sherlock|Sherlock]] 03:52, 27 December 2012 (EST)

= Specific Bug Discussions =

== Misc Technical Bug ? ==

''(The context of this discussion seems to have been lost)''

This is a technical bug that doesn't happen to everyone and one this article wasn't really meant to chronical - but we won't turn away helping a fellow player if it can't be helped. It's just that there are so many random crash points in this game that it would take far too long to find them all or come up with solutions for them.

Certainly, the transfer crash can happen to some players, but it's not one that can be reproduced easily. It's just like the random crash that some players get when they research a floater medic. It crashes the game for some of us, but others don't seem to notice it at all.

It really depends on your hardware and OS setup, whether or not your copy of the game is damaged or your savegame is damaged, etc.

Does it happen in all games or just this one savegame?

- [[User:NKF|NKF]]

-----

== "Invisible Muton" bug ==

Upon shooting repeatedly a Muton, it sometimes plays its "death" animation without sound (as if falling unconscious) and it is no longer displayed in the screen, while remaining visible to my soldiers (I can center the screen and the cursor appears yellow over them). Under this state, they cannot be targeted by Stun Rods. They may play their death animation anytime they get shot, until they truly die, when they emit their characteristic sound and leave a corpse (along with any items carried).

I'm quite fond of laser weapons, maybe this happens more often with those.

Also, though I remember experiencing this quite often fighting Mutons, it may happen to any other high health race.--[[User:Trotsky|Trotsky]] 02:59, 2 July 2006 (PDT)

-----

Never seen that one myself. Another "unpatched game" thing maybe?

There's a (very rare) bug that allows your soldiers to live if they become stunned by an explosion that happens to kill them. Sometimes the game will register their death, and THEN register that they've been stunned. In every case I've seen this happen, however, the unit will have such a low amount of health that a single fatal wound will render it dead (again) on the next turn. I have a vague memory that other players may have been able to get a medkit to the scene on time...

I dunno if that's related to your issue at all (I doubt it, but... meh). I'd advise using a Mind Probe on the alien the next time it happens so you can check the aliens stun/health levels.

- [[User:Bomb_Bloke|Bomb Bloke]]

----

I'm pretty sure I've seen this with Mutons. Possibly Chrysallids as well, another high health, high armor creature. They were still readily killed by shooting the place they are. Good thought on the MP, BB

---[[User:MikeTheRed|MikeTheRed]] 08:51, 2 July 2006 (PDT)

----

I've been known to have a dying muton(in fire) to spin around and then switch to the female civilian death animation. With the scream and everything. Even got a civilian death registered at the end of the mission. And this didn't just happen once, but on another separate occasion.

Hmm. shape-shifting reptilians in the game! LOL! Happens alot [[User:EsTeR|EsTeR]]

Unusually enough, I once had a sectopod die and then drop a tank corpse. I was using the Lightning at the time for my troop carrier, so you can imagine my surprise.

Then there was one occasion where a floater dropped a snakeman corpse. Let's not even get into the sort of things the aliens like to stuff themselves with.

Your invisible alien bug is quite common, although there appears to be many causes for it. I think one involves a full object table when it comes to invisible aliens in bases. But it can also happen in ordinary missions as well. I'm guessing the game may have tried to do something in the wrong order, and sprite information for the unit may have been lost or corrupted along the way.

Having had an experience where all the chryssalids become invisible in one base defence mission was quite a shocker. I fixed this by saving the game, quitting and then restarting the game. If you ever get an invisible alien again, try this and see if it helps. If it doesn't, well, just keep a careful watch on your map and any alerts that pop up as you play.

There's a similar but less severe bug where a dead alien will still leave its centre-on-unit alert button, but this goes away shortly after you move or turn.

- [[User:NKF|NKF]]

----

That last bug happens when exploding Cyberdiscs kill nearby Sectoids, doesn't it?--[[User:Trotsky|Trotsky]] 23:56, 2 July 2006 (PDT)

----

This is a pretty easy one. I guess this bug occured on UFO recovery on a battleship, an alien base assault or a base defense mission? As soon as there are too many items on the map, the game saves some item slots for the equipment to be displayed (since it is more valuable and more important to research). This would also make stun weapons lethal if the stunned aliens would vanish. therefore the game has a failsafe if an alien is stunned (or badly wounded and becoming uncontious). The downed alien's stun level is set exactly on its left health points therefore resurrecting it instantly. This cycle is broken when the alien is finally killed. This means if you want to stun an alien in such a situation you have to destroy some items first.

- by tequilachef (April 4th 2007)

== Vanishing snakemen ==

I've known snakemen to become invisible when standing on a hay bale. On the first occassion I had a poor tank getting shot while spending numerous turns looking for it. On the second occasion I had an alien under Psi-control, left it on the hay bale, and couldn't find it next turn. - Egor

---

This is not limited to snakemen. Hay bale block visibility quite much when a unit is standing on it. Two possible solutions:
- Destroy the hay before entering
- Shoot at the hay. If it is destroyed any unit on it will become visible (as long as no other bales are blocking the line of sight). You might also hit the enemy directly.

I Dnt know if the aliens are affected by this diminished sight, too. My guess would be no.

- By tequilachef (April 4th, 2007)

== Blaster Bomb Bug ==

I'm currently playing through X-com UFO Defense, I have the collectors edition version. I'm in the process of trying to catch a live alien commander and the blaster bomb bug is making this very difficult. If i remember correctly a commander is always in the command center of the the alien bases. The problem is anytime i get close there is always a dude with a blaster launcher up there that tries to kill my troops. When they try to fire it down at me the bug kicks in and they blow up the whole command room and all the aliens in it because they can't figure out how to get the blaster bomb down the grav lift thing in there. This is making it very dificult to actually catch a live commander. Anyone have any ideas for tactics or anything to breach that room without the aliens trying to fire a blaster launcher up there? - eL Hector

: I can suggest two possible solutions. The first is to wait outside the command room for the alien to move closer to you. If it comes out of the room or if you know it has moved down the lift, you then burst in and stand right next to it to stop it from firing the blaster. This is risky because there could very well be a heavy plasma toting alien in there. The other is to use a small launcher and launch it up at the ceiling near where you think the alien with the blaster is standing. -[[User:NKF|NKF]]

== Disappearing Ammunition ==

I have observed that problem with X-COM 1.2, modded with XCOMUTIL. My stun bombs and heavy rocket missiles, along with clips for the auto cannon went missing.
[[User:Vagabond|Vagabond]]

------

Just run a test using my 1.4 DOS version with XComUtil but my stun bombs didn't disappear: 30 + 1 back in the base they came from, same number after I went tactical and I dusted-off immediately. Are you running XComUtil with Runxcom.bat or did you simply run Xcusetup?

[[User:Hobbes|Hobbes]] 22:12, 22 February 2007 (PST)

:Is it a case of hitting the 80-item limit?--[[User:Ethereal Cereal|Ethereal Cereal]] 12:28, 23 February 2007 (PST)

------
With runxcomw.bat, as everytime. Apologies, I retested and it seems like I was mistakened, but I could have sworn that I lost them dang stunbombs. Had to manufacture some. I will test some more, using four heavy weapons and seeing whether their ammunition disappears at all. Thanks. [[User:Vagabond|Vagabond]]

==MC at end = MIA?==

I am sure I have seen this again recently, where I won a mission with no casualties (I thought), but the last thing I killed was a Commander that had been chain MC'ing a psi-attack-magnet trooper, and that trooper was listed as MIA at the end (presumably because he was on the enemy side at the end of combat). Is this a bug, or is there another way to get MIA's on a completed mission that I might have missed?

Since then I have been waiting for the leaders to panic at the end before killing them (or waiting for a rare resist), so I can safely exit, but am I being overcautious?

--[[User:Sfnhltb|Sfnhltb]] 13:45, 27 February 2007 (PST)

If the trooper was mind controlled on the turn you killed the last alien it will be listed as MIA. No bug there :)

[[User:Hobbes|Hobbes]] 18:16, 1 March 2007 (PST)

Huh, why would that happen - your soldier should recover the very next round, why would he go MIA?

--[[User:Sfnhltb|Sfnhltb]] 18:20, 1 March 2007 (PST)

Doesn't make sense to me as well but that's how the game works.

[[User:Hobbes|Hobbes]] 15:05, 2 March 2007 (PST)

----

It seems that regaining control of units under enemy mind control works different for alien and human players. My guess: aliens under human MC are reverted to alien control AFTER THE ALIEN AND BEFORE THE HUMAN TURN while human units under alien control are reverted RIGHT AT THE BEGINNING OF THE HUMAN TURN. This explains three different phenomenons:

- The discussed MIA "bug" (he unit would be returned in the next human turn, but since it never starts it is lost. The mission is still won since no unit with a "genuine alien" marking is left)

- The fact that a mission is lost when the last human falls under MC while it is not won when this happens to the last standing alien (the aliens get their unit back before their turn starts and therefore have a unit left to pass the "anyone alive?" check, the humans would have no unit left to start a turn with. They WOULD have as soon as the turn starts, but no unit left before turn means bust)

- The fact that aliens still can see all an MCed human saw at the end of the human turn that follows the MC while this is not vice versa (The MCed human can give information to the alien side before reverted while an MCed alien is reverted too early). The result is that aliens can control a human indefinitely without having any alien seeing him until the MC is disrupted for one turn.

All confused? Then I did a good job! No seriously, this must be the explanation, I couldn't think of any other way.

- By tequilachef (April 4th, 2007)

: You're absolutely correct on the first two points. It's a sequence issue - you never get round to recovering the unit before the new turn starts, so you end without any units whatsoever. Makes senses too since the aliens would continue to continue to mind control that same unit over and over indefinitely.

: The third point however: The aliens don't need to know the location of the last MC'd unit. They know the location of all your troops whether they've seen them or not from the very start. They appear to give you a few turns of grace where they won't attack you outright (unless, from my observation, all your soldiers are incredibly weak). This is evident because all of the aliens will eventually make their way towards the nearest soldier even though their movement pattern may seem semi-random. Also, they know where you are because they can initiate psionic attacks without having seen any of your troops. They generally go after the weakest troops first.

: Just to add a semi-related point, but from the alien's perspective. If an MC'd alien unit is in the exits when you abort the mission, this alien is not recovered and in fact simply vanishes. Any equipment it was carrying is recovered, unknown artefacts or otherwise. You could possibly think of this as their version of MIA. However, the aliens differ ever so slightly in that if it's the last alien standing and under temporary mind control by the player, the mission doesn't end straight away. But I guess this is only because the player has everything under control, whereas in the other scenario, the Ai is in control.

: -[[User:NKF|NKF]]

My observations show that, at least in some versions of the game (tested with clean DOS 1.4 version, under DOSBox), the game crashes at the end of the human turn if all alien units which are still alive, are Mind-Controlled. If it was confirmed, it would be another not-listed-yet (serious) bug.

[[User:Sherlock|Sherlock]] 17:52, 26 December 2012 (EST)

== Crash Site in the atlantic ocean ==

That's right, my game generated a crash site on water. Here are the details:

- Crash Site a bit southeast of the USA (which was infiltrated a few days before by sectoids, resulting base had already been taken out), but certainly not on land.

- UFO: battleship, floater, alien harvest

- Geoscape: 8 X-Com Bases, 1 (known) Alien base, 2 other crash sites, 1 other (known) flying UFO (though almost worldwide decoder coverage), 3 X-Com Crafts out, 1 waypoint

- Date: January 2000

- Most Interesting: The Craft that downed the ship was a recently finished Firestorm (first human-alien hybrid craft I had built, I know this is lame for that date. Limited myself on 25 Scientists to improve the challenge) equipped with twin plasma. I had it built and equipped in Antarctica and then transferred to Europe. This base had no Elerium, a fact that enabled me to use the infinite fuel exploit which was in effect when downing the UFO. My craft was only slightly damaged when doing so. The battleship was the first target assigned to the craft, it came directly from my base.

- When shot down, the UFO was not targetted by any other craft.

- I had not lost or sold a single craft to that point.

- When sending a squad to the crash site the game didn't crash but generated a farm land ground combat terrain.

- I was not able to reproduce the bug from the savegame dated 2 hours before downing the UFO

Well guys, any intelligent guesses? I still have the savegames (before and after downing)! If you want to have a look, write here.

- By tequilachef (April 5th 2007)
----
: Well I'm sure you know about crash sites that are near land can sometimes actually be on water, so I'm going to assume that this site is well far away from any land mass. Could it be a weird entry in GEODATA\WORLD.DAT that has a land mass out in the ocean? Also are you sure the game didn't crash? Sometimes when it does it will load the previous mission (and usually 90% are at farm terrain). Are you sure it generated a new map and not load the last one?
:No real guesses but maybe some starting points to look at. I've probably stated some obvious situations you know about and have accounted for, but it never hurts to double check :D
- [[User:Pi Masta|Pi Masta]] 14:23, 5 April 2007 (PDT)

== Inconsistencies in MCing Cyberdiscs and Sectopods ==

I experienced, that when MCing one quadrant of a large terror unit any action it does only affects this quadrant (especially use of time units). That means, when TUs are up for one part, MC another one and continue firing. This however does not work out when moving the unit while it is not under complete control. The TUs used up by the resulting reaction fire from the rest of the unit is also deducted from the TUs "your" part has left (making it impossible for the controlled parts to return fire). This however only happens under reaction fire, not if "your" part fires on it's own. I don't know if this comes up when uncontrolled parts shoot by themselves in the alien turn, since this is hard to find out.

: That's because large units literally are made up of four separate units. They only share the same set of general stats (in unitref.dat). Unfortunately the 'under mind control flag' is unique to the four units, not the shared stats! So you in effect have multiple units under different control sharing the same stats. So if you move and it results in a reaction from the unit, it will spend the TUs you're using.
: Successful mind control automatically fills up the unit's TUs, so each mind controlled sector gets to move or attack again until there are no more sectors to mind control. Useful way of turning reapers into long range scouts!
: In TFTD, they attempted to fix this bug, but in fact made it much-much worse! The only way to mind control the unit properly is to control the upper left quadrant. Only! Any other quadrant will result in a partial (clockwise) control, and you may gain control of units other than that unit, or may even get into situations where you gain permanent 'partial control' of a large unit you haven't even sited. Wackiness all around!

:- [[User:NKF|NKF]]

== Facility Dismantle Bug ==

Boba: I've never experienced this bug myself in all my games in the Collectors Edition. It may very well vary from computer to computer.

-[[User:NKF|NKF]]
:I, however, have experienced it. I lost an entire month's worth of playtime because I couldn't solve it. [[User:Arrow Quivershaft|Arrow Quivershaft]]

::Anyone, any ideas on why it might vary from PC to PC? -[[User:MikeTheRed|MikeTheRed]]

:::I'd check other factors before blaming a given system. Assuming no mods are being used the most obvious is the order in which you initiated the construction of the modules. Then we've got which one was due to be completed first, and I'm sure there's a few other things to test out. Usually, a player won't cancel in-progress modules on a regular basis, so you wouldn't expect this bug to turn up often. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

:Easy way to reproduce: build 2 General Stores. Now delete the "second one" (see offset 16-39 in [[BASE.DAT]] for the order). Wait for the first one to complete. It'll crash immediately after the "end of construction" dialog. A fix is available [[User:Seb76#Bug_Fixes | here]]. [[User:Seb76|Seb76]] 15:52, 22 July 2008 (PDT)

== Manufacturing Limit Bug ==

Unfortunately, Mike, no you did not get it correct. It is the raw number of hours needed to complete the project, not the projected hours. I discussed this on the X-Com Forums a few months back at the following link: http://www.xcomufo.com/forums/index.php?showtopic=242027760&st=0&#entry164411

I did tests at the time in regard to the accuracy of the data given there, but I've lost the results. I'll quickly redo the tests in the next hour or so. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:00, 8 June 2007 (PDT)

:Tests complete. The breakpoints for every item were exactly where I predicted, regardless of number of engineers assigned. (I ran up a huge queue of items at my dedicated factory base on an old game, and then assigned whatever engineers would fit onto one project at a time, canceling projects as data was confirmed. This is only semi-random, but it serves our purposes.) I did run into a single issue, though. It appears that despite having 5 empty hangars at a (different!) base, the workshop there could not queue up more than 3 of any one craft at a time, thus making this bug impossible to replicate with the Firestorm or Lightning, as you must be producing more than three for the bug to occur. However, it still works with the Avenger. Later, I shall see about constructing a dedicated Hangar base with 7 hangars in order to attempt to replicate the bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:33, 8 June 2007 (PDT)

::Sounds great, Arrow. Why not post a simple example that shows how the problem works. As in, "with 1 Eng and 2 Avengers you might think X, but no, it's Y". And please delete my example. And it's a fine pleasure to meet you! Cool - [[User:MikeTheRed|MikeTheRed]]

:::When you say the usual resources are used by the "lost" resources, that includes cash, right? It sounds like if you're willing to foot the extra bill [[Buying/Selling/Transferring#Manufacturable_Prices|money/component-wise]], this could be used to build Avengers slightly faster then normal.

::: The usual time is 34000 hours. Double that and subtract 65535 and you're left with a paltry 2465 hours. Even a single workshop squad of 10 engineers will pull that off in a little over ten days. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

::::Sadly, this exploit doesn't work, because the high bit is stored SOMEWHERE. I lack a hex reader and have no code reading skills to speak of, so I'm a bit limited here. If you set up a Workshop as you described, the game would take all the time for 2 Avengers, all the resources for the same, but in the end only produce 1 Avenger. Meanwhile, I'll run more tests on the resources thing. I could swear it consumes the resources, but I'll double check.

:::::There is no need to store the high bits if the actual completion condition (assuming adequate money) is "number made is number ordered", which wouldn't reference the hours remaining at all. - [[User:Zaimoni|Zaimoni]] 01:49, 9 Oct 2007 (CDT)

::::Tests done; I was unable to replicate the 'disappearing item' trick,(Which I didn't test for last night) even with Avengers! It appears I was wrong; this still counts as a bug, though, because the wraparound is a problem.

::::Ironic that so much of this discussion centers around Avengers, because that's where I discovered this in the first place! [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:48, 9 June 2007 (PDT)

----

I'm revisiting XCOM and was working on [[Manufacturing Profitability]]... Arrow, can you (or anyone else) say a little bit more on the Known Bugs page about this [[Known_Bugs#Manufacturing_Limit_Bug]]? It's not clear to me exactly what the bug does, except that it understates hours. Is that all?... does it still take the (non-buggy) amount of time, still use all the same resources, still make the same number, etc.? It sounds like it could be a drastic bug - or is it only a very superficial one, a display bug for the hours? It sounds like you're leaning toward this latter.

Also on a semi-related note... I could swear I saw much more detailed info on the [[Known_Bugs#Facility_Maintenance_Costs]] issue... IIRC, the incorrect amount that's charged for maintenance, depends on exactly where a facility is in the base. IOW, different "rows" of the base cost different amounts. Could somebody provide a link there, and/or flesh the bug out better?

Thanks! - [[User:MikeTheRed|MikeTheRed]] 11:22, 8 October 2007 (PDT)

:I've actually seen the bug work both ways, but I've only been able to actually replicate the more superficial version of the bug. So the bug report up is about a superficial bug that drastically understates production time. If you wish to make this clearer, you have my blessings. As well, that 'different charging based on location' is dealt with here: http://ufopaedia.org/index.php?title=Talk:Base_Facilities ; however, the table has been broken with the Wikiupgrade, and I lack sufficient knowledge of HTML table code to fix it. But it should be of use to you. [[User:Arrow Quivershaft|Arrow Quivershaft]] 11:26, 8 October 2007 (PDT)

::Cool, I fixed [[Talk:Base Facilities]] but also re-organized and expanded [[Base Facilities]] so that it includes that bug in detail, as per Talk... this is an important issue that should be up front. I see that there's a separate [[Maintenance costs]] page, but I can't see having something so important (the maintenance bug explanation) all on its own page (which makes for a rather short page) rather than together with all the rest of the base facility info. If others agree (or don't care), I'll move anything remaining on Maintenance Costs to the Base Facilities page, then delete Maintenance Costs and re-route links. And if somebody does care, then please move my new section to Maintenance Costs, and move all the links, etc. Oh also I put in more words on your Manufacturing Limit Bug - how does it look? - [[User:MikeTheRed|MikeTheRed]] 16:37, 8 October 2007 (PDT)

:Looks pretty good, although it'll wrap fully; if you ask for 120000 hours, it won't be displaying 'almost no' time. The way I discovered it was when building two Avengers; I ordered two, paid for two, waited for two...and got one. But as said, haven't managed to repeat it, so until I do, we'll leave it like that. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:00, 8 October 2007 (PDT)

::I just revised and put in your specific example, because it's certainly possible some of us die-hard players will order up more than 1 Avenger at a time - and it's guaranteed it'd be a pain if 1 of them disappeared, laugh. I wasn't sure how concrete you were on that example but now I hear you say, you are sure it happened at least once. - [[User:MikeTheRed|MikeTheRed]] 18:33, 8 October 2007 (PDT)

:I have a question concerning the manufacturing "bug" which eats a craft in production due to wrap-over of the byte. Arrow (or whoever did the test), did you have a large quantity of craft already built at your bases? If so, I think this bug has more to deal with clogging up [[CRAFT.DAT]]. See, that file has a limit of 50 entries. Each craft takes up one record and each base you have built also consumes one spot. 8 bases allows 42 craft to be housed, while 6 bases allow 44. If you try to buy or manufacture craft once the file is full, nothing shows up in the game even if you have hangar space available. --[[User:Zombie|Zombie]] 19:00, 8 October 2007 (PDT)

::Huh, I never knew that. I don't see it listed on the Bugs page... I'll stick it in there. I've never approached that number, but some folks might. - [[User:MikeTheRed|MikeTheRed]] 19:07, 8 October 2007 (PDT)

:I was able to continue building other Avengers after that project, and they appeared correctly, so I do not believe that is the issue. In any event, I have a very bad case of 'archivism' and probably still have the save game and the CRAFT.DAT file around on my system; in fact, I think I was playing it a few days ago. I can see if I can find it and upload it; it created a 'hole' in the Avenger fleet numbers, where Avenger's x and x+2 were built, but x+1 was not. I'll look for it tonight and tomorrow and upload it to the wiki if I find it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:10, 8 October 2007 (PDT) EDIT: I found the file; I have 28 Avengers and 1 Skyranger in my employ. All Avenger numbers EXCEPT #2(Avenger-2) are accounted for, and I have not sacked or lost any Avengers. So this is where the hole and 'eaten' Avenger is. If anyone wants the CRAFT.DAT file from this game, I'd be happy to forward it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:20, 8 October 2007 (PDT)

::Sure, send it my way and I'll take a look at it. (Might as well send me the whole saved game as I may want to look at the other files too). I have tried to recreate this bug by manufacturing 1, 2 and 3 Avengers at a clip but all of them always show up. Don't know what else I could do to get this problem to crop up. --[[User:Zombie|Zombie]] 21:32, 8 October 2007 (PDT)

:File emailed. On the side, I've tried the same thing, and never been able to repeat the bug. It's been months since the first discovery, so I can't recall whether it was the first or the second Avenger that didn't appear. So maybe it was just a fluke. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:57, 8 October 2007 (PDT)

== Unconscious Enemy in Equipment Screen ==

The following happened to me repeatedly over the last few days.

In the last tactical Mission a live alien has been captured. When now beginning an UFO crash recovery mission this type of alien (same race and rank) appears in the equipment screen before the mission starts, meaning I can give it to any of my soldiers.
If I do so I can store the alien in the skyranger for the duration of the mission and, if it gains consciousness, kill or stun it at the end of it. A pile of equipment without a corpse will be in the UFO, indicating that the stunned alien is not some kind of duplicate but instead has been taken from the aliens of this mission. This is supported by the fact that in those missions the maximum number of crew members has not been surpassed.
If I do not do so the Alien will be placed in the crashed UFO. Whether it is unconscious or not I do not know, but the fact that it is completely disarmed when encountered in the battle suggests that it is.

So far it seems the following is necessary for the bug to occur:
# An alien has to be captured alive in the last tactical combat
# It has to be of the same race and rank as one of the aliens in the new tactical combat

So far this only worked...:
# If the new tactical combat was an UFO crash recovery of a medium scout.
# For floaters and mutons
# For soldiers and navigators
# If the alien in the last mission was stunned by normal weapon fire (although I do not think this is important) and not picked up (again, not likely to be important) or destroyed (which would mean it has to be actually captured)

It seems NOT to depend on the following:
# The type of the last mission (were, so far: Ground assault battleship, crash recovery large scout, base defense)
# Which squad or vessel was involved capturing the alien
# Where it is locked up
# If it has been transferred since capture or not

Would be interesting to know:
# What happens if the alien in the inventory screen is the only survivor
# If the alien in the invenory screen is one of the aliens randomly killed in the crash or not (it is likely to be one of the killed aliens, so far the equipment piles were always within the UFO)
# If this is not limited on crashed medium scouts: Does this work with terror units? What about large ones?

Maybe this is related to the proximity grenade bug (transfer of item properties to next tactical combat).

Additionally, in one of those mission a part of the terrain was not generated correctly. It was in farm terrain (The house on the right square, or north east square, in [[Image:Terrain-cult.gif|this pic]]). The outer wall right to the right window of the southern wall (1st Floor) was missing. Directly outside of the hole was a floor tile. I could walk a soldier through the wall, but he fell right through the tile. Dunno if this has to do with the stunned alien bug.

Version is collectors edition (the one from abandonia.com).

----------------

When a mission starts, the GeoScape engine generates the unit and object tables (in MissDat's [[OBPOSREF.DAT]], [[UNIPOS.DAT]], and [[UNIREF.DAT]]) before "shutting down". The Tactical engine then generates the maps, places the aliens on it, and blows up the UFO (if need be). Whether or not map generation and the subsequent events happen before you equip your soldiers I don't yet know.

The test would be to check the aforementioned files to see if they contain an unconcious alien, and/or the body.

Note that you can't see the bodies of large units on the ground (they count as four seperate objects covering four seperate tiles, so allowing the user to pick one up would essentially let you rip them apart).

- [[User:Bomb Bloke|Bomb Bloke]] 06:35, 5 August 2007 (PDT)

----------------

I honestly have no idea of how all those files work. But I still have a savegame in battlescape that is in one of those missions. So if anyone wants to have a look at those files...

I forgot to mention: I reloaded a geoscape savegame shortly before the battle to recreate the bug, but it seems that reloading in geoscape before the buggy battle eliminates the bug. I guess his should narrow down the possible reasons...

--------

Next time it happens, backup the aforementioned files before you start another mission. I'm afraid a savegame wouldn't be of much help.

- [[User:Bomb Bloke|Bomb Bloke]] 00:54, 7 August 2007 (PDT)

== Soldiers moved to outside of combat screen ==

Hi, I've got a DOS version of UFO:EU, and I've encountered a bug in the tactical combat. Sometimes (rarely) a X-COM soldier changes its location on the map on player's turn start and is placed on outside of the map, one tile north from the (north) border of the field. AFAIR the unit is then selectable (you get the flashing highlight when cursor is above), but is stuck outside of the field. Has anybody encountered this bug? It seems to happen randomly, but more frequently during the terror missions and on early turns (so maybe it's caused by high number of player/alien/civilian units?). --[[User:Maquina|Maquina]] 08:16, 3 September 2007 (PDT)

:I've never encountered this bug in CE of UFO. Presuming AFAIR means "As Far As I Recall," what exactly was the soldier doing? Any equipment data, location, or stat info might help us pin it down. Were afflicted soldiers always carrying a specific equipment set or weapon? Where were they on the map before they got moved? Did they get bumped a few spaces, or teleported halfway across the Battlescape? Does it happen more often on a specific difficulty?(Your theory would suggest this would happen most commonly on Superhuman) Against a certain type of alien? Best of all, if you can recreate the situation in a game, save the game and then you could upload the save file to the forums or this wiki, and the rest of us could take a look for ourselves and the code divers could root around for the cause. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:03, 3 September 2007 (PDT)

:: I've had this happen to me several times in UFO and TFTD. I don't know if it's specific to the Dos version or if it can happen in the CE as well. Sometimes the soldier ends up beyond the boundary of the map right at the start of the mission, at other times it happens after you load a game. This game is glitchy, which is the source for so many of its bugs, so your soldier's coordinates are probably getting corrupted to the point where they are -1 on either the X or Y axis of the maps's normal boundaries. For me it's commonly along the top edge of the map. I don't ever recall it happening mid-mission, only at the start or after a load. I cannot faithfully say whether it happened with or without XComutil, but that could be one of the possibly many causes for this. - [[User:NKF|NKF]]

:: I don't play UFO often, so I rely on just several campaigns played. This happens rarely (I've encountered this bug twice in my last campaign with ~80 missions played), but if you haven't seen this happen then it probably doesn't show up in the CE edition. In my experience the soldier is moved always beyond the north/top map border. I think (but I'm not sure) that this affects the first soldier from the team more commonly than others (or maybe even exclusevily?). The equipment/armor carried is probably not relevant, since the units moved this way don't have any special stuff, and this bug shows up on different stages of the gameplay (ie. sometimes when you have ordinary rifles, sometimes when all your units got heavy plasmas and power suits). --[[User:Maquina|Maquina]] 04:12, 4 September 2007 (PDT)

'''MY ramblings have been moved to my discussion page''' [[User:EsTeR|EsTeR]]

==Great Circle Route==

Should we have the Great Circle Route bug noted on this page at all? [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:33, 6 October 2007 (PDT)

: what is the great circle route? [[User:Jasonred|Jasonred]] 07:56, 31 March 2009 (EDT)

:: Pick two points on a globe, then hold a thread or string taut at those two points. That practically minimizes the length of the thread/string on the globe. You're now looking at a great circle arc (or route), the shortest distance between two points on a globe. -- [[User:Zaimoni|Zaimoni]] 11:15 March 2009 (CDT)

: Just as a line is the shortest distance between 2 points on a flat plane, a great circle is the shortest distance between 2 points on the surface of a sphere. The bug, by the way, is that aircraft in the game ''don't'' follow this shortest, "great circle" route. [[User:Spike|Spike]] 12:38, 31 March 2009 (EDT)

:: What a grand sounding name, for something so simple, lol. ... I thought you were talking about when you tell your soldiers to go from point A to point B, and for some reason they figure that Zone A and Zone B are really far apart, despite actually being side by side. (I shot a hole through a wall, clicked to walk to the other side, and my idiot soldier walked one big circle... to use the door! And got ambushed and killed by an alien. ... dum dum DUMB DUMB.)
:: Even the more modern games have problems with their pathfinding algorythms. Admittedly, games like Baldur's Gate had to do it in realtime.
:: On a semi-related note, I remember this guy called E-man, he was chasing a guided laser beam that was going to kill his girl, around the world, but he couldn't outrun it since he couldn't break the speed of light, only equal it by changing into a Laser himself. So... inspiration! He turned into a very powerful laser, and made a shortcut THROUGH THE EARTH... the straight line beats the great circle route, lol.
:: Thanks for the reply guys [[User:Jasonred|Jasonred]] 15:56, 31 March 2009 (EDT)

Added to article. [[User:Spike|Spike]] 16:41, 3 September 2012 (EDT)

==Bug not listed: Missing soldiers during base defense==

I encountered an interesting bug concerning base defense missions:
My base got attacked while about 30 soldiers and 10 HWPs were present. The usual equipment assignment screen was skipped and the mission started instantly with only the HWPs spawned at the map. Not even a single soldier bothered to show up... *sigh*
Although this turned out to be in my favor (you should have seen the puzzled Ethereals trying to panic my tanks) I´d like to avoid this bug if possible. I was able to reproduce this bug several times and with different bases.
Can anyone explain this bug and/or tell me how to avoid it?

Game version: Collectors edition. - [[User:NewJoker|NewJoker]]

-----

Well, ideally, we need to know what your base's construction was to be sure of this, but I think the most likely circumstance is that the HWPs took up all the spawn points. HWPs have maximum priority for spawning(followed by Soldiers, and then Aliens), so if you have enough of them garrisoning a base, it's entirely possible that soldiers and aliens won't spawn. However, this doesn't explain why the soldiers didn't start stealing the Alien spawn points...in any event, you might want to take the save game file, zip it up, and get ready to email it. I'm sure [[User:Zombie|Zombie]] would be quite interested. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:28, 13 November 2007 (PST)

-----

It's not the spawn points, it's a [[UNITPOS.DAT]] limitation. A maximum of forty records (out of the total of eighty) are allocated for your units, and tanks (which take up four records each) get first pick. Having ten tanks means there's no room left for anything else.

Ditch one HWP and you should see four units take it's place. - [[User:Bomb Bloke|Bomb Bloke]] 16:42, 13 November 2007 (PST)

-----

I´ll try with a decreasing number of tanks and report the results. As I wrote above having only HWPs isn´t too bad dependent on what enemy is attacking. [[User:NewJoker|NewJoker]]

----

This should be mentioned in the [[ExploitsE#Base Defence Mission Spawning Issues]] section. The Bugs/Exploits really need to be sorted and consolidated. - [[User:NinthRank|NinthRank]] 16:57, 13 November 2007 (PST)

-----

The limitation to 40 records seems to be the case; each tank I dumped got replaced by four soldiers.
So this can be used to effectively manage unit combination. Thanks for the quick replies! [[User:NewJoker|NewJoker]]

==Bug not listed: Ufo Gold (Windows Vers. abandonia.com) crashing when plasma defense is finished==

I recordnized this bug a few times now. (with hacked AND unhacked game)
If i place a plasma defense in 7 bases at the same Time and they are finished at the same Time, the game crashes sometimes.
In hacked game, it seems to crash even more when Alien containment is finished, plasma defense, shield defense...etc.
couldnt find it here...greetz

: I somehow doubt the sourcing is the issue. [You may want to fund the next XCOM series game with a Take2 re-release of UFO :)] More generally: the game only reports the construction of a given type of facility once, no matter how many bases it completes at simultaneously. I've only tested this in vivo with three-of-a-kind at once across six bases, however. It does seem reasonable that some sort of counter of undisplayed completions would "overflow" (attaining crash). -- [[User:Zaimoni|Zaimoni]] 10:05, Feb. 28 2008 CST

::I've encountered this bug myself with General Stores, actually, not just Plasma Defense(which I never build). EDIT: Some quick tests seem to show that there's a chance the game will crash any time two base facilities are done at the same time, regardless of whether they're in the same base or not or if they're the same facility.(although it seems to happen MUCH more in the event they're in different bases.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:13, 28 February 2008 (PST)

== Soldier Recruiting Bugs Tested ==

Just to note that I have positively tested and replicated the bugs listed under the new(ish) section [[Known Bugs#Soldier Recruiting Bugs|Soldier Recruiting Bugs]]. [[User:Spike|Spike]] 18:08, 19 March 2008 (PDT)

==Floater Medic Bug==

I have not thus far encountered the Floater Medic Bug; in fact, Floater Medics are often used to fill up my Rogue Gallery with interrogations. [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:50, 24 April 2008 (PDT)

Strange, it would always occur in my version. I don't remember where I got it from, but I
know it was a download from the internet. Using the XCom Hack v2.5, I viewed the alien in
the Alien Containment edit. I now have Type (race):____, and a Rank: Soldier for the
Floater Medic. It might just be corruption, but I do not have the resources to look into
it. [[User:Muton commander|Muton commander]] 19:24, 12 May 2008 (Pacific Time Zone)

I've never encountered it either. [[User:Magic9mushroom|Magic9mushroom]] 07:47, 23 July 2009 (EDT)

I think this only happens in the CE version. A disassembly of the code reveals that the stack to hold the matrix for what topics have not yet been researched is too short. It seems that those who ported the code from DOS doubled the local variable sizes blindly. There is already a problem that there are two-few bytes necessary for the entire alien organism section of the UFOpaedia, but double the expected size of the registers and it fills up quite easily unless a lot of autopsies and interrorgations have already been done. The only other situations that are handled by the same routine are the navigator revealing mission data or engineers revealing ship data, but there isn't enough topics in either section to overflow the stack variables. - [[User:Morgan525|Tycho]] 08:27, 22 June 2013 (EDT)

==Strength Overflow==

During one of my games with TFTD I noticed a really annoying thing happen during battles.
As my troops rose up the 'stat.' ladder they got better and better (as you'd expect), until they hit about 50 strentgh and completely lost the ability to throw anything.
Even trying to throw something tiny like a grenade or flare into the adjacent tile resulted in the 'Out of Range' message being displayed.

Anyone come across this before?
This was in TFTD CE.
[[User:Tifi|Tifi]] 07:55, 27 April 2008 (PDT)

:This is fairly well documented. The pathfinding algorithm for throwing objects will balk if anything is in the way of the throw and refuse to allow you to throw. What's happening is that your soldiers have become so strong that their throws are intercepting the 'ceiling' of the Battlescape(the top of L3), and as such the game thinks that the throw is blocked(because in order for the throw to complete, the object would have to be tossed up to the nonexistant L4). There's two ways around this:

:The Normal Way: Try shorter throws, throwing from lower heights, or throwing while kneeling. Beyond that, possibly get some new troops.

:The Sneaky Way: Manually edit the Strength scores of your soldiers in [[SOLDIER.DAT]] so that they're back to a usable strength level. If you set "Initial Strength" (offset 46 decimal or 2E hex) to 0 and "Strength Improvement" (offset 57 decimal or 39 hex) to a value of 50, you can permanently lock the soldiers at 50 strength. (You can lock them higher than that if you so choose, but not lower.

:Other than this, there's no workarounds I can think of offhand. [[User:Arrow Quivershaft|Arrow Quivershaft]] 08:10, 27 April 2008 (PDT)

:: There's normally no problem with the max level of 70 in open settings. However TFTD has a lot of low ceilings such as in the shipping lane missions and colonies, and the lower ceilings impairs your throwing quite a bit. In addition to shorter throws/kneeling, try moving out from under any overhangs if there is one just above you. - [[User:NKF|NKF]] 12:33, 27 April 2008 (PDT)

== Bug not listed: Sticking your head through the ceiling ==
This is something I just discovered: When you step on a small object inside of a building your soldier sticks his/her head through the ceiling and can see what's upstairs. You can even see the soldiers head coming out of the floor and that soldiers can shoot aliens upstairs. When I did this the alien I saw/shot was facing the other way, but I guess you could get shot if the alien was facing you. [[User:RedNifre|RedNifre]] 17:34, 11 May 2008 (PDT)

:That's not listed under "Bugs" because it's covered under "Exploits", right here: [[Exploiting_Collison_Detection#See_Through_A_Ceiling]] [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:26, 11 May 2008 (PDT)

:: I don't know if it was ever covered anywhere, but there's this neat trick that might sound similar to the walk-through-'wall object'-wall trick except that it involves your unit climbing slopes. They'll appear as though they've gone up a level, but are actually not on that level. They only visually appear to be there, but are really still on the bottom level.

:: It happens a lot when walking up the desert or forest slopes. I think the trick involves standing on ground level, and then ordering the unit to 'move' into the hill rather than setting the waypoint while on level 1. The soldier will move up the slope and perhaps stop on the slope or even reach the top of the slope, but will still appear when you're only viewing the ground map layer. The soldier is really still on the ground level, but will have elevation offset.

:: One really interesting way of using this trick is in the mountain region. If you can find a cliff face and a low hill nearby, you can literally have your soldier scale the cliff by standing the soldier on the hill, and then walking towards the cliff. It's ridiculous, but your soldier never quite reaches the top of the cliff tiles, so ends up walking up a slope.

:: On a side note, standing at the top of the ramp of the Skyranger is the same as standing on ground level - you're only offset a bit. This means that smoke on level 1 and the sides of the Skyranger will not provide protection when you're at the top of the ramp.

:: On another related note in relation: In TFTD (doesn't happen a lot in UFO), you might find it difficult to toss grenades onto underwater slopes. To remedy this, raise the level up by one. It might look like you're tossing at air(and you are), but it'll get the grenade where you want it. Odd, but true. I must remember to put this in the grenade explanation section. -[[User:NKF|NKF]] 23:11, 11 May 2008 (PDT)

== Base Defence bug that causes a crash? ==

Does anyone know about a bug in a base defence mission that causes the game to crash? The game keeps crashing on the 4th or 5th alien turn.

:I've encountered that myself, but it should be noted that overall, X-COM is not the most stable game and is prone to crashing often at anytime. The differences between the hardware it was designed for and the hardware we're running it on cannot be helping matters at all; it's really a small miracle it even runs without an emulator in the first place(I've got games from 1999 that will bluescreen my machine instantly). As such, I'm not sure it's worth noting as a bug, since it's a 'game feature'(albeit a detrimental one). In any case, what're you doing letting the aliens attack you anyways? ;) [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:33, 18 July 2008 (PDT)

:It sounds like an alien is in one of the outlying locations and attempting to destroy the top floor item. Possibly a radar or defense station. - [[User:Morgan525|Tycho]]

== Sources for a DOS4GW transplant ==

I was specifically thinking of the LucasArts Dark Forces demo, but I half-recall the actual source I used when testing that ~1999 was Id's DOOM. -- [[User:Zaimoni|Zaimoni]] 16:03, 7 August 2008 (CDT)

== Phantom Carried Casualty ==

You are carrying an unconscious soldier in one hand, and the soldier dies of his/her wounds. The dead soldier remains visible on the "left hand / right hand object" battlescape display, but is no longer visible in the inventory display. The problem can be fixed by moving another object into the same hand.

I've seen this bug with UFO Extender by [[User:Seb76|Seb76]] - possibly might be something to do with his manipulation of the inventory screen, rather than a general bug. I believe I've also seen this with other objects that were being carried in the hands, disappearing from the Inventory screen, but I'm not sure. I don't think it's an item limit bug, as XcomUtil shows 40 item slots free. [[User:Spike|Spike]] 08:58, 21 September 2008 (PDT)

:I think it has to do with the KO units KIA mod. Its doesn't take into account units held so when it tries to detemine where to place the corpse, there is no location. The routine doesn't undo the item-carried-sprite-ID byte for the holder. -[[User:Morgan525|Tycho]]

== Civilians As Enemies to MC'd Aliens ==

I ran across this issue a few times and just wondered if you guys experienced this. I MC'd a part of a Reaper (I always do the lower left for large aliens) on a Terror Site, then moved it a few squares. It suddenly stopped dead in it's tracks and then the alien spotted indicator increased by 1. When I clicked on the indicator to see where the enemy unit was, it brought me to L2 of the large apartment complex. However, nothing was there. When I sent a Flying-Suited soldier up there to peek in the window (eeek! A peeping tom!) he saw a female civilian standing there. This type of problem has happened numerous times to me so it's not a once-off thing. Maybe it's a LOS issue? Or maybe an alien indicator problem? Or a combination of the two? Don't know, but I'm curious if you guys have seen it. --[[User:Zombie|Zombie]] 23:40, 19 December 2008 (CST)

:There are a lot of major issues with MC'ing 4 square aliens. One of them being that you could accidentally MC an alien far off in the corner of the map, IIRC? Anyhow, maybe you should have tried MC'ing all 4 squares of the reaper and see if that changed things. -[[User:Jasonred|Jasonred]]

The long-range MC of other aliens when Mind-Controlling large aliens is only present in Terror From The Deep, due to a workaround to try and resolve the earlier bugs(and exploits) associated with controlling one square of a large unit at the time. In TFTD, successfully MC'ing part of a Large unit will also grant you control of the next three units in UNITPOS.DAT, in order. If you didn't MC the upper left portion of the large unit(the first UNITPOS entry for any large unit), you can potentially wind up in control of other aliens. So this doesn't apply to UFO. As for Zombie's issue, never seen it. And finally...Jasonred, on Talk pages, please indent your statement with colons so it differentiates from other people's comments, and sign your posts with 4 ~'s, like I will now do. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==Elerium Base Bug==

Jasonred: This bug has long since been known about. Elerium units on the Battlescape can be picked up by shooting away the power source; this one item counts as 50 units, and as such ANY elerium item spawned on any Battlescape counts as 50 Elerium. This issue with your own Elerium spawning as collectable loot in a Base Defense mission only occurs in older DOS versions, and is at the whim of the 80 item limit. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:55, 18 February 2009 (CST)

:Base defense does not seem to follow the 80 item limit in that DOS version. There are a lot of bugs that have long been known about. However this one was not included in the ufopedia for some reason.
:Also, the main thing about this bug is that it does not potentially double your elerium stores. It potentially multiplies them 50 times.
:... First time this happened to me, I was pretty flabbergasted. Here I was being conservative with my limited Elerium, refraining from blowing up UFOs when possible, when I perform a base defense and gain 3000 Elerium from it. Holy spit. -[[User:Jasonred|Jasonred]]

Alright, my error. Thanks for clarifying. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==HWP Fusion Bomb and SWS PWT Displacer Ammo Manufacturing Cost Bug==

At a cost of $15000, 400 Tech hours, 5 Zrbite, and 8 Aqua Plastics, this is the exact same cost as the HWP Fusion Bomb from X-COM EU, converted over to the equivalent TFTD resources. As such, it shouldn't be counted as a bug, since it is clearly what Mythos intended. [[User:Arrow Quivershaft|Arrow Quivershaft]] 09:55, 15 November 2008 (CST)

:Hmm, in that case maybe it should be treated as a generic game engine issue and not a TFTD specific issue - but I still think it's a design error. Can you think of any logical reason why the SWS/HWP version of the ammo should be more expensive (in cost and in materials) than both the craft ammo and the (more powerful) personal ammo? It makes no logical sense. Hence I think it's a design error. Nothing can be inferred from the fact it's unchanged from XCOM-EU, that doesn't imply any deliberate decision. It could just be the replication of an original error in XCOM-EU. [[User:Spike|Spike]] 11:17, 15 November 2008 (CST)

:: I can think of a logical reason to justify this: X-Com doesn't understand the technology as well as the aliens do (which is obvious, given the length of time each side has known the tech). Handheld Blaster/Blaster Bombs are just a copy of the alien design and therefor relatively cheap and efficient, but that can't be mounted on a turret. So X-Com has to make a new design, and they obviously didn't do that good a job as the aliens would have done. This explains Tank/Plasma being weaker than Heavy Plasma too. (Why is FBL Craft ammo cheaper than the tank ammo though? Maybe X-Com gave up on/simplified the guidance system and made it just a "dumb" cannon shell/torpedo instead which doesn't have multiple waypoints? Or maybe they just did a better job there?). [[User:Cesium|Cesium]] 04:07, 25 November 2009 (EST)

:Whilst we discuss it, I'll park my original text in here:

* ''Displacer/PWT ammo cost bug - at over $100,000 total cost per round, the ammunition for this SWS weapon is far more expensive to manufacture (both in money and rare materials) than the equivalent ammo for the Aquanaut-carried Disruptor Pulse Launcher, or the craft-based Pulse Wave Torpedo, despite being less powerful than either. This would seem to be a design mistake.''

See Also [[Talk:Displacer/PWT]]

:: I don't like the higher cost either, but I think it's a tradeoff of expense and quality for the convenience of portability. Sort of like an MP3 player to the gramophone... or maybe that's not a good comparison. -[[User:NKF|NKF]] 13:43, 15 November 2008 (CST)

A better comparison might be a desktop computer to a laptop. As a general rule, laptops are more expensive, but a similarly priced desktop gives you more power. Desktops are cheaper and offer power, laptops are more expensive and offer portability(though the gap is rapidly narrowing). [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:49, 15 November 2008 (CST)

:I think those are good analogies. But they don't apply in this case. To continue your analogies: We are paying mainframe prices for a clunky desktop that has only laptop processing power, and we're buying a mainframe for desktop prices. The vehicle version ("desktop") - is ''less'' portable and ''less'' powerful than the personal version (DPL = "laptop"), ''less'' capable than the craft version ("mainframe") - 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 SWS use up ''more'' of both Zrbite and Aqua Plastics than the Craft version. Do we really think it's logical that a tactical battlefield round, less powerful than its man-carried equivalent, takes more explosive and structural material to produce than both the more powerful man-carried version and also more than the air-to-air round that has 60km range and can take down a major alien combat craft? There is a clearly perverse bang-per-buck here, on every measure. My sincere belief is that this was an original mistake in the XCOM-EU engine that got copied into TFTD as well. The craft round should have the higher base price, but 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. But what I don't think is debatable is that is not logical for the SWS/HWP rounds to be more expensive than the craft rounds. It's clearly a mistake. Even in game balance terms, the only thing the HWP/SWS rounds have going for them is conserving "80-Item Limit" space, which I severely doubt was ever a game design consideration since it's just an awkward programming compromise. Any advantage inherent in the HWP/SWS is already reflected in the very high platform cost - there is no need to inflate the ammo costs as well. The bottom line is that a round for a (mini-)tank does not cost more, does not use more materials, than the same type of round for a long range anti-aircraft weapon that has much greater damage capacity and penetrating capacity. [[User:Spike|Spike]] 14:35, 15 November 2008 (CST)

I'm going to add this to the bug list now. [[User:Spike|Spike]] 16:06, 25 February 2009 (CST)

:Still don't think this is a bug though. Just because it's more expensive to manufacture than the hand-held or craft-mounted ammo, it doesn't mean the stats are wrong. Perhaps the programmers wanted to balance the tactical portion of the game a little more by making the ammo cost more for tanks. It doesn't have to be logical to be intended. Now if you had proof which said that the ammo was supposed to cost less but the stats were wrong, then yes, I'd agree. So if you boil it all down it comes to a disparate logic issue, not a bug.--[[User:Zombie|Zombie]] 21:31, 25 February 2009 (CST)

::I have to side with Zombie here. While the ammo may be disproportionately expensive, by the definition used on the rest of the page for bug, it doesn't fit. All the other bugs are errors in program logic or function or routines that are unintentional problems with the game, most of which are not warned of ahead of time. The ammo for the tank costs exactly what is listed and operates entirely as intended, whereas the rest of the bugs are not intended game features. Even if the numbers were entered wrong, that would be a data entry error, not a program bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:28, 26 February 2009 (CST)

:If it was a data entry error, I'd consider that a type of bug... assuming we had proof of the goof so to speak. LOL. --[[User:Zombie|Zombie]] 00:49, 26 February 2009 (CST)

:: It feels too specific an entry to be a data entry error.

:: I'm reminded of the high explosive. I know, I know - it's not an exact parallel to the FBL issue. A High Explosive is practically two grenades. Double weight, double bulk. Slightly above two times the damage. However, it costs five times the price of a standard grenade. Even though you're paying more for not-as-much, I don't think that could be considered a bug. A rip off, yes, but not a bug.

:: Here's a thought: Think about the immediate benefits each of the two controversial ammo types give back to you. Aircraft ammo = activity points. Tank ammo = loot. Yes, I know that aircraft ammo also generate crash sites, but you still have the ground combat to contend with.

:: One other thought: With careful management of your ammo, you'll probably never spend any elerium on the handheld version's ammo. Could it be the handheld that's really at issue here rather than the others? In the end I feel that it doesn't really matter. -[[User:NKF|NKF]] 03:38, 26 February 2009 (CST)

: I'm with Zombie that a data entry error is a bug (we have other examples), but also agree some proof is probably needed. And I agree with NKF that in the scheme of things, it doesn't really matter much. I don't think the HE pack is a good comparison (though the HE pack should be heavier) as it's reasonable to pay disprortionately more to get additional power at the same tech level. The fusion weapons are a case of paying more to actually get ''less'' power. I am not bothered by the handheld vs vehicle balance, not least because the game generally makes handheld weapons better than their vehicle equivalents, so I can accept that as an across-the-board design decision.

: I can also see a game balance argument ''if'' we believe that Fusion Tank ammo is more of an overall game-winning weapon than craft Fusion Bombs. But I'm not sure I agree with that statement. And even if it's true, and there's a game balance argument (in which case it would apply equally to handheld Fusion launchers), it's still illogical. The less powerful, battlefield warhead should not cost massively more in exotic materials than the much more powerful air to air warhead that brings down Battleships. I agree though that just because it's illogical does not prove it's a bug (i.e. unintended). [[User:Spike|Spike]] 07:48, 26 February 2009 (CST)

Ok we more or less seem to be in agreement that this isn't a bug, but it is very confusing/illogical. Maybe we can shift the "bug" text from the article page and roll that into the [[Hovertank/Launcher]] and [[Displacer /P. W. T.]] pages now. Feel free to combine any text from the discussion above if necessary. --[[User:Zombie|Zombie]] 09:22, 26 February 2009 (CST)

: Unless we can ''prove'' it's a data entry error (unlikely), how about calling it an "Anomaly" instead of a bug? [[User:Spike|Spike]] 10:59, 26 February 2009 (CST)

Looks like plain old game imbalance to me.
The way I see it, Hovertank Plasma and Launcher were meant to be stronger. Much much stronger. Let's look at Tank Cannon, Launcher and Laser. The logic is that it's a tank mounted weapon, so the tank can carry a much larger and more powerful version of the same weapon, right?
It's pretty stupid that a Hovertank Plasma is weaker than the Heavy Plasma... you could just mount a Heavy Plasma on a Hovertank and get them exactly equal. In fact, I suspect that the hovertanks were ALSO meant to have more powerful weapons than the man-portable versions.
Unfortunatly, the game designers then realised that this made the hovertanks far too powerful. So... the programmers nerfed the power of the hovertank weapons. BUT they forgot to lower the ammo costs. [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 11:20, 26 February 2009 (CST)

: Well you are opening up a much larger issue there. The Fusion weapons are an anomaly, an inconsistency. But handheld weapons are more powerful than equivalent vehicle weapons across the board, consistently. So that looks like a deliberate design decision, not a mistake. [[User:Spike|Spike]] 17:33, 26 February 2009 (CST)

:: There are two exceptions to the rule: Tank/Cannon: 60AP vs. Heavy Cannon 56AP. Tank/Laser: 110 Laser vs. Heavy Laser: 85 Laser. The hovertank\plasma only differs by a measly 5 (an extra 0 - 10 damage, which means a lot vs. UFO inner hull armour). I guess the trend here was to moderate the area effect tank strengths. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

I'd have to agree with you there Spike. This wasn't a mistake, however odd it may seem. It was a deliberate attempt to try and balance the game. Below is a table I created ages ago for my (now defunct) strategy guide detailing the HWP's and what handheld weapon corresponds to it. When you stick them side-by-side, it really becomes apparent that the programmers were trying to base the HWP weapons off the handheld weapons somewhat. The only thing that doesn't follow a nice and distinct scheme is the damage. That's what is the clincher. --[[User:Zombie|Zombie]] 20:26, 26 February 2009 (CST)
 
<table {{StdCenterTable}} class="sortable">
<tr {{StdDescTable_Heading}}><th align="left" width="150">Tank Type</th><th width="70">DAM</th><th width="80">Snap</th><th width="90">Aimed</th><th width="90">Aimed</th><th width="80">Snap</th><th width="70">DAM</th><th align="right" width="140">Handheld</th></tr>
<tr><th align="left">Tank/Cannon</th><td>60</td><td>60%</td><td>90%</td><td>90%</td><td>60%</td><td>561</td><th align="right">Heavy Cannon</th></tr>
<tr><th align="left">Rocket Launcher</th><td>85</td><td>55%</td><td>115%</td><td>115%</td><td>55%</td><td>87.52</td><th align="right">Rocket Launcher</th></tr>
<tr><th align="left">Laser Cannon</th><td>110</td><td>50%</td><td>85%</td><td>84%</td><td>50%</td><td>85</td><th align="right">Heavy Laser</th></tr>
<tr><th align="left">Hovertank/Plasma</th><td>110</td><td>85%</td><td>100%</td><td>100%</td><td>86%</td><td>80</td><th align="right">Plasma Rifle</th></tr>
<tr><th align="left">Hovertank/Launch</th><td>140</td><td>--%</td><td>120%</td><td>120%</td><td>--%</td><td>200</td><th align="right">Blaster Launcher</th></tr>
</table>
1AP rounds. 
2Average between the Small and Large Rocket.

: Hold up! Tank rounds do 60AP. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

So what's wrong? The table says 60 for the Tank/Cannon and 56 for HC-AP. Those are correct, no? --[[User:Zombie|Zombie]] 23:41, 26 February 2009 (CST)

: Sorry, didn't realise it was two tables side by side (or rather mirrored). Eyes only noticed the left side of the table. -[[User:NKF|NKF]] 23:53, 26 February 2009 (CST)

:: If the Hovertank Launcher did 200 damage, or worse if the Hovertank Launcher did EVEN MORE damage than the Blaster Launcher... that would make them easily the most deadly things on the map. As it is, the hovertank launcher is already pretty overpowered, even with 140 power.

I might be six years late here, but I think there could be an explanation for this in RL physics — indeed, in RL nuclear weapons programs. Incoming wall of text.

There are two sorts of nuclear reactions that produce energy: fission of large nuclei, and fusion of small nuclei. Fission can occur under normal temperatures and pressures, but involves a neutron chain reaction. As such, fission devices have to have a certain mass of fissionable material (the ''critical mass'') so that the neutrons stay in the material and cause more fission rather than escaping; this means that such devices cannot be scaled down below about suitcase or large backpack size (not all of this is actually nuclear material; rather, most of it is conventional explosives used to rapidly assemble the supercritical mass from subcritical masses). They also produce large quantities of radioactive fallout, which is problematic. Fusion, on the other hand, requires extreme temperatures and pressures, but does not necessarily require a neutron chain reaction. This means that they can theoretically be scaled down to much smaller sizes... except that the only available compact source (ie, not building-sized) of those extreme temperatures and pressures is the detonation of a fission bomb. Thus, all known fusion weapons currently in existence involve a relatively-small fission stage that detonates a much more powerful fusion stage.

The "Holy Grail" of nuclear weapons research is what's called a [[wikipedia:Pure fusion weapon|pure-fusion weapon]]. Because it has no fission stage, a pure-fusion weapon would release little fallout (note here that fallout is material that emits radiation long '''after''' the detonation; a pure-fusion weapon would emit copious amounts of deadly neutron radiation when actually used, but that would dissipate within seconds) and could be scaled down to grenade-launcher size (though it would obviously be far more powerful than a conventional grenade). They would be far easier to produce, as well; producing weapons-grade uranium and plutonium requires large and powerful isotopic separation equipment and/or a full-sized nuclear reactor, whereas deuterium can be extracted from water with trivial ease and lithium and tritium are relatively simple to obtain and make respectively. The main issue is that while the pressures required to confine the fusion material during the reaction are achievable with chemical explosives, the temperatures necessary for fusion are emphatically not. You need a stronger initiator; some material with a higher energy density even than plutonium. In RL the only initiator strong enough is antimatter — hard to produce and contain, to say the least — but the aliens in X-Com have a source that's stored far more easily... Elerium.

I posit that the "fusion" line of weapons in X-Com are exactly what they're named: tactical fusion bombs, made possible by an Elerium detonator. (A more controlled reaction on those lines — a fusion reactor with Elerium-spiked fuel — in UFO Power Sources would also explain the discrepancy between the calculations based on fuel efficiency and the lack of city-killer blasts when a Power Source's Elerium cooks off.)

Given the assumption that "fusion" weapons are indeed fusion weapons, with Elerium serving only as a detonator, the oddly high Elerium cost of the Hovertank/Launcher's ammunition is finally explainable. The HWP Fusion Bombs are, literally, smaller than Blaster Bombs and craft Fusion Balls (presumably because of size constraints in the launching mechanism in tanks). Having less explosives to compress the fuel means you need an even higher temperature to compensate — thus, more Elerium detonator — but because the actual power of the bomb is mostly from fusion and not Elerium decomposition, the yield is still lower.

I intend to remove this from the list of Known Bugs on this basis if nobody can find a hole in my logic. [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 02:03, 17 April 2015 (EDT)

:I'll have to disagree. Your argument while interesting, is just supposition and an attempt to give validation by taking ideas (that the developers probably never considered) to justify a flaw, very much in the same manner as those who try to explain why UFOs do not respond in interceptions. In truth, like many of the other bugs listed here, they are the result of issues caused by the time constraints the Gallops where under. Much of the production/buying/selling aspects of the game have game balance issues and don't make sense when cross referenced to other similar elements in the game and/or their overall effect to either combat or the strategy layer, especially in regards to the game's economics. [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]]) 05:06, 17 April 2015 (EDT)

::Why would they match up in terminology with the actual use to which any military would put Elerium by accident? Because, no shit, if a military got their hands on a substance with Elerium's properties this is literally exactly what they'd do (at least as far as explosives go). I can cite a paper talking about the superiority of antimatter-fusion weapons to pure antimatter weapons if you want; the title is "Fourth Generation Nuclear Weapons: Military effectiveness and collateral effects". [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 05:21, 17 April 2015 (EDT)

:quote all the sources you like, it still doesn't explain the waste in the manufacture process. With elerium being such a "scarce" resource, there is no logic in producing something that require more elerium and delivers less of a battlefield effect. It would be more logical and efficient to have had the platform fire regular blaster bombs, since they only require 3 elerium not 5.[[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])
::IMHO, any logic argument can be presented to why those HWP Elerium Bombs should cost less/more or be more efficient. That is not the point here. A bug is when a game feature is working improperly or/and is causing technical issues, either due to limitations, insufficient testing, whatever. Design choices are a completely different matter: the Heavy Laser is a nearly useless weapon due to its stats but no one ever considers it to be bugged due to its stats. It was a choice, that was slightly changed on TFTD with the Heavy Gauss. To consider the stats of the HWP Fusion a bug then you'd have to label a lot of choices as bugs when they are simply design choices. You may not agree with them but that doesn't make them bugs in the generally accepted definition of the term. And quoting Arrow Quivershaft on the top comment of this discussion: "At a cost of $15000, 400 Tech hours, 5 Zrbite, and 8 Aqua Plastics, this is the exact same cost as the HWP Fusion Bomb from X-COM EU, converted over to the equivalent TFTD resources. As such, it shouldn't be counted as a bug, since it is clearly what Mythos intended"[[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 19:35, 25 April 2015 (EDT)
::Also, the consensus until now expressed by several people that previously discussed this is that this is not a bug. The main supporter of the bug argument seems to be Spike at the beginning but during the discussion but halfway the discussion he says: "I agree though that just because it's illogical does not prove it's a bug (i.e. unintended)" [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 20:54, 25 April 2015 (EDT)
You don't get to claim benefit of the doubt here, Tycho. All game features are assumed to not be bugs unless there is compelling evidence presented otherwise. You claim this is a bug based on the suppositional logic that more powerful weapons should cost more and almost nothing else. The price wasn't altered (and neither was the power) in TFTD, so there's no evidence of mistake there (as an aside, the Displacer/Sonic having its power listed as 130 when it's 110 in the game engine clearly ''is'' a bug). The only bit you might be able to interpret that way would be the description of the Hovertank/Launcher's weapon as causing "immense devastation" compared to the description of the Blaster Bomb as "highly powerful" (the potential implication being that the HWP Fusion Bomb is stronger), but that's iffy at best since there's hardly a graded table of adjectives in use and on those very same pages in the UFOpaedia it lists the damage of each weapon as what it actually is.

The claim that it's a bug is based entirely on theorising about yields. I've given alternate theorising that would explain the yields (and I already explained that the semi-automatic nature of the Hovertank/Launcher and physical space for its high ammo could justify the need for a smaller round), which undercuts that claim. We can't know who's right, but the assumption should always be that the designers knew what they were doing; to assume until proven otherwise that they had no clue is extreme hubris and contempt. Moreover, you are in a minority of one or perhaps of two against a majority of several. Your claim to representing consensus is blatantly false.

Now, I'm going to wait a couple more days to see if anyone comes forward with anything substantive, as I waited a week after my reply to your original non-refutatory dismissal, and then reinstate the removal if nobody puts forward a cogent objection. [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 22:57, 25 April 2015 (EDT)
:Now that I think of it, though, an "oddities" page where we talk about this, the shitty Heavy Laser/Heavy Gauss, the No More Soldiers limit, and other not-bug things might be in order. It would help to make this page about actual bugs and not about weirdness that is nevertheless clearly as intended. Thoughts? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 23:04, 25 April 2015 (EDT)

:At the time, I didn't continue the argument as my point was that removing something based on one person's belief, no matter how cleverly thought out, wasn't good enough to warrant removing from the list. (I would have pointed out all the different theories on UFO interception AI, but I see that has already been removed.) I hadn't read all the discussions because I assumed that no consensus had been reached, similar to the Interception AI discussion. Mushroom, could have just pointed out that this issue was already settled years ago but no one bothered to removed it from the list, instead of resurrecting a "dead" discussion as though it had not been settled and just stated that the developers intended to discourage the use of this HWP by making the cost of its ammo high. I still don't agree that the HWP ammo is more efficient and thus justification for its production cost, especially since the developers would have never needed this level of justification or would have had the time to devote to so small an aspect of the game.

:I definitely agree that this page needs to be updated. Another reason I argued so strongly is because so many topics on this page do not fall into the category of bug as has been defined. I thought this page was also devoted to listing all the illogical aspects of the game due to the lack of enforcement on the definition. [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])

::If I only had a dime for each time someone proposes to change something on this wiki, everyone agrees, and then nobody ends up taking action... :) It's always better to take initiative and edit things. I agree also with an update to this page, and separating bugs from limitations. But definitely no more 'this should have been done this way' arguments to present design decisions as 'bugs' [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 17:43, 26 April 2015 (EDT)

:Okay. I'm planning to rip out the following and stick them on a separate page:

:Great Circle "bug" (this isn't really a "bug" so much as unoptimised code)
:Side-on Intercept "bug" (ditto, but given UFOs' tendency to alter course suddenly it's not even particularly unoptimised)
:Head-on Intercept "bug" (come on, this is just bitching)
:Instant Getaway "bug" (more an anomaly than a bug)
:80-item limit (intentional and the rationale is obvious to boot)
:Purchase limit (working as intended)
:Soldier recruiting limit (being charged for attempting to buy more is a bug, but the limit itself isn't)
:Soldier battlescape limit (there's a consequence of this which is a bug, the CtD with 10+ tanks, but not the limit itself)
:Manufacturing Completion Time Display "bug" (you can look at it and see what time it finishes, and it goes down at the right rate; it may seem a little unintuitive but it isn't "wrong")
:Manufacturing Rate Interruption Loss "bug" (more bitching)
:Manufacturing Rate limit (working as intended; the attempt to get around it in TFTD is bugged, but the EU behaviour isn't)
:HWP Fusion Bomb Ammo Cost "bug" (we're in agreement here it seems)

:There's plenty that need a tidyup on top of that but as far as the page split itself goes, are we agreed? Also, I'm thinking of calling the page "Anomalies and Game Limits", opinions? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 01:58, 3 May 2015 (EDT)

== DOS4GW - What the heck is it? ==

It's been ages since I had to remember this stuff, so those who remember clearer than I do, forgive me if my descriptions aren't accurate. Hopefully the general idea will come across.

Back in ye olde days of computere gamynge - and where there were more E's to go around, memory handling was a tricky beast to handle. Computer memory is divided into several different categories. Conventional, extended and I think expanded. I might be jumbling the terminologies for the last two a bit. Doesn't matter - memory was just cut up into small segments. The two most common memory types to PCs at the time were pretty small but were readily available. The third one - the most expandable (aka the chip with its massive 4 Megs of RAM you just spent your whole month's allowance on!), wasn't as easy to get at.

To get access to the higher memory that was available to the computer, special memory handlers had to be used. Drivers like HIMEM, emm386, etc were used.

DOS4GW is one such handler that lets the game access the computer's available expanded memory. Lots of games that came out at the time use this. Doom, Duke Nukem 3d, Syndicate, Ultima Underworld, X-Com UFO/TFTD, etc. LOTS of games. Any time you ran a game from the dos console and you saw the Dos4GW message flash by briefly it would be assisted by it (well, it stayed on the screen for ages back when processors were slower!).

It took the hassle out of memory handling and let the game access the available memory on the computer as one big flat block of memory to play with.

So what was meant in the article was to simply replace the dos4gw.exe with a more up-to-date version from another game. I think the way to tell its version was just in the message that it displayed. You can just run the dos4gw.exe file in a console window. It'll give an error, but the message it shows will indicate its version. UFO 1.4 uses Dos4gw 1.95, for example.

-[[User:NKF|NKF]] 01:22, 6 March 2009 (CST)
:DOS4GW also switched the processor from 16bit to 32bit mode. [[User:Seb76|Seb76]] 13:58, 6 March 2009 (CST)

== Clipping ==
I have a new bug. Its harmless. I have a savegame (EU CE - modified game) which has a sectoid within another sectoid. In the alien turn, one secturd walked off the roof and dropped down <s>onto</s> into another. (I guess there DNA is indentical afterall, so they 'become one' with the world). If you want the savegame (superhuman edited using UFOloader, UFO Mod v1, xcomed, Khor Chin WeapEdit v0.1) drop me a request on the my page somewhere. [[User:EsTeR|EsTeR]] 01:40, 18 September 2009 (EDT)

: Not something many would encounter, but definitely something that can happen. Units can occupy the same physical space, but the game cannot display them all. It'll only draw one of them. Actually saw this effect happen back in the early days of XComutil when it gained the ability to manually add new aliens into a battlescape. It did this by slotting them into the same spaces occupied by existing aliens. Then the fun would happen when you saw a couple of Mutons suddenly walk out of a sectoid. Not sure how the game determines who gets hurt when struck by a bullet. May very well depend on the order they are stored in the unitpos.dat file.

: There are a couple of ways you can replicate this in-game, but I can only provide theories on how you could do it. Such as shooting the ceiling above you and letting the unit drop through, or moving a tank off a ledge and getting its non-primary segments land directly on top of another unit. By the way, the rear end of tanks get stuck in walls if you attempt to move north or east off any ledges. -[[User:NKF|NKF]] 02:18, 18 September 2009 (EDT)

: Ok, so as long as others know about this, then all is good. I had never seen it and was doing alot of head scratching until I shot the alien.

== Berserk HWP crashes the game ==
In the article page it mentions that aliens which go berserk with their integrated weapons will crash the game. This is only true for Mind Controlled aliens (or units under X-COM control) - alien controlled units which go berserk do not crash the game. I tested an MC'd Celatid just now and it doesn't crash the game either, though it doesn't immediately go berserk - it waits another turn for some odd reason. Someone want to check this to verify my results? --[[User:Zombie|Zombie]] 20:31, 27 December 2009 (EST)

==HWP Morale Loss==

HWPs have 110 Bravery, which [[Morale#Effect_of_Bravery|normally prevents morale loss]], but I wonder if they can still lose morale due to loss of units with a morale-loss modifier. It'd depend on how the math is done. If, for, example, the -20 to morale for a dead unit is static, then multiplied by any [[Morale#Officers|morale loss modifier]], then reduced by 2 for every ten point of bravery, any officer death without another officer on the field will necessarily reduce HWP Morale.

It all depends on how the equation plays out and when modifiers are added. For sake of this post, I propose the following as the morale-loss equation: 20*(rank death modifier)-((Bravery-10)/5)*(1.00-Leadership bonus)=Morale Lost. (Rather than using 22 as a base, I'm going to assume Bravery is internally decremented by 10 for this equation as 0 Bravery is impossible without editing and it makes the math easier for the purpose of the example.)

It makes sense to me that rather than having 110 bravery hard-coded as an exception to "No morale lost", it simply works the same way in the normal equation, but is high enough that it negates most morale loss events, as even if an officer is killed, another officer is usually left on the field to help negate the penalty. That said, if a large portion of the team is wiped out at once, any surviving officers may not be able to negate it all, allowing tanks to start having noticeable morale loss.

So with the death multipliers, we can determine that every XCOM officer killed has a set death value. Rookies and Squaddies are -20, Sergeants are -24, Captains are -26, Colonels -30, and Commanders -35.

For example, under this theory, if a Sergeant is killed with no other ranked units on the field, a Squaddie with 50 Bravery would lose 16 Morale. (20*1.2-(50-10)/5*1.00=16). A HWP would, at the same time, lose 4 morale. The Sergeant's death is worth -24 Morale, and without another officer on the field to ameliorate the loss, the Tank's bravery only can 'absorb' 20 points of the morale lost. If it was instead the Commander lost, with no other officers on the field, the HWP would lose instead 15 points of morale, given that a Commander's death (20*1.75) is worth a whopping 35 points of morale loss if no other officers are present.

And if you have, say, four colonels and the Commander on rear/psi duty, and some alien flings a grenade or a blaster bomb into the back of the Skyranger and blows all three of them up and they were the only officers, the HWP has now lost 55 morale, which gives it a 10% chance of panicking/berserking on the next turn!

In the end this'll probably need to be tested for accuracy, but those are my thoughts right now.

Also, for the record, most units that berserk go to 255 TUs while still using the original TU-expenditure calculations; it's part of what makes berserk units so dangerous. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:34, 11 January 2012 (EST)

:Tested it under vanilla CE. Took a squad out containing just about every rank there is (commander + colonel + captions + sergeants), plus a tank. Blew up and killed all soldiers with a single blaster bomb shell, leaving just the tank, which lost no morale (sorry).

:I also brought a group of rookies along with a single commander + tank, and killed just the ranked unit. Tank lost no morale. A rookie with 60 bravery lost 17 (which matches the loss predicted by the formula currently on the morale page), whereas under your formula he should've lost 25.

:Still, you're on the right track. I've long had my own theory as to why tanks have been known to lose morale. Take a look at [[UNITREF.DAT#42|UNITREF.DAT[42]]] - this is the offset that stores a unit's rank. Notice something? The value gets higher as the X-COM unit's rank gets higher. Works in ''reverse'' for aliens, for whatever reason. I sorta figure it's so killing a mind controlled alien commander doesn't mess with your morale too badly, but there's a big problem with that theory and you can probably tell what it is...

:If the highest this figure gets for an X-COM unit is 5 (commander rank), then a killing a mind controlled alien ''terrorist'' with a rank value of ''7'' should net an even higher morale loss penalty. And indeed it does - I took a rookie and a tank to a terror mission, mind controlled and killed a terrorist, and the tank lost 10 morale. Guess it would've lost six if I'd taken a commander instead of a rookie, but that's still something.

:Note that the formula on the morale page does ''not'' account for this - it states that at bravery 110 the alien's death loss multiplier would always be applied to a base morale loss of 0, but that's obviously wrong. You're spot on in saying that the base morale loss figures are not totally dependant on bravery, and the "death loss" penalty is applied first. Would probably require a few more trials to determine what that penalty ''is'' for alien soldiers and terrorists though.

:Just for kicks, I edited a plasma tank to have 0 morale. It panicked in the normal way (either sitting still or charging off to the SE). When it berserked, the game crashed as soon as I dismissed the status message. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 18:54, 12 January 2012 (EST)

:: Thought I'd give it a spin. I sent a laser tank in with a squad and had it start shooting at team members. Each time it killed an ally, it would lose morale. Once it was under 50 morale, I waited until it panicked. Since I was playing the dos version, the game didn't crash but I suspect a memory leak of some sort may have occurred that would normally shut down the CE version. What would happen in CE if a soldier were to be edited and granted a tank turret, and then made to panic? Would the game crash? I'm just wondering if it's related to the weapon as opposed to the fact the tank is a treated as a large unit. -[[User:NKF|NKF]] 00:43, 13 January 2012 (EST)

::: Ah, friendly fire! Thought I'd tested for that, but obviously not...

::: Oddly enough, now that I try it, I see that the twenty point hit for killing a unit on the same side can be adjusted by the leadership bonus of the victim. Eg, kill a lone commander and his 35% penalty reduction takes the extra morale lost from 20 down to 13 (which is exactly how much a tank will lose, given that it otherwise wouldn't lose any at all).

::: Of course, this completely messes up my theory about alien soldier/terrorist ranks overriding the 110 bravery score. It doesn't. My tank "only" lost 10 morale because the alien's rank acted as a 50% leadership bonus... Though I suppose that's still interesting to know, because it suggests that keeping a simple alien soldier under mind control is more effective then risking your own commander in the field.

::: I took an otherwise unarmed rookie and assigned him a tank cannon + ammo. He could manually fire this weapon in much the same way a tank can. Forcing him to berserk crashed CE, under DOS he just spun around. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 21:20, 13 January 2012 (EST)

== 80-items limit on CE edition ==

I have the feeling that the 80-items limit does not apply to the CE edition and is instead a 110-items limit (at least during base defence). Can anyone confirm? [[User:Seb76|Seb76]] 16:24, 24 February 2010 (EST)

:I believe this limit was increased for TFTD. Maybe it was also increased for the CE edition of UFO, and only ever applied to the DOS edition of UFO?? [[User:Spike|Spike]] 20:03, 11 March 2010 (EST)

== Paying for Dirt in TFTD ==

I have the steam version of TFTD and am unable to replicate this bug. Testing with the starting base, I dismantled a few modules, added up my income and expenses, and it reconciled with my cash at the beginning of the next month. I even tried again, dismantling every module except the access lift, and once again saw no income discrepancy. Am I missing something, or is it possible this bug was actually fixed in TFTD? --[[User:Jewcifer|Jewcifer]] 12:18, 16 March 2012 (EDT)

:'twas probably fixed. It would indeed be helpful to add a small note to bugs on this page which are EU-specific but not obviously so (like this one). -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 17:14, 16 March 2012 (EDT)

::Every now and then I get the urge to test some of the more important bugs myself in my steam version of TFTD. Perhaps I will make a more complete effort and record the results somewhere on the wiki. --[[User:Jewcifer|Jewcifer]] 12:08, 21 March 2012 (EDT)

== Paying for dirt: Source of bug discovered! ==

Well, I never have read this anywhere (which kind of strikes me as odd, thinking of how obvious this one seemed to me... And i have NO programming background whatsoever), so I'll post it here, hoping that there are still some active members willing to try and verify my findings. If so, please comment here, because then I will inform bladefirelight to include this in any upcoming xcomutil release. If it had been discovered before, well then I just wasted some time here. Comment below, I will delete this entry.

As the main bug page mentions, when dismantling a facility still under construction the premium will only be paid once it would have been finished. This suggests some connection between paying the premium and building time. Looking into the infos here: [[BASE.DAT]], I quickly discovered what the problem was: When a facility is dismantled, the Bytes related to the location of base facilities are updated correctly. HOWEVER the game omits to update build time to FF (which is "will never finish", an entry only found on unused squares). If the facility is finished when it is dismantled (or destroyed during combat), then the 00 in the build time byte will stand. If it was under construction, the value indicating the remainig build time will continue to tick down towards 00 as if the facility was still there.

Now at the end of the month the following seems to happen: The game checks for ANY 00 entry in the build time bytes, and if there are 00 entries, it will look up in the location bytes the type of structure to determine the amount of maintenance for that 00-construction-time-square. When it finds "dirt", then it will charge the 80 grand (my guess would be that those are somewhere hard-coded).

This explains all phenomena related to this bug, like a dismantled hangar costing 320.000 grand or the premium only popping up after the build time of a dismantled facility that was under construction has expired.

Now the fix is pretty easy: Open the BASE.DAT in a hex-editor and change the bytes in question to FF!

== Minimized Interceptor Bug (Ufo CE) ==

Maybe this bug is not just related to saving, because I had a similar problem last night. The game didn't crash, but it kept restarting the same Battlescape mission.
One Avenger (A-3) was pacing a Battleship, while another Avenger (A-1) was sent to pick up the pieces of a Terror Ship that had been shot down by an Interceptor. Despite having no weapons (oversight on my part), A-3 wanted to attack the Battleship, but I minimized the screen, hoping it would land.
While the screen was minimized, A-1 landed at the Crash Site from the Terror Ship and started this mission. Right after finishing it, I got the message that A-3 was ready to land next to the Battleship. Happy that I'd get the loot, I started the mission.
After cleaning it out, I got the usual Loot and Promotion screens and went back to the Geoscape. A few seconds later, I was back in the equipment screen and the Battleship Mission started again. I played it once more, because - hey - additional loot, right? Err... no. At the end, I got the correct Loot screen for this attempt and the very same promotion I had gotten in the first attempt (A Rookie from another base promoted to Sergeant).
Got back to Geoscape and a few seconds later back to the Equipment screen. I aborted this mission (same Battleship again), got back to Geoscape and - you guessed it - back to the Equipment screen. After aborting this mission as well and getting back to Geoscape, I used the few seconds I had to go to 'Options' and 'Abort Game'. Maybe I could have made A-3 disengage from the Battleship since I think I saw them both on the Geoscape, a yellow diamond and a red plus, but it was pretty late by that time.
--[[User:Matzebrei|Matzebrei]] 15:06, 15 May 2012 (EDT)

This is a known bug. There is a work around. You should patrol the ship with troops and not land... Finish shooting down the other airborne ships first. Then when the ships doing the shooting are returning to base, change patrolling ship with troops to advance to downed ship in order to commence ground combat mission.
--[[User:JGF|JGF]] ([[User talk:JGF|talk]]) 07:55, 9 November 2016 (UTC)

== Activity Overflow Bug ==

This is a potentially campaign-ending bug. This was seen in the Steam distribution, DOS version (on Windows 2003 Server EE). Not sure if UFO Extender was being used - probably it was. End of Jan 1999 turn shows an extreme negative/underflow Monthly Rating score, which in turn is caused by extreme overflow of UFO Activity levels. Note that that funding "score" - the increased funding by countries - was very positive at the same time!:

[[File:dissatisfied customers.png]]

UFO Activity, by Areas and by Countries, is literally off the chart. Clearly some kind of integer overflow:

[[File:ufo-areas.png]]
[[File:ufo-countries.png]]

X-Com activity is also off the chart:

[[File:xcom-areas.png]]
[[File:xcom-countries.png]]

In addition to the likely outcome that I will lose the game in Feb 1999, it means I can't use the graphs to detect UFO activity outside of my radar coverage.

I have only seen this bug once, and (probably very unusually) I am running under Windows 2003 Server EE (!!). My hunch would be that's the cause, Windows 2003 Server is not the best games platform. :)

[[User:Spike|Spike]] 07:22, 3 September 2012 (EDT)

Further information:

I don't necessarily lose the game in Feb or March 1999. The Monthly Ratings from Feb onward are just based on the current month, not historical score to-date. However it still greatly increases the risk of suffering from the [[Known_Bugs#Losing_My_Favourite_Game|Losing My Favourite Game]] bug - which also greatly complicates doing too many controlled experiments on this Activity Overflow bug, because a few restores of the saved game quickly leads to X-Com Project termination (and humanity's doom).

Possibly the Activity Overflow bug is caused by an initial value of the score (or an array of score values) not being correctly zeroed at the start of the game. See this graph, which shows a negative score in May 1998, prior to the start of the game in Jan 1999.

[[File:Prehistoric_negative_score.png]]

[[User:Spike|Spike]] 08:48, 3 September 2012 (EDT)

I encountered the same Activity Overflow Bug in Windows 7 using Steam version, Windows option with UFOExtender latest version.

[[User:Humbe|humbe]] 2012.10.04 09:05 UTC

I encountered the same bug at end of january with latest xcomutil patched CE version (with only bug fixes patched) with ufo extender newest version running (close to default options). Got many saves from that first month. Even if loading very early save where I had done no missions yet, and just did stuff in base, graphs still show negative for various periods in 1998. Sounds more like corruption than something actually overflowing to me.

[[User:Archlight|Archlight]] 18:34, 24 September 2012 (EDT)

== Bad Paths Bug ==

I suggest to add bad paths on UFOs maps to the article, as another bug in the game.

[[User:Sherlock|Sherlock]] 09:25, 26 December 2012 (EST)
:That sounds reasonable to me. [[User:Spike|Spike]] 10:03, 26 December 2012 (EST)

==Expenditure Graph==
The economy graph for "Expenditure" neglects funds spent on new facilities. I noticed this in my current (DOS) game when I built eight Psi-Labs at the start of April and it didn't increase. I know it counts everything on the Purchase screen; I'm not yet sure whether it counts manufacturing costs.

Is this enough of a bug to be mentioned? Can anyone confirm whether or not it occurs in CE, and whether it counts manufacturing costs? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 02:40, 17 May 2016 (UTC)

==Workshop Crowding==
It seems there is a bug whereby you can allocate more projects/engineers than available workshop space. This can be triggered by setting up two concurrent manufacturing jobs, setting one of them to have 0 engineers working on it, then set the other to have as many engineers as you can assign to it, filling the workshop space. Then go to the other job with 0 engineers, and it will show a negative workshop space available, now if you assign at least one engineer to this project, you can assign the rest of your engineers however you please.

This is my first edit. I find it hard to believe I'd be the first to find this bug after so many years, can someone please confirm a reproduction and that it isn't documented somewhere I've missed? I am running the DOS version of UFO, but I'm also running XComUtil, not sure if that has an impact, or what patch level I'm on. - [[User:Uncertainty|Uncertainty]] 11:00, 20 Dec 2016 (AEDT) Update: Cannot reproduce on the CE version, still unsure of the patch level of the DOS version I'm running and don't know how to accurately determine that. - [[User:Uncertainty|Uncertainty]] 22:00, 29 Dec 2016 (AEDT)

: An easy way to check is whether you can research Magnetic Navigation after collecting one from an alien sub, or if you have to research a Lobsterman Navigator beforehand. If you can research it right away then you have v2, which is what the CE version is mostly based on. If you can't research it and must get the navigator, then it's the unpatched copy of the game. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 22:24, 29 December 2016 (UTC)

Update 2: Thanks NKF, I'm not running TFTD, but I figured out that I was running v1.2 of XCOM1. I cannot reproduce the bug on v1.4 so the bug only applies to v1.2 and has been patched in newer versions. - [[User:Uncertainty|Uncertainty]] 16:45, 31 Dec 2016 (AEDT)

= Unconfirmed bugs =

== Alien mission succeeds despite Ground Assault ==

Suppose aliens decide to do a mission. So they send a scout UFO. If you shoot it down, the alien mission gets derailed and the next scout becomes delayed, sometimes a little, sometimes a lot. Seems like the headquarters are waiting for the first scout to report back home or something. But eventually the second scout shows up so you shoot it down too. The third one also takes a long while to arrive and if you shoot that down too, the aliens either give up on the mission completely or send their big ships which only aimlessly fly to and fro, never land and leave soon, empty handed. This way or that way, the alien mission is a failure.

On the other hand if you wait for the scout to land, assault it with your Skyranger and win the mission, the alien's mission continues as if nothing happened. The second scout appears on time. So you ground-assault it too but the third and fourth scout also appear on time. Then the larger UFOs show up and land as if nothing happened to the scouts. You ground-assault them too, including the last Battleship that happens. But guess what? The alien mission is a SUCCESS even despite none of the UFOs making it back to base. Really annoying if the mission is an Infiltration, you can't take their juicy big UFOs because if you do, you are going to lose a country. But on the other hand all these Alien Harvests and Alien Abductions? Lots of juicy spoil and tons of points despite the aliens achieving what they wanted.

I need to add that I was playing some weird version of the game whose data was rejected by OpenXCom with "an invalid CHRYS.PCK file, please update to the latest version" message. So I don't know if this bug exists only there or is present in the latest version of the game too or even whether this is a bug or an expected behavior. - [[User:TowigOs|TowigOs]] ([[User talk:TowigOs|talk]]) 00:24, 3 August 2025 (UTC)

== Transfers can put you into debt ==

Any action you can do that consumes money will throw a big fat "NOT ENOUGH MONEY" error if you don't have the prerequisite cash on hand. Except item transfers. You can transfer stuff around merrily even when you are tens of millions in debt and on the brink of collapse from financial mismanagement. Maybe aliens MCed the movers to skip checking for money on your bank account and just hope they will get paid, eventually. Or they might MCed your bank to lend you money behind your back, allowing to go bankrupt reorganizing the content of your bases. At least you don't have to pay interest on these unwanted loans.

Looks like someone forgot to put "if (money<invoice) then {NotEnoughMoney();return;}" somewhere into that code path.

Note: Getting into debt because your base maintenance is much higher than your income and you did not have the cash is perfectly OK. These bills have to be paid. And you will go belly up financially if you allow this to go too deep.

=Cleanup needed=
Hmm this whole Talk page needs a cleanup. A lot of the Not Listed bugs, should be listed, or are listed. [[User:Spike|Spike]] 10:03, 26 December 2012 (EST)

:So, before it will be made, yet three more observations.

:1. There is no possibility to give back (to stop hiring) a plane without craft weapon.

:2. Alien Reproduction is unavailable in a normal game without hacking/save editing. This is probably connected to further errors on maps. A bug/error/programmers' oversight of the some kind is present in TFTD where it is impossible to obtain Examination Room. It is so because many tiles on maps are wrongly assigned to game's objects. Namely, [[Examination Room (TFTD)]] is treated as Alien Implanter - but there is plenty of errors of this type, on various maps (perhaps also in UFO: EU).

:3. Among soldiers in UFO:EU, there are Russians. Some non-Slavs may not know that Slavic (also Russian) family names have different masculine and feminine forms. For example, Petrov, Belov, Likhachev, Gorokhov, Chukarin, Andianov, Voronin, Maleev are all masculine names; women must be called Petrova, Belova, Likhacheva, Gorokhova, Chukarina, Andianova, Voronina, Maleeva respectively (however, a rule that the feminine form is always made by adding -a is wrong, e.g. Tolstoy - Tolstaya). The soldier's name Mikhail Gorokhova (which is possible in UFO: EU) is just ridiculous (for everyone who has even little knowledge about Russian things). Tatyana Petrov is also an impossible combination. X-Com creators probably assumed that family names are the same for men and women in all languages, and, as a result, they made only mechanisms for storing masculine and feminine forms of first names, not family names. But taking reality under consideration, this is a bug.

: [[User:Sherlock|Sherlock]] 16:22, 26 December 2012 (EST)

== Common bugs vs. UFO EU specific bugs ==

I believethere is one more thing that needs to be cleaned. Namely, both EU and TFTD share the same game engine, so some bugs are common for them both. However, there exists a page with a list of TFTD bugs, and it is clear (or: should be clear) which of the bugs are specific for TFTD. I think the same should be done with EU specific bugs: to hold them apart from bugs common for both games. Some bugs exist in both games but manifest themselves differently (like problems with mind-controlling of big aliens) - they are not true common bugs.

Or even more: one could expect a clear information by each bug, in which game and in which version of the game the bug occurs. And whether a patch exists or not. Sometimes such information is given now, and sometimes it is not. And if one does not know exactly which versions are affected by the bug, it should also be mentioned clearly.

[[User:Sherlock|Sherlock]] 04:13, 27 December 2012 (EST)

== Rename page title to indicate which game this refers to? ==

I was looking for a list of bugs related to XCOM Apocalypse, and it took me a while to realize this was about a totally different game. There are 4 games (not counting the 2 opensource projecrs) here on UFOP - maybe that could be reflected in the article aswell?
[[User:Panzerlol|Panzerlol]] 20:35, 31 March 2013 (EDT)

==New "bugs" submitted directly to main page with no apparent explanation==

WakkaDakka, have you actually managed to replicate this "missing time units" bug, or was it just a one-off freak occurrence? I'm not sure it merits main-page space until we have some idea how to replicate it.

N21, how were you seeing the future to begin with? It's only a bug if it occurs in the normal course of play.

[[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 03:36, 28 May 2015 (EDT)

== Enemy Unknown 1994: Save game bug mid mission. ==

Effect : Loading saved game mid mission just displays a black screen with the cursor at the top left, whilst the music continues to play in the background.
I don't believe the game has crashed out to DOS, having tried both CLS and DIR to no avail. Your can no longer interact with the game, making you force quit the app.

[[File:Screen_shot_2016-11-07_at_19.39.31.png|thumb|left]] 

I'm using Boxer 1.40 on a Mac - which in turn is built off Dosbox 0.74.
I remember seeing this bug years ago on Windows XP too, so I don't think it is platform specific.
I'm currently running it with some of the XCOMUtil patches too - but have had the issue crop up without any of the patches.

Playing on Superhuman level, I use a Skyranger with 14 soldiers equipped with Laser Rifles.

Cause : Hard to be specific. But here are the facts.
I have my suspicions it may be do to with fog of war rendering issues.
I've had it occur frequently when going to the NW edge of a map.

I also had issue on Alien base 1. I have a save game and can suggest moving a unit and saving it in another slot - that alone causes the issue. So if someone knows how to debug this I can supply that. Not sure if the combined number of aliens and yourself casue this.. I managed to eventually work thru a series of corrupted saves that wouldn't load to one that worked again).

Here is a sample save game where the game only needs one specific movement to corrupt a game when you save after the move.

[[File:GAME_10.zip]]
I've uploaded two images to show the move for S Bradley
[[File:Screen_shot_2016-11-11_at_13.50.13.png|thumb|left]] 
and the destination square to move him too. When you complete that move and save the game it corrupts.
[[File:Screen_shot_2016-11-11_at_13.50.17.png|thumb|left]] 

Incidentally there were two downed UFO's at this time, with a second Skyranger en-route to UFO 42. This mission was for UFO 43 with another Skyranger.

The problem frequently occurs.
Ive had it occur recently on the following types of mission:
Terror, Alien Base, Supply ship, Large Scout, predominantly with Sectoids and Cyberdiscs, but also with Mutons and Floaters.
The only thing all these missions have had in common was lots of units on both sides. For example 13 Floaters on a Scout mission, 9 Cyberdiscs on a Terror mission etc.

--

Other quirky things I've seen relating to Stunned units:

1) You can't stun a unit, forcing you to shoot it to complete the mission.
The target being stunned drops to the ground in a heap, but the game says you can still see it and can re-stun unit....

2) Celatids. You stun it, then it wakes up and moves away. The unit no longer renders correctly. It's like a sheet of garbled colored/transparent dots.

3) A stunned unit, other than a Celatid wakes up, and is invisible but you get the '1' in red square for visible enemy. You can stun unit and get the animation for it falling to the ground again.

--

Teleported unit off screen (notice the yellow arrow over the unit, which alas is invisible at the split second I took screenshot - OS/X rendering crap-shoot).
[[File:Screen_shot_2016-11-12_at_14.18.07.png|thumb|left]] 
The unit was teleported from the top of the stairs in an entirely different building, rendering the unit unusable for the mission. I ended up reloading it and doing over.... - [[User:JGF|JGF]]

:Stop spamming [[Special:RecentChanges|the changelog]], please - if you're working on a page and want to see the results of your edits midway through, use the Preview button. Don't hit Save until you are ''done''.

:I can't replicate any issues with your provided save. Bradley doesn't have enough TUs to "complete" the requested move, but asking him to make the attempt anyway, then saving / reloading, works fine for me under 1.4 as well as CE. For what it's worth, as far as I'm aware the game in no way keeps track of the number of actions you've performed during a given turn; at least, I haven't been able to find any such counter embedded in the save files.

:I do suggest you leave your units with more time units - when ending turn, any agents who ''might'' spot an alien during the enemy's turn should ideally have some cover, a kneeling stance, and enough action points to defend themselves with a reaction shot. Using your full TU allocation on movement is somewhat suicidal, and even when you can get away with it, it tends to leave agents without enough energy to move when they really need to.

:Your invisible units may be related to [[Known_Bugs#Invisible_Chryssalids|this bug]] - presumably you can trigger similar behaviour by knocking out all instances of a given alien species within a map, saving / reloading, and then waiting for one of the aliens to awake. I was able to replicate it with an Ethereal, for example.

:Difficult to comment on your garbled Celatid without seeing it first-hand. Ditto for your un-stunnable target. I'd quite like to inspect them with my save editor, though, and ditto for the teleported unit. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 05:46, 13 November 2016 (UTC)

Thanks for scaling the images nice to see the wiki syntax.
It's odd to here you say he didn't have enough Time Units left, because for me the move is allowed.
Where did you get your 1.4 patch?
I applied 1.4 too and am wondering if I got a bad version.
Also did you get your original XCOM off GOG or some place like that?
I have the original CD. I think it's the US version as I used to live there.

== Time Units reset to 0 when soldier reaches 255 TUs ==

I have been playing an old version of UFO: Enemy Unknown, where there is no limit on TUs for soldiers. At certain point, two of my best soldiers reached the limit of 255 TUs, which rendered them useless at now they have 0 TUs.
I tried to reduce their TUs by editing Soldier.DAT, but it did not help. If I check soldiers from the base menu, I can see that the value has been changed, but in the battle their stats are still the same and thus they have 0 TUs and cannot be moved with.

Do any of you know, how to fix this bug? Where is the limiter located, can I change it so that is will be as in the new versions? In any case, I believe this bug should be mentioned on the page. It is mentioned here though: http://www.ufopaedia.org/index.php/Time_Units --[[User:Achernar|Achernar]] ([[User talk:Achernar|talk]]) 21:13, 9 May 2017 (UTC)

: Feel free to add the issue - the page is a hodge podge of whatever issues folks have at the time or as they come across them.

: While I'm no expert on the file structure of the executable for the first release of the game, I suspect you'll find the cause for the byte roll-over feature is that there were no stat limiters to begin with. Best way to cope with it is to either retire anyone approaching supersoldier status to base defence duty, buy more soldiers and spread the experience out more evenly, or update to 1.4 and find a sound patch to restore the original sound samples.

: For your broken soldier: I'm, assuming you edited the soldier.dat file. If you saved the game while in the battlescape, the game creates a temporary copy of the soldier stats and keeps them in unitref.dat. This is to keep track of in-battle status changes, experience, etc. You'll need to edit the current TU levels in this file as well. Or beat the mission with the soldiers that can move and you'll see your edits reflected in the next battle. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 05:45, 11 May 2017 (UTC)

== Fire rate bug & German version footsteps ==

These don't seem to be documented for some reason: (DOS Version)

The fire rate always resets to 3 if an alien or an alien mind controlled unit throws a grenade.

If German is chosen as language to play, the footsteps of all soldiers, regardless of the terrain they walk on, will sound as if they are walking on a metal surface like the inside of the Skyranger, UFO or the base. [[User:Bard|Bard]] ([[User talk:Bard|talk]]) 05:38, 8 April 2019 (CEST)

== Direct incendiary hit causing no reaction fire? ==

On the Incendiary page, it is reported that a direct hit will not cause an alien to spin around and return fire. I have tested this in OpenXcom and find that the aliens do, in fact, return fire. If this can be confirmed in original X-Com, it would be good to add to known bugs.

: It's safe to say everything you find on this wiki relating to the classic game pages were gleaned from the original games. OpenXcom, being an independently developed fan project, will have its own list of fixes and changes chronicled in its own documentation. In fact I would not be surprised that good deal of the more technical information on this wiki has been contributed by those that had some input into the OpenXcom project. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 05:16, 8 June 2021 (UTC)

:: Thanks, good to know. Would still love to know if anyone has tested this in classic game. If not, I will when I can, so it can be added to known bugs [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 22:05, 15 June 2021 (UTC)

==Alien weapon loadouts bug/anomaly==
There are actually 10 alien weapon loadout sets, not 9. The actual first set is 70% "early"/20% "mid"/10% "late". This loadout set never appears in-game, though, because the setup at game start counts as a month rollover which means that weapon loadouts (which are called when the mission occurs, not at month start when the mission is scheduled) are called from the second set during January, the third set during February, and so on. This is probably an oversight by the Gollops (note that race weights reach their final values in October; were it not for this quirk, weapon loadouts also would), but it's hard to be sure. Should this be added? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 15:02, 28 April 2025 (UTC)

The Mysteries of X-COM

2025-08-04T02:04:24Z

TowigOs: Question: What happens to UFOs that do Terror/Retaliation missions?

Discussion page for some less clear aspects of the series

==General issues==

===How fast can alien craft travel in space?===

Some alien missions (repeated attacks on X-COM bases, for instance) come daily. This seems to imply that alien craft are able to travel the distance from Mars to Earth in a matter of hours.

: Or maybe, as you suggest in your novels, they have a staging area near Earth, such as the dark side of the Moon. [[User:Spike|Spike]] 15:36, 25 February 2009 (CST)

::Really fast. Consider that they don't need to push aside atmosphere, as well as the fact that momentum is conserved in space, so they can achieve very high speeds with gravity slingshots. (Mars DOES have 2 moons, recall.) Also note that they may be operating a bit closer to home(the far side of the moon, perhaps?) it's simply that the command staff are at Cydonia. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Good article in last month's Scientific American pointing out we only rely on gravity slingshots because we still use chemical rockets with pathetic delta-V. Once 2nd and 3rd generation plasma engines come on line (1st gen are in flight now) the gravity slingshot will become an irrelevance. No doubt UFO drives are at least as good as our (future) 3rd gen plasma drives, probably way better since they warp space.

(Reminds me of the old Guild Navigator joke - I just warped space from Ix, and boy is my mind tired. Oh well, you had to be there)

[[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

:Also keep in mind that both Phobos and Deimos are tiny. They are basically captured asteroids. Neither would be useful in gravity assist. But yeah, the UFO's shouldn't need any assist anyway.[[User:Mannon|Mannon]] 11:35, 30 March 2011 (EDT)
::Case in point: http://xkcd.com/681_large/ (Deimos can be escaped with someone on a bike and a plank stacked on a brick, Phobos requires a good pitching arm). --[[User:Xuncu|Xuncu]] 16:55, 13 April 2013 (EDT)

:Consider that many of the same aliens as UFO/EU are in X-COM Intercepter, having necessarily had to break light speed. Consider that if outside any atmoshphere a battleship could reach 4800 knots(in-game top speed) within two minutes (which is about how long it appears to take in-game) then it is accelerateing at about 18m/s/s or almost 2Gs. In 24 hours it would reach 1,555km/s. At this speed (assuming it turned it's drive off after 24h) it would travel about 134,000,000km each day. The maximum distance between Earth and mars is about 401,000,000km.
:For simplicity, because we have room to work with here, even if a battleship were to accelerate for 24 hours while orbiting mars, and again had to decelerate for 24 hours in orbit after reaching earth, (all while a chrysalid inside balanced two apples on each of it's mandibles) it would still only take 5 days to reach earth when both planets are at opposite orbital positions. It seems that the Ethereals can wipe out your base and not have to miss Ladies Night, assuming the club is also on earth. ''Ethereal Mind-Trick: "You don't want to 'blow dis joint'. You want to come back to the UFO for a little abduction mhmhmhmhhmm.'' [[User:Darkestaxe|Darkestaxe]] 23:38, 12 April 2013 (EDT)
::On one hand, "near-constant multiple organ failure" problably includes THAT organ. Ouch. On the other, sheer force of will problably works on that for them (lucky them); and with Psionics, you can make any woman belive that "this long" (holds hands a few inches apart) is 1 foot, as well as literally make her forget any other man she's thought about before, as well as Algerbra. Unhooking a bra would, however, still a challenge unto itself. And, since we are given specific dates in-game, there's plenty of programs online that can calculate the distance between planets for any given time, as well as lists of Oppositions (when two plants are at their closest): http://cseligman.com/text/planets/marsoppositions.htm For example, in 1999, the in-game year of the first game, on April 24th, Mars was only 86 million Km away (though Kudos if you can beat the game THAT early into a campaign) --[[User:Xuncu|Xuncu]] 16:55, 13 April 2013 (EDT)

===What happens to the crashed UFO craft and its crew?===

Downed alien craft disappear after a few days have passed. No explanation is given to this whatsoever, so what really happens to them?

Possible answers:
* The UFO and its occupants are recovered by other humans.
* The Aliens manage to repair the craft and fly back to space. (unlikely, in the event that the power plant blew up and they have no Elerium)
* The Aliens self-destruct the craft and kill themselves in the process, ensuring their remains will not be recovered by humans. (This is, in fact, the in-game explination. Read the mission briefing. [[User:Darkestaxe|Darkestaxe]] 23:38, 12 April 2013 (EDT))
* The UFO Powerplant eventually suffers a meltdown and explodes, eliminating any vestiges of alien presence.
* The Aliens blow up the UFO and disappear into the countryside.
* Most likely answer, IMHO: The local government/ funding nations give X-COM a limited time window to launch any operation, similiar to what you see in covert ops movies: "Complete the mission within 36 hours, or we initiate Carpet Bombing of the area". This is very likely considering that each nation actually has jurisdiction, and X-com is operating each military op with permission and cooperation by local authorities. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)
*Similiarly, I assume that nations which have signed a pact with the aliens launch a rescue operation and assist their alien friends. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)
: In the UFO TV show, it's stated that alien craft and bodies degrade quickly in Earth's atmosphere, disappearing completely in hours or a few days. [[User:Spike|Spike]] 15:36, 25 February 2009 (CST)
:: If that was the case, then one of the gases present in the atmosphere would be very toxic to the aliens. They would be restricted on their activities outside their craft, not to mention they would have to terraform the planet to be able to live here. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

:: As Zombie said, doesn't Alien Containment support this idea? [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

::Those are excellent suggestions. One of the X-COM books detailed that aliens throw up a force field around crashed UFOs to give them time to repair the craft. This would also explain the limited size of the Battlescape (the area of the force field...the field was thrown up before the crash, thus why the craft wasn't always centered in it) as well as why the Battlescape is devoid of human life(the aliens took care of that up front.) Similarly, large scale bombing works as well, as does the local government going in to clean it up themselves. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)
:::If there's a force field around the craft what is it supposed to repel? The atmosphere? Because humans have no problem entering the field and operating inside it. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
::::Of course they do! Have you ever noticed how dumb your units can be? That's because the aliens can't live with too much nitrogen, so they turn some of it in their force field to oxygen, and excessive amounts of oxygen make you act weird. After a while, their power source runs out and the nitrogen returns, dissolving them into E-115. (What did you think it was made of?) AT least, that's what seemes logical to me, ad is a combination of many postulates here. 21:36, 18 March 2010 (EDT)
:::::That would require that the aliens' biochemistry and the alien alloys used in the power sources reacted with nitrogen, which is a mostly inert gas on normal temperature and pressure and a . It's kinda of weird that the aliens didn't bothered with fixing that vulnerability with their craft and bodies during millions of years (what happens if the force field malfunctions while capturing cattle? ooops!) but ok. The increase in the amount of oxygen would probably also turn any kind of fire into large explosions throughtout the force field. [[User:Hobbes|Hobbes]] 21:24, 19 March 2010 (EDT)
::The force field was intended to keep humans out so the aliens were undisturbed. The first major hurdle X-COM had was figuring out a way to bypass those fields so they COULD get troops and aircraft inside. [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:54, 26 February 2009 (CST)
*I'd guess that the aliens would eventually mount their own rescue missions, especially once they realized that XCOM is farming their ships for resources (they must know we don't have ready access to their alloys and Elerium) and co-opting their technology. In the Firaxis game, when idling in the Situation Room screen, Central's (often amusing) radio chatter implies that there are many more UFO's and reports that don't go into the globe. Additionally: only 16 countries are covered, and there are over 150 countries on earth, plus all the oceans. After all, if we were shooting down every last ship, then the alien collective shouldn't be able to land so many aliens for Terror Missions. --[[User:Xuncu|Xuncu]] 02:48, 26 January 2013 (EST)

===How do the aliens carry their equipment?===
Like human soldiers, aliens can carry weapons and equipment in locations like legs, belt, shoulders and backpack, regardless of the fact that some of their races even lack those anatomical features.

:Potentially a sticky gel-like area on the limb. Though really, since we were never intended to access alien inventories and the AI does all inventory management internally, this may simply be something that was never considered. Speaking from a slightly different standard, most aliens do not carry excessive amounts of gear; often their equipment would be able to fit in both hands. Also recall that Floaters and Ethereals have capes and robes(which may have inside pockets, or the Floaters could store them in the anti-grav/life support unit or inside surgically created body cavities during the installation, while Ethereals could support their excess gear with telekinesis), Mutons have armor(which may have external straps or adhesive areas), and Snakemen have an armor plate(which could have straps, adhesive, inside pockets, or even a backpack.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

:We already know the answer to this one - they cheat! ;) [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

===Are X-COM transport craft piloted?===

:Almost certainly, since a remotely-piloted craft could be returned to base when the mission was aborted or failed. It's entirely possible that all X-COM soldiers are qualified pilots of the appropriate craft, since it would make no sense for X-COM to waste space on the plane for a noncombatant, or to have a single-point of failure on the mission like that. (The aliens could screw over the entire op by killing the pilot). It also explains why the craft is lost when the mission fails or is aborted with no one inside(lacking a pilot, the aliens are able to easily destroy it.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

:: On the other hand, even a tank/hovertank is capable of getting the craft back to base. Perhaps there is an autopilot function. X-com craft are also infamous for choosing strange and bizarre intercept paths, based on latitude lines... almost as if they followed some a few simple lines of code from 1993 programming (bit of 4th wall breakage there...) -[[User:Jasonred|Jasonred]]

:Of course, given the tanks seem to be remotely piloted from an X-COM base, its possible that the tank being in the craft allows the Tank pilot to reroute into the control systems for the dropship and take it over. Limiting this to having the tank inside is a rather good idea. [[User:Arrow Quivershaft|Arrow Quivershaft]] 12:07, 27 February 2009 (CST)

:I recall that the various cutscenes in the PSX version had a pilot, most notably in the "Mission Failure" scene, where it shows the pilot being killed. --[[User:Mabmoro|Mabmoro]] 16:06, 13 March 2009 (EDT)

===What sort of physical process is used to increase human stats over time?===

The increases in some stats are easy explained by experience gained on missions (firing abiility, reactions, etc.). However, in the cases of physical stats (TUs, stamina, strength) the increase must be augmented by an artificial process, since it isn't easily explainable that humans can significantly increase body mass/speed/endurance just by physical activity/exercise.

:Lifting weights will increase strength. Running and cardio exercise will increase endurance, and performing the same task multiple times will allow you to perform it faster. I see no reason natural increase doesn't work. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)
::I assume that it is possible to a human to use those methods to double its physical condition, but that being the case why are X-COM recruits so... undeveloped? Maybe this is a more intriguing aspect. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

What I don't get is that when someone gets blasted that they gain a lot of extra health. For crying out loud, the aliens are throwing around plasma and ridicoulously HUGE explosions. Shouldn't they be suffering from third-degree burns? I would expect them to at least have a major sore spot where they got hit. [[User:Tsunamiatunzen1|Tsunamiatunzen1]] September 24

:There's been arguments over whether the soldiers in X-COM are the Green Berets or equivalents of their various militaries, just average soldiers that volunteered for the job, or if the Council of Funding Nations is corrupt and is using this as an excuse to foist off their most useless soldiers onto the X-COM project. If the latter, it would easily explain their rather poor early stats. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

::Maybe the stat increases relate to the troops getting more comfortable performing all operations - lifting, running, combat actions - when the aliens no longer scare the cr*p out of them so much. [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

:: I know what you mean... if this were Jagged Alliance, it'd be like trying to hire Mike and getting Gumpy instead... ouch! ... IMHO, it looks as if the COFN is being funny about this. Clearly, the troops assigned to X-com have had extensive weapons training... each and every one of them can use just about any standard weapon, including Rocket Launchers, incindieries, auto Cannons, etc. However, NONE of them have any combat experience, coming to you as fresh rookies. And their stats look as if they were selected based on a pot luck basis rather than screening among the elite troops... [[User:Jasonred]]

:Health isn't gained from getting shot. But as for the "ludicrously low stats" issue, maybe they're being selected on some other basis, or there's a real shortage of volunteers. [[User:Magic9mushroom|Magic9mushroom]] 04:56, 25 September 2009 (EDT)

:: I think that the X-COM's soldiers have big responsibilities, can't have children. They are sworn in and only then go to the field - if someone can't be trusted to keep a secret, he's getting sacked, given a shitty job (ever wondered who maintained the General Stores?) or worse. - n, 16:47, 16 August 2010 (GMT+2)

In Hotpoint's [http://www.tthfanfic.org/Story-16092/Hotpoint+XSGCOM+Goa+uld+Defence.htm| XSGCOM: Goa'uld Defense], his explanation is that after a few missions of watching their fellow newbies die, the survivors give in and volunteer for an experimental regimen of performance-enhancing drugs. IRL, steroids and such don't result in instant strength enhancement, they just encourage accelerated development of muscles. [[User:Kalaong|Kalaong]] 03:16, 28 March 2011 (EDT)

Heh: http://www.nerfnow.com/comic/901 --[[User:Xuncu|Xuncu]] 02:52, 26 January 2013 (EST)

As much as I've played this series for decades, and know full well how pitiful the starting stats of soldiers are, at least with respect to the game's rules, I really feel I must wonder and ask why we think those starting stats are 'underdeveloped' or 'pot luck'? What, exactly, are we basing this judgement on beyond how poorly they seem to perform in-game against a force that is quite honestly and clearly demonstrated as superior to humans in the first few missions, where only luck and superior numbers appear to manage to secure any wins for the organization and, in turn, humanity? How much can the average X-COM 'Rookie' carry in pounds as gear, and is it considered substantial compared to Army kit, or not? How many direct hits from a rifle can they take normally without dying or keeling over from fatal wounds, and how does this compare to real-world soldiers' survivability? How much time is one turn meant to represent, and how far can the average 'Rookie' run in that time, and how does that compare to how fast a fully-kitted Army soldier can move?

Has all of this already been figured out elsewhere? Otherwise, I'm starting to question whether we have any real proof that 'Rookies' AREN'T "The best of the best of the best, sir! With honors" beyond just how it 'looks' and 'feels' during gameplay, which is already skewed by the enemy having superior firepower and attributes, or, in the case of replacements, existing troops being pushed far beyond previously-perceived human limits from such extreme combat maneuvers as have resulted in success against, as I said earlier, a far superior force (EDIT: want to clarify on this point that I'm taking the 'what doesn't kill you makes you stronger' stance on the original question for this section). If the stats extrapolated for OpenXcom are any indication, this is most certainly the case, even with Sectoids, to an extent. While Sectoids will never have anything on humans in the Health department, being as fragile as they are (though some rookies can have less health, apparently, but only a few unlucky ones), they are surprisingly enduring, with tons of stamina, being 20 points higher than the X-COM 'Rookie' maximum upper limit for initial stat generation, and the same for Bravery (though this seems to be the case with all AI controlled entities, except mechanical ones, which have an impervious 110 Bravery). Reactions are also higher than possible with a Rookie, and speed (TUs) is on par with the statistical average for rookies, same with accuracy ratings, and even strength. This is just looking at the grunts, too, not even considering the stat boosts Leaders and Commanders have. As expected, the average X-COM Rookie's stats are almost universally superior to the civilians, representing the average member of humanity. The only exception is Stamina, and I'm starting to think this is to compensate AI units somehow for an AI that may not be able to manage energy levels as well as a human.

Anyway, just felt someone had to bring this up here. If it really is explained elsewhere, it probably should be clarified here, as well, for consistency, anyway. (EDIT: I just felt it was being taken at face value far too readily in this discussion, and it just didn't seem right to just assume it with no evidence, despite all my experience playing this series, and noticing full well the soldiers' stats feeling constraining at first) --[[User:StormhawkAPS|StormhawkAPS]] 01:08, 4 October 2013 (EDT)

=== What happens to UFOs that do Terror/Retaliation missions? ===

Both, the Terror missions and the Alien Retaliation end the same. A UFO comes along, reaches some point and disappears. The aliens do their terror/XCom base destruction and after that ... crickets. Nobody picks them up, nobody cares about them, nothing.

Check it for yourself. Go to a Terror site but abort. The site just disappears (if you go to an UFO landing site and abort, the UFO is still there, flying away).

Or try this. Go to the Terror site and defeat the aliens. Well, aren't you missing something? The UFO! What UFO? There isn't one. Well, that is the point!

Or if you allow one of your bases to be destroyed, the UFO arrives at the base and then the two just ... disappear. Where do the aliens go? Given the fact how strapped for resources they are (check the question about why the aliens use so little force in the war), I find it pretty perplexing.

Maybe the UFO dumps these crews on these sites, shots directly upwards all the way to space and waits in the orbit for a signal from the ground. When the aliens on Earth finish their terror/destruction, they send their signal, the UFO shoots back down, picks the crew up and shoots off. This is why you can't see it.

Except there is a plethora of plot holes in this theory. If that is the case for these two missions, then why don't ALL the UFOs do the same. Well the scouts obviously have to find a suitable spot first, hence the flying to and fro over a region but why they enter the atmosphere from a quarter-of-the-world away and fly at high speed to their intended region is a mystery to me. Did they get lost or something? And why the large UFOs need to do these sweeps too??? Can't the scouts just send them some coordinates so they could dive in directly instead of parading in front of XCom radars???

Ok, wait a minute. Aliens use hyper-waves for long range communication and navigation, including detection and ranging (hence Hyperwave Decoder). They use psionics for short range communication. Mankind uses a much more primitive means for both, communication and detection and ranging. Where did I hear this before? Oh, yes! The UK radar system from the second world war. Thing is, at that time UK needed a radar fast so they went with something primitive that could be developed and constructed quickly. Then the German's Zeppelin came to investigate. And left. Then the Germans attacked but ... they did not destroy the radar. They attacked it once but a few days they left and left the radar alone, never to return to it. They lost the war for Britain as a result. Why Germans did not destroy the radar was a complete mystery for a long time. Then long after the war some Brits came in contact with the German officer who led the German invasion of Britain and asked him "why did you not destroy the British radar system". The answer? "You did not have a radar system!" It turned out that Germans had so much more advanced radar systems that they could not recognize the primitive British radar design for what it was. Yes, the Germans did detect the British radar signals but they concluded it was just power grid arcing. Check [https://www.youtube.com/watch?v=a60LJGYK-ZQ The Secret History Of British Radar] for details. This gives me the idea that the aliens also believe humans can't track their UFOs because the aliens don't see any human made hyper-waves or psionics. Yes, they can hear strange electromagnetic noise in some areas or even in most populated areas but they assume it is "just something arcing there". This could also explain why they have to search for an XCom base for quite a bit of time before they can attack it. XCom is a top secret organization and it is tiny. All that psionic noise from all the humans around it must be hiding the bases pretty successfully. Especially when you build a "mind shield" there (which is just an over-powered psionic noise maker) ([[User:TowigOs|TowigOs]] ([[User talk:TowigOs|talk]]) 02:04, 4 August 2025 (UTC))

==Enemy Unknown/UFO Defence issues==
===Why isn't Earth overrun by Snakeman/Chryssalids?===

According to the UFOPaedia, Snakemen's "Reproduction is asexual, with each snakeman carrying up to fifty eggs inside its body at any one time" adding the ominious conclusion: "Left to its own devices this species would be a severe threat to life on earth."
Moreover, this species is usually accompanied by the Chryssalids, which have a capacity to reproduce themselves very quickly using humans. So, any survivors of crash sites or terror attacks could start reproducing themselves hidden, resulting in large areas being overrun by those aliens later on.

Possible answers:
* Both races have a self-destruct mechanism incorporated into their psysiology to prevent this.
* The entire area is purged by large scale bombing. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)

::One thing suggested in fan data was that Snakemen have air tablets in their stomach...which may be different from earth's atmosphere, which would limit their lifespan in earth's atmosphere, also making egg-laying pointless, since the offspring wouldn't be able to breathe or survive. It has also been suggested that Chryssalids have a very rapid metabolism. Though Chryssalids are likely just as, if not more useful, as a threat or a bargaining tool. When attempting to get a nation to capitulate to their demands, the aliens could threaten to employ Chryssalids en masse, or offer to remove a mass infestation in exchange for the government's cooperation. Or even further, it's possible that Chryssalids are under Ethereal control and maintaining the control link at that distance is taxing, thus eliminating mass use of the creatures. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Two words: [[Alien Containment]]. That answers everything except for the UFOPaedia articles for the aliens themselves which contradict it. --[[User:Zombie|Zombie]] 00:42, 26 February 2009 (CST)
: For captured aliens, yes. But what survivors of uninvestigated crash sites? [[User:Hobbes|Hobbes]]

::Zombie is commenting that based on the need for an Alien Containment unit, the aliens cannot survive in earth's atmosphere for extended periods, needing special atmospheric blends and/or nutrient pools which earth is unable to provide naturally, thus limiting their operations outside of the craft. (If the aliens won the war, it's likely this would be one of the first things that they would 'correct'.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:54, 26 February 2009 (CST)

===What is the propose of the 'disco balls' found inside some UFOs?===

:Given that they explode, they could be storage reservoirs for coolant for the computers or other systems. They could also be circuit breakers or electrical junction boxes, or even a component of the UFO's particle beam they use to fry X-COM Interception craft. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Here again, two words: [[Alien Entertainment]]. Even though the spheres are not set to Alien Entertainment in the MCD files, they are almost certainly related to the process somehow. --[[User:Zombie|Zombie]] 00:42, 26 February 2009 (CST)

:Maybe they are for having discos? [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

:Presumably [[Alien Entertainment]] is psionic in some way, maybe they're Psi-Emitters or something? -[[User:magic9mushroom|magic9mushroom]]

::'Disco balls' = Alien 'LSD' emitters. Travelling through space to go on almost-suicide missions force aliens to develop POWERFUL relaxing devices to entertain themselves and not go insane :P. --[[User:Nekrocow|Nekrocow]] 20:10, 24 June 2012 (EDT)

::: Assuming it's about eyeball-like pod #3, it's absent on base maps, and present only in two UFOs: Battleship (in Alien Entertainment), but Terror Ship on the second deck has one in Alien Entertainment room, but two on the bridge. Those are also the only two ships running ground battles and carrying Terror Units (bases have them, but normally don't expect to use them), so... either remote control psionic relays or something else related to ground combat? -[[User:TBeholder|TBeholder]] ([[User talk:TBeholder|talk]]) 21:04, 30 December 2015 (EST)

===Who buys those alien bodies/equipment from X-COM?===

:Equipment likely goes to the funding nations or the international black market. No rebel group is going to ask too many questions about being offered guns that can [[Heavy Plasma|slice through the hull of an MBT]] or [[Alien Grenade|grenades that can level a building]] or [[Blaster Launcher|man-portable guided missiles]]; it'd just be cash-and-carry. Similarly, scientists would likely be interested in looking at much of this stuff for their own research. This would also explain the lack of market forces; the funding nations could have a set price for each item, or if X-COM is selling them under the table to rebels and rogue scientists, they can set the price and refuse to budge. The money on corpses could also be an "Alien Bounty" paid by the Funding Nations, as a reward for each alien that X-COM can prove they killed. Or it could be bought by other groups...rumor has it that some fast food restaurants have processes that can make ANY meat, no matter the source, look and taste the same, and a Muton would make a LOT of McBurgers. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)
From the USO (Kasey Chang): XARQUID SUSHI.

===How did the aliens get to Mars?===

There are no indications that UFOs are capable of faster than light speed. So how did they get to Mars in the first place?

:The UFOs are mission craft, used for the legwork. The fighters; we never see the carriers. Given the aliens have been proven to be interstellar, they either Clone-A-Crew as needed when coming the long way to keep the UFOs crewed, or its far more likely that the aliens did have or still do have larger "Carrier" ships, which are capable of FTL travel, that were/are further out in the Solar System that store and dispatch UFOs to mission locations. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

:: One word: TFTD. The entire city of T'leth was put into cryogenic suspended animation? Or look at X-com Interceptor. X-com and the aliens show the ability to enter hyperspace or whatever it is.
::: T'Leth is another mystery of its own. More to that later on :) [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
::... there are no indications that the UFOs are INcapable of FTL... I don't think you would want to perform FTL travel within Earth's planetary atmosphere!
::: There are no indications that they are capable as well. And X-COM scientists don't seem to detect any FTL capabilities in UFOs during their research. And after the war the Elerium stocks dwindled, and it would make sense to perform some sort of interstellar missions to detect and harvest Elerium, however none are mentioned. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
:::: Unless you count the events of X-com Interceptor? [[User:Jasonred]] [[User:Jasonred|Jasonred]] 21:15, 26 February 2009 (CST)
::::: I am refering to the events between Enemy Unknown and TFTD. There is clearly a big distinction between the alien craft on EU and those of Interceptor. [[User:Hobbes|Hobbes]] 09:38, 27 February 2009 (CST)
::::: Enemy Unknown is set in 1999, TFTD in 2040, Interceptor in 2067... looks entirely plausible that they DID begin research into space exploration immediately after the events of Enemy Unknown. These things take time you know. Remember that the universe is a huge place, and Earth had rather limited Elerium Reserves by the end of EU. It takes... what, 30 Elerium just to fly an Avenger halfway across Earth? They could hardly afford to fly around randomly in space HOPING to come across elerium, they had to figure out detections methods, then scan the galaxy sector by sector, possibly partially using non-Elerium based propulsion at times... I can't remember if it's canon or fanfic, but I remember reading that all Elerium on Earth was reserved for space exploration.
As for FTL, Earth does get it for sure sometime between 1999 and 2067. And I'm pretty certain the technology is Elerium based. It's not a huge logic jump to assume that the aliens have access to FTL Elerium based tech.
Though I'm a bit puzzled why all T'leth technology is based on Zrbrite, when the aliens uniformly use Elerium, all the way from Earth to Cydonia to the far reaches of space. -[[User:Jasonred|Jasonred]]

:It takes 12 Elerium to fuel an Avenger, though how much 1 Elerium is is an ongoing debate. As for Elerium, it was reserved for propulsion research when the funding nations divvied up X-COM's resources, and then they blew it all without learning anything more than the original X-COM scientists. And yes, Earth clearly gets FTL after TFTD but before Interceptor. The reason Elerium is not used in TFTD is because Elerium becomes inert and useless upon contact with seawater. Similarly, seawater aggressively corrodes Alien Alloys and eventually completely dissolves them. Zrbite functions similar to Elerium, being gold mixed with alien bio-material. Unfortunately, Zrbite only works when supported by a massive energy grid created by T'leth and becomes inert upon its destruction. [[User:Arrow Quivershaft|Arrow Quivershaft]] 12:07, 27 February 2009 (CST)

OK... take the UNIT of elerium out of the equation... let's say that Earth had 5000 units of elerium, so 6 units get's an Avenger halfway around the world, and 12 units is sufficient to reach Mars. Hardly enough fuel reserves for intergalactic travel then.
2065 On October the 27th, the probe 'Tombstone 1' returns reports to Earth. It's data show that the globular star cluster where it rests, one hundred light-years from Earth, contains many life-supporting planets. Many of the planet's within the probe's scanning range also apparently possess great mineral wealth, including trace veins of elerium-115.
Hmm... So, mankind discovers FTL technology on their own in those 65 years? ah... come to think of it, if they've got non-Elerium based space travel and FTL, and more powerful weapons too, what's the big deal about Elerium in the Frontier? Does mankind even need it anymore?
As for T'leth, it is meant to be over 65 million years old, and CRASHLANDED on Earth due to a solar flare. Was the Ultimate Alien a prophet, thus chose to base T'leth on aqua plastics and Zrbite when T'lth was first constructed? Or did T'leth crash land, followed by frenzied activity where the entire city was replaced part by part, the alien alloys swapped for Aqua Plastics?
...
Actually, come to think of it, it's obviously a massive plothole due to limited timeframe, no point in discussing too deeply. Sigh... [[User:Jasonred|Jasonred]] 13:50, 27 February 2009 (CST)

:It's implied that despite the loss of ability to use the alien technology from the First and Second alien wars, simply being able to see and examine their designs catapulted earth's technology forward at least a few decades...which really is entirely reasonable. Much of the technology can be replicated on earth, and the principles and designs can be reapplied.

:As for the deal with Elerium, its needed to power stronger weapons and is also wonderful for power generation; its efficiency in power generation is what allows Mega Primus to even exist.

:And was there anywhere that specifically said that T'Leth was made of Aqua Plastics? I don't recall. Yes, the rest of their subs are made of aqua plastics, but I'm wondering if something the size of a medium city might perhaps be made of something a bit more durable. PS: Thanks for signing your post! :D [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:17, 27 February 2009 (CST)

It's not a plothole at all. There is no Elerium on Earth, whereas the aliens can manufacture Zrbite on Earth, since there's gold here. Therefore it's obvious why they used Zrbite. Also, there's the fact that it was an Aquatoid colony mission, intended to produce an "aquatic paradise", so using Aqua Plastics instead of Alien Alloys is perfectly justified. [[User:magic9mushroom]]

:I think that the use of Aqua Plastics instead of Alien Alloys is perfectly justified by the fact that T'leth crashed million of years ago while the aliens that came to take a shot or two at earth were two million years ahead technologically. So Aqua plastics was some plastic that was used by aliens before they've got the Alloys. You might argue - it's Aqua Plastics, so Aqua =/= Space. Well, Aliens weren't calling them aqua, and there wasn't anything saying that Aqua Plastics is not suitable for Space Travel. --[[User:Domenique|Domenique]] 11:10, 19 May 2010 (EDT)

... I think Alien Alloys alone would catapult earth's technology forward a decade, and there's no reason humanity can't use those anymore, just not in water. According to timeline, some space pirates manage to make the decommisioned Avengers run on non-Elerium fuel... a large technological step.
By the time of Interceptor, Elerium weapons aren't that powerful. Good point about power generation though.
I would assume that T'leth SHOULD have been constructed out of Alien Alloys, since it was originially an interplanetary vessel? Generally, everything in EU was made of Alien Alloys, everything in TFTD was made out of Aqua plastics. Both of which seemed plenty durable.

::Have you noticed that the UFOs fly however their mission parameters tell them to? The UFOs pretty much IGNORE interceptions by X-com craft... if their mission tells them to make 3 passes, speed up, slow down, speed up... they will follow that pattern exactly, whether X-com craft are firing on them or not.

::Question: How long does it take the Avenger to reach Mars from Earth? [[User:Jasonred]] [[User:Jasonred|Jasonred]] 19:12, 26 February 2009 (CST)
:::No longer than a week, in my opinion. Probably less than 2 days. Since canonically, the design of the Avenger had the Cydonia mission in mind, it would be capable of very high interplanetary speeds. (You could choose to burn 40% of the Elerium in one blast to get to high speed. Or you could burn even more and refuel while it's landed...or it could be a mission with no guaranteed escape for the crew. The lives of the many over those of the few and all that, especially since the war hinges on the mission.) In addition, you can fit a full complement of soldiers on board with no real excess room for supplies, and the longer it takes to get to Mars, the greater the chance the aliens will spot it coming for them and mount a serious defense. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:20, 26 February 2009 (CST)
:::If you'd burn that much fuel to accelerate the craft then you'd have to use as much again to decelerate it and attain a planetary orbit, otherwise you'll simply overshoot the planet and head towards outer space. This is also another aspect to take into account when thinking about the speed of UFOs. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

::: UFO drives are non-Newtonian so those sort of rocket equations don't necessarily apply. I think filling up a car with gas is a closer analogy. [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

::: Well, they could put a mini mind shield on the Avenger, shoot down a UFO roughly their size, and then fly to Cydonia when the UFO they shot down was supposed to return based on the instructions found by the hyper-wave decoder. Basically taking the place of the UFO. Shouldn't be too hard since the UFO's are pretty common by the time you research Cydonia or Bust. [[User:Tsunamiatunzen1|Tsunamiatunzen1]] 14 February 2010 (MST)

::That would leave 20% of the fuel to take off the Avenger and land it. Not really that unreasonable. While they're landed, they could potentially refuel the Avenger, or the mission might have been planned as a 1-way trip from the get-go. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

Perhaps Elerium-based drives are a bit like Ramjet engines, where they're actually useless or inefficient ''below'' a certain threshold speed? --[[User:Xuncu|Xuncu]] 03:02, 26 January 2013 (EST)

===What happened to Mars and the alien civilization there?===

According to the Brain, Mars was blooming with life had a alien civilization millions of years ago. However, Mars nowadays is a barren world and the alien civilization seems reduced to the area on Cydonia.

:That may well have been before Mars lost the majority of its atmosphere due to its weak magnetic field. As the atmosphere dissipated, the aliens left or died off. It's also possible that the aliens, shown in the game over to have little respect for planets other than as sites for slaves and resources, they strip-mined the planet dry(and the rust from the machines created the red coloring), and then seeded Earth so that the slave workforce would grow for future extraction of Earth's resources. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

===Where are the human-alien hybrids referred to on the UFOPaedia?===

:For the ones on earth, probably in hiding or in laboratories for research. For the ones the aliens have, potentially improving the Sectoid gene pool or being used as food or menial tasks. Cloning is alot easier than making genetic hybrids and there's nothing that says their first-generation experiments would be suitable for combat. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

:: They are babies at the time of X-com, and few in number. Their aren't even that many of them by the time of X-com Apocalypse. [[User:Jasonred]] [[User:Jasonred|Jasonred]] 19:12, 26 February 2009 (CST)

:Not to mention the ones in X-COM: Apocalypse are less-than-fit for battle before extensive training. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

===Why did the aliens only activate T'Leth after they were defeated?===

On TFTD T'Leth is shown as an entity/city of major power that is capable of conducting a war on its own. But the aliens leave it dormant although they could have used it to speed the process of taking control of Earth.

:Perhaps the Enemy Unknown aliens are legitimately scared of the TFTD aliens and are unsure how long they could trust them. Evil is not monolithic; the TFTD aliens may be more interested in themselves than the alien empire, so they were kept as an ace-in-the-hole. This is the same reason (canonically) that SKYNET did not originally send the T-1000 to assassinate Sarah Connor; SKYNET was scared of what the T-1000 could do and had only a bare minimum of control over it, so it only used it as an option when it had nothing left to lose. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

T'Leth is in fact so powerful that all it has to do is surface, in order for X-com to be considered to have lost the war.
In fact, looking at the timelines, it takes 40 years for T'leth to wake up from it's slumber... that's one good reason not to use it. By the time it activated, the war would already be over. [[User:Jasonred]]

Because the whole purpose of the Enemy Unknown aliens was to rescue the TFTD aliens from T'leth, and there was no way of seeing whether the T'leth-based invasion in TFTD would even work - from their perspective it's possible that getting T'leth to bootstrap itself could have caused a catastrophe (they don't know whether or how badly it's damaged). Presumably the aliens planned to mount a proper rescue operation after locking down Earth and readying it for the aquatic paradise that was the entire point of the T'leth expedition in the first place. [[User:magic9mushroom]]

T'Leth was a coleny ship sent by the Sectoid/Aquatoid's millions of years earlier. This is why the Aquatoids use electronics to augment there control over other creatures, while there progeny are genetically modified to gain the same control. In TFTD it's implied that the T'Leth had been partialy active for a long time. Thawing out aliens in small groups but never going in full production. UFO aliens may have not intended to start the full awakening cycle until they had a chance to prepare the planet.
OR, given the Ultimate Alien was aquatoid in origin by his looks and there was no other races from the first game involved. And the fact that Sectoid/Aqutoid's are not the top of the food chain with the Ethereal and Brain being more powerful it's possible the brain had decided that the Ultimate Alien was a threat to it's power. It was not until it's death that they tried send the signal. --[[User:BladeFireLight|BladeFireLight]] 17:19, 22 March 2010 (EDT)

===Why did the aliens use limited force during the First Alien War?===

Imagine Independence Day or War of the Worlds: UFO above the major Earth cities destroying the national leadership and any resistance. Or simply announce to Earth that they are now a part of their empire and resistence is futile. Instead, they go 1 mission each day, allowing humans to capture their craft, research their technology, discover their intentions and mount a successful defense. Don't the aliens watch sci-fi movies to see how it should be done?

:Perhaps they don't have the standing forces to do so, and are in the process of building up the forces needed to do so. Perhaps they don't want to wipe out the entire power structure too fast; they want to leave some pieces in place for when they rebuild. Perhaps they're too condescending to think that humanity ever really has a chance; they've probably conquered thousands of other planets without anyone ever successfully resisting them. Perhaps they consider the X-COM project to be a rearguard action that, while a valiant effort and a credible threat, is ultimately doomed to failure because they simply cannot win in the end, which is why they undermine it. Indeed, the reason you need to launch the Cydonia mission in order to win is because X-COM simply cannot stop the aliens in a ground war; the aliens have an effectively infinite supply line and standing forces(though nothing says they're all waiting to swamp the earth), and the only way to win is to kill the command staff(which the aliens believe X-COM will not be able to do, lacking both knowledge of where the Brain is and any practical means to get there.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)
::The most plausible explanation seems to be the one employed in the Worldwar series, by Harry Turtledove, but that does not seem to mesh with what the Brain says about having been on Mars for a while, since then they could watch the Earthlings perpetually. Of course, what it says is probably a bunch of lies. Thinking about what it says for too long also raises the question of why the aliens attacked when they did, of course... [[User:Vizzydix1|Vizzydix1]] 21:52, 18 March 2010 (EDT)

The aliens are completely lacking in weapons of mass destruction. When you get right down to it, their aircraft are very fast, manuevarable and durable, but they have rotten firepower. Even the battleship is unable to bring down an Interceptor in 1 shot.
The terror missions and X-com Base Defences prove that the Aliens are unable to simply launch orbital bombardments... in fact, they appear to have no Air to Land weapons whatsoever...
When you get right down to it, the aliens are pretty stupid. Also, their scientists seem inferior to Earth's. Seems to me that they only had the advantage of Elerium deposits and thus elerium based research.
X-COM was unable to win in an all-out war with the aliens, but remember that X-com is a small little covert group with several dozen soldiers and a handful of aircraft. Can you imagine the result if the aliens had caused a joint war effort by the UN? You would have Lockheed factories converted to Avenger production, several platoons of soldiers outfitted with Flying Suits, Lasers, Heavy Plasma, thousands upon thousands of Laser Tanks...
I would say that keeping the fight to covert action on both sides was actually beneficial to the aliens, really. [[User:Jasonred]]
* Nope, the aliens could just invoke John's Law and blow up the planet with a kamikaze battleship at .9c. Even failing that, the alien battlefleet could come in numbers sufficent to blot out the sun.--[[User:(name here)|(name here)]] 14:39, 8 November 2009 (EST)
** Lest we forget, X-Com is essentially the Spartans to the aliens' Persian Empire. So they'd just fight in the shade (which would be a blessing in desert missions). --[[User:Guido Talbot|Guido Talbot]] 13:58, 16 July 2010 (EDT)
*** Mass producing those technologies on such a large scale would be impractical considering that those said technologies sans Laser Technology rely heavily on Elerium. Thus the Earth forces would be heavily reliant on downed or landed UFO's to resupply their Elerium powered craft making such efforts pointless.

Aliens first began with smal scouting missions, so maybe all we expirience in X-Com is initial attacks by aliens, maybe the whole base was begining scouting and waiting for the invasion fleet? Aliens problably could be in sense dumber than humans, humans are adaptable and thinking, our technology advances fast, and we are fast and smart enough to stop the invasion before it begins. Aliens problably were not used to it so they thought "oh well, another invasion...". --[[User:Domenique|Domenique]] 11:10, 19 May 2010 (EDT)

Mankind, as a whole, is incredibly cunning and full of guile. We are also incredibly aggressive. A trait that the most of the Aliens can barely concieve. Though we are weaker physically, mentally, etc, we are overly developed when it comes to strategem and war. The aliens are, in essence, have come to an inverse of Flatland. Though they are advanced, it is they who are 2D to our 3D approach to fighting. They return to earth, and through extensive research and testing, determine that inferior are strategically to humans. So...they use their advances to what they percieve as the most full advantage, and call for reinforcements over the initial months of the First Alien War. For eons, only the Sectoid make arrivals to earth. When the Brain finally realizes the situation, that mankind has woke up and is dealing with them most directly, it begins to get desperate, it sends reinforcements, but only incrementally. (Its always focused on peak efficiency). The concept of overwhelming force is illogical and some how, disdainful, to it. It prefers nuance, interogation, politics, and assessment. The Brain determine that its more effective to eliminate allies of XCOM than to face it directly. The concept of obliterating anything from orbit is reprehensible. Everything must be examined, especially the dead creatures you leave behind. Over time, it would learn man's tactics and assimilate. In fact, each race called in is an example of the Brain adapting. The Floaters bring forth an extra dimension to combat. The snakemen aggressiveness and accuracy. Mutons a culmination of superior warrior breeding, raw physical power, and determination not unlike the so called human soul. Finally, the Ethereals enter, with capacity to bring overwhelming force. In time, as they do on Mars base, they might begin joint force attacks with Mutons backed by Ethereals, supported by a mix of terror weapons. Fortunately, the First Alien War is ended before they fully develop such cunning. Hence the desperate act of T'Leth. The Brain has learned the power of anger fueled by vengeance and desperation.
--[[User:BlackLibrary|BlackLibrary]] 11:10, 29 May 2011 (EDT)

:I've always viewed it as primarily a lack of resources. Even if you get a UFO every single day and shoot them all down so that there's no possible chance of any of them being the same UFO that's still only several hundred to perhaps a thousand or few UFO's over the course of several years. And most of those are quite small and not too difficult to take out with regular old interceptors and human armaments. If used all at once it might be enough to achieve air superiority, particularly if the Battleships do all the heavy lifting. But it also might not. It certainly would NOT provide enough soldiers to mount a worldwide ground offensive. The crews on those ships aren't all that big. There's also no reason to assume that all those craft, weapons, soldiers, and more importantly... elerium are all available at the same time. It's quite likely that the aliens are cloning new soldiers, building new weapons and UFO's, and possibly receiving supplies (particularly of elerium) from deep space. Elerium is needed to manufacture a lot of their stuff as well, and we already know it's a limited resource in our solar system. Consider on top of that how much get's used up as fuel every time a UFO visits Earth. If they sent all their UFO's they would use up their reserves of Elerium all at once for a 1 day attack that ultimately would fail. Instead of conquering the Earth wholesale they are trying to influence governments into signing secret pacts with them so that they can control the population of the Earth rather than wipe us out. They do this by using terrorism to intimidate the public and inserting clones to infiltrate governments while holding secret negotiations. A steady stream of UFO missions keeps up the pressure until governments break. Lucky for us they never expected us to bring the fight to the command center on mars. Just imagine if they had built base defenses like we can for our bases. heh Lord would it be aggravating building up a crew of top notch soldiers, constructing an Avenger from scratch, scrapping together all the gear, sending it to Mars, and then watching it get blown to bits before it even lands... O,o Also consider that their UFO's have operated with relative impunity for a very long time. Presumably XCom is the first organization to shoot down a UFO? As for Earth ramping up for a full scale war, it'd be unlikely that we could really produce enough alien technology in any reasonable timescale to actually outfit whole nations armies, especially with limited Elerium. Perhaps the tech that doesn't require Elerium, but then again shifting an entire army from one weapon system to another is not as simple as merely producing all the weapons. It's an extremely long, arcane, and baffling process. Getting just the branches of the US military to switch to laser weapons would probably take at least a decade. I think that limited resources and the intent to control and dominate rather than eliminate the population of the Earth explain it. For that matter they would see the human population it-self as a resource. Hence the use of small scale terrorism rather than attempting to use any weapons of mass destruction. A bunch of aliens walking around shooting people is still pretty damn scary stuff.[[User:Mannon|Mannon]] 13:12, 30 March 2011 (EDT)

I would have thought that the simplest answer here is best. The aliens are manifestly unable to survive outside containment or bases for prolonged periods. Further, their clearest technological advantage over the humans (at least, prior to X-Com research) is mind control. Therefore, their primary method of offence is not to get bogged down in a ground war, but to engage in the overthrow of governments by infiltration, coercion, corruption and bribery, and achieve complaisance by terrorisation of the general populace. It is for this reason that standard combat tactics involving large hierarchies are ineffectual against the aliens (when the government/command can be mind controlled and the theatre can be defined by a mobile alien force). A decentralised, partly cellular, covert approach like X-Com is preferable, but unable to win an outright ground war either (being composed of, at maximum, 250 soldiers). Of course in reality, the irony is that the aliens/bourgeoisie/Fox network have Mind Controlled you, the X-Com commander into wasting your time with retro video games instead of doing anything about their societal control!
--[[User:Oogleshay|Oogleshay]] 16:16, 18 October 2011 (EDT)

My theory is that the aliens are deliberately trying to be low-key because they know once the UN can no longer keep the invasion a secret, they will have no reason to pull their punches at defending Earth. The aliens want to make it so that once humanity at large fully realizes what's going on, it's already too late - they're poking the sleeping giant but take care not to awaken it before amputating all limbs to make it unable to defend itself once awake.--[[User:Amitakartok|amitakartok]] 06:33, 14 January 2012 (EST)

Perhaps the aliens suffer from a lack of proper logistics. If we assume that their purpose was to retrieve the lost colony ship(T'leth) then it wouldn't seem particularly likely that the aliens would have brought along the necessary logistics to support a full scale invasion of Earth. Furthermore it is quite possible that the alien ships you encounter in the first XCOM are actually not dedicated invasion ships but rather re-purposed fighter ships(which would explain the total lack of artillery or bombardment capabilities).
--[[User:Theinsomniac|Theinsomniac]] ([[User talk:Theinsomniac|talk]]) 22:47, 17 February 2014 (EST)

I disagree with all this. "Mankind is the greatest species." - hogwash. The aliens are clearly capable of wiping out humanity when they wish, if you read the whole of the lose game screens. The game had to be designed to give humans a chance to fight back. With this caveat: the only reasons the aliens don't start wiping out the population would be to preserve humanity. With the harvesting and abduction missions, clearly they are looking for something in the fauna and flora of Earth. Something that a massive assault would make improbable to find due to the overwhelming loss of life that would occur. The most logical explanation would be that the aliens want to harvest specimens with specific genetics traits, so they would want to be able to sift through as much of the population as possible to find those with the best traits. Before wiping out the rest of the "inferior specimens". This explanation would also fit to the story that the brain tells at the end of the Cydonia mission (if that story is more than just a desperate attempt to save itself.) [Why the aliens are so incompetent is due to incomplete development of the strategic layer by the designers, especially with the economy.] [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])

Obviously, in the remake, this is much more easily explained as the Etherial search for Psions making human extermination ''not'' being their goal (but in fact, the ''last'' thing they want, since we're the best shot they got for their apparent true goal: ascendance), but to an limited degree is is reasonable to retroactively apply this motivation to the 1994 Etherials/Cydonian Brain. On a similar vein, where the Gallop Brothers even thinking about T'leth yet during Defense's development? I saw not too long ago, I think on the History Channel, of a 'realistic' take at trying to fight off an invasion/occupation force, also noted to be about harvesting, not about outright killing all humans: with presumed FTL tech, even someting a fraction of lightspeed, and the number and masses of UFOs involved both in the special and in XCOM; it'd be much easier to just strap some engines on some large asteroids and spam them at Earth, which those points prove is possible: a much easier and effective means to exterminate humans, if the goal was xenophobic in nature--- but I digress. Consider.. hmmm, yeh, the US invasion of Iraq or Aphganistan: we COULD of just nuked the hell out either country and called it a day. Presuming a lot, but maybe some of the same reasons America didn't are the same? Intergalatic politics not allowing such WMDs? Excessive collateral damage wasn't their interest? Looking for something specific on an individual basis? That the aliens (may) want slaves, and reasons on that vein, is a big difference they have. Going back to the special, how humanity won is by a mass infitration/kamakaze attack on the barge/battleship-sized UFOs, and making it "not worth" continuing the occupation (in similar nature to people wizing up to Bush's bullshit and losing so many soldiers to cheap-ass IEDs and Soviet-era tech making the Iraq War unpopular)..... again, assuming alien behaviors and mechanics of motivations are anything remotley "human-like". So, at best, I'd ascribe the 1994 alien's motivation as the same as in the special: conquering for resources. Cortez conquering my ancestors for gold. --[[User:Xuncu|Xuncu]] ([[User talk:Xuncu|talk]]) 08:03, 18 February 2014 (EST)

My personal theory in regards to this is simple. To get to Mars from where they originated they would have to travel at relativist speeds (at or at least close to the speed of light) this requires a lot of energy and at this speed every microgram counts. (a single microgram of cargo can cost a ton of fuel at FTL speeds).
So the aliens travelling to Mars, instead of bringing a massed invasion fleet bring the bare minimum. Embryos or even genetic samples for each of their species, blueprints for weapons and equipment, basic manufacturing facilities, mining equipment and a transport vessel designed to be cannibalised to set up the initial Cydonia base, with only a ghost crew to start things off.
This explains the year prior to the start of the game (the steady increase in UFO reports, abductions ect.) the aliens need resources, they probably got some from mining the area around Cydonia to build some of their equipment but to grow clones they need a nutrient medium (not to mention the food they need for themselves) which means they have to go to earth and harvest. The initial missions were probably in areas such as the ocean, or jungles, harvesting flora and fauna. But given how little they would be able to harvest this way (they would have trouble finding enough protein not to mention the fact that mutons are said to be obligate carnivores) which meant increased incursions on populated areas (such as farms) add to this the lack of genetic diversity means that they would abduct humans to help provide some means of altering their genetic code to better handle earth diseases and atmosphere.
This can also explain why you only get small UFOs initially, they don't have the resources to build battle ships (until they have mined enough to expand their production facilities and build bigger craft). It also explains why they lack weapons.
TFTD show that the alien's method for “education” is to just implant knowledge. What this means is you have a bunch of aliens with the same hard-wired brain (clones) and with the same knowledge. Limiting their ability to adapt and change (they don't have years of experience to work on, nor have they had to think of the knowledge they have it's just given to them as fact).
Once X-com is formed they now find themselves battling an enemy that not only adapts to use their technology but builds on it (personal armour, power suits, flying suits, fusion ball tanks, ect). The whole alien invasion is doomed from the start.
Given time the aliens could have built up a massive fleet capable of overwhelming earth (which was probably their initial plan) but due to X-com getting involved that plan got knocked back. They can mine Mars and the asteroid belt for minerals to build their weapons, but without raiding earth for the fauna to feed their troops and grow their clones they can not build an army.
The aliens probably observed earth previously. (maybe Roswell was a scouting mission which failed to return) as such they underestimated our detection and interception capabilities (the back-story actually states that X-com is using the best craft available and previous attempts to intercept UFOs failed using conventional earth technology, which probably explains the limited weapon load-outs for x-com craft (they are built on high speed prototypes designed as proof of concept not actual in service craft so they had to jury rig hard points).
This basically means that the aliens were unprepared for earth's level of resistance, before they even had a force capable of fighting. If they had been more careful, built their forces in silence (by farming wild life in the jungles and oceans, instead of going for rich targets like farms to load up on cow parts quickly) they may have been able to launch an invasion before earth even knew what was happening (just imagine if the game started with 20 battleships over every country, mutons march down the streets carrying heavy plasmas and blaster bombs, while snakemen and chrysalids strike major cities, all the while ethreals are mind controlling everyone... try winning that game with just 2 interceptors, a couple of rifles, some heavy weapons and 8 soldiers who can't hit the broad side of a barn from point blank range with a guided rocket --[[User:crwydryny|crwydryny]] 14:50, 30 December 2015 (GMT)

I think that the aliens simply had no concept that they could be defeated. By analogy: when a dog trainer shows up to tame a savage dog, she's not showing up with a troupe of armed bodyguards, because that would be a silly level of overpreparedness. She's not worried the dog will outsmart her. She's not worried that the dog will figure out how to handle the leash, wrap it around her neck, and then demolish her car. If anything like that started happening, she'd be so utterly astonished, because it's never happened so far with any of the dogs she's trained. She'd be slow to react or to adapt her strategy, because the situation would be so difficult for her to believe. Dogs just don't behave that way! Similarly, the combination of battleships, mind control, and plasma has always been so overwhelmingly effective that the Ethereals have never needed to be smart, or adaptive, or even make accurate assessments about the intricate details of the planets they're taking over. Plus, they're a society of clones operating in a strict hierarchy, and literally sharing thoughts psionically. They probably have only a vague understanding of "individuality", and I doubt they have much understanding of guerrilla warfare, because they've never seen it succeed. Their political and interpersonal dynamics are vastly simpler than ours. I doubt that they're even aware that X-COM exists as an entity that is independent of our world governments. [[User:Jessicest|Jessicest]] ([[User talk:Jessicest|talk]]) 22:23, 15 March 2020 (UTC)

The question of ages “Why aliens never have the smart of ramming Earth with a UFO flying at sub-lightspeed?” They have plenty of smaller UFO to spare and given there are no advanced bases on the Moon and the absence of “carrier-grade” UFO, interplanetary travel should be quite feasible to them, thus their UFO can achieve sub-lightspeed. Actually, a similar question is also presented in Star Wars “Why Galactic Empire never rams a Rebel-controlled planet with a Star Destroyer flying at sub-lightspeed?” So I made up an answer for both questions: When a spacecraft’s velocity approaches lightspeed, it becomes “transparent” in the real-space, for it has begun to “phase” into the so-called “hyperspace”, when it reaches lightspeed, it completely disappears from the real-space into the “hyperspace lane”. So ramming Earth or any other celestial bodies with something flying at sub-lightspeed is not feasible, because the projectile will simply goes through the target like a ghost, without making any damage. [[User:Lixiaofossil|Lixiaofossil]] ([[User talk:Lixiaofossil|talk]]) 14:09, 6 December 2023 (UTC+8)

I have a theory of my own. According to my theory the aliens (let's call them Invaders) actually started their existence on Earth, which is only about 6000 years old. There are Big Bang scenarios where the universe is 13 billions of years old but Earth/the solar system/the Milky Way is only 6000 years old because the big bang started around the space it now occupies and all that mass of the universe slowed up the timing here in the center of the expansion pretty bad while the edges got a lot more time to age. Life in the universe (or at least in the Milky Way galaxy) was created by aliens from another dimension. There happened an argument between the main extra-dimensional alien (who designed the life, let's call him Creator) and one of his subordinates (who wanted something else, let's call him Adversary), so Adversary created the first Invaders to mess up the Creator's handiwork as badly as possible. However after centuries of messing the DNA Adversary with his Invaders learned the hard way that messing up Creator's handiwork cannot be done by methods chosen at random, some theory must be used. To develop these theories the Invaders created The Brain and placed it on Mars to have it out of reach of any mess. So The Brain developed the theory but now it did not work because the DNA of the life of Earth was too messed up and to add insult to injury the Creator deployed some nasty countermeasures to protect all the untouched DNA that still existed. New DNA strands were needed, preferably ones that the Creator does not care too much about. And here comes T'leth, an ancient colony ship from the outer edges, sailing towards Milky Way due to its plethora of aquatic planets. It initially contained only GillMen and their squid-like hyper-intelligent leader (let's call these aliens Aquians). Aquians made the understandable mistake of not securing their colony ship's computers (it is easy to make this mistake when you are the only civilization around in your galaxy) against hacking so now (with everyone onboard asleep) their computers get hacked, data downloaded and analyzed. The Invaders discover that Aquians were too dangerous to let live here, so they decided to crash T'leth into Earth hard enough to kill everyone onboard but not hard enough to destroy the DNA. However that led to the Earth destabilizing, giant water geysers spewing billions of cubic kilometers of water into atmosphere, flooding the entire surface of the planet with a giant flood and wiping everything out. Pretty nasty surprise from the Creator that dealt a severely crippling blow to the Invaders and their plans. Some sectoids found refugee against this disaster in the T'leth itself, where they were forced to become water-adapted Aquatics but the rest was killed and buried. Now The Brain on Mars had a big problem. Skeleton crew only, no carbon-based materials on the planet itself, only lots of carbon dioxide in the atmosphere and no interplanetary travel technology to speak of (the vessel they used to get to Mars was cannibalized to create the Cydonian underground complex). The Brain scrapped most of the Martian atmosphere to get its hand on some carbon, allowing it to build a few thousands scientists but discovering Elerium, figuring out how to mine it and how to use it, how to make Alien Alloys, Power Sources, etc, etc took them 4500 years and now is year 1999 and they are just starting to try and take the Earth back. Aquians (the inhabitants of T'leth) are only GillMen and the leading alien, all the other alien life forms were created by Sectoids. I do not have a theory about why the Creator did not protect Aquians from the shenanigans of the Invaders. The most sensible explanation was that they left their galaxy without his permission (Milky Way was supposed to be the domain of humans) and hence the Creator decided to teach them some consequences. And why the Creator decided to not protect humans from the shenanigans of the Invaders? Because at the very beginning the humans turned their back to him and damaged their ability to commune with him so badly that it took 4000 years to just start the repairs. And also he had to decide the humans needed some hard lessons to learn too. TLDR: Why the Invaders used such a limited force in the First Alien War? Because they wiped themselves out by their own stupidity and now are trying to rebuild from scratch on a barren and desolate planet. ([[User:TowigOs|TowigOs]] ([[User talk:TowigOs|talk]]) 01:30, 4 August 2025 (UTC))

===What may be the hidden function of UFO Power Sources?===

Why does no UFO contain something similar to craft weapon despite the fact that most of them may shoot, some are very painfully? And the only UFO that can't do that is Small Scout; on the other side, it can fly with 2200 km/hr Speed yet does not even contain UFO Power Source, whereas the Speed of Medium Scout (with 1 UPS on board) is 2400 km/hr only. More so, the Speed of Battleship (4 UPS within) is 5000 km/hr, that is only about twice of Small Scout one. So, what is the function of UFO Power Source? Let us suppose that they not only increase UFO Speed but actually are used as Plasma Guns during air combat.

Next, it is reasonable that UFO Navigation controls that weapon system; probably they need at least one per each UPS. Also Navigation may increase UFO's maneuverability when close to Earth's surface; pro arguments are: Harvester carries 10 Navigations (to pinpoint small targets, say, lonely cattle), Terror ship has 8 (to drop terror squad accurately onto city roads as shown in the Intro movie), Abductor has 5 (to pinpoint lonely men at rustic areas; also it's Size is Medium, not Large as Harvester), Supply ship has 4 (all that it should do is landing near Alien Bases); Battle ship has 4 (as it's main activity are air combats and X-Com base assaults); both Large and Medium Scouts (Small Size ships) have 2 each.

Next, though Large and Medium Scouts have the same UPS and Navigation number, the first is faster being larger. But Large Scouts carry not only Navigators but 3 (estimating by Sectoid staff on Superhuman Difficulty) Engineers also. Probably, Engineers may adjust UPS to optimal performance that results in Speed increment (from 2400 to 2700 km/hr) and Weapon Range increment (from 15 to 34 km) yet Weapon Power doesn't change (20 damage units per attack). All the larger UFOs have full Engineer staff on board, namely 2, so their UPS are adjusted by default.

Abductor and Harvester have 2 UPS each, 40 du Weapon Power, 20 and 22 km Weapon Range, 4000 and 4300 km/hr Speed respectively. Supply ship has 3 UPS, 60 du Weapon Power, 34 km Weapon Range yet only 3200 km/hr Speed. Terror and Battle ships have 4 UPS each, 120 and 140 du Weapon Power, 42 and 65 km Weapon Range respectively; their Speed values are 4800 and 5000 km/hr.

At this stage of our research we have got two questions.

First, Weapon Power values are expected to be proportional to the number of UPS multiplied by 20 du, so Terror and Battle ships should have only 80 du each. Probably, the explanation of such increase is UPS configuration. In both cases UPS are placed by corners of quadrate. Let's suppose, without too much far-fetching, that plasma beams, normally dissipating and losing power at larger distance, may focus somehow being close together, yet not too close, as Battle ship Weapon Power is higher. Also, that may explain the Weapon Range increment as well. Note that Large Scout has normal Weapon Power but quite high Weapon Range, 34 km, probably because of extended Engineer staff; otherwise it is expected to be next to Medium Scout's one, that is about 15 km. According to Abductor/Harvester, Supply ship and Terror ship data, each additional UPS increases the Range by 9 km in average.

Second question is the Speed of Supply ship. One (well adjusted by Engineers) UPS increases UFO Speed from 2200 to 2700 km/hr (Large Scout as compared with Small Scout). Another UPS yields 4000-4300 km/hr. Another two yield 4800-5000 km/hr. So, in average, each UPS brings another 700 km/hr to basic Speed of 2200 km/hr.

This Speed is probably provided by some propulsion device built in UFO's construction, as Small Scouts have about nothing but hulls and no trophy but alloys may be recovered. Another anomaly is special reinforcement of ship hull. Calculating the ratio of Damage Capacity to recovered Alloys quantity we get 5-7 for Large Scout, Harvester, Abductor; 13-15 for Supply, Terror and Battle ships; 18 for Medium Scout and 50 for Small one. Hypothetically, Small Scouts may be the most expensive ones to craft, while Harvesters are the cheapest, though it is quite reasonable in some way. Also, the theory of built-in UPS and Navigation may explain why even extremely damaged UFOs that have lost all their usual UPS may land without crush and crater, automatically, if Navigators are dead. Not speaking that Small Scout crew and personnel is presented by one Soldier (Muton occasionally), so its missions may be automatic in general. (Well, suggesting there is one hidden UPS out there somewhere, we just get another set of numbers: basic Speed of 1500 km/hr plus the same 700 km/hr per additional UPS in average. And three hidden UPS would give us simple linear dependence: Speed = UPS Number x 700 km/hr.) Still, even if we exclude Small Scouts from our research totally, the problem remains: Suppliers are slow.

Thus, the expected Speed of Supplier is about 4200 km/hr, not just 3200. The possible explanation is their cargo of 20 Food units, since these ones are fragile containers (as they may be easily damaged in cross-fire) vulnerable to acceleration overloads; on the other side, Harvesters carry 14 Food units but they have 10 Navigation units vs. 4 on Supplier's board, so more advanced propulsion control may reduce these overloads.

Also, there is once more interesting fact: only Terror and Battle ships have Entertainment modules, 8 and 24 respectively. And only these two types carry Terrorist alien combat units, 10 and 6 respectively (as well as Alien Bases, with 55 Entertainments in average and 7 Terrorists). Let's suppose that the true purpose of these enigmatic devices is 'entertainment', or rather brain-washing, to bring Terrorists under their master's control without excess efforts, or at least to suppress their aggression temporarily. Though, it is another topic at all.

At Terror ships, Battle ships and Alien Bases there are some devices looking like red spheres with blue tubes connected. They referred as plasma conduits, and Engineers may be found over there. Yet hardly that means the same green plasma their weapons shoot with. Let's suggest that these things contain some kind of special food produced from harvested trophies and used by aliens, especially by Terrorists as they need more energy to fight. Maybe, since they are subject to psionic control, or stun damage, in contradistinction from X-Com HWP tanks, even Cyberdisks and Sectopods have some organic brain-like component inside, so they need food too, in addition to electric accumulators, or Elerium batteries recharge.

Now back to the main question. Note that UFOs may not shoot two or more targets simultaneously, or at least never displays such activity. If so, these Plasma Guns have one-target operation mode only. It corresponds with the usual function of combined UPS and Navigation system as ship propulsion engine. Next, let's suggest that Navigators are ship Gunners also, while Engineers may adjust UPS to yield additional power boosting Speed and Weapon Range. Also it is reasonable that one of two Navigators controls the flight while another shoots during air combats, with some help of ship Engineers.

Another fact is Alien Bases, even Cydonian, have neither Rocket Defense nor Plasma or similar defense system at all, only some alien combat units at most, though it could be expected to have anti-aerial power weaponry (versus meteorite bombardment, for example). Obviously, base UPS can't be used that way as they are deep beneath planet's surface.

To conclude, let's note one more observation. UFO Power Sources have no complicated control console, as Navigations do, not even chair nearby. Yet there must be something Engineers can do with. Even Muton ones. Navigation control panels don't fit, as Engineers are looking at UPS from close range, without distant controls. On the other side, two Engineers are enough to adjust four UPS in opposite corners of Battleships. Also, as UFOs with solo UPS may change flight direction due to Navigators, their control of UPS generated fields must be quite versatile. So let us suggest that Engineer's job is periodical control of some close range field that protects UPS from propulsion forces and thereby distorts any distant sensors beyond reliability.

Though it's only theoretical, aforesaid may pretend to explain some unclear details of UFO Power Source functions.
[[User:VanTorrens|VanTorrens]] ([[User talk:VanTorrens|talk]]) 12:45, 24 October 2019 (CEST)

===Why battlescapes always being "opaque"?===

Every time an X-COM taskforce disembarks from the transport, they always find the surrounding being completely “shrouded”, despite in common military practice, there must be recon satellites and/or scout planes to overwatch the AO, even with hostiles marked and tracked. Even if X-COM doesn’t have that kind of luxury, their transports should be able to scan the AO before landing to provide a rather clear and detailed map for soldiers.

And similarly, X-COM bases seemly never have any CCTV system, so during a Base Defense mission, the soldiers effectively fight in blind despite on their own turf.

However in Alien Base Assaults, it’s understandable. Since an alien base is subterranean and it’s almost devoid of artificial illumination, also it’s impossible to send a spy for pre-battle reconnaissance, and seems aliens don’t have terminals for being hacked in corridors, so an alien base is supposed to be “shrouded”.
[[User:Lixiaofossil|Lixiaofossil]] ([[User talk:Lixiaofossil|talk]]) 15:24, 5 December 2023 (UTC+8)

==TFTD issues==
===What was the relationship between the aliens from the 1st and 2nd wars?===

Quoting from the UFOPaedia regarding Alien Origins: 'Deep in the oceans there lie ancient
sites used by the Aliens to contact their stellar cousins.' This also has some implications regarding the issue of why T'Leth was only activated when the Sectoids were defeated.

*Gill Men are coopted Terran creatures, Aquatoids are a differently-modified Sectoid breed, Lobstermen are machine soldiers that are manufactured, Tasoths are clone soldiers that are grown.

Aquatoids are the ancestors of the Sectoids. The colony ship was sent out slowing than light hundreds of millions of years ago. Sectoids are a more genetically advanced race. The rest of UFO aliens were picked up after that point. The Brain and Ethereals probably conquered the Sectoids and don't regard them highly. While the Aquatoids that were thawed over the years created, conquered (Gill Man) or manufactured the rest of the allies over time. I picture the Tasoth as probably something they brought with them and have been working on. Since most of the Aquatoids come from suspended animation they have not tinkered with genes much. Instead modifying and using electronics (MC Chip) to control. --[[User:BladeFireLight|BladeFireLight]] 17:28, 22 March 2010 (EDT)

===What kind of materials were 'synomium' and 'adamantium'?===

The first one is mentioned on the name of the alien communication devices and the second one appears at the end when T'Leth is destroyed: 'he twisting hugeness of T'leth begins to rupture.
Flames and smoke spew from its gleaming spires and adamantium halls.'

:Synomium is probably a special material used in the comm. devices, like Stargate's naquadah (universal stuff), naquadria (unstable power source), trinium (hull material) and neutronium (superdense metal). Adamantium is a legendary material in ancient literature that is said to be indestructible, similarly to mithril.--[[User:Amitakartok|amitakartok]] 10:55, 3 November 2009 (EST)

:Adamantium is said to be one of the strongest elements in many books and films such as X-men. --[[User:St.froppelie|St.froppelie]] 19:45, 23 October 2011 (GMT)

*See also Wikipedia article on Adamantium: [http://en.wikipedia.org/wiki/Adamantium]

===How deep were X-COM bases located on the seas?===

*Floating bases would be easier to build, repair and supply. However they would have to be tethered to the ocean bed or possess some sort of propulsion to prevent them from drifing with the ocean currents. But it would also allow for easy redeployment of the base.
*Submersible bases could allow for better sonar detection. Same problems regarding ocean currents would apply. In case of hull breaches entire modules would be quickly flooded and any crew present would be crushed by water pressure or drown. Base could be built and then submerged (requires depth control)
*Seabed bases would be the hardest to build and supply. Several other factors could limit their deployment, such as unstable areas (underwater volcanoes, prone to seaquakes, rock avalanches, etc.) and depths.
*Given that the Alien Retaliation missions in TFTD are called "Floating Base Attack", I'd say floating. Also remember that your starting sonar can't see Very Deep, which rules out seabed bases. [[User:magic9mushroom]]
** Floating doesn't always happen on the surface. The surface has to deal with large waves ad bobbing up and down, submerged only has the currents it could be stabilized easier. --[[User:BladeFireLight|BladeFireLight]] 11:57, 14 January 2010 (EST)
* I was recently researching how far you have to be down to not be effected by surface conditions. You have to be submerged 1/2 of a waves lenght (measured crest to crest) Best I can find is that the average wave is 150 yards accross. To not be effected by the waves you have to be 75 Yards below. This is way below the depth needed to not be effected by the bends when surfaceing. I figure they are probably right at the limit of what can be safe for quick surfacing and well anchored to avoid getting [http://www.youtube.com/watch?v=LwKXfc_a4Ag tossed in a storm]. --[[User:BladeFireLight|BladeFireLight]] 17:37, 22 March 2010 (EDT)
**Something else to consider - these 'floating bases' could be large modular submarines/submersibles. If memory serves, submarines basically maintain sea-level pressure regardless of the depth, so that could explain why they'd be able to be 75+ feet below sea level and not suffer the bends when surfacing.
::(Or, y'know, we could just say "a wizard did it".) --[[User:Guido Talbot|Guido Talbot]] 14:13, 16 July 2010 (EDT)

==XCOM: Enemy Unknown (2012) issues==
===Motives behind the invasion===
Now, the UberEtherial pretty much spells out the whole point of the invasion, as well as of their use & control of all the other aliens: they ''wanted'' humanity to evolve and become powerful, because they needed a species that was both high in physical prowess, and a powerful psychic warrior. He (presuming gender) freely admits that their bodies suck (and that the other races suck in body and/or mind even more), and the 1st-3rd-1st person pronoun switch in ONE sentence ("We who failed to ascend as ''they'' thought we would") and "preparation for what lies ahead", as well as his descriptions of the other alien races in the Temple Ship imply a number of things:
*The other races are enslaved races, perhaps from earlier invasions (possibly starting with Sectoids and Etherials being different castes of the same species?), themselves having been enhanced by their own resistances, before becoming enslaved on the degree of being puppets.
*The whole point of the invasion is enslavement of humans, not extermination, for the perfect warrior-- any Metroid fans can think of the Chozo also becoming masters of Psionics and energy manipulation, at the cost of becoming physically frail and infertile, and entrusting the Power Suit -- and their legacy -- to Samus.
*The alien surgeries (which greatly resemble Sensory Deprivation tanks-- you can even zoom in to see captive humans twitch sporadically) are their version of XCOM's Psi Lab (which ''also'' greatly resemble Sensory Deprivation tanks): they are 'farming' humans for Psi potential, similar to how us, the player, may farm soldiers for our own Psi Squad
*Which then makes XCOM almost as much the ''Etherial's'' project as it is the Council's (hence why they do not invade or attack XCOM HQ or Interceptor bases)
*Someone/thing ''else'' is involved, someone the Etherials are in some way subservient to: notice in the Temple Ship and in the Overseer UFO, the strange, Cathedral-like "Stained Glass Windows". To me, there appear to be ''two'' figures in each: the much more visible 4-armed Etherial silhouette, and in a transparent, but slightly darker shade of lavender, some other 6-8 limbed creature, with a larger body and a very different head-shape behind the first.
*"What lies ahead" may mean some coming disaster, or merely a challenge and testing from this sequel-hook of "They"
*Additionaly: the description of the Hyperwave device implies contact with an alternate dimension. The organic-metallic (silicon based, perhaps?) form of the Outsiders (as opposed to the rather obvious "manufactured and machined parts grafted onto flesh" Cyborg attachments of both Floater varieties), and their absence (especially from the Temple Ship) after the device's capture, as well as released screenshots of the upcoming FPS XCOM game (mentioning Outsiders AND being placed several decades ago)-- all this suggests alternate timelines as well as alternate dimensions (in quantum physics, these are practically the same thing anyways), as well as some species native to this ''Outside'' dimension that are the ones, this "They", whom are actually calling the shots.
--[[User:Xuncu|Xuncu]] 03:56, 26 January 2013 (EST)

*Just to verify the point about the Outsiders, they are called OUTSIDERS, which pretty much means not native, so possibly they are not native to this dimension, also, "What lies ahead" Could possibly be foreshadowing a TFTD remake? And the Outsiders are merely, prototypes of the Ultimate Alien?
[[User:XBrassxDragonX|XBrassxDragonX]] 22:59, 25 May 2013 (EDT)

*The UberEthereal is a rebel against "They" he/she/it united a group of Ethereals, and left "They" Then, he/she/it proceeded to search for the Ultimate Race, a race that was as tough as a Muton, and as Psionically Powerful as an Ethereal, these were the Humans. This Ultimate Race would overthrow "They" and thus, complete the Ethereal's legacy, it could also be, that through the use of implants, and sacrificing physical strength for Psionic Power, the Humans could walk the same path as the Ethereals, and be contacted by whatever was left of "They" then, the Humans would help "They" rebuild, and realize the sinister motivations behind "They's" plan, and thus, repeat the story in a never-ending cycle.

===How is it possible for Psionic soldiers to exist?===
After capturing a Psi-capable enemy and dissecting it: does XCOM reverse-engineer the implants and insert them into troops (whether they test positive (capable of using them) or not)? Or, is the testing just digging for a Psi signal that ''is already there''? In which case, it's a human-evolved trait, but from where, and why wasn't it found before? Vahlen's reasearch implies similar genetic struture between aliens and humans: do humans and Etherials/Sectoids have a common Psi-capable ancestor, or have the Etherials been interfereing with human evolution for at least 20-30 years (or however old troopers tend to be, with Shaojie Zhang and his advanced age, equally possible to have Psi-Abilites), if no longer? At least in Apocalypse, there's the excuse of Sectoid/Human Hybrids. How do humans use a power just discovered that year, and only a few months of practice, end up with the capacity to potentially mind-control Etherials, each of which who have several thousand years of personal experience with Psi abilites? --[[User:Xuncu|Xuncu]] 05:28, 11 April 2013 (EDT)
:It's implied that humans were always latent psionics (it's possible that if we weren't, the Ethereals would never have bothered us at all). The cutscene where your first psionic is found suggests the testee is immersed in some sort of purple gas, which presumably causes some physiological change to make them operant psionics. As for how human psionics get so good so quickly, good question, though bear in mind that psionic humans are implied to be an Ethereal's equal in raw power, but while an Ethereal has to expend psionic power all the time just to stay alive and standing, a human can devote it all to his psionic attacks. This could explain why humans are on an equal footing with Ethereals despite having comparatively little practice. More simply, it could just be that humans are badass compared to aliens; we certainly seem to be able to reverse engineer their technology in record time AND then make improvements to it, suggesting we're frankly just "better" than them. [[User:Binkyuk|Binkyuk]] 09:07, 12 April 2013 (EDT)

:Another possibility could be that Elerium exposure maybe one of the factors. While Doctor Vahlen stated that she found a correlation with high will power and psychic ability, gameplay mechanics aside there are cases where a very high willed soldier came back from the Psionic Labs who had displayed no psychic prowess whatsoever. Elerium is used in the alien technologies and it was only after the Alien attack that XCOM was able to 'make' psionic soldiers. Another piece of evidence is that pieces of equipment such as the Psi Armor and the Mind Shield require a large quantity of Elerium in order to manufacture and that it 'enhances' the Psychic abilities of the wearer. While it is true that Elerium is used as a power source for the armor, unlike the hulking Titan armor the Psi armor is essentially a skinsuit/catsuit/muscle suit that has no visible heavy pieces of armor but yet the Elerium requirements for a set of Psi Armor exceed the Elerium requirements for the larger, heavier Titan armor. Logically (again, gameplay mechanics aside) speaking the lighter Ghost armor could perform the same if it used the same amount of Elerium for the Titan armor yet it requires more to function. Combined with the fact that the Psionic Labs and the Gallop Chamber (Both facilities that involve Psionic's) are the only XCOM facilities outside of the Elerium Generator that requires Elerium in their construction means that Elerium maybe linked to the manifestation of Psychic phenomena.
[[User:GMPilot0079|GMPilot0079]] 3:56, 13 May 2013 (CST)

===Bureau/Enemy Within/My Little Pony Supplemental===
{{Ref Open | title = Yes, really}}
How does a ''Psychic'' attack on an XCOM soldier cause obvious psychological effects (-will, -aim), but damages ''armor'' first?

So, it's a safe assumption that the "They" spoken up above is probably the likes of [[Ethereal_(Bureau)|Asaru and Shamash]], "True" Etherials, who's physical forms have been discarded in trade of bodies made of pure energy--- much like EU/EW's Outsiders (not the Zudjari-- for clarity's sake, "Outsider" means the UFO-commander type alien in EU, and Bureau's 'Outsiders' shall be specifically called "Zudjari") are ''also'' described as being of pure energy. So, Bass Dragon was half-right: the Outsiders are not prototypes, they're attempts to ''reverse-engineer'' the Ultimate Life-forms that are the True Etherials. Shamash outright said they exist in multiple realities (either in the "omnipresent" sense (and the "physical" body is just the part that happens to intersect this reality), or that they can shift between alternate realities, XCOM's dimension included), and the Hyperwave Uplink, which seems to be the source for the Outsider's existence, has in-game descriptions that states that it has some kind of access to alternate dimensions, I think confirms this. The fact that Origin could study and emulate Shamash through scientific methods also leads credence that the Outsiders were scientific attempts to manufacture a True Etherial (or analogue thereof), via the Uplink.

The slave collars on the Bureau's Sectoids. I used to think that Sectoids may have been a low catse, but effectively the same species as Etherials. But, that was more based on the 1994 game's depictions, where the Sectoids were weaklings, but seemed to be "just another member of the alien horde." With 4-armed Etherials being canon, it's more likley that Etherials share a common ancestor with Slenderman than Sectoids, since evolution doesn't really work that way (ie: all/most (modern) Earth animals with spinal chords (chordate [http://en.wikipedia.org/wiki/Chordate] ) follow a "head and 4 limbs and 2 eyes" body configuration). More likely, Sectoids are the "for hire/sale" whipping boy of the universe. Additionally, the slave collars that are suggested to help link them to the Mosaic Network, show how incomplete Origin's manipulation of Shamash was: in the infliltration of the Spire in Arizona, Dr Wier comments that Mosaic "seems to want to help". But, as the normal Etherials were collectively working together, that is why EU's Sectoids were without collars: the Etherials had no need for them.

Sectoids on sale, now 50% off, this Rel only, here on Shopduct n' Slave!

Now, the Meld: it always struck me as odd how ''careless'' the aliens seemed to be, leaving massive resources laying around for XCOM to collect. If XCOM was some kind of MMORPG, I would bet that players who chose the Alien factions would often blow up the Elerium Generators and Navigational Computers if it looked like they were going to lose a base or UFO (Chryssalid Rush, ke ke ke!). That they leave the Meld hanging around seems to me that they ''want'' XCOM to get it, which goes with what I wrote long ago up there about how XCOM could be said to also be the Etherial's project, at least indirectly.

On the other hand; how does Meld tie in with the purpose of the invasion? Searching for the Ultimate Life Form, "as we sought to uplift them, to prepare them." In other words: those aren't mere storage canisters, XCOM Bait, or bombs. They're ''dispersal units''. The Etherials' plot was to seed Earth with Meld to enhance physical capacities anyways (Mechtoids, Floater/Heavies), while doing abductions as mass "Farming" for Psi-positive humans (ie; like how the player buys soldiers in bulk, and picks out the ones we want to submit for Psi testing). Failures: we fire them, Zudjari kill them and dump 'em out back, Etherials and The Matrix turn them into flood slurry, and the Wachowski Siblings make a third movie and lose all credibility.

Which brings me to my third topic, where I talk about a cute talking unicorn that hails from a magical Fantasy kingdom of baby horses.

In the crossover fanfic [http://www.fimfiction.net/story/100455/stardust XCOM/FiM: Stardust], the Author is (with obvious liberties) attempting to stay accurate to XCOM's technical information (with assistance from this very 'Paedia: he's seen my work here). The major alterations to the plot are that Bradford replaces the player character of the Commander, and instead of Fluttershy reforming Discord, Discord makes a bet with Twilight Sparkle to "Convince me, irrefutably, that friendship is the strongest power in the universe."

With Twilight accepting the terms, Discord teleports her to April 02, 2015, to the site of a Terror Mission in Washington DC, within 30 feet of a Chryssalid.
:If you've read this far, I assume I've had your interest. If I now have your attention, and want to read the story without getting spoilers, scroll down to where '''Elerium''' is next written in bold.

So, obvious question: "What the hell does that have to do with anything?!" Well, the Author is trying to stay accurate to EU and Bureau (he did start writing before much of EW was revealed) while writing his own story, and he addresses several valid points that solve, or at least address several XCOM mysteries. The unique viewpoint of involving cartoon ponies is for flavor, amusement, and contrast to better see them.

As the story continues; Twilight is captured by XCOM, and almost Interrogated by Dr Vahlen, but manages to escape the containment cell. Hijinks ensue, Dr Shen talks Bradford into allowing him to make contact (referencing the in-game Arc Thrower conversation between the three), and Twilight is now a 'guest' of XCOM, taking residence in "Stardust" Labs. Eventually, she helps in XCOM's research of both alien technology, and her own magic abilities: The magic field she uses in Equestria is also available on Earth, but is stiff from "disuse," but is discovered to be the same field that the Aliens use for Psionic abilities. It's revealed that Elerium is, or is at least an analogue to "Arcanite", a material that boosts magic abilities. Ergo: Elerium boosts Psionic abilities. As Twilight assists in both XCOM Research, and indirectly with missions themselves, with her magic, her use of the Field begins to awaken the Psionic/Magic abilities of the humans around her. For example, Commander Bradford has 'time-stopping' precognition; several times, he has seen TPKs, only to snap back into real time shortly before it all goes to hell-- save states, basically.

Her assistance also points out that the implants found in the aliens, particularly the Sectoid Commanders, also have Elerium circuitry that activates/boosts/projects their Mind Control ability (as well as all aliens to be able to be controlled by the Etherials, who have not yet been revealed in the story, save for a refrence to/by a possible EXALT/Osiris member, and another to William Carter). This also points out that the Etherials are not specifically "Religious" of themselves, as Origin was, but are scientific-minded (the "All Technologies" research credit).

The mystery of XCOM this addresses is, as Analyst Krut points out in The Bureau: "Why?"

"Dear Twilight Sparkle,

'''ELERIUM.'''

Sincerely,
:Pinkie Pie!"

The Field that makes the abilities possible has probably always been here, and is perhaps universal, as inherent as magnetism or gravity (or, if you want a ''stupid'' comparison: like the "Chroma" in ''Indigo Prophecy''). And, with Elerium and it's use making Psionics easier for humans, Earth is now a 'factory' for making the most potentially dangerous beings in the universe.

Evolution, at least on Earth, is more about "Good enough"/"it ''works'', duddn't it?" than any search/aim for "better", and certainly not "perfect". If there was no evolutionary push (or capacity) to be able to use the Field (as useful as it would be), such traits would not develop. Interesting examples where real-world animals do use advanced physics are the Pistol Shrimp, who's claw has evolved in such a way that's essentially a [[Sonic_Pistol]] and can make a luminescent spark of plasma that's the same temperature as the surface of the sun, and dolphins that use complex fluid dynamics that humans barely understand to, basically, just pass the time [http://www.youtube.com/watch?v=TMCf7SNUb-Q].

So, the Field that makes Psionic abilities possible is, in fact, accessible to humans, but as it is not often developed; it's rare, or doesn't manifest strongly. But it ''is'' there, so there is a motivation for the Etherials to come to Earth and do their testing (Incidentally, I don't think there is anything really saying that the Etherials knew that Asaru and Shamash were here).

Which also addresses "Why now?"

Because Elerium is now on Earth: in The Bureau, it's established that the Zudjari have been seeding the Earth with Elerium as early as 1957 (the year that Spudnik was launched: the satellite is even seen in the opening sequence of a campaign). If Elerium boosts Field abilities, such as Psionics, then 58 years of low-level global exposure may have triggered/boosted enough to draw the attention of the Etherials (incidentally, background radiation from above-ground nuclear tests peaked in 1963 at about 0.15 mSv per year worldwide, or about 7% of average background dose from all sources. The Limited Test Ban Treaty of 1963 prohibited above-ground tests, thus by the year 2000 the worldwide dose from these tests has decreased to only 0.005 mSv per year [http://en.wikipedia.org/wiki/Background_radiation#Atmospheric_nuclear_testing]-- and in Angela's ending, she gets the US Government to use nukes to erase evidence of the invasion). This may also be why the aliens seem careless with Elerium; not as effective at making enhancements as dispersing Meld, but may help instigate Psi activations.

Now, I realize: if Psi powers ARE a scientifically understandable energy wave (and not straight-up "Magic"), then it does make sense that armor is damaged ''as well'', and that the suits that include Elerium can block the "piercing/bypassing" damage that I think would be more realistic. And for the armors it doesn't make sense for; they don't give an HP bonus big enough to make the difference.

Which leads to one more interesting thought: Elerium is not exclusive to the "Etherial Empire", or whoever controls the Sectoids (as Elerium is not in Apocalypse(?), but Sectoids are): while not naturally native to Earth, there's nothing saying how limited-- or abundant-- Elerium is throughout the universe (Arcanite). Less evidence, and more of a hunch: may Elerium be somewhat... "viral"? That it may at least "try" to spread as it goes, as the Bureau suggests? Like a milder version of Tiberium [http://cnc.wikia.com/wiki/Tiberium] or Phazon [http://metroid.wikia.com/wiki/Phazon]?

Obviously, Origin didn't have the device that had Asaru before the invasion, BUT, Faulk said the device was found ''in an Elerium Mine'' (in Montana). In other words, the Elerium aggregated around Asaru, who was there ''first''. So, there is enough to establish that there is a link between Elerium exposure/presence, and Psionic abilities, as is shown in Stardust.

In conclusion:
* ???? - Asaru arrives on Earth
* ???? - Sectoids, a clone race, are sold in open intergalactic slave markets to various alien empires across the universe: as clones and near-blank genetic templates, their adaptability, ability to be mass produced, and 'ease of use' (aided by Psionic links to one another) lends to the success of their sale.
* 65,000,000 BCE - The Lovecraftian "Vortex" Empire (refrence: Ecco the Dolphin [http://eccothedolphin.wikia.com/wiki/Vortex_Queen] - would explain why they look like Earth's aquatic animals), hailing from aquatic worlds, crash land a colony ship on Earth, either because, or ''as'' the impact that led to the extinction of the Dinosaurs-- and in the process, pave the way for mammals, and eventually for Humans to rise, whom will spend the rest of Time crossing Space, and even going into other Dimensions, obliterating every alien menace they encounter. Way to go, guys.
** Due to the exclusion of Elerium and their preference of aquatic habitats, their own research creates Zrbite and Aquaplastics, and they modify their own Sectoid slaves/genome templates into the Aquatoids.
* ????-1957-1962 - Zudjari, as part of their normal conquests' terraform operations, and the search for True Etherials, seeded Earth with Elerium in [[The_Bureau:_XCOM_Declassified|The Bureau]]. Asaru awakens, Shamash is killed, and Origin is deleted in a massive Etherial-fueled Psionic wave.
* 1962-2015 - Background radiation from Elerium is covered up by atmospheric Nuclear Testing, but the effects are still felt worldwide: while skills may not be developed, Psionic potential grows.
* 2015-2016? - The "cast out" Etherials begin their conquest and research of Humans and Earth, led here either by Elerium's energy signature, Psionic energy signatures, or due to the presence of the two True Etherials on a single planet; and event said to be a multiversal rarity. The battles between them and XCOM are a boon to human science and technology. Psionic experimentation, and the dispersal of Meld lead to the enhancement of both the human mind and body. Then the Etherials get blown the fuck up.
** Black Market interests begin the EXALT organization, a paramilitary group made with the aim of stealing and adapting alien technology and materials to force human evolution. After the raid on their headquarters and the neutralization of their command leadership, remaining members go into hiding, and begin to pass and adapt their ideology down family lines.
* 1997-2002 - Due to the energy signal released by the death of the multidimensional being Shamash: in an alternate timeline/dimension, the Etherial invasion happens earlier: since the Alien Brain is a computer, it's able to organize the invasion that much faster. The Tachyon signal released upon it's destruction lasts only a little while, but as the Tachyon is a (theoretical) FTL particle, it's properties are not restricted to 'normal' space-time.
* 2027 - Reminants of EXALT reorganize into the Cult of Sirus.
* 2041-2046 - As the Aquatoids were able to receive the signal as easily as their Sectoid cousins, they began the resurrection of T'leth: thus, the [[TFTD|Second Alien War]].
* 2084 - The Micronoids, while not as experienced as Etherials at multidimensional travel, also register the death of Shamash, and begin [[Apocalypse|their assault]] on the largest Earth-based population: Mega-Primus. Thanks for that, Carter.
** Sectoid-Human hybrids were origionally developed by the Etherials in an attempt to add the docile and controllable aspects of the Sectoids to the physically and psionically potent human race, much like the 1957 experiments with Africanized Honey Bees. In fact, ''exactly'' like those experiments: those bees are now known as "Killer Bees", and the Human-Sectoid mutants are willing to fight for XCOM, in exchange for universal rights.

Aaaaaaaaaaaaaaaaand there: a Grand Unified Theory of XCOM!
{{Ref Close | source = --[[User:Xuncu|Xuncu]] 08:53, 24 November 2013 (EST) }}
And yes, I feel there's legitimacy in connecting XCOM to Ecco: [http://www.youtube.com/watch?v=blaX_eMz3Qw Et voilà.]--[[User:Xuncu|Xuncu]] 17:49, 24 November 2013 (EST)

[[Category: Fiction]]
[[Category:Enemy Unknown/UFO Defense]]

The Mysteries of X-COM

2025-08-04T01:30:09Z

TowigOs: Another theory why did the aliens use limited force during the First Alien War

Discussion page for some less clear aspects of the series

==General issues==

===How fast can alien craft travel in space?===

Some alien missions (repeated attacks on X-COM bases, for instance) come daily. This seems to imply that alien craft are able to travel the distance from Mars to Earth in a matter of hours.

: Or maybe, as you suggest in your novels, they have a staging area near Earth, such as the dark side of the Moon. [[User:Spike|Spike]] 15:36, 25 February 2009 (CST)

::Really fast. Consider that they don't need to push aside atmosphere, as well as the fact that momentum is conserved in space, so they can achieve very high speeds with gravity slingshots. (Mars DOES have 2 moons, recall.) Also note that they may be operating a bit closer to home(the far side of the moon, perhaps?) it's simply that the command staff are at Cydonia. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Good article in last month's Scientific American pointing out we only rely on gravity slingshots because we still use chemical rockets with pathetic delta-V. Once 2nd and 3rd generation plasma engines come on line (1st gen are in flight now) the gravity slingshot will become an irrelevance. No doubt UFO drives are at least as good as our (future) 3rd gen plasma drives, probably way better since they warp space.

(Reminds me of the old Guild Navigator joke - I just warped space from Ix, and boy is my mind tired. Oh well, you had to be there)

[[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

:Also keep in mind that both Phobos and Deimos are tiny. They are basically captured asteroids. Neither would be useful in gravity assist. But yeah, the UFO's shouldn't need any assist anyway.[[User:Mannon|Mannon]] 11:35, 30 March 2011 (EDT)
::Case in point: http://xkcd.com/681_large/ (Deimos can be escaped with someone on a bike and a plank stacked on a brick, Phobos requires a good pitching arm). --[[User:Xuncu|Xuncu]] 16:55, 13 April 2013 (EDT)

:Consider that many of the same aliens as UFO/EU are in X-COM Intercepter, having necessarily had to break light speed. Consider that if outside any atmoshphere a battleship could reach 4800 knots(in-game top speed) within two minutes (which is about how long it appears to take in-game) then it is accelerateing at about 18m/s/s or almost 2Gs. In 24 hours it would reach 1,555km/s. At this speed (assuming it turned it's drive off after 24h) it would travel about 134,000,000km each day. The maximum distance between Earth and mars is about 401,000,000km.
:For simplicity, because we have room to work with here, even if a battleship were to accelerate for 24 hours while orbiting mars, and again had to decelerate for 24 hours in orbit after reaching earth, (all while a chrysalid inside balanced two apples on each of it's mandibles) it would still only take 5 days to reach earth when both planets are at opposite orbital positions. It seems that the Ethereals can wipe out your base and not have to miss Ladies Night, assuming the club is also on earth. ''Ethereal Mind-Trick: "You don't want to 'blow dis joint'. You want to come back to the UFO for a little abduction mhmhmhmhhmm.'' [[User:Darkestaxe|Darkestaxe]] 23:38, 12 April 2013 (EDT)
::On one hand, "near-constant multiple organ failure" problably includes THAT organ. Ouch. On the other, sheer force of will problably works on that for them (lucky them); and with Psionics, you can make any woman belive that "this long" (holds hands a few inches apart) is 1 foot, as well as literally make her forget any other man she's thought about before, as well as Algerbra. Unhooking a bra would, however, still a challenge unto itself. And, since we are given specific dates in-game, there's plenty of programs online that can calculate the distance between planets for any given time, as well as lists of Oppositions (when two plants are at their closest): http://cseligman.com/text/planets/marsoppositions.htm For example, in 1999, the in-game year of the first game, on April 24th, Mars was only 86 million Km away (though Kudos if you can beat the game THAT early into a campaign) --[[User:Xuncu|Xuncu]] 16:55, 13 April 2013 (EDT)

===What happens to the crashed UFO craft and its crew?===

Downed alien craft disappear after a few days have passed. No explanation is given to this whatsoever, so what really happens to them?

Possible answers:
* The UFO and its occupants are recovered by other humans.
* The Aliens manage to repair the craft and fly back to space. (unlikely, in the event that the power plant blew up and they have no Elerium)
* The Aliens self-destruct the craft and kill themselves in the process, ensuring their remains will not be recovered by humans. (This is, in fact, the in-game explination. Read the mission briefing. [[User:Darkestaxe|Darkestaxe]] 23:38, 12 April 2013 (EDT))
* The UFO Powerplant eventually suffers a meltdown and explodes, eliminating any vestiges of alien presence.
* The Aliens blow up the UFO and disappear into the countryside.
* Most likely answer, IMHO: The local government/ funding nations give X-COM a limited time window to launch any operation, similiar to what you see in covert ops movies: "Complete the mission within 36 hours, or we initiate Carpet Bombing of the area". This is very likely considering that each nation actually has jurisdiction, and X-com is operating each military op with permission and cooperation by local authorities. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)
*Similiarly, I assume that nations which have signed a pact with the aliens launch a rescue operation and assist their alien friends. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)
: In the UFO TV show, it's stated that alien craft and bodies degrade quickly in Earth's atmosphere, disappearing completely in hours or a few days. [[User:Spike|Spike]] 15:36, 25 February 2009 (CST)
:: If that was the case, then one of the gases present in the atmosphere would be very toxic to the aliens. They would be restricted on their activities outside their craft, not to mention they would have to terraform the planet to be able to live here. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

:: As Zombie said, doesn't Alien Containment support this idea? [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

::Those are excellent suggestions. One of the X-COM books detailed that aliens throw up a force field around crashed UFOs to give them time to repair the craft. This would also explain the limited size of the Battlescape (the area of the force field...the field was thrown up before the crash, thus why the craft wasn't always centered in it) as well as why the Battlescape is devoid of human life(the aliens took care of that up front.) Similarly, large scale bombing works as well, as does the local government going in to clean it up themselves. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)
:::If there's a force field around the craft what is it supposed to repel? The atmosphere? Because humans have no problem entering the field and operating inside it. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
::::Of course they do! Have you ever noticed how dumb your units can be? That's because the aliens can't live with too much nitrogen, so they turn some of it in their force field to oxygen, and excessive amounts of oxygen make you act weird. After a while, their power source runs out and the nitrogen returns, dissolving them into E-115. (What did you think it was made of?) AT least, that's what seemes logical to me, ad is a combination of many postulates here. 21:36, 18 March 2010 (EDT)
:::::That would require that the aliens' biochemistry and the alien alloys used in the power sources reacted with nitrogen, which is a mostly inert gas on normal temperature and pressure and a . It's kinda of weird that the aliens didn't bothered with fixing that vulnerability with their craft and bodies during millions of years (what happens if the force field malfunctions while capturing cattle? ooops!) but ok. The increase in the amount of oxygen would probably also turn any kind of fire into large explosions throughtout the force field. [[User:Hobbes|Hobbes]] 21:24, 19 March 2010 (EDT)
::The force field was intended to keep humans out so the aliens were undisturbed. The first major hurdle X-COM had was figuring out a way to bypass those fields so they COULD get troops and aircraft inside. [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:54, 26 February 2009 (CST)
*I'd guess that the aliens would eventually mount their own rescue missions, especially once they realized that XCOM is farming their ships for resources (they must know we don't have ready access to their alloys and Elerium) and co-opting their technology. In the Firaxis game, when idling in the Situation Room screen, Central's (often amusing) radio chatter implies that there are many more UFO's and reports that don't go into the globe. Additionally: only 16 countries are covered, and there are over 150 countries on earth, plus all the oceans. After all, if we were shooting down every last ship, then the alien collective shouldn't be able to land so many aliens for Terror Missions. --[[User:Xuncu|Xuncu]] 02:48, 26 January 2013 (EST)

===How do the aliens carry their equipment?===
Like human soldiers, aliens can carry weapons and equipment in locations like legs, belt, shoulders and backpack, regardless of the fact that some of their races even lack those anatomical features.

:Potentially a sticky gel-like area on the limb. Though really, since we were never intended to access alien inventories and the AI does all inventory management internally, this may simply be something that was never considered. Speaking from a slightly different standard, most aliens do not carry excessive amounts of gear; often their equipment would be able to fit in both hands. Also recall that Floaters and Ethereals have capes and robes(which may have inside pockets, or the Floaters could store them in the anti-grav/life support unit or inside surgically created body cavities during the installation, while Ethereals could support their excess gear with telekinesis), Mutons have armor(which may have external straps or adhesive areas), and Snakemen have an armor plate(which could have straps, adhesive, inside pockets, or even a backpack.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

:We already know the answer to this one - they cheat! ;) [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

===Are X-COM transport craft piloted?===

:Almost certainly, since a remotely-piloted craft could be returned to base when the mission was aborted or failed. It's entirely possible that all X-COM soldiers are qualified pilots of the appropriate craft, since it would make no sense for X-COM to waste space on the plane for a noncombatant, or to have a single-point of failure on the mission like that. (The aliens could screw over the entire op by killing the pilot). It also explains why the craft is lost when the mission fails or is aborted with no one inside(lacking a pilot, the aliens are able to easily destroy it.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

:: On the other hand, even a tank/hovertank is capable of getting the craft back to base. Perhaps there is an autopilot function. X-com craft are also infamous for choosing strange and bizarre intercept paths, based on latitude lines... almost as if they followed some a few simple lines of code from 1993 programming (bit of 4th wall breakage there...) -[[User:Jasonred|Jasonred]]

:Of course, given the tanks seem to be remotely piloted from an X-COM base, its possible that the tank being in the craft allows the Tank pilot to reroute into the control systems for the dropship and take it over. Limiting this to having the tank inside is a rather good idea. [[User:Arrow Quivershaft|Arrow Quivershaft]] 12:07, 27 February 2009 (CST)

:I recall that the various cutscenes in the PSX version had a pilot, most notably in the "Mission Failure" scene, where it shows the pilot being killed. --[[User:Mabmoro|Mabmoro]] 16:06, 13 March 2009 (EDT)

===What sort of physical process is used to increase human stats over time?===

The increases in some stats are easy explained by experience gained on missions (firing abiility, reactions, etc.). However, in the cases of physical stats (TUs, stamina, strength) the increase must be augmented by an artificial process, since it isn't easily explainable that humans can significantly increase body mass/speed/endurance just by physical activity/exercise.

:Lifting weights will increase strength. Running and cardio exercise will increase endurance, and performing the same task multiple times will allow you to perform it faster. I see no reason natural increase doesn't work. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)
::I assume that it is possible to a human to use those methods to double its physical condition, but that being the case why are X-COM recruits so... undeveloped? Maybe this is a more intriguing aspect. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

What I don't get is that when someone gets blasted that they gain a lot of extra health. For crying out loud, the aliens are throwing around plasma and ridicoulously HUGE explosions. Shouldn't they be suffering from third-degree burns? I would expect them to at least have a major sore spot where they got hit. [[User:Tsunamiatunzen1|Tsunamiatunzen1]] September 24

:There's been arguments over whether the soldiers in X-COM are the Green Berets or equivalents of their various militaries, just average soldiers that volunteered for the job, or if the Council of Funding Nations is corrupt and is using this as an excuse to foist off their most useless soldiers onto the X-COM project. If the latter, it would easily explain their rather poor early stats. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

::Maybe the stat increases relate to the troops getting more comfortable performing all operations - lifting, running, combat actions - when the aliens no longer scare the cr*p out of them so much. [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

:: I know what you mean... if this were Jagged Alliance, it'd be like trying to hire Mike and getting Gumpy instead... ouch! ... IMHO, it looks as if the COFN is being funny about this. Clearly, the troops assigned to X-com have had extensive weapons training... each and every one of them can use just about any standard weapon, including Rocket Launchers, incindieries, auto Cannons, etc. However, NONE of them have any combat experience, coming to you as fresh rookies. And their stats look as if they were selected based on a pot luck basis rather than screening among the elite troops... [[User:Jasonred]]

:Health isn't gained from getting shot. But as for the "ludicrously low stats" issue, maybe they're being selected on some other basis, or there's a real shortage of volunteers. [[User:Magic9mushroom|Magic9mushroom]] 04:56, 25 September 2009 (EDT)

:: I think that the X-COM's soldiers have big responsibilities, can't have children. They are sworn in and only then go to the field - if someone can't be trusted to keep a secret, he's getting sacked, given a shitty job (ever wondered who maintained the General Stores?) or worse. - n, 16:47, 16 August 2010 (GMT+2)

In Hotpoint's [http://www.tthfanfic.org/Story-16092/Hotpoint+XSGCOM+Goa+uld+Defence.htm| XSGCOM: Goa'uld Defense], his explanation is that after a few missions of watching their fellow newbies die, the survivors give in and volunteer for an experimental regimen of performance-enhancing drugs. IRL, steroids and such don't result in instant strength enhancement, they just encourage accelerated development of muscles. [[User:Kalaong|Kalaong]] 03:16, 28 March 2011 (EDT)

Heh: http://www.nerfnow.com/comic/901 --[[User:Xuncu|Xuncu]] 02:52, 26 January 2013 (EST)

As much as I've played this series for decades, and know full well how pitiful the starting stats of soldiers are, at least with respect to the game's rules, I really feel I must wonder and ask why we think those starting stats are 'underdeveloped' or 'pot luck'? What, exactly, are we basing this judgement on beyond how poorly they seem to perform in-game against a force that is quite honestly and clearly demonstrated as superior to humans in the first few missions, where only luck and superior numbers appear to manage to secure any wins for the organization and, in turn, humanity? How much can the average X-COM 'Rookie' carry in pounds as gear, and is it considered substantial compared to Army kit, or not? How many direct hits from a rifle can they take normally without dying or keeling over from fatal wounds, and how does this compare to real-world soldiers' survivability? How much time is one turn meant to represent, and how far can the average 'Rookie' run in that time, and how does that compare to how fast a fully-kitted Army soldier can move?

Has all of this already been figured out elsewhere? Otherwise, I'm starting to question whether we have any real proof that 'Rookies' AREN'T "The best of the best of the best, sir! With honors" beyond just how it 'looks' and 'feels' during gameplay, which is already skewed by the enemy having superior firepower and attributes, or, in the case of replacements, existing troops being pushed far beyond previously-perceived human limits from such extreme combat maneuvers as have resulted in success against, as I said earlier, a far superior force (EDIT: want to clarify on this point that I'm taking the 'what doesn't kill you makes you stronger' stance on the original question for this section). If the stats extrapolated for OpenXcom are any indication, this is most certainly the case, even with Sectoids, to an extent. While Sectoids will never have anything on humans in the Health department, being as fragile as they are (though some rookies can have less health, apparently, but only a few unlucky ones), they are surprisingly enduring, with tons of stamina, being 20 points higher than the X-COM 'Rookie' maximum upper limit for initial stat generation, and the same for Bravery (though this seems to be the case with all AI controlled entities, except mechanical ones, which have an impervious 110 Bravery). Reactions are also higher than possible with a Rookie, and speed (TUs) is on par with the statistical average for rookies, same with accuracy ratings, and even strength. This is just looking at the grunts, too, not even considering the stat boosts Leaders and Commanders have. As expected, the average X-COM Rookie's stats are almost universally superior to the civilians, representing the average member of humanity. The only exception is Stamina, and I'm starting to think this is to compensate AI units somehow for an AI that may not be able to manage energy levels as well as a human.

Anyway, just felt someone had to bring this up here. If it really is explained elsewhere, it probably should be clarified here, as well, for consistency, anyway. (EDIT: I just felt it was being taken at face value far too readily in this discussion, and it just didn't seem right to just assume it with no evidence, despite all my experience playing this series, and noticing full well the soldiers' stats feeling constraining at first) --[[User:StormhawkAPS|StormhawkAPS]] 01:08, 4 October 2013 (EDT)

==Enemy Unknown/UFO Defence issues==
===Why isn't Earth overrun by Snakeman/Chryssalids?===

According to the UFOPaedia, Snakemen's "Reproduction is asexual, with each snakeman carrying up to fifty eggs inside its body at any one time" adding the ominious conclusion: "Left to its own devices this species would be a severe threat to life on earth."
Moreover, this species is usually accompanied by the Chryssalids, which have a capacity to reproduce themselves very quickly using humans. So, any survivors of crash sites or terror attacks could start reproducing themselves hidden, resulting in large areas being overrun by those aliens later on.

Possible answers:
* Both races have a self-destruct mechanism incorporated into their psysiology to prevent this.
* The entire area is purged by large scale bombing. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)

::One thing suggested in fan data was that Snakemen have air tablets in their stomach...which may be different from earth's atmosphere, which would limit their lifespan in earth's atmosphere, also making egg-laying pointless, since the offspring wouldn't be able to breathe or survive. It has also been suggested that Chryssalids have a very rapid metabolism. Though Chryssalids are likely just as, if not more useful, as a threat or a bargaining tool. When attempting to get a nation to capitulate to their demands, the aliens could threaten to employ Chryssalids en masse, or offer to remove a mass infestation in exchange for the government's cooperation. Or even further, it's possible that Chryssalids are under Ethereal control and maintaining the control link at that distance is taxing, thus eliminating mass use of the creatures. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Two words: [[Alien Containment]]. That answers everything except for the UFOPaedia articles for the aliens themselves which contradict it. --[[User:Zombie|Zombie]] 00:42, 26 February 2009 (CST)
: For captured aliens, yes. But what survivors of uninvestigated crash sites? [[User:Hobbes|Hobbes]]

::Zombie is commenting that based on the need for an Alien Containment unit, the aliens cannot survive in earth's atmosphere for extended periods, needing special atmospheric blends and/or nutrient pools which earth is unable to provide naturally, thus limiting their operations outside of the craft. (If the aliens won the war, it's likely this would be one of the first things that they would 'correct'.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:54, 26 February 2009 (CST)

===What is the propose of the 'disco balls' found inside some UFOs?===

:Given that they explode, they could be storage reservoirs for coolant for the computers or other systems. They could also be circuit breakers or electrical junction boxes, or even a component of the UFO's particle beam they use to fry X-COM Interception craft. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Here again, two words: [[Alien Entertainment]]. Even though the spheres are not set to Alien Entertainment in the MCD files, they are almost certainly related to the process somehow. --[[User:Zombie|Zombie]] 00:42, 26 February 2009 (CST)

:Maybe they are for having discos? [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

:Presumably [[Alien Entertainment]] is psionic in some way, maybe they're Psi-Emitters or something? -[[User:magic9mushroom|magic9mushroom]]

::'Disco balls' = Alien 'LSD' emitters. Travelling through space to go on almost-suicide missions force aliens to develop POWERFUL relaxing devices to entertain themselves and not go insane :P. --[[User:Nekrocow|Nekrocow]] 20:10, 24 June 2012 (EDT)

::: Assuming it's about eyeball-like pod #3, it's absent on base maps, and present only in two UFOs: Battleship (in Alien Entertainment), but Terror Ship on the second deck has one in Alien Entertainment room, but two on the bridge. Those are also the only two ships running ground battles and carrying Terror Units (bases have them, but normally don't expect to use them), so... either remote control psionic relays or something else related to ground combat? -[[User:TBeholder|TBeholder]] ([[User talk:TBeholder|talk]]) 21:04, 30 December 2015 (EST)

===Who buys those alien bodies/equipment from X-COM?===

:Equipment likely goes to the funding nations or the international black market. No rebel group is going to ask too many questions about being offered guns that can [[Heavy Plasma|slice through the hull of an MBT]] or [[Alien Grenade|grenades that can level a building]] or [[Blaster Launcher|man-portable guided missiles]]; it'd just be cash-and-carry. Similarly, scientists would likely be interested in looking at much of this stuff for their own research. This would also explain the lack of market forces; the funding nations could have a set price for each item, or if X-COM is selling them under the table to rebels and rogue scientists, they can set the price and refuse to budge. The money on corpses could also be an "Alien Bounty" paid by the Funding Nations, as a reward for each alien that X-COM can prove they killed. Or it could be bought by other groups...rumor has it that some fast food restaurants have processes that can make ANY meat, no matter the source, look and taste the same, and a Muton would make a LOT of McBurgers. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)
From the USO (Kasey Chang): XARQUID SUSHI.

===How did the aliens get to Mars?===

There are no indications that UFOs are capable of faster than light speed. So how did they get to Mars in the first place?

:The UFOs are mission craft, used for the legwork. The fighters; we never see the carriers. Given the aliens have been proven to be interstellar, they either Clone-A-Crew as needed when coming the long way to keep the UFOs crewed, or its far more likely that the aliens did have or still do have larger "Carrier" ships, which are capable of FTL travel, that were/are further out in the Solar System that store and dispatch UFOs to mission locations. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

:: One word: TFTD. The entire city of T'leth was put into cryogenic suspended animation? Or look at X-com Interceptor. X-com and the aliens show the ability to enter hyperspace or whatever it is.
::: T'Leth is another mystery of its own. More to that later on :) [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
::... there are no indications that the UFOs are INcapable of FTL... I don't think you would want to perform FTL travel within Earth's planetary atmosphere!
::: There are no indications that they are capable as well. And X-COM scientists don't seem to detect any FTL capabilities in UFOs during their research. And after the war the Elerium stocks dwindled, and it would make sense to perform some sort of interstellar missions to detect and harvest Elerium, however none are mentioned. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
:::: Unless you count the events of X-com Interceptor? [[User:Jasonred]] [[User:Jasonred|Jasonred]] 21:15, 26 February 2009 (CST)
::::: I am refering to the events between Enemy Unknown and TFTD. There is clearly a big distinction between the alien craft on EU and those of Interceptor. [[User:Hobbes|Hobbes]] 09:38, 27 February 2009 (CST)
::::: Enemy Unknown is set in 1999, TFTD in 2040, Interceptor in 2067... looks entirely plausible that they DID begin research into space exploration immediately after the events of Enemy Unknown. These things take time you know. Remember that the universe is a huge place, and Earth had rather limited Elerium Reserves by the end of EU. It takes... what, 30 Elerium just to fly an Avenger halfway across Earth? They could hardly afford to fly around randomly in space HOPING to come across elerium, they had to figure out detections methods, then scan the galaxy sector by sector, possibly partially using non-Elerium based propulsion at times... I can't remember if it's canon or fanfic, but I remember reading that all Elerium on Earth was reserved for space exploration.
As for FTL, Earth does get it for sure sometime between 1999 and 2067. And I'm pretty certain the technology is Elerium based. It's not a huge logic jump to assume that the aliens have access to FTL Elerium based tech.
Though I'm a bit puzzled why all T'leth technology is based on Zrbrite, when the aliens uniformly use Elerium, all the way from Earth to Cydonia to the far reaches of space. -[[User:Jasonred|Jasonred]]

:It takes 12 Elerium to fuel an Avenger, though how much 1 Elerium is is an ongoing debate. As for Elerium, it was reserved for propulsion research when the funding nations divvied up X-COM's resources, and then they blew it all without learning anything more than the original X-COM scientists. And yes, Earth clearly gets FTL after TFTD but before Interceptor. The reason Elerium is not used in TFTD is because Elerium becomes inert and useless upon contact with seawater. Similarly, seawater aggressively corrodes Alien Alloys and eventually completely dissolves them. Zrbite functions similar to Elerium, being gold mixed with alien bio-material. Unfortunately, Zrbite only works when supported by a massive energy grid created by T'leth and becomes inert upon its destruction. [[User:Arrow Quivershaft|Arrow Quivershaft]] 12:07, 27 February 2009 (CST)

OK... take the UNIT of elerium out of the equation... let's say that Earth had 5000 units of elerium, so 6 units get's an Avenger halfway around the world, and 12 units is sufficient to reach Mars. Hardly enough fuel reserves for intergalactic travel then.
2065 On October the 27th, the probe 'Tombstone 1' returns reports to Earth. It's data show that the globular star cluster where it rests, one hundred light-years from Earth, contains many life-supporting planets. Many of the planet's within the probe's scanning range also apparently possess great mineral wealth, including trace veins of elerium-115.
Hmm... So, mankind discovers FTL technology on their own in those 65 years? ah... come to think of it, if they've got non-Elerium based space travel and FTL, and more powerful weapons too, what's the big deal about Elerium in the Frontier? Does mankind even need it anymore?
As for T'leth, it is meant to be over 65 million years old, and CRASHLANDED on Earth due to a solar flare. Was the Ultimate Alien a prophet, thus chose to base T'leth on aqua plastics and Zrbite when T'lth was first constructed? Or did T'leth crash land, followed by frenzied activity where the entire city was replaced part by part, the alien alloys swapped for Aqua Plastics?
...
Actually, come to think of it, it's obviously a massive plothole due to limited timeframe, no point in discussing too deeply. Sigh... [[User:Jasonred|Jasonred]] 13:50, 27 February 2009 (CST)

:It's implied that despite the loss of ability to use the alien technology from the First and Second alien wars, simply being able to see and examine their designs catapulted earth's technology forward at least a few decades...which really is entirely reasonable. Much of the technology can be replicated on earth, and the principles and designs can be reapplied.

:As for the deal with Elerium, its needed to power stronger weapons and is also wonderful for power generation; its efficiency in power generation is what allows Mega Primus to even exist.

:And was there anywhere that specifically said that T'Leth was made of Aqua Plastics? I don't recall. Yes, the rest of their subs are made of aqua plastics, but I'm wondering if something the size of a medium city might perhaps be made of something a bit more durable. PS: Thanks for signing your post! :D [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:17, 27 February 2009 (CST)

It's not a plothole at all. There is no Elerium on Earth, whereas the aliens can manufacture Zrbite on Earth, since there's gold here. Therefore it's obvious why they used Zrbite. Also, there's the fact that it was an Aquatoid colony mission, intended to produce an "aquatic paradise", so using Aqua Plastics instead of Alien Alloys is perfectly justified. [[User:magic9mushroom]]

:I think that the use of Aqua Plastics instead of Alien Alloys is perfectly justified by the fact that T'leth crashed million of years ago while the aliens that came to take a shot or two at earth were two million years ahead technologically. So Aqua plastics was some plastic that was used by aliens before they've got the Alloys. You might argue - it's Aqua Plastics, so Aqua =/= Space. Well, Aliens weren't calling them aqua, and there wasn't anything saying that Aqua Plastics is not suitable for Space Travel. --[[User:Domenique|Domenique]] 11:10, 19 May 2010 (EDT)

... I think Alien Alloys alone would catapult earth's technology forward a decade, and there's no reason humanity can't use those anymore, just not in water. According to timeline, some space pirates manage to make the decommisioned Avengers run on non-Elerium fuel... a large technological step.
By the time of Interceptor, Elerium weapons aren't that powerful. Good point about power generation though.
I would assume that T'leth SHOULD have been constructed out of Alien Alloys, since it was originially an interplanetary vessel? Generally, everything in EU was made of Alien Alloys, everything in TFTD was made out of Aqua plastics. Both of which seemed plenty durable.

::Have you noticed that the UFOs fly however their mission parameters tell them to? The UFOs pretty much IGNORE interceptions by X-com craft... if their mission tells them to make 3 passes, speed up, slow down, speed up... they will follow that pattern exactly, whether X-com craft are firing on them or not.

::Question: How long does it take the Avenger to reach Mars from Earth? [[User:Jasonred]] [[User:Jasonred|Jasonred]] 19:12, 26 February 2009 (CST)
:::No longer than a week, in my opinion. Probably less than 2 days. Since canonically, the design of the Avenger had the Cydonia mission in mind, it would be capable of very high interplanetary speeds. (You could choose to burn 40% of the Elerium in one blast to get to high speed. Or you could burn even more and refuel while it's landed...or it could be a mission with no guaranteed escape for the crew. The lives of the many over those of the few and all that, especially since the war hinges on the mission.) In addition, you can fit a full complement of soldiers on board with no real excess room for supplies, and the longer it takes to get to Mars, the greater the chance the aliens will spot it coming for them and mount a serious defense. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:20, 26 February 2009 (CST)
:::If you'd burn that much fuel to accelerate the craft then you'd have to use as much again to decelerate it and attain a planetary orbit, otherwise you'll simply overshoot the planet and head towards outer space. This is also another aspect to take into account when thinking about the speed of UFOs. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

::: UFO drives are non-Newtonian so those sort of rocket equations don't necessarily apply. I think filling up a car with gas is a closer analogy. [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

::: Well, they could put a mini mind shield on the Avenger, shoot down a UFO roughly their size, and then fly to Cydonia when the UFO they shot down was supposed to return based on the instructions found by the hyper-wave decoder. Basically taking the place of the UFO. Shouldn't be too hard since the UFO's are pretty common by the time you research Cydonia or Bust. [[User:Tsunamiatunzen1|Tsunamiatunzen1]] 14 February 2010 (MST)

::That would leave 20% of the fuel to take off the Avenger and land it. Not really that unreasonable. While they're landed, they could potentially refuel the Avenger, or the mission might have been planned as a 1-way trip from the get-go. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

Perhaps Elerium-based drives are a bit like Ramjet engines, where they're actually useless or inefficient ''below'' a certain threshold speed? --[[User:Xuncu|Xuncu]] 03:02, 26 January 2013 (EST)

===What happened to Mars and the alien civilization there?===

According to the Brain, Mars was blooming with life had a alien civilization millions of years ago. However, Mars nowadays is a barren world and the alien civilization seems reduced to the area on Cydonia.

:That may well have been before Mars lost the majority of its atmosphere due to its weak magnetic field. As the atmosphere dissipated, the aliens left or died off. It's also possible that the aliens, shown in the game over to have little respect for planets other than as sites for slaves and resources, they strip-mined the planet dry(and the rust from the machines created the red coloring), and then seeded Earth so that the slave workforce would grow for future extraction of Earth's resources. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

===Where are the human-alien hybrids referred to on the UFOPaedia?===

:For the ones on earth, probably in hiding or in laboratories for research. For the ones the aliens have, potentially improving the Sectoid gene pool or being used as food or menial tasks. Cloning is alot easier than making genetic hybrids and there's nothing that says their first-generation experiments would be suitable for combat. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

:: They are babies at the time of X-com, and few in number. Their aren't even that many of them by the time of X-com Apocalypse. [[User:Jasonred]] [[User:Jasonred|Jasonred]] 19:12, 26 February 2009 (CST)

:Not to mention the ones in X-COM: Apocalypse are less-than-fit for battle before extensive training. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

===Why did the aliens only activate T'Leth after they were defeated?===

On TFTD T'Leth is shown as an entity/city of major power that is capable of conducting a war on its own. But the aliens leave it dormant although they could have used it to speed the process of taking control of Earth.

:Perhaps the Enemy Unknown aliens are legitimately scared of the TFTD aliens and are unsure how long they could trust them. Evil is not monolithic; the TFTD aliens may be more interested in themselves than the alien empire, so they were kept as an ace-in-the-hole. This is the same reason (canonically) that SKYNET did not originally send the T-1000 to assassinate Sarah Connor; SKYNET was scared of what the T-1000 could do and had only a bare minimum of control over it, so it only used it as an option when it had nothing left to lose. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

T'Leth is in fact so powerful that all it has to do is surface, in order for X-com to be considered to have lost the war.
In fact, looking at the timelines, it takes 40 years for T'leth to wake up from it's slumber... that's one good reason not to use it. By the time it activated, the war would already be over. [[User:Jasonred]]

Because the whole purpose of the Enemy Unknown aliens was to rescue the TFTD aliens from T'leth, and there was no way of seeing whether the T'leth-based invasion in TFTD would even work - from their perspective it's possible that getting T'leth to bootstrap itself could have caused a catastrophe (they don't know whether or how badly it's damaged). Presumably the aliens planned to mount a proper rescue operation after locking down Earth and readying it for the aquatic paradise that was the entire point of the T'leth expedition in the first place. [[User:magic9mushroom]]

T'Leth was a coleny ship sent by the Sectoid/Aquatoid's millions of years earlier. This is why the Aquatoids use electronics to augment there control over other creatures, while there progeny are genetically modified to gain the same control. In TFTD it's implied that the T'Leth had been partialy active for a long time. Thawing out aliens in small groups but never going in full production. UFO aliens may have not intended to start the full awakening cycle until they had a chance to prepare the planet.
OR, given the Ultimate Alien was aquatoid in origin by his looks and there was no other races from the first game involved. And the fact that Sectoid/Aqutoid's are not the top of the food chain with the Ethereal and Brain being more powerful it's possible the brain had decided that the Ultimate Alien was a threat to it's power. It was not until it's death that they tried send the signal. --[[User:BladeFireLight|BladeFireLight]] 17:19, 22 March 2010 (EDT)

===Why did the aliens use limited force during the First Alien War?===

Imagine Independence Day or War of the Worlds: UFO above the major Earth cities destroying the national leadership and any resistance. Or simply announce to Earth that they are now a part of their empire and resistence is futile. Instead, they go 1 mission each day, allowing humans to capture their craft, research their technology, discover their intentions and mount a successful defense. Don't the aliens watch sci-fi movies to see how it should be done?

:Perhaps they don't have the standing forces to do so, and are in the process of building up the forces needed to do so. Perhaps they don't want to wipe out the entire power structure too fast; they want to leave some pieces in place for when they rebuild. Perhaps they're too condescending to think that humanity ever really has a chance; they've probably conquered thousands of other planets without anyone ever successfully resisting them. Perhaps they consider the X-COM project to be a rearguard action that, while a valiant effort and a credible threat, is ultimately doomed to failure because they simply cannot win in the end, which is why they undermine it. Indeed, the reason you need to launch the Cydonia mission in order to win is because X-COM simply cannot stop the aliens in a ground war; the aliens have an effectively infinite supply line and standing forces(though nothing says they're all waiting to swamp the earth), and the only way to win is to kill the command staff(which the aliens believe X-COM will not be able to do, lacking both knowledge of where the Brain is and any practical means to get there.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)
::The most plausible explanation seems to be the one employed in the Worldwar series, by Harry Turtledove, but that does not seem to mesh with what the Brain says about having been on Mars for a while, since then they could watch the Earthlings perpetually. Of course, what it says is probably a bunch of lies. Thinking about what it says for too long also raises the question of why the aliens attacked when they did, of course... [[User:Vizzydix1|Vizzydix1]] 21:52, 18 March 2010 (EDT)

The aliens are completely lacking in weapons of mass destruction. When you get right down to it, their aircraft are very fast, manuevarable and durable, but they have rotten firepower. Even the battleship is unable to bring down an Interceptor in 1 shot.
The terror missions and X-com Base Defences prove that the Aliens are unable to simply launch orbital bombardments... in fact, they appear to have no Air to Land weapons whatsoever...
When you get right down to it, the aliens are pretty stupid. Also, their scientists seem inferior to Earth's. Seems to me that they only had the advantage of Elerium deposits and thus elerium based research.
X-COM was unable to win in an all-out war with the aliens, but remember that X-com is a small little covert group with several dozen soldiers and a handful of aircraft. Can you imagine the result if the aliens had caused a joint war effort by the UN? You would have Lockheed factories converted to Avenger production, several platoons of soldiers outfitted with Flying Suits, Lasers, Heavy Plasma, thousands upon thousands of Laser Tanks...
I would say that keeping the fight to covert action on both sides was actually beneficial to the aliens, really. [[User:Jasonred]]
* Nope, the aliens could just invoke John's Law and blow up the planet with a kamikaze battleship at .9c. Even failing that, the alien battlefleet could come in numbers sufficent to blot out the sun.--[[User:(name here)|(name here)]] 14:39, 8 November 2009 (EST)
** Lest we forget, X-Com is essentially the Spartans to the aliens' Persian Empire. So they'd just fight in the shade (which would be a blessing in desert missions). --[[User:Guido Talbot|Guido Talbot]] 13:58, 16 July 2010 (EDT)
*** Mass producing those technologies on such a large scale would be impractical considering that those said technologies sans Laser Technology rely heavily on Elerium. Thus the Earth forces would be heavily reliant on downed or landed UFO's to resupply their Elerium powered craft making such efforts pointless.

Aliens first began with smal scouting missions, so maybe all we expirience in X-Com is initial attacks by aliens, maybe the whole base was begining scouting and waiting for the invasion fleet? Aliens problably could be in sense dumber than humans, humans are adaptable and thinking, our technology advances fast, and we are fast and smart enough to stop the invasion before it begins. Aliens problably were not used to it so they thought "oh well, another invasion...". --[[User:Domenique|Domenique]] 11:10, 19 May 2010 (EDT)

Mankind, as a whole, is incredibly cunning and full of guile. We are also incredibly aggressive. A trait that the most of the Aliens can barely concieve. Though we are weaker physically, mentally, etc, we are overly developed when it comes to strategem and war. The aliens are, in essence, have come to an inverse of Flatland. Though they are advanced, it is they who are 2D to our 3D approach to fighting. They return to earth, and through extensive research and testing, determine that inferior are strategically to humans. So...they use their advances to what they percieve as the most full advantage, and call for reinforcements over the initial months of the First Alien War. For eons, only the Sectoid make arrivals to earth. When the Brain finally realizes the situation, that mankind has woke up and is dealing with them most directly, it begins to get desperate, it sends reinforcements, but only incrementally. (Its always focused on peak efficiency). The concept of overwhelming force is illogical and some how, disdainful, to it. It prefers nuance, interogation, politics, and assessment. The Brain determine that its more effective to eliminate allies of XCOM than to face it directly. The concept of obliterating anything from orbit is reprehensible. Everything must be examined, especially the dead creatures you leave behind. Over time, it would learn man's tactics and assimilate. In fact, each race called in is an example of the Brain adapting. The Floaters bring forth an extra dimension to combat. The snakemen aggressiveness and accuracy. Mutons a culmination of superior warrior breeding, raw physical power, and determination not unlike the so called human soul. Finally, the Ethereals enter, with capacity to bring overwhelming force. In time, as they do on Mars base, they might begin joint force attacks with Mutons backed by Ethereals, supported by a mix of terror weapons. Fortunately, the First Alien War is ended before they fully develop such cunning. Hence the desperate act of T'Leth. The Brain has learned the power of anger fueled by vengeance and desperation.
--[[User:BlackLibrary|BlackLibrary]] 11:10, 29 May 2011 (EDT)

:I've always viewed it as primarily a lack of resources. Even if you get a UFO every single day and shoot them all down so that there's no possible chance of any of them being the same UFO that's still only several hundred to perhaps a thousand or few UFO's over the course of several years. And most of those are quite small and not too difficult to take out with regular old interceptors and human armaments. If used all at once it might be enough to achieve air superiority, particularly if the Battleships do all the heavy lifting. But it also might not. It certainly would NOT provide enough soldiers to mount a worldwide ground offensive. The crews on those ships aren't all that big. There's also no reason to assume that all those craft, weapons, soldiers, and more importantly... elerium are all available at the same time. It's quite likely that the aliens are cloning new soldiers, building new weapons and UFO's, and possibly receiving supplies (particularly of elerium) from deep space. Elerium is needed to manufacture a lot of their stuff as well, and we already know it's a limited resource in our solar system. Consider on top of that how much get's used up as fuel every time a UFO visits Earth. If they sent all their UFO's they would use up their reserves of Elerium all at once for a 1 day attack that ultimately would fail. Instead of conquering the Earth wholesale they are trying to influence governments into signing secret pacts with them so that they can control the population of the Earth rather than wipe us out. They do this by using terrorism to intimidate the public and inserting clones to infiltrate governments while holding secret negotiations. A steady stream of UFO missions keeps up the pressure until governments break. Lucky for us they never expected us to bring the fight to the command center on mars. Just imagine if they had built base defenses like we can for our bases. heh Lord would it be aggravating building up a crew of top notch soldiers, constructing an Avenger from scratch, scrapping together all the gear, sending it to Mars, and then watching it get blown to bits before it even lands... O,o Also consider that their UFO's have operated with relative impunity for a very long time. Presumably XCom is the first organization to shoot down a UFO? As for Earth ramping up for a full scale war, it'd be unlikely that we could really produce enough alien technology in any reasonable timescale to actually outfit whole nations armies, especially with limited Elerium. Perhaps the tech that doesn't require Elerium, but then again shifting an entire army from one weapon system to another is not as simple as merely producing all the weapons. It's an extremely long, arcane, and baffling process. Getting just the branches of the US military to switch to laser weapons would probably take at least a decade. I think that limited resources and the intent to control and dominate rather than eliminate the population of the Earth explain it. For that matter they would see the human population it-self as a resource. Hence the use of small scale terrorism rather than attempting to use any weapons of mass destruction. A bunch of aliens walking around shooting people is still pretty damn scary stuff.[[User:Mannon|Mannon]] 13:12, 30 March 2011 (EDT)

I would have thought that the simplest answer here is best. The aliens are manifestly unable to survive outside containment or bases for prolonged periods. Further, their clearest technological advantage over the humans (at least, prior to X-Com research) is mind control. Therefore, their primary method of offence is not to get bogged down in a ground war, but to engage in the overthrow of governments by infiltration, coercion, corruption and bribery, and achieve complaisance by terrorisation of the general populace. It is for this reason that standard combat tactics involving large hierarchies are ineffectual against the aliens (when the government/command can be mind controlled and the theatre can be defined by a mobile alien force). A decentralised, partly cellular, covert approach like X-Com is preferable, but unable to win an outright ground war either (being composed of, at maximum, 250 soldiers). Of course in reality, the irony is that the aliens/bourgeoisie/Fox network have Mind Controlled you, the X-Com commander into wasting your time with retro video games instead of doing anything about their societal control!
--[[User:Oogleshay|Oogleshay]] 16:16, 18 October 2011 (EDT)

My theory is that the aliens are deliberately trying to be low-key because they know once the UN can no longer keep the invasion a secret, they will have no reason to pull their punches at defending Earth. The aliens want to make it so that once humanity at large fully realizes what's going on, it's already too late - they're poking the sleeping giant but take care not to awaken it before amputating all limbs to make it unable to defend itself once awake.--[[User:Amitakartok|amitakartok]] 06:33, 14 January 2012 (EST)

Perhaps the aliens suffer from a lack of proper logistics. If we assume that their purpose was to retrieve the lost colony ship(T'leth) then it wouldn't seem particularly likely that the aliens would have brought along the necessary logistics to support a full scale invasion of Earth. Furthermore it is quite possible that the alien ships you encounter in the first XCOM are actually not dedicated invasion ships but rather re-purposed fighter ships(which would explain the total lack of artillery or bombardment capabilities).
--[[User:Theinsomniac|Theinsomniac]] ([[User talk:Theinsomniac|talk]]) 22:47, 17 February 2014 (EST)

I disagree with all this. "Mankind is the greatest species." - hogwash. The aliens are clearly capable of wiping out humanity when they wish, if you read the whole of the lose game screens. The game had to be designed to give humans a chance to fight back. With this caveat: the only reasons the aliens don't start wiping out the population would be to preserve humanity. With the harvesting and abduction missions, clearly they are looking for something in the fauna and flora of Earth. Something that a massive assault would make improbable to find due to the overwhelming loss of life that would occur. The most logical explanation would be that the aliens want to harvest specimens with specific genetics traits, so they would want to be able to sift through as much of the population as possible to find those with the best traits. Before wiping out the rest of the "inferior specimens". This explanation would also fit to the story that the brain tells at the end of the Cydonia mission (if that story is more than just a desperate attempt to save itself.) [Why the aliens are so incompetent is due to incomplete development of the strategic layer by the designers, especially with the economy.] [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])

Obviously, in the remake, this is much more easily explained as the Etherial search for Psions making human extermination ''not'' being their goal (but in fact, the ''last'' thing they want, since we're the best shot they got for their apparent true goal: ascendance), but to an limited degree is is reasonable to retroactively apply this motivation to the 1994 Etherials/Cydonian Brain. On a similar vein, where the Gallop Brothers even thinking about T'leth yet during Defense's development? I saw not too long ago, I think on the History Channel, of a 'realistic' take at trying to fight off an invasion/occupation force, also noted to be about harvesting, not about outright killing all humans: with presumed FTL tech, even someting a fraction of lightspeed, and the number and masses of UFOs involved both in the special and in XCOM; it'd be much easier to just strap some engines on some large asteroids and spam them at Earth, which those points prove is possible: a much easier and effective means to exterminate humans, if the goal was xenophobic in nature--- but I digress. Consider.. hmmm, yeh, the US invasion of Iraq or Aphganistan: we COULD of just nuked the hell out either country and called it a day. Presuming a lot, but maybe some of the same reasons America didn't are the same? Intergalatic politics not allowing such WMDs? Excessive collateral damage wasn't their interest? Looking for something specific on an individual basis? That the aliens (may) want slaves, and reasons on that vein, is a big difference they have. Going back to the special, how humanity won is by a mass infitration/kamakaze attack on the barge/battleship-sized UFOs, and making it "not worth" continuing the occupation (in similar nature to people wizing up to Bush's bullshit and losing so many soldiers to cheap-ass IEDs and Soviet-era tech making the Iraq War unpopular)..... again, assuming alien behaviors and mechanics of motivations are anything remotley "human-like". So, at best, I'd ascribe the 1994 alien's motivation as the same as in the special: conquering for resources. Cortez conquering my ancestors for gold. --[[User:Xuncu|Xuncu]] ([[User talk:Xuncu|talk]]) 08:03, 18 February 2014 (EST)

My personal theory in regards to this is simple. To get to Mars from where they originated they would have to travel at relativist speeds (at or at least close to the speed of light) this requires a lot of energy and at this speed every microgram counts. (a single microgram of cargo can cost a ton of fuel at FTL speeds).
So the aliens travelling to Mars, instead of bringing a massed invasion fleet bring the bare minimum. Embryos or even genetic samples for each of their species, blueprints for weapons and equipment, basic manufacturing facilities, mining equipment and a transport vessel designed to be cannibalised to set up the initial Cydonia base, with only a ghost crew to start things off.
This explains the year prior to the start of the game (the steady increase in UFO reports, abductions ect.) the aliens need resources, they probably got some from mining the area around Cydonia to build some of their equipment but to grow clones they need a nutrient medium (not to mention the food they need for themselves) which means they have to go to earth and harvest. The initial missions were probably in areas such as the ocean, or jungles, harvesting flora and fauna. But given how little they would be able to harvest this way (they would have trouble finding enough protein not to mention the fact that mutons are said to be obligate carnivores) which meant increased incursions on populated areas (such as farms) add to this the lack of genetic diversity means that they would abduct humans to help provide some means of altering their genetic code to better handle earth diseases and atmosphere.
This can also explain why you only get small UFOs initially, they don't have the resources to build battle ships (until they have mined enough to expand their production facilities and build bigger craft). It also explains why they lack weapons.
TFTD show that the alien's method for “education” is to just implant knowledge. What this means is you have a bunch of aliens with the same hard-wired brain (clones) and with the same knowledge. Limiting their ability to adapt and change (they don't have years of experience to work on, nor have they had to think of the knowledge they have it's just given to them as fact).
Once X-com is formed they now find themselves battling an enemy that not only adapts to use their technology but builds on it (personal armour, power suits, flying suits, fusion ball tanks, ect). The whole alien invasion is doomed from the start.
Given time the aliens could have built up a massive fleet capable of overwhelming earth (which was probably their initial plan) but due to X-com getting involved that plan got knocked back. They can mine Mars and the asteroid belt for minerals to build their weapons, but without raiding earth for the fauna to feed their troops and grow their clones they can not build an army.
The aliens probably observed earth previously. (maybe Roswell was a scouting mission which failed to return) as such they underestimated our detection and interception capabilities (the back-story actually states that X-com is using the best craft available and previous attempts to intercept UFOs failed using conventional earth technology, which probably explains the limited weapon load-outs for x-com craft (they are built on high speed prototypes designed as proof of concept not actual in service craft so they had to jury rig hard points).
This basically means that the aliens were unprepared for earth's level of resistance, before they even had a force capable of fighting. If they had been more careful, built their forces in silence (by farming wild life in the jungles and oceans, instead of going for rich targets like farms to load up on cow parts quickly) they may have been able to launch an invasion before earth even knew what was happening (just imagine if the game started with 20 battleships over every country, mutons march down the streets carrying heavy plasmas and blaster bombs, while snakemen and chrysalids strike major cities, all the while ethreals are mind controlling everyone... try winning that game with just 2 interceptors, a couple of rifles, some heavy weapons and 8 soldiers who can't hit the broad side of a barn from point blank range with a guided rocket --[[User:crwydryny|crwydryny]] 14:50, 30 December 2015 (GMT)

I think that the aliens simply had no concept that they could be defeated. By analogy: when a dog trainer shows up to tame a savage dog, she's not showing up with a troupe of armed bodyguards, because that would be a silly level of overpreparedness. She's not worried the dog will outsmart her. She's not worried that the dog will figure out how to handle the leash, wrap it around her neck, and then demolish her car. If anything like that started happening, she'd be so utterly astonished, because it's never happened so far with any of the dogs she's trained. She'd be slow to react or to adapt her strategy, because the situation would be so difficult for her to believe. Dogs just don't behave that way! Similarly, the combination of battleships, mind control, and plasma has always been so overwhelmingly effective that the Ethereals have never needed to be smart, or adaptive, or even make accurate assessments about the intricate details of the planets they're taking over. Plus, they're a society of clones operating in a strict hierarchy, and literally sharing thoughts psionically. They probably have only a vague understanding of "individuality", and I doubt they have much understanding of guerrilla warfare, because they've never seen it succeed. Their political and interpersonal dynamics are vastly simpler than ours. I doubt that they're even aware that X-COM exists as an entity that is independent of our world governments. [[User:Jessicest|Jessicest]] ([[User talk:Jessicest|talk]]) 22:23, 15 March 2020 (UTC)

The question of ages “Why aliens never have the smart of ramming Earth with a UFO flying at sub-lightspeed?” They have plenty of smaller UFO to spare and given there are no advanced bases on the Moon and the absence of “carrier-grade” UFO, interplanetary travel should be quite feasible to them, thus their UFO can achieve sub-lightspeed. Actually, a similar question is also presented in Star Wars “Why Galactic Empire never rams a Rebel-controlled planet with a Star Destroyer flying at sub-lightspeed?” So I made up an answer for both questions: When a spacecraft’s velocity approaches lightspeed, it becomes “transparent” in the real-space, for it has begun to “phase” into the so-called “hyperspace”, when it reaches lightspeed, it completely disappears from the real-space into the “hyperspace lane”. So ramming Earth or any other celestial bodies with something flying at sub-lightspeed is not feasible, because the projectile will simply goes through the target like a ghost, without making any damage. [[User:Lixiaofossil|Lixiaofossil]] ([[User talk:Lixiaofossil|talk]]) 14:09, 6 December 2023 (UTC+8)

I have a theory of my own. According to my theory the aliens (let's call them Invaders) actually started their existence on Earth, which is only about 6000 years old. There are Big Bang scenarios where the universe is 13 billions of years old but Earth/the solar system/the Milky Way is only 6000 years old because the big bang started around the space it now occupies and all that mass of the universe slowed up the timing here in the center of the expansion pretty bad while the edges got a lot more time to age. Life in the universe (or at least in the Milky Way galaxy) was created by aliens from another dimension. There happened an argument between the main extra-dimensional alien (who designed the life, let's call him Creator) and one of his subordinates (who wanted something else, let's call him Adversary), so Adversary created the first Invaders to mess up the Creator's handiwork as badly as possible. However after centuries of messing the DNA Adversary with his Invaders learned the hard way that messing up Creator's handiwork cannot be done by methods chosen at random, some theory must be used. To develop these theories the Invaders created The Brain and placed it on Mars to have it out of reach of any mess. So The Brain developed the theory but now it did not work because the DNA of the life of Earth was too messed up and to add insult to injury the Creator deployed some nasty countermeasures to protect all the untouched DNA that still existed. New DNA strands were needed, preferably ones that the Creator does not care too much about. And here comes T'leth, an ancient colony ship from the outer edges, sailing towards Milky Way due to its plethora of aquatic planets. It initially contained only GillMen and their squid-like hyper-intelligent leader (let's call these aliens Aquians). Aquians made the understandable mistake of not securing their colony ship's computers (it is easy to make this mistake when you are the only civilization around in your galaxy) against hacking so now (with everyone onboard asleep) their computers get hacked, data downloaded and analyzed. The Invaders discover that Aquians were too dangerous to let live here, so they decided to crash T'leth into Earth hard enough to kill everyone onboard but not hard enough to destroy the DNA. However that led to the Earth destabilizing, giant water geysers spewing billions of cubic kilometers of water into atmosphere, flooding the entire surface of the planet with a giant flood and wiping everything out. Pretty nasty surprise from the Creator that dealt a severely crippling blow to the Invaders and their plans. Some sectoids found refugee against this disaster in the T'leth itself, where they were forced to become water-adapted Aquatics but the rest was killed and buried. Now The Brain on Mars had a big problem. Skeleton crew only, no carbon-based materials on the planet itself, only lots of carbon dioxide in the atmosphere and no interplanetary travel technology to speak of (the vessel they used to get to Mars was cannibalized to create the Cydonian underground complex). The Brain scrapped most of the Martian atmosphere to get its hand on some carbon, allowing it to build a few thousands scientists but discovering Elerium, figuring out how to mine it and how to use it, how to make Alien Alloys, Power Sources, etc, etc took them 4500 years and now is year 1999 and they are just starting to try and take the Earth back. Aquians (the inhabitants of T'leth) are only GillMen and the leading alien, all the other alien life forms were created by Sectoids. I do not have a theory about why the Creator did not protect Aquians from the shenanigans of the Invaders. The most sensible explanation was that they left their galaxy without his permission (Milky Way was supposed to be the domain of humans) and hence the Creator decided to teach them some consequences. And why the Creator decided to not protect humans from the shenanigans of the Invaders? Because at the very beginning the humans turned their back to him and damaged their ability to commune with him so badly that it took 4000 years to just start the repairs. And also he had to decide the humans needed some hard lessons to learn too. TLDR: Why the Invaders used such a limited force in the First Alien War? Because they wiped themselves out by their own stupidity and now are trying to rebuild from scratch on a barren and desolate planet. ([[User:TowigOs|TowigOs]] ([[User talk:TowigOs|talk]]) 01:30, 4 August 2025 (UTC))

===What may be the hidden function of UFO Power Sources?===

Why does no UFO contain something similar to craft weapon despite the fact that most of them may shoot, some are very painfully? And the only UFO that can't do that is Small Scout; on the other side, it can fly with 2200 km/hr Speed yet does not even contain UFO Power Source, whereas the Speed of Medium Scout (with 1 UPS on board) is 2400 km/hr only. More so, the Speed of Battleship (4 UPS within) is 5000 km/hr, that is only about twice of Small Scout one. So, what is the function of UFO Power Source? Let us suppose that they not only increase UFO Speed but actually are used as Plasma Guns during air combat.

Next, it is reasonable that UFO Navigation controls that weapon system; probably they need at least one per each UPS. Also Navigation may increase UFO's maneuverability when close to Earth's surface; pro arguments are: Harvester carries 10 Navigations (to pinpoint small targets, say, lonely cattle), Terror ship has 8 (to drop terror squad accurately onto city roads as shown in the Intro movie), Abductor has 5 (to pinpoint lonely men at rustic areas; also it's Size is Medium, not Large as Harvester), Supply ship has 4 (all that it should do is landing near Alien Bases); Battle ship has 4 (as it's main activity are air combats and X-Com base assaults); both Large and Medium Scouts (Small Size ships) have 2 each.

Next, though Large and Medium Scouts have the same UPS and Navigation number, the first is faster being larger. But Large Scouts carry not only Navigators but 3 (estimating by Sectoid staff on Superhuman Difficulty) Engineers also. Probably, Engineers may adjust UPS to optimal performance that results in Speed increment (from 2400 to 2700 km/hr) and Weapon Range increment (from 15 to 34 km) yet Weapon Power doesn't change (20 damage units per attack). All the larger UFOs have full Engineer staff on board, namely 2, so their UPS are adjusted by default.

Abductor and Harvester have 2 UPS each, 40 du Weapon Power, 20 and 22 km Weapon Range, 4000 and 4300 km/hr Speed respectively. Supply ship has 3 UPS, 60 du Weapon Power, 34 km Weapon Range yet only 3200 km/hr Speed. Terror and Battle ships have 4 UPS each, 120 and 140 du Weapon Power, 42 and 65 km Weapon Range respectively; their Speed values are 4800 and 5000 km/hr.

At this stage of our research we have got two questions.

First, Weapon Power values are expected to be proportional to the number of UPS multiplied by 20 du, so Terror and Battle ships should have only 80 du each. Probably, the explanation of such increase is UPS configuration. In both cases UPS are placed by corners of quadrate. Let's suppose, without too much far-fetching, that plasma beams, normally dissipating and losing power at larger distance, may focus somehow being close together, yet not too close, as Battle ship Weapon Power is higher. Also, that may explain the Weapon Range increment as well. Note that Large Scout has normal Weapon Power but quite high Weapon Range, 34 km, probably because of extended Engineer staff; otherwise it is expected to be next to Medium Scout's one, that is about 15 km. According to Abductor/Harvester, Supply ship and Terror ship data, each additional UPS increases the Range by 9 km in average.

Second question is the Speed of Supply ship. One (well adjusted by Engineers) UPS increases UFO Speed from 2200 to 2700 km/hr (Large Scout as compared with Small Scout). Another UPS yields 4000-4300 km/hr. Another two yield 4800-5000 km/hr. So, in average, each UPS brings another 700 km/hr to basic Speed of 2200 km/hr.

This Speed is probably provided by some propulsion device built in UFO's construction, as Small Scouts have about nothing but hulls and no trophy but alloys may be recovered. Another anomaly is special reinforcement of ship hull. Calculating the ratio of Damage Capacity to recovered Alloys quantity we get 5-7 for Large Scout, Harvester, Abductor; 13-15 for Supply, Terror and Battle ships; 18 for Medium Scout and 50 for Small one. Hypothetically, Small Scouts may be the most expensive ones to craft, while Harvesters are the cheapest, though it is quite reasonable in some way. Also, the theory of built-in UPS and Navigation may explain why even extremely damaged UFOs that have lost all their usual UPS may land without crush and crater, automatically, if Navigators are dead. Not speaking that Small Scout crew and personnel is presented by one Soldier (Muton occasionally), so its missions may be automatic in general. (Well, suggesting there is one hidden UPS out there somewhere, we just get another set of numbers: basic Speed of 1500 km/hr plus the same 700 km/hr per additional UPS in average. And three hidden UPS would give us simple linear dependence: Speed = UPS Number x 700 km/hr.) Still, even if we exclude Small Scouts from our research totally, the problem remains: Suppliers are slow.

Thus, the expected Speed of Supplier is about 4200 km/hr, not just 3200. The possible explanation is their cargo of 20 Food units, since these ones are fragile containers (as they may be easily damaged in cross-fire) vulnerable to acceleration overloads; on the other side, Harvesters carry 14 Food units but they have 10 Navigation units vs. 4 on Supplier's board, so more advanced propulsion control may reduce these overloads.

Also, there is once more interesting fact: only Terror and Battle ships have Entertainment modules, 8 and 24 respectively. And only these two types carry Terrorist alien combat units, 10 and 6 respectively (as well as Alien Bases, with 55 Entertainments in average and 7 Terrorists). Let's suppose that the true purpose of these enigmatic devices is 'entertainment', or rather brain-washing, to bring Terrorists under their master's control without excess efforts, or at least to suppress their aggression temporarily. Though, it is another topic at all.

At Terror ships, Battle ships and Alien Bases there are some devices looking like red spheres with blue tubes connected. They referred as plasma conduits, and Engineers may be found over there. Yet hardly that means the same green plasma their weapons shoot with. Let's suggest that these things contain some kind of special food produced from harvested trophies and used by aliens, especially by Terrorists as they need more energy to fight. Maybe, since they are subject to psionic control, or stun damage, in contradistinction from X-Com HWP tanks, even Cyberdisks and Sectopods have some organic brain-like component inside, so they need food too, in addition to electric accumulators, or Elerium batteries recharge.

Now back to the main question. Note that UFOs may not shoot two or more targets simultaneously, or at least never displays such activity. If so, these Plasma Guns have one-target operation mode only. It corresponds with the usual function of combined UPS and Navigation system as ship propulsion engine. Next, let's suggest that Navigators are ship Gunners also, while Engineers may adjust UPS to yield additional power boosting Speed and Weapon Range. Also it is reasonable that one of two Navigators controls the flight while another shoots during air combats, with some help of ship Engineers.

Another fact is Alien Bases, even Cydonian, have neither Rocket Defense nor Plasma or similar defense system at all, only some alien combat units at most, though it could be expected to have anti-aerial power weaponry (versus meteorite bombardment, for example). Obviously, base UPS can't be used that way as they are deep beneath planet's surface.

To conclude, let's note one more observation. UFO Power Sources have no complicated control console, as Navigations do, not even chair nearby. Yet there must be something Engineers can do with. Even Muton ones. Navigation control panels don't fit, as Engineers are looking at UPS from close range, without distant controls. On the other side, two Engineers are enough to adjust four UPS in opposite corners of Battleships. Also, as UFOs with solo UPS may change flight direction due to Navigators, their control of UPS generated fields must be quite versatile. So let us suggest that Engineer's job is periodical control of some close range field that protects UPS from propulsion forces and thereby distorts any distant sensors beyond reliability.

Though it's only theoretical, aforesaid may pretend to explain some unclear details of UFO Power Source functions.
[[User:VanTorrens|VanTorrens]] ([[User talk:VanTorrens|talk]]) 12:45, 24 October 2019 (CEST)

===Why battlescapes always being "opaque"?===

Every time an X-COM taskforce disembarks from the transport, they always find the surrounding being completely “shrouded”, despite in common military practice, there must be recon satellites and/or scout planes to overwatch the AO, even with hostiles marked and tracked. Even if X-COM doesn’t have that kind of luxury, their transports should be able to scan the AO before landing to provide a rather clear and detailed map for soldiers.

And similarly, X-COM bases seemly never have any CCTV system, so during a Base Defense mission, the soldiers effectively fight in blind despite on their own turf.

However in Alien Base Assaults, it’s understandable. Since an alien base is subterranean and it’s almost devoid of artificial illumination, also it’s impossible to send a spy for pre-battle reconnaissance, and seems aliens don’t have terminals for being hacked in corridors, so an alien base is supposed to be “shrouded”.
[[User:Lixiaofossil|Lixiaofossil]] ([[User talk:Lixiaofossil|talk]]) 15:24, 5 December 2023 (UTC+8)

==TFTD issues==
===What was the relationship between the aliens from the 1st and 2nd wars?===

Quoting from the UFOPaedia regarding Alien Origins: 'Deep in the oceans there lie ancient
sites used by the Aliens to contact their stellar cousins.' This also has some implications regarding the issue of why T'Leth was only activated when the Sectoids were defeated.

*Gill Men are coopted Terran creatures, Aquatoids are a differently-modified Sectoid breed, Lobstermen are machine soldiers that are manufactured, Tasoths are clone soldiers that are grown.

Aquatoids are the ancestors of the Sectoids. The colony ship was sent out slowing than light hundreds of millions of years ago. Sectoids are a more genetically advanced race. The rest of UFO aliens were picked up after that point. The Brain and Ethereals probably conquered the Sectoids and don't regard them highly. While the Aquatoids that were thawed over the years created, conquered (Gill Man) or manufactured the rest of the allies over time. I picture the Tasoth as probably something they brought with them and have been working on. Since most of the Aquatoids come from suspended animation they have not tinkered with genes much. Instead modifying and using electronics (MC Chip) to control. --[[User:BladeFireLight|BladeFireLight]] 17:28, 22 March 2010 (EDT)

===What kind of materials were 'synomium' and 'adamantium'?===

The first one is mentioned on the name of the alien communication devices and the second one appears at the end when T'Leth is destroyed: 'he twisting hugeness of T'leth begins to rupture.
Flames and smoke spew from its gleaming spires and adamantium halls.'

:Synomium is probably a special material used in the comm. devices, like Stargate's naquadah (universal stuff), naquadria (unstable power source), trinium (hull material) and neutronium (superdense metal). Adamantium is a legendary material in ancient literature that is said to be indestructible, similarly to mithril.--[[User:Amitakartok|amitakartok]] 10:55, 3 November 2009 (EST)

:Adamantium is said to be one of the strongest elements in many books and films such as X-men. --[[User:St.froppelie|St.froppelie]] 19:45, 23 October 2011 (GMT)

*See also Wikipedia article on Adamantium: [http://en.wikipedia.org/wiki/Adamantium]

===How deep were X-COM bases located on the seas?===

*Floating bases would be easier to build, repair and supply. However they would have to be tethered to the ocean bed or possess some sort of propulsion to prevent them from drifing with the ocean currents. But it would also allow for easy redeployment of the base.
*Submersible bases could allow for better sonar detection. Same problems regarding ocean currents would apply. In case of hull breaches entire modules would be quickly flooded and any crew present would be crushed by water pressure or drown. Base could be built and then submerged (requires depth control)
*Seabed bases would be the hardest to build and supply. Several other factors could limit their deployment, such as unstable areas (underwater volcanoes, prone to seaquakes, rock avalanches, etc.) and depths.
*Given that the Alien Retaliation missions in TFTD are called "Floating Base Attack", I'd say floating. Also remember that your starting sonar can't see Very Deep, which rules out seabed bases. [[User:magic9mushroom]]
** Floating doesn't always happen on the surface. The surface has to deal with large waves ad bobbing up and down, submerged only has the currents it could be stabilized easier. --[[User:BladeFireLight|BladeFireLight]] 11:57, 14 January 2010 (EST)
* I was recently researching how far you have to be down to not be effected by surface conditions. You have to be submerged 1/2 of a waves lenght (measured crest to crest) Best I can find is that the average wave is 150 yards accross. To not be effected by the waves you have to be 75 Yards below. This is way below the depth needed to not be effected by the bends when surfaceing. I figure they are probably right at the limit of what can be safe for quick surfacing and well anchored to avoid getting [http://www.youtube.com/watch?v=LwKXfc_a4Ag tossed in a storm]. --[[User:BladeFireLight|BladeFireLight]] 17:37, 22 March 2010 (EDT)
**Something else to consider - these 'floating bases' could be large modular submarines/submersibles. If memory serves, submarines basically maintain sea-level pressure regardless of the depth, so that could explain why they'd be able to be 75+ feet below sea level and not suffer the bends when surfacing.
::(Or, y'know, we could just say "a wizard did it".) --[[User:Guido Talbot|Guido Talbot]] 14:13, 16 July 2010 (EDT)

==XCOM: Enemy Unknown (2012) issues==
===Motives behind the invasion===
Now, the UberEtherial pretty much spells out the whole point of the invasion, as well as of their use & control of all the other aliens: they ''wanted'' humanity to evolve and become powerful, because they needed a species that was both high in physical prowess, and a powerful psychic warrior. He (presuming gender) freely admits that their bodies suck (and that the other races suck in body and/or mind even more), and the 1st-3rd-1st person pronoun switch in ONE sentence ("We who failed to ascend as ''they'' thought we would") and "preparation for what lies ahead", as well as his descriptions of the other alien races in the Temple Ship imply a number of things:
*The other races are enslaved races, perhaps from earlier invasions (possibly starting with Sectoids and Etherials being different castes of the same species?), themselves having been enhanced by their own resistances, before becoming enslaved on the degree of being puppets.
*The whole point of the invasion is enslavement of humans, not extermination, for the perfect warrior-- any Metroid fans can think of the Chozo also becoming masters of Psionics and energy manipulation, at the cost of becoming physically frail and infertile, and entrusting the Power Suit -- and their legacy -- to Samus.
*The alien surgeries (which greatly resemble Sensory Deprivation tanks-- you can even zoom in to see captive humans twitch sporadically) are their version of XCOM's Psi Lab (which ''also'' greatly resemble Sensory Deprivation tanks): they are 'farming' humans for Psi potential, similar to how us, the player, may farm soldiers for our own Psi Squad
*Which then makes XCOM almost as much the ''Etherial's'' project as it is the Council's (hence why they do not invade or attack XCOM HQ or Interceptor bases)
*Someone/thing ''else'' is involved, someone the Etherials are in some way subservient to: notice in the Temple Ship and in the Overseer UFO, the strange, Cathedral-like "Stained Glass Windows". To me, there appear to be ''two'' figures in each: the much more visible 4-armed Etherial silhouette, and in a transparent, but slightly darker shade of lavender, some other 6-8 limbed creature, with a larger body and a very different head-shape behind the first.
*"What lies ahead" may mean some coming disaster, or merely a challenge and testing from this sequel-hook of "They"
*Additionaly: the description of the Hyperwave device implies contact with an alternate dimension. The organic-metallic (silicon based, perhaps?) form of the Outsiders (as opposed to the rather obvious "manufactured and machined parts grafted onto flesh" Cyborg attachments of both Floater varieties), and their absence (especially from the Temple Ship) after the device's capture, as well as released screenshots of the upcoming FPS XCOM game (mentioning Outsiders AND being placed several decades ago)-- all this suggests alternate timelines as well as alternate dimensions (in quantum physics, these are practically the same thing anyways), as well as some species native to this ''Outside'' dimension that are the ones, this "They", whom are actually calling the shots.
--[[User:Xuncu|Xuncu]] 03:56, 26 January 2013 (EST)

*Just to verify the point about the Outsiders, they are called OUTSIDERS, which pretty much means not native, so possibly they are not native to this dimension, also, "What lies ahead" Could possibly be foreshadowing a TFTD remake? And the Outsiders are merely, prototypes of the Ultimate Alien?
[[User:XBrassxDragonX|XBrassxDragonX]] 22:59, 25 May 2013 (EDT)

*The UberEthereal is a rebel against "They" he/she/it united a group of Ethereals, and left "They" Then, he/she/it proceeded to search for the Ultimate Race, a race that was as tough as a Muton, and as Psionically Powerful as an Ethereal, these were the Humans. This Ultimate Race would overthrow "They" and thus, complete the Ethereal's legacy, it could also be, that through the use of implants, and sacrificing physical strength for Psionic Power, the Humans could walk the same path as the Ethereals, and be contacted by whatever was left of "They" then, the Humans would help "They" rebuild, and realize the sinister motivations behind "They's" plan, and thus, repeat the story in a never-ending cycle.

===How is it possible for Psionic soldiers to exist?===
After capturing a Psi-capable enemy and dissecting it: does XCOM reverse-engineer the implants and insert them into troops (whether they test positive (capable of using them) or not)? Or, is the testing just digging for a Psi signal that ''is already there''? In which case, it's a human-evolved trait, but from where, and why wasn't it found before? Vahlen's reasearch implies similar genetic struture between aliens and humans: do humans and Etherials/Sectoids have a common Psi-capable ancestor, or have the Etherials been interfereing with human evolution for at least 20-30 years (or however old troopers tend to be, with Shaojie Zhang and his advanced age, equally possible to have Psi-Abilites), if no longer? At least in Apocalypse, there's the excuse of Sectoid/Human Hybrids. How do humans use a power just discovered that year, and only a few months of practice, end up with the capacity to potentially mind-control Etherials, each of which who have several thousand years of personal experience with Psi abilites? --[[User:Xuncu|Xuncu]] 05:28, 11 April 2013 (EDT)
:It's implied that humans were always latent psionics (it's possible that if we weren't, the Ethereals would never have bothered us at all). The cutscene where your first psionic is found suggests the testee is immersed in some sort of purple gas, which presumably causes some physiological change to make them operant psionics. As for how human psionics get so good so quickly, good question, though bear in mind that psionic humans are implied to be an Ethereal's equal in raw power, but while an Ethereal has to expend psionic power all the time just to stay alive and standing, a human can devote it all to his psionic attacks. This could explain why humans are on an equal footing with Ethereals despite having comparatively little practice. More simply, it could just be that humans are badass compared to aliens; we certainly seem to be able to reverse engineer their technology in record time AND then make improvements to it, suggesting we're frankly just "better" than them. [[User:Binkyuk|Binkyuk]] 09:07, 12 April 2013 (EDT)

:Another possibility could be that Elerium exposure maybe one of the factors. While Doctor Vahlen stated that she found a correlation with high will power and psychic ability, gameplay mechanics aside there are cases where a very high willed soldier came back from the Psionic Labs who had displayed no psychic prowess whatsoever. Elerium is used in the alien technologies and it was only after the Alien attack that XCOM was able to 'make' psionic soldiers. Another piece of evidence is that pieces of equipment such as the Psi Armor and the Mind Shield require a large quantity of Elerium in order to manufacture and that it 'enhances' the Psychic abilities of the wearer. While it is true that Elerium is used as a power source for the armor, unlike the hulking Titan armor the Psi armor is essentially a skinsuit/catsuit/muscle suit that has no visible heavy pieces of armor but yet the Elerium requirements for a set of Psi Armor exceed the Elerium requirements for the larger, heavier Titan armor. Logically (again, gameplay mechanics aside) speaking the lighter Ghost armor could perform the same if it used the same amount of Elerium for the Titan armor yet it requires more to function. Combined with the fact that the Psionic Labs and the Gallop Chamber (Both facilities that involve Psionic's) are the only XCOM facilities outside of the Elerium Generator that requires Elerium in their construction means that Elerium maybe linked to the manifestation of Psychic phenomena.
[[User:GMPilot0079|GMPilot0079]] 3:56, 13 May 2013 (CST)

===Bureau/Enemy Within/My Little Pony Supplemental===
{{Ref Open | title = Yes, really}}
How does a ''Psychic'' attack on an XCOM soldier cause obvious psychological effects (-will, -aim), but damages ''armor'' first?

So, it's a safe assumption that the "They" spoken up above is probably the likes of [[Ethereal_(Bureau)|Asaru and Shamash]], "True" Etherials, who's physical forms have been discarded in trade of bodies made of pure energy--- much like EU/EW's Outsiders (not the Zudjari-- for clarity's sake, "Outsider" means the UFO-commander type alien in EU, and Bureau's 'Outsiders' shall be specifically called "Zudjari") are ''also'' described as being of pure energy. So, Bass Dragon was half-right: the Outsiders are not prototypes, they're attempts to ''reverse-engineer'' the Ultimate Life-forms that are the True Etherials. Shamash outright said they exist in multiple realities (either in the "omnipresent" sense (and the "physical" body is just the part that happens to intersect this reality), or that they can shift between alternate realities, XCOM's dimension included), and the Hyperwave Uplink, which seems to be the source for the Outsider's existence, has in-game descriptions that states that it has some kind of access to alternate dimensions, I think confirms this. The fact that Origin could study and emulate Shamash through scientific methods also leads credence that the Outsiders were scientific attempts to manufacture a True Etherial (or analogue thereof), via the Uplink.

The slave collars on the Bureau's Sectoids. I used to think that Sectoids may have been a low catse, but effectively the same species as Etherials. But, that was more based on the 1994 game's depictions, where the Sectoids were weaklings, but seemed to be "just another member of the alien horde." With 4-armed Etherials being canon, it's more likley that Etherials share a common ancestor with Slenderman than Sectoids, since evolution doesn't really work that way (ie: all/most (modern) Earth animals with spinal chords (chordate [http://en.wikipedia.org/wiki/Chordate] ) follow a "head and 4 limbs and 2 eyes" body configuration). More likely, Sectoids are the "for hire/sale" whipping boy of the universe. Additionally, the slave collars that are suggested to help link them to the Mosaic Network, show how incomplete Origin's manipulation of Shamash was: in the infliltration of the Spire in Arizona, Dr Wier comments that Mosaic "seems to want to help". But, as the normal Etherials were collectively working together, that is why EU's Sectoids were without collars: the Etherials had no need for them.

Sectoids on sale, now 50% off, this Rel only, here on Shopduct n' Slave!

Now, the Meld: it always struck me as odd how ''careless'' the aliens seemed to be, leaving massive resources laying around for XCOM to collect. If XCOM was some kind of MMORPG, I would bet that players who chose the Alien factions would often blow up the Elerium Generators and Navigational Computers if it looked like they were going to lose a base or UFO (Chryssalid Rush, ke ke ke!). That they leave the Meld hanging around seems to me that they ''want'' XCOM to get it, which goes with what I wrote long ago up there about how XCOM could be said to also be the Etherial's project, at least indirectly.

On the other hand; how does Meld tie in with the purpose of the invasion? Searching for the Ultimate Life Form, "as we sought to uplift them, to prepare them." In other words: those aren't mere storage canisters, XCOM Bait, or bombs. They're ''dispersal units''. The Etherials' plot was to seed Earth with Meld to enhance physical capacities anyways (Mechtoids, Floater/Heavies), while doing abductions as mass "Farming" for Psi-positive humans (ie; like how the player buys soldiers in bulk, and picks out the ones we want to submit for Psi testing). Failures: we fire them, Zudjari kill them and dump 'em out back, Etherials and The Matrix turn them into flood slurry, and the Wachowski Siblings make a third movie and lose all credibility.

Which brings me to my third topic, where I talk about a cute talking unicorn that hails from a magical Fantasy kingdom of baby horses.

In the crossover fanfic [http://www.fimfiction.net/story/100455/stardust XCOM/FiM: Stardust], the Author is (with obvious liberties) attempting to stay accurate to XCOM's technical information (with assistance from this very 'Paedia: he's seen my work here). The major alterations to the plot are that Bradford replaces the player character of the Commander, and instead of Fluttershy reforming Discord, Discord makes a bet with Twilight Sparkle to "Convince me, irrefutably, that friendship is the strongest power in the universe."

With Twilight accepting the terms, Discord teleports her to April 02, 2015, to the site of a Terror Mission in Washington DC, within 30 feet of a Chryssalid.
:If you've read this far, I assume I've had your interest. If I now have your attention, and want to read the story without getting spoilers, scroll down to where '''Elerium''' is next written in bold.

So, obvious question: "What the hell does that have to do with anything?!" Well, the Author is trying to stay accurate to EU and Bureau (he did start writing before much of EW was revealed) while writing his own story, and he addresses several valid points that solve, or at least address several XCOM mysteries. The unique viewpoint of involving cartoon ponies is for flavor, amusement, and contrast to better see them.

As the story continues; Twilight is captured by XCOM, and almost Interrogated by Dr Vahlen, but manages to escape the containment cell. Hijinks ensue, Dr Shen talks Bradford into allowing him to make contact (referencing the in-game Arc Thrower conversation between the three), and Twilight is now a 'guest' of XCOM, taking residence in "Stardust" Labs. Eventually, she helps in XCOM's research of both alien technology, and her own magic abilities: The magic field she uses in Equestria is also available on Earth, but is stiff from "disuse," but is discovered to be the same field that the Aliens use for Psionic abilities. It's revealed that Elerium is, or is at least an analogue to "Arcanite", a material that boosts magic abilities. Ergo: Elerium boosts Psionic abilities. As Twilight assists in both XCOM Research, and indirectly with missions themselves, with her magic, her use of the Field begins to awaken the Psionic/Magic abilities of the humans around her. For example, Commander Bradford has 'time-stopping' precognition; several times, he has seen TPKs, only to snap back into real time shortly before it all goes to hell-- save states, basically.

Her assistance also points out that the implants found in the aliens, particularly the Sectoid Commanders, also have Elerium circuitry that activates/boosts/projects their Mind Control ability (as well as all aliens to be able to be controlled by the Etherials, who have not yet been revealed in the story, save for a refrence to/by a possible EXALT/Osiris member, and another to William Carter). This also points out that the Etherials are not specifically "Religious" of themselves, as Origin was, but are scientific-minded (the "All Technologies" research credit).

The mystery of XCOM this addresses is, as Analyst Krut points out in The Bureau: "Why?"

"Dear Twilight Sparkle,

'''ELERIUM.'''

Sincerely,
:Pinkie Pie!"

The Field that makes the abilities possible has probably always been here, and is perhaps universal, as inherent as magnetism or gravity (or, if you want a ''stupid'' comparison: like the "Chroma" in ''Indigo Prophecy''). And, with Elerium and it's use making Psionics easier for humans, Earth is now a 'factory' for making the most potentially dangerous beings in the universe.

Evolution, at least on Earth, is more about "Good enough"/"it ''works'', duddn't it?" than any search/aim for "better", and certainly not "perfect". If there was no evolutionary push (or capacity) to be able to use the Field (as useful as it would be), such traits would not develop. Interesting examples where real-world animals do use advanced physics are the Pistol Shrimp, who's claw has evolved in such a way that's essentially a [[Sonic_Pistol]] and can make a luminescent spark of plasma that's the same temperature as the surface of the sun, and dolphins that use complex fluid dynamics that humans barely understand to, basically, just pass the time [http://www.youtube.com/watch?v=TMCf7SNUb-Q].

So, the Field that makes Psionic abilities possible is, in fact, accessible to humans, but as it is not often developed; it's rare, or doesn't manifest strongly. But it ''is'' there, so there is a motivation for the Etherials to come to Earth and do their testing (Incidentally, I don't think there is anything really saying that the Etherials knew that Asaru and Shamash were here).

Which also addresses "Why now?"

Because Elerium is now on Earth: in The Bureau, it's established that the Zudjari have been seeding the Earth with Elerium as early as 1957 (the year that Spudnik was launched: the satellite is even seen in the opening sequence of a campaign). If Elerium boosts Field abilities, such as Psionics, then 58 years of low-level global exposure may have triggered/boosted enough to draw the attention of the Etherials (incidentally, background radiation from above-ground nuclear tests peaked in 1963 at about 0.15 mSv per year worldwide, or about 7% of average background dose from all sources. The Limited Test Ban Treaty of 1963 prohibited above-ground tests, thus by the year 2000 the worldwide dose from these tests has decreased to only 0.005 mSv per year [http://en.wikipedia.org/wiki/Background_radiation#Atmospheric_nuclear_testing]-- and in Angela's ending, she gets the US Government to use nukes to erase evidence of the invasion). This may also be why the aliens seem careless with Elerium; not as effective at making enhancements as dispersing Meld, but may help instigate Psi activations.

Now, I realize: if Psi powers ARE a scientifically understandable energy wave (and not straight-up "Magic"), then it does make sense that armor is damaged ''as well'', and that the suits that include Elerium can block the "piercing/bypassing" damage that I think would be more realistic. And for the armors it doesn't make sense for; they don't give an HP bonus big enough to make the difference.

Which leads to one more interesting thought: Elerium is not exclusive to the "Etherial Empire", or whoever controls the Sectoids (as Elerium is not in Apocalypse(?), but Sectoids are): while not naturally native to Earth, there's nothing saying how limited-- or abundant-- Elerium is throughout the universe (Arcanite). Less evidence, and more of a hunch: may Elerium be somewhat... "viral"? That it may at least "try" to spread as it goes, as the Bureau suggests? Like a milder version of Tiberium [http://cnc.wikia.com/wiki/Tiberium] or Phazon [http://metroid.wikia.com/wiki/Phazon]?

Obviously, Origin didn't have the device that had Asaru before the invasion, BUT, Faulk said the device was found ''in an Elerium Mine'' (in Montana). In other words, the Elerium aggregated around Asaru, who was there ''first''. So, there is enough to establish that there is a link between Elerium exposure/presence, and Psionic abilities, as is shown in Stardust.

In conclusion:
* ???? - Asaru arrives on Earth
* ???? - Sectoids, a clone race, are sold in open intergalactic slave markets to various alien empires across the universe: as clones and near-blank genetic templates, their adaptability, ability to be mass produced, and 'ease of use' (aided by Psionic links to one another) lends to the success of their sale.
* 65,000,000 BCE - The Lovecraftian "Vortex" Empire (refrence: Ecco the Dolphin [http://eccothedolphin.wikia.com/wiki/Vortex_Queen] - would explain why they look like Earth's aquatic animals), hailing from aquatic worlds, crash land a colony ship on Earth, either because, or ''as'' the impact that led to the extinction of the Dinosaurs-- and in the process, pave the way for mammals, and eventually for Humans to rise, whom will spend the rest of Time crossing Space, and even going into other Dimensions, obliterating every alien menace they encounter. Way to go, guys.
** Due to the exclusion of Elerium and their preference of aquatic habitats, their own research creates Zrbite and Aquaplastics, and they modify their own Sectoid slaves/genome templates into the Aquatoids.
* ????-1957-1962 - Zudjari, as part of their normal conquests' terraform operations, and the search for True Etherials, seeded Earth with Elerium in [[The_Bureau:_XCOM_Declassified|The Bureau]]. Asaru awakens, Shamash is killed, and Origin is deleted in a massive Etherial-fueled Psionic wave.
* 1962-2015 - Background radiation from Elerium is covered up by atmospheric Nuclear Testing, but the effects are still felt worldwide: while skills may not be developed, Psionic potential grows.
* 2015-2016? - The "cast out" Etherials begin their conquest and research of Humans and Earth, led here either by Elerium's energy signature, Psionic energy signatures, or due to the presence of the two True Etherials on a single planet; and event said to be a multiversal rarity. The battles between them and XCOM are a boon to human science and technology. Psionic experimentation, and the dispersal of Meld lead to the enhancement of both the human mind and body. Then the Etherials get blown the fuck up.
** Black Market interests begin the EXALT organization, a paramilitary group made with the aim of stealing and adapting alien technology and materials to force human evolution. After the raid on their headquarters and the neutralization of their command leadership, remaining members go into hiding, and begin to pass and adapt their ideology down family lines.
* 1997-2002 - Due to the energy signal released by the death of the multidimensional being Shamash: in an alternate timeline/dimension, the Etherial invasion happens earlier: since the Alien Brain is a computer, it's able to organize the invasion that much faster. The Tachyon signal released upon it's destruction lasts only a little while, but as the Tachyon is a (theoretical) FTL particle, it's properties are not restricted to 'normal' space-time.
* 2027 - Reminants of EXALT reorganize into the Cult of Sirus.
* 2041-2046 - As the Aquatoids were able to receive the signal as easily as their Sectoid cousins, they began the resurrection of T'leth: thus, the [[TFTD|Second Alien War]].
* 2084 - The Micronoids, while not as experienced as Etherials at multidimensional travel, also register the death of Shamash, and begin [[Apocalypse|their assault]] on the largest Earth-based population: Mega-Primus. Thanks for that, Carter.
** Sectoid-Human hybrids were origionally developed by the Etherials in an attempt to add the docile and controllable aspects of the Sectoids to the physically and psionically potent human race, much like the 1957 experiments with Africanized Honey Bees. In fact, ''exactly'' like those experiments: those bees are now known as "Killer Bees", and the Human-Sectoid mutants are willing to fight for XCOM, in exchange for universal rights.

Aaaaaaaaaaaaaaaaand there: a Grand Unified Theory of XCOM!
{{Ref Close | source = --[[User:Xuncu|Xuncu]] 08:53, 24 November 2013 (EST) }}
And yes, I feel there's legitimacy in connecting XCOM to Ecco: [http://www.youtube.com/watch?v=blaX_eMz3Qw Et voilà.]--[[User:Xuncu|Xuncu]] 17:49, 24 November 2013 (EST)

[[Category: Fiction]]
[[Category:Enemy Unknown/UFO Defense]]

Talk:Known Bugs

2025-08-03T00:30:07Z

TowigOs: Fix typos and add missing info

= Classification etc =

== Bugs vs Exploits ==

Could someone comment please on the distinction between a bug and an exploit, and where to put each one? I would guess that a bug is something that undesirable and an exploit "might be" desirable, if you want to cheat. But what about exploits that happen by accident, or bugs that need to be forced to happen?

I was going to add the Research Rollover bug to the Exploits sections, but they seem to all be under construction. What's the agreed approach?

[[User:Spike|Spike]] 04:16, 15 March 2008 (PDT)

* i think that an exploit is somthing you can trigger and gain an advantage from. a bug may or may not have a known trigger, and does not give an advantage if it does.
: All exploits are bugs, either in implementation or design. When using a bug to gain advantages that bug is used as an exploit (you are exploiting the bug). [[User:FrederikHertzum|FrederikHertzum]] 13:39, 10 May 2011 (EDT)

:: IMHO, Laser Pistols Gifts to train reactions is an exploit, but it does not involve any bugs. It merely exploits the fact that laser pistols will not penetrate the front armor of Flying Suits. [[User:Jasonred|Jasonred]] 16:31, 10 May 2011 (EDT)

::: I guess the point is to differentiate if it's a bug that's being exploited to your advantage, or it it's something confined within the game mechanics that you are exploiting to your advantage (even if using it as intended). -[[User:NKF|NKF]] 02:31, 11 May 2011 (EDT)

:::: Another definition: An exploit is
::::: a) a move allowed by game interface
::::: b) that sidesteps another part of the game mechanics
::::: c) and creates inadequate advantage for the moving player in the process.
::::: An exploit is not a bug, but it can be connected with a bug, if the latter allows a move mentioned in a). Most obvious exploits render whole parts of game mechanics obsolete (see b) above), because they are always more advantageous. In games that feature equal terms for AI and the player, an exploit can be discerned simply by the fact that AI does not use it (sadly this is not true in X-COM). Clear exploit in X-COM: Transfer soldiers = no monthly payment. Suspect exploits: grenade layout. Most probably not an exploit: Sniping (although the inequality with AI is suspect). Clearly not an exploit: dropping weapons to prevent Psi mass murder (this one is made exploitable by the AI unable to pick up weapons, but is not an exploit per se).--[[User:Kyrub|kyrub]] 05:30, 11 May 2011 (EDT)

The dropping weapons sort of turns into an exploit if you do the "everyone suspect of being a psi weakling drops their weapons at the end of the turn. They all pick up their weapons again if unpsied in the next turn." The grenade layout or grenade hot potato is probably not what the game designers had in mind, but I shudder at the thought of someone who only played X-com then joined the army pulling the pin out of his grenade and then dropping it into his haversack or slinging it on his belt. [[User:Jasonred|Jasonred]] 07:43, 11 May 2011 (EDT)

: Yeah, I think we agreed somewhere that shoving live grenades in your pockets and not having them go off is madness. The relay however is not sensible but certainly possible if only a very short one (if with a live grenade), or to toss a grenade forward and prime it at the second to last person. Or more reasonably, something like a stick of dynamite with an extra long fuse. Even that's very dangerous.

: By the way, what does everyone here think of using the mind probe to check if it's safe to attack an alien while standing in full view of it, or if you're right up next to it? I've been using it a lot lately (in lieu of the psi amp), so you could say I've been exploiting the mind probe to my advantage to help me with my decision making. But is that counted as a cheat since I'm picking my moments to attack up close when the enemy cannot return fire? -[[User:NKF|NKF]] 03:30, 12 May 2011 (EDT)

:: When identifying a mechanic as an "unfair exploit" (as opposed to just a "tactic"), perhaps a simpler checklist is this (though Kyrub's is spot-on):

:: a) Is this something the developers should've expected players to do?
:: b) Is this something the developers could've easily prevented?

:: If the answer to both is "yes", then it seems fair game to me. For eg, sniping at aliens: The game KNOWS whether the soldier can see the target (you get a flashing indicator if so), and so it would've been trivial to prevent it. Is it something the regular gamer will try? Certainly; therefore it can be considered expected behaviour. Ditto for using the Mind Probe to make attacks without fear of reaction fire; those things aren't cheap, they sell for a bunch, so it stands to reason that they'd have tactical value!

:: Things like the transfer bug are clear exploits. The devs would've implemented that system so that, if you order personal near the end of the month, you don't end up paying for them twice before they ever arrive - but in the process, they forgot that "purchase" transfers are treated in the same way as "between-base" transfers. To fix one scenario without breaking the other, they'd've needed to code in some extra stuff so the game could tell the difference - they probably just figured the regular gamer would never notice, assuming they ever realised the problem existed.

:: The "dropping weapons" thing is a little trickier to work out - yes, the devs should've seen it coming, but would it've been easy to fix? Aliens could've been twigged to either ignore un-armed soldiers... but those soldiers could re-equip next turn. Aliens could also've been twigged to attack randomly... but that would make their psi powers far LESS effective! I suppose the fix, if any, would've been unarmed melee attacks, but the implementation they went with seems to be the next best thing IMO.

:: In regards to the "grenades in inventory" thing, it's probably common knowledge by now, but they DO go off in the alpha of the game. Presumably someone made a conscious decision to change that, though it could still just be an accidental bug. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:02, 12 May 2011 (EDT)

Sniping at aliens is a very bizarre case, since almost all players will fall prey to the aliens sniping at you long before they snipe the aliens. The behaviour of the aliens to step within sight radius, take one step back, then fire without fear of retaliation *looks* and *feels* like clear exploitation of the rules, but the computer can't be a cheater, can it? So we humans carry that one step further. Mind you, I think X-com would be in trouble if the aliens could snipe you from across the map once they know your positions... especially since the aliens have cheating "if I spot 1 human, I spot ALL of them" abilities. Especially on maps where the aliens get Blaster Bombs...

An interesting note about sniping and LOS: When I first played Xcom, my first mission was in the jungle. Because of all those plants, when my first soldiers spotted an alien, after he shot at him, I tried to make my 2nd soldier open fire and was informed "NO Line of Fire". I could only get my 2nd soldier to fire by positioning him in such a way that I got the flashing number. Henceforth, I assumed that you could ONLY fire at the aliens when the flashing number was there. LOL. LOF. LOS.

Transfer bug wise, I thought that the devs merely programmed the game to count how many staff were currently in the base, then deduct that from Xcom coffers? As far as ordering personnel near month end goes, you end up paying salary for them if you order them more than 48 hours from month end, right? "realistically", they should make staff draw salaries based on when they were hired, but this would be too much effort.

"dropping weapons" would have been easy enough to fix... just teach alien AI how to pick up weapons. Like they did in Apocalypse.

As far as grenade relays go, if you ever join the army, and you toss a live grenade at your squadmate, you're gonna be court martialled! lol. Xcom grenades are weird cause they presumably come with a computer console where you program them or something that takes a lot of TU, if I already have a grenade in my hand I don't think it takes long to prime it compared to throwing it...

Pretty clear exploit/bug is tossing grenades through the ceiling? That breaks all laws of realism/logic/whatever, and I'm sure the devs didn't plan for THAT to happen! [[User:Jasonred|Jasonred]] 18:18, 12 May 2011 (EDT)

: Turns out the "spot one, spot all" thing was wrong all these years. However, units can be "spotted" by sniping an alien, hitting it, but failing to outright kill it; this may have contributed to the misconception.

: The game considers the base to have the correct amount of personal as soon as you initiate a transfer - if a base has room for ten people, you can't send two groups of ten, as soon as the first is in transit the game will correctly recognise that the destination is now filled up and won't allow you to send any more. Likewise, if you hire soldiers, they'll count towards the allowance of more promotions in your ranks before they ever arrive at a base. That is to say, the payment system deals with personal counts in a different way to every other system in the game, making it look like it's intentional (if badly exploitable) behaviour. In terms of transit times, those seem to vary, I know a purchase of scientists takes 72 hours to arrive.

: Er, yes, getting aliens to pick up weapons would've indeed fixed the dropping thing. Shoulda thought of that...

: The grenade thing is indeed unrealistic however you look at it. Certainly throwing the things through ceilings is a bug, and its use is a large exploit. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 20:02, 12 May 2011 (EDT)

:: Then how do the aliens "spot" the psi weakling to target him for psi attacks? Doesn't the game ALWAYS start blasting the juiciest target, regardless of LOS? Or is it just coincidence? [[User:Jasonred|Jasonred]] 22:22, 12 May 2011 (EDT)

::: They really have to "[[UNITPOS.DAT#8|spot]]" the target before they can blast them (however, it appears that later in a campaign this rule gets broken). If they've only spotted a psi-''resistant'' trooper, they typically won't bother to make attacks at all. There's a lot of relevant information in [http://www.strategycore.co.uk/forums/Can-alien-attempt-Mind-control-Pani-t8115.html this thread]. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 23:28, 12 May 2011 (EDT)

: Your talking about your post on http://www.strategycore.co.uk/forums/Can-alien-attempt-Mind-control-Pani-t8115.html&pid=96123&mode=threaded#entry96123 ? Well, I'd just like to point out a massive flaw in your testing logic. You forgot that aliens will launch psi attacks based on chance of success, and chance of success varies based on distance from aliens. In other words, it could easily be that the aliens only attempted psi when your soldier was within sight of them because your soldier was now NEAR to them and therefore they had a strong chance of success.

: Also, as you have noted, it appears that your rule gets broken. In fact, it is not uncommon at all for the Ethereal Commander who is boxed up in the Command Center to launch psi attacks on victims who are separated from him by several layers of walls, as long as their proximity to him is near enough. [[User:Jasonred|Jasonred]] 21:19, 13 May 2011 (EDT)

:: Those are valid points. I've hence built a somewhat more robust testing scenario, which you may wish to [[:Image:Alien Psi Demonstration 1.rar|try for yourself]].

:: The save game consists of cloned Ethereal soldiers (all cranked up to 100 psi strength/skill), and many clones of a single trooper (most of whom have the same psi values). The Ethereals are all cooped up in a sealed room in the SW of the map, with a single trooper who has 140 psi strength/skill.

:: Directly outside the building is another trooper who only has 1 strength/skill. In the NE of the map, in another sealed room, is a soldier with 40 strength/skill. Before placing him there, I had him shoot one of the Ethereals just once, resetting index 8 of his UnitPos record to 0. Only he and the trooper inside the room with the Ethereals have hence been "exposed" to the aliens, but the "best chance of success" is obviously the psi-weakling directly outside the building.

:: If you load the map and end turn, the aliens will first attempt to take control of the dude on the other side of the map, then get to work on the guy in the room with them. Once they've taken these two, they'll completely ignore all other units.

:: In short, aliens can't use psi attacks on a unit UNLESS their UnitPos[8] index is set to less then that of the alien's intelligence stat. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 05:41, 14 May 2011 (EDT)

::: Good one. That test definitely proves a lot, rather conclusively. [[User:Jasonred|Jasonred]] 06:53, 14 May 2011 (EDT)

== Bugs vs Limits ==

''(Discussion continued from [[Talk:Known Bugs#Soldier Recruiting Bugs Tested|Soldier Recruiting Bugs Tested]])''

The "Soldier Recruiting Limit" is not a bug, it is a limitation of the game. Therefore, this should be removed from the page. If we want it somewhere else (like a new page such as [[Game Limitations]]), that would be appropriate. --[[User:Zombie|Zombie]] 01:42, 9 November 2008 (CST)

::Not sure that's necessarily the best idea, Zombie, since many of the entries on the Known Bugs article(as well as some entries on the Exploits pages) are limitations of the game engine. On just a brief glance through, the following caught my eye as engine limitations: Manufacturing limit, Storage limit, Purchase limit, 80-item limit, Proximity Grenade limit, Large units not waking up from stun, Interception last shot bug, Alien UFL radar blitz-through bug(Passing through the detection range of a radar before the detection check comes up), Free manufacturing, free wages, UFO Redux, point-scoring with Ctrl-C, permanent MC of chryssalids, Zombie-MC resurrection of agents, alien inventory exploits, anything involved with bad collision detection, extinguishing fire with a Smoke Grenade, and even your personal favorite, denying the aliens access to their own spawn points. So in conclusion, maybe it should just be left as it is; conversely, all of these entries could be kept where they are and also on a Game Limitations page, or we could leave the headers there and link them over to the appropriate topics on Game Limitations. What do you think? [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:21, 9 November 2008 (CST)

: I agree with AQ (great list of examples by the way - and the Smoke/Fire limit would be another). Many, if not most, of the bugs are "Limitations" but they are logically inconsistent and not what a player would expect to happen: they are imposed by (at best) memory limitations or (at worst) design/programming oversights. I think the easiest thing to do would be to change the title of the page to Known Bugs and Limitations, or put an explanatory note at the beginning of the section to explain that "Bugs" is taken to included "Limitations". [[User:Spike|Spike]] 13:16, 9 November 2008 (CST)

By the strictest sense of meaning, a "bug" is a mistake or error on the programmers part. Limitations imposed by design or memory are not the same creature as the people involved were consciously aware of the decision. I suppose that to the normal player, any type of behavior which is unexpected/unwanted is automatically dumped in the bug category because to them there is no difference. To those of us who study the game files however, the two are unequivalent. Programming oversights, yes, those are bugs.

Some of those limitations AQ mentions are (to me at least) bugs: free manufacturing, free wages, permanent MC of Cryssies (or actually any alien for that matter), Zombie resurrections and collision detection. Large aliens not waking up from stun is again, a bug. The programmers obviously had some issues when dealing with large units in general and never quite got it right. They made some progress in TFTD by trying to fix mind controlling each section of a large unit, but royally screwed it up by selecting the next 3 entries in UNITPOS.DAT no matter what they pointed to.

Perhaps it's just my background in logic which makes me want to push for a separate category for limitations. Then again, as long as everything is listed somewhere I'm happy. --[[User:Zombie|Zombie]] 22:06, 9 November 2008 (CST)

: Actually, taking a look through the page as a whole there are various other Limits described, and the distinction between Bugs and Limits is made quite rigorously throughout - not just in the Soldier Limits and Bugs section, where the Soldier Recruiting Limit is referred to as a Limit whereas other bugs (such as paying salaries for soldiers you can't recruit) are referred to as Bugs. So we maybe just need to rename the pages "Bugs and Limits" and add an explanatory note on the distinction. From a user point of view, rather than a programmer point of view, a bug is an unexpected (inconsistent or illogical) behaviour, so for that reason I think it makes sense to keep them on the same page but try to ensure they are all correctly classified as Bug or Limit.

: By the way, it could be hard to absolutely distinguish Bugs from Limits as I suspect there are going to be some grey areas where you would have to second-guess the intentions and decisions of the coders to know for sure if something was a designed-in Limit, or just an oversight (Bug). [[User:Spike|Spike]] 06:50, 10 November 2008 (CST)

::If we distinguish in this manner, I suggest the definition of "Limit" should be, "Something imposed by the game files or engine as a limitation, most likely in context to the capabilites of the then-current personal computer." More succinctly, anything that was done to allow the game to run acceptably on what was then a PC. This would include both the Soldier and 80-Item limits, the spawn limit(40 units per side), Smoke/Fire limit, and some of the others listed. (The Purchase limit was probably more of a convienence for the programmers than anything, but it is clearly an intended feature.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:11, 10 November 2008 (CST)

: I would add to this that sometimes a Limit may be imposed as a game design / gameplay decision, rather than in order to conserve a constrained resource in the platform (=PC). Also, I would suggest that ''intended'' Limits are Limits, but ''unintended'' consequences of Limits are Bugs. Obviously, making this distinction involves some guesswork. But I would guess that while the limit on total smoke/fire hexes was an intended Limit (to conserve PC resources), the ability to put out fires with smoke grenades and disperse smoke with IC rounds is probably an unintended consequence of the Limit, and so should probably be considered a Bug. Similarly, Base Defence spawn points are probably an intended limit, but the ability to flood spawn points is an unintended consequence of this, and thus a Bug (and an Exploit). (Spawn points should have been shared out 50/50, not humans-first). [[User:Spike|Spike]] 12:07, 11 November 2008 (CST)

::The limit on Soldier and Interception craft were probably more of a limit imposed because they capped the file and figured that X-COM wouldn't ever need more than 40 interception craft or 250 soldiers. (And I've never needed that many, case in point.)

::As for spawns, its actually difficult to take advantage of it in any reasonably established base. X-COM can spawn up to 40 soldiers in a base defense mission(tanks count as 4 soldiers), as a limit of LOC.DAT. Aliens have the same limit. So in order to take advantage of the bug, the base needs 40 or less spawns total. The Access Lift has 8 spawn points, General Stores(weapon-handling) has 11, Living Quarters has 8 more. This is 27 Spawns just getting soldiers in a base and armed. (Although the General Stores can be cut out if you perform the bug properly). Large Radar and HWD have 6 spawns(Small Radar has 2), and Hangar has 15. So overall, the "Spawn prevention" can be hard to take advantage of with all but the smallest bases. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:48, 11 November 2008 (CST)

Just to clarify, X-COM interception craft are not capped at 40 ships. LOC.DAT has a cap of 50 "things" on the geoscape screen at a time. This is shared between X-COM bases, X-COM ships, alien bases, seen or unseen UFO's, terror sites, crash sites, landing sites and waypoints. In a perfect game world with little alien activity and normally constructed bases, the max number of X-COM craft possible is 44: 5 bases with 8 hangars each plus one base with 4 hangars (or any combination thereof). If you illegally modify your base layout with an editor to get rid of the access lift, the max can be increased to 45 ships (9 hangars in 5 bases). Once clogged, all alien activity will cease.

The base defense limit of 40 units exists because of UNITPOS.DAT which has a cap of 80 entries total (tanks occupy 4 entries in this file). Auto-win missions in a base defense mission by clogging all the spawn points with X-COM units isn't as tough as it sounds, especially if your base is small or doesn't contain hangars. The main thing is getting your full quota of 40 units to spawn (meaning you should try not to have any tanks as they count as 4 units but only occupy one spawn point). This limits the base size to something like 5-6 modules depending on what you build. Still, even having more than 6 modules isn't bad as it forces aliens to spawn intermingled between your troops. With 40 armed guys staring in every direction, you can get positions of all the aliens in the first round and possibly even kill them all (depends on weapons and alien race of course). --[[User:Zombie|Zombie]] 20:12, 11 November 2008 (CST)

: I would say that Limits are the CAUSE of bugs... also, I feel that fire/smoke limit can be called a bug, because a player normally has no way to tell this, other than observation. Whereas the game DIRECTLY and CLEARLY informs you whenever you hit the 80 item or 250 soldier limits, which is more fair. [[User:Jasonred|Jasonred]] 15:22, 23 March 2009 (EDT)

Also IMHO it is not true that, say, 250-soldiers limit is a real game bug. In fact, it is not, it is just a rule of the game, or its limitation. And it is unimportant what its reason is (such or another way to store game data).

A bug is, by definition, an unexpected and involuntary result of programmers' work. However, we can only guess what the programmers wanted to attain, so this definition is both unpractical and impossible to be applied. It would be better to assume that a bug is a feature which has negative influence in the game. To clarify: the (un)famous 250-soldiers limitation does not harm in practice, as the number is really enough to play the game. But the even-more-unfamous 80-item limitation does harm and it has negative consequences - it is enough to recall the disappearing of bodies during some missions.

OK, there is no objective criteria to judge whether a feature of the game is a bug or just a limitation. But sometimes subjective criteria have to be enough. Otherwise, we would have to consider the 8-bases limit a bug. Does it make any sense? And if no, what is the difference between the 8-bases limit and the 250-soldiers limit? I feel neither is a bug. Because neither leads to further negative consequences.

And further, IMHO the buggy nature of some game features is quite obvious. If you cannot send more than 100 "parcels" of items at the same time, it is still not the bug. But if you must pay for an item you are trying to send but you cannot do it - it is a bug, perhaps everybody will agree. And similarly: the 255-scientists limitation is not a bug. But the strange behaviour of the game when you bought the 256th scientist is a bug. It would be just a limitation if the game did not allow to buy another scientist. But it allows while it cannot serve the 256th scientist properly, and that is why it is a bug.

So, I vote for removing the 250-soldiers limit from the bug list. If I am wrong in it, please add to the list also:
# 8-bases limit,
# maps with limited terrain (why should they be limited?),
# base area and base facilities limit (why wouldn't we be able to have 10 hangars in a base?),
# etc.

In yet other words, in my opinion it is not enough to show that the game does not allow to have more certain items or to do more certain actions. In order to count this among bugs, we should show that it really harms during playing the game, or just bears negative consequences.

[[User:Sherlock|Sherlock]] 03:52, 27 December 2012 (EST)

= Specific Bug Discussions =

== Misc Technical Bug ? ==

''(The context of this discussion seems to have been lost)''

This is a technical bug that doesn't happen to everyone and one this article wasn't really meant to chronical - but we won't turn away helping a fellow player if it can't be helped. It's just that there are so many random crash points in this game that it would take far too long to find them all or come up with solutions for them.

Certainly, the transfer crash can happen to some players, but it's not one that can be reproduced easily. It's just like the random crash that some players get when they research a floater medic. It crashes the game for some of us, but others don't seem to notice it at all.

It really depends on your hardware and OS setup, whether or not your copy of the game is damaged or your savegame is damaged, etc.

Does it happen in all games or just this one savegame?

- [[User:NKF|NKF]]

-----

== "Invisible Muton" bug ==

Upon shooting repeatedly a Muton, it sometimes plays its "death" animation without sound (as if falling unconscious) and it is no longer displayed in the screen, while remaining visible to my soldiers (I can center the screen and the cursor appears yellow over them). Under this state, they cannot be targeted by Stun Rods. They may play their death animation anytime they get shot, until they truly die, when they emit their characteristic sound and leave a corpse (along with any items carried).

I'm quite fond of laser weapons, maybe this happens more often with those.

Also, though I remember experiencing this quite often fighting Mutons, it may happen to any other high health race.--[[User:Trotsky|Trotsky]] 02:59, 2 July 2006 (PDT)

-----

Never seen that one myself. Another "unpatched game" thing maybe?

There's a (very rare) bug that allows your soldiers to live if they become stunned by an explosion that happens to kill them. Sometimes the game will register their death, and THEN register that they've been stunned. In every case I've seen this happen, however, the unit will have such a low amount of health that a single fatal wound will render it dead (again) on the next turn. I have a vague memory that other players may have been able to get a medkit to the scene on time...

I dunno if that's related to your issue at all (I doubt it, but... meh). I'd advise using a Mind Probe on the alien the next time it happens so you can check the aliens stun/health levels.

- [[User:Bomb_Bloke|Bomb Bloke]]

----

I'm pretty sure I've seen this with Mutons. Possibly Chrysallids as well, another high health, high armor creature. They were still readily killed by shooting the place they are. Good thought on the MP, BB

---[[User:MikeTheRed|MikeTheRed]] 08:51, 2 July 2006 (PDT)

----

I've been known to have a dying muton(in fire) to spin around and then switch to the female civilian death animation. With the scream and everything. Even got a civilian death registered at the end of the mission. And this didn't just happen once, but on another separate occasion.

Hmm. shape-shifting reptilians in the game! LOL! Happens alot [[User:EsTeR|EsTeR]]

Unusually enough, I once had a sectopod die and then drop a tank corpse. I was using the Lightning at the time for my troop carrier, so you can imagine my surprise.

Then there was one occasion where a floater dropped a snakeman corpse. Let's not even get into the sort of things the aliens like to stuff themselves with.

Your invisible alien bug is quite common, although there appears to be many causes for it. I think one involves a full object table when it comes to invisible aliens in bases. But it can also happen in ordinary missions as well. I'm guessing the game may have tried to do something in the wrong order, and sprite information for the unit may have been lost or corrupted along the way.

Having had an experience where all the chryssalids become invisible in one base defence mission was quite a shocker. I fixed this by saving the game, quitting and then restarting the game. If you ever get an invisible alien again, try this and see if it helps. If it doesn't, well, just keep a careful watch on your map and any alerts that pop up as you play.

There's a similar but less severe bug where a dead alien will still leave its centre-on-unit alert button, but this goes away shortly after you move or turn.

- [[User:NKF|NKF]]

----

That last bug happens when exploding Cyberdiscs kill nearby Sectoids, doesn't it?--[[User:Trotsky|Trotsky]] 23:56, 2 July 2006 (PDT)

----

This is a pretty easy one. I guess this bug occured on UFO recovery on a battleship, an alien base assault or a base defense mission? As soon as there are too many items on the map, the game saves some item slots for the equipment to be displayed (since it is more valuable and more important to research). This would also make stun weapons lethal if the stunned aliens would vanish. therefore the game has a failsafe if an alien is stunned (or badly wounded and becoming uncontious). The downed alien's stun level is set exactly on its left health points therefore resurrecting it instantly. This cycle is broken when the alien is finally killed. This means if you want to stun an alien in such a situation you have to destroy some items first.

- by tequilachef (April 4th 2007)

== Vanishing snakemen ==

I've known snakemen to become invisible when standing on a hay bale. On the first occassion I had a poor tank getting shot while spending numerous turns looking for it. On the second occasion I had an alien under Psi-control, left it on the hay bale, and couldn't find it next turn. - Egor

---

This is not limited to snakemen. Hay bale block visibility quite much when a unit is standing on it. Two possible solutions:
- Destroy the hay before entering
- Shoot at the hay. If it is destroyed any unit on it will become visible (as long as no other bales are blocking the line of sight). You might also hit the enemy directly.

I Dnt know if the aliens are affected by this diminished sight, too. My guess would be no.

- By tequilachef (April 4th, 2007)

== Blaster Bomb Bug ==

I'm currently playing through X-com UFO Defense, I have the collectors edition version. I'm in the process of trying to catch a live alien commander and the blaster bomb bug is making this very difficult. If i remember correctly a commander is always in the command center of the the alien bases. The problem is anytime i get close there is always a dude with a blaster launcher up there that tries to kill my troops. When they try to fire it down at me the bug kicks in and they blow up the whole command room and all the aliens in it because they can't figure out how to get the blaster bomb down the grav lift thing in there. This is making it very dificult to actually catch a live commander. Anyone have any ideas for tactics or anything to breach that room without the aliens trying to fire a blaster launcher up there? - eL Hector

: I can suggest two possible solutions. The first is to wait outside the command room for the alien to move closer to you. If it comes out of the room or if you know it has moved down the lift, you then burst in and stand right next to it to stop it from firing the blaster. This is risky because there could very well be a heavy plasma toting alien in there. The other is to use a small launcher and launch it up at the ceiling near where you think the alien with the blaster is standing. -[[User:NKF|NKF]]

== Disappearing Ammunition ==

I have observed that problem with X-COM 1.2, modded with XCOMUTIL. My stun bombs and heavy rocket missiles, along with clips for the auto cannon went missing.
[[User:Vagabond|Vagabond]]

------

Just run a test using my 1.4 DOS version with XComUtil but my stun bombs didn't disappear: 30 + 1 back in the base they came from, same number after I went tactical and I dusted-off immediately. Are you running XComUtil with Runxcom.bat or did you simply run Xcusetup?

[[User:Hobbes|Hobbes]] 22:12, 22 February 2007 (PST)

:Is it a case of hitting the 80-item limit?--[[User:Ethereal Cereal|Ethereal Cereal]] 12:28, 23 February 2007 (PST)

------
With runxcomw.bat, as everytime. Apologies, I retested and it seems like I was mistakened, but I could have sworn that I lost them dang stunbombs. Had to manufacture some. I will test some more, using four heavy weapons and seeing whether their ammunition disappears at all. Thanks. [[User:Vagabond|Vagabond]]

==MC at end = MIA?==

I am sure I have seen this again recently, where I won a mission with no casualties (I thought), but the last thing I killed was a Commander that had been chain MC'ing a psi-attack-magnet trooper, and that trooper was listed as MIA at the end (presumably because he was on the enemy side at the end of combat). Is this a bug, or is there another way to get MIA's on a completed mission that I might have missed?

Since then I have been waiting for the leaders to panic at the end before killing them (or waiting for a rare resist), so I can safely exit, but am I being overcautious?

--[[User:Sfnhltb|Sfnhltb]] 13:45, 27 February 2007 (PST)

If the trooper was mind controlled on the turn you killed the last alien it will be listed as MIA. No bug there :)

[[User:Hobbes|Hobbes]] 18:16, 1 March 2007 (PST)

Huh, why would that happen - your soldier should recover the very next round, why would he go MIA?

--[[User:Sfnhltb|Sfnhltb]] 18:20, 1 March 2007 (PST)

Doesn't make sense to me as well but that's how the game works.

[[User:Hobbes|Hobbes]] 15:05, 2 March 2007 (PST)

----

It seems that regaining control of units under enemy mind control works different for alien and human players. My guess: aliens under human MC are reverted to alien control AFTER THE ALIEN AND BEFORE THE HUMAN TURN while human units under alien control are reverted RIGHT AT THE BEGINNING OF THE HUMAN TURN. This explains three different phenomenons:

- The discussed MIA "bug" (he unit would be returned in the next human turn, but since it never starts it is lost. The mission is still won since no unit with a "genuine alien" marking is left)

- The fact that a mission is lost when the last human falls under MC while it is not won when this happens to the last standing alien (the aliens get their unit back before their turn starts and therefore have a unit left to pass the "anyone alive?" check, the humans would have no unit left to start a turn with. They WOULD have as soon as the turn starts, but no unit left before turn means bust)

- The fact that aliens still can see all an MCed human saw at the end of the human turn that follows the MC while this is not vice versa (The MCed human can give information to the alien side before reverted while an MCed alien is reverted too early). The result is that aliens can control a human indefinitely without having any alien seeing him until the MC is disrupted for one turn.

All confused? Then I did a good job! No seriously, this must be the explanation, I couldn't think of any other way.

- By tequilachef (April 4th, 2007)

: You're absolutely correct on the first two points. It's a sequence issue - you never get round to recovering the unit before the new turn starts, so you end without any units whatsoever. Makes senses too since the aliens would continue to continue to mind control that same unit over and over indefinitely.

: The third point however: The aliens don't need to know the location of the last MC'd unit. They know the location of all your troops whether they've seen them or not from the very start. They appear to give you a few turns of grace where they won't attack you outright (unless, from my observation, all your soldiers are incredibly weak). This is evident because all of the aliens will eventually make their way towards the nearest soldier even though their movement pattern may seem semi-random. Also, they know where you are because they can initiate psionic attacks without having seen any of your troops. They generally go after the weakest troops first.

: Just to add a semi-related point, but from the alien's perspective. If an MC'd alien unit is in the exits when you abort the mission, this alien is not recovered and in fact simply vanishes. Any equipment it was carrying is recovered, unknown artefacts or otherwise. You could possibly think of this as their version of MIA. However, the aliens differ ever so slightly in that if it's the last alien standing and under temporary mind control by the player, the mission doesn't end straight away. But I guess this is only because the player has everything under control, whereas in the other scenario, the Ai is in control.

: -[[User:NKF|NKF]]

My observations show that, at least in some versions of the game (tested with clean DOS 1.4 version, under DOSBox), the game crashes at the end of the human turn if all alien units which are still alive, are Mind-Controlled. If it was confirmed, it would be another not-listed-yet (serious) bug.

[[User:Sherlock|Sherlock]] 17:52, 26 December 2012 (EST)

== Crash Site in the atlantic ocean ==

That's right, my game generated a crash site on water. Here are the details:

- Crash Site a bit southeast of the USA (which was infiltrated a few days before by sectoids, resulting base had already been taken out), but certainly not on land.

- UFO: battleship, floater, alien harvest

- Geoscape: 8 X-Com Bases, 1 (known) Alien base, 2 other crash sites, 1 other (known) flying UFO (though almost worldwide decoder coverage), 3 X-Com Crafts out, 1 waypoint

- Date: January 2000

- Most Interesting: The Craft that downed the ship was a recently finished Firestorm (first human-alien hybrid craft I had built, I know this is lame for that date. Limited myself on 25 Scientists to improve the challenge) equipped with twin plasma. I had it built and equipped in Antarctica and then transferred to Europe. This base had no Elerium, a fact that enabled me to use the infinite fuel exploit which was in effect when downing the UFO. My craft was only slightly damaged when doing so. The battleship was the first target assigned to the craft, it came directly from my base.

- When shot down, the UFO was not targetted by any other craft.

- I had not lost or sold a single craft to that point.

- When sending a squad to the crash site the game didn't crash but generated a farm land ground combat terrain.

- I was not able to reproduce the bug from the savegame dated 2 hours before downing the UFO

Well guys, any intelligent guesses? I still have the savegames (before and after downing)! If you want to have a look, write here.

- By tequilachef (April 5th 2007)
----
: Well I'm sure you know about crash sites that are near land can sometimes actually be on water, so I'm going to assume that this site is well far away from any land mass. Could it be a weird entry in GEODATA\WORLD.DAT that has a land mass out in the ocean? Also are you sure the game didn't crash? Sometimes when it does it will load the previous mission (and usually 90% are at farm terrain). Are you sure it generated a new map and not load the last one?
:No real guesses but maybe some starting points to look at. I've probably stated some obvious situations you know about and have accounted for, but it never hurts to double check :D
- [[User:Pi Masta|Pi Masta]] 14:23, 5 April 2007 (PDT)

== Inconsistencies in MCing Cyberdiscs and Sectopods ==

I experienced, that when MCing one quadrant of a large terror unit any action it does only affects this quadrant (especially use of time units). That means, when TUs are up for one part, MC another one and continue firing. This however does not work out when moving the unit while it is not under complete control. The TUs used up by the resulting reaction fire from the rest of the unit is also deducted from the TUs "your" part has left (making it impossible for the controlled parts to return fire). This however only happens under reaction fire, not if "your" part fires on it's own. I don't know if this comes up when uncontrolled parts shoot by themselves in the alien turn, since this is hard to find out.

: That's because large units literally are made up of four separate units. They only share the same set of general stats (in unitref.dat). Unfortunately the 'under mind control flag' is unique to the four units, not the shared stats! So you in effect have multiple units under different control sharing the same stats. So if you move and it results in a reaction from the unit, it will spend the TUs you're using.
: Successful mind control automatically fills up the unit's TUs, so each mind controlled sector gets to move or attack again until there are no more sectors to mind control. Useful way of turning reapers into long range scouts!
: In TFTD, they attempted to fix this bug, but in fact made it much-much worse! The only way to mind control the unit properly is to control the upper left quadrant. Only! Any other quadrant will result in a partial (clockwise) control, and you may gain control of units other than that unit, or may even get into situations where you gain permanent 'partial control' of a large unit you haven't even sited. Wackiness all around!

:- [[User:NKF|NKF]]

== Facility Dismantle Bug ==

Boba: I've never experienced this bug myself in all my games in the Collectors Edition. It may very well vary from computer to computer.

-[[User:NKF|NKF]]
:I, however, have experienced it. I lost an entire month's worth of playtime because I couldn't solve it. [[User:Arrow Quivershaft|Arrow Quivershaft]]

::Anyone, any ideas on why it might vary from PC to PC? -[[User:MikeTheRed|MikeTheRed]]

:::I'd check other factors before blaming a given system. Assuming no mods are being used the most obvious is the order in which you initiated the construction of the modules. Then we've got which one was due to be completed first, and I'm sure there's a few other things to test out. Usually, a player won't cancel in-progress modules on a regular basis, so you wouldn't expect this bug to turn up often. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

:Easy way to reproduce: build 2 General Stores. Now delete the "second one" (see offset 16-39 in [[BASE.DAT]] for the order). Wait for the first one to complete. It'll crash immediately after the "end of construction" dialog. A fix is available [[User:Seb76#Bug_Fixes | here]]. [[User:Seb76|Seb76]] 15:52, 22 July 2008 (PDT)

== Manufacturing Limit Bug ==

Unfortunately, Mike, no you did not get it correct. It is the raw number of hours needed to complete the project, not the projected hours. I discussed this on the X-Com Forums a few months back at the following link: http://www.xcomufo.com/forums/index.php?showtopic=242027760&st=0&#entry164411

I did tests at the time in regard to the accuracy of the data given there, but I've lost the results. I'll quickly redo the tests in the next hour or so. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:00, 8 June 2007 (PDT)

:Tests complete. The breakpoints for every item were exactly where I predicted, regardless of number of engineers assigned. (I ran up a huge queue of items at my dedicated factory base on an old game, and then assigned whatever engineers would fit onto one project at a time, canceling projects as data was confirmed. This is only semi-random, but it serves our purposes.) I did run into a single issue, though. It appears that despite having 5 empty hangars at a (different!) base, the workshop there could not queue up more than 3 of any one craft at a time, thus making this bug impossible to replicate with the Firestorm or Lightning, as you must be producing more than three for the bug to occur. However, it still works with the Avenger. Later, I shall see about constructing a dedicated Hangar base with 7 hangars in order to attempt to replicate the bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:33, 8 June 2007 (PDT)

::Sounds great, Arrow. Why not post a simple example that shows how the problem works. As in, "with 1 Eng and 2 Avengers you might think X, but no, it's Y". And please delete my example. And it's a fine pleasure to meet you! Cool - [[User:MikeTheRed|MikeTheRed]]

:::When you say the usual resources are used by the "lost" resources, that includes cash, right? It sounds like if you're willing to foot the extra bill [[Buying/Selling/Transferring#Manufacturable_Prices|money/component-wise]], this could be used to build Avengers slightly faster then normal.

::: The usual time is 34000 hours. Double that and subtract 65535 and you're left with a paltry 2465 hours. Even a single workshop squad of 10 engineers will pull that off in a little over ten days. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

::::Sadly, this exploit doesn't work, because the high bit is stored SOMEWHERE. I lack a hex reader and have no code reading skills to speak of, so I'm a bit limited here. If you set up a Workshop as you described, the game would take all the time for 2 Avengers, all the resources for the same, but in the end only produce 1 Avenger. Meanwhile, I'll run more tests on the resources thing. I could swear it consumes the resources, but I'll double check.

:::::There is no need to store the high bits if the actual completion condition (assuming adequate money) is "number made is number ordered", which wouldn't reference the hours remaining at all. - [[User:Zaimoni|Zaimoni]] 01:49, 9 Oct 2007 (CDT)

::::Tests done; I was unable to replicate the 'disappearing item' trick,(Which I didn't test for last night) even with Avengers! It appears I was wrong; this still counts as a bug, though, because the wraparound is a problem.

::::Ironic that so much of this discussion centers around Avengers, because that's where I discovered this in the first place! [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:48, 9 June 2007 (PDT)

----

I'm revisiting XCOM and was working on [[Manufacturing Profitability]]... Arrow, can you (or anyone else) say a little bit more on the Known Bugs page about this [[Known_Bugs#Manufacturing_Limit_Bug]]? It's not clear to me exactly what the bug does, except that it understates hours. Is that all?... does it still take the (non-buggy) amount of time, still use all the same resources, still make the same number, etc.? It sounds like it could be a drastic bug - or is it only a very superficial one, a display bug for the hours? It sounds like you're leaning toward this latter.

Also on a semi-related note... I could swear I saw much more detailed info on the [[Known_Bugs#Facility_Maintenance_Costs]] issue... IIRC, the incorrect amount that's charged for maintenance, depends on exactly where a facility is in the base. IOW, different "rows" of the base cost different amounts. Could somebody provide a link there, and/or flesh the bug out better?

Thanks! - [[User:MikeTheRed|MikeTheRed]] 11:22, 8 October 2007 (PDT)

:I've actually seen the bug work both ways, but I've only been able to actually replicate the more superficial version of the bug. So the bug report up is about a superficial bug that drastically understates production time. If you wish to make this clearer, you have my blessings. As well, that 'different charging based on location' is dealt with here: http://ufopaedia.org/index.php?title=Talk:Base_Facilities ; however, the table has been broken with the Wikiupgrade, and I lack sufficient knowledge of HTML table code to fix it. But it should be of use to you. [[User:Arrow Quivershaft|Arrow Quivershaft]] 11:26, 8 October 2007 (PDT)

::Cool, I fixed [[Talk:Base Facilities]] but also re-organized and expanded [[Base Facilities]] so that it includes that bug in detail, as per Talk... this is an important issue that should be up front. I see that there's a separate [[Maintenance costs]] page, but I can't see having something so important (the maintenance bug explanation) all on its own page (which makes for a rather short page) rather than together with all the rest of the base facility info. If others agree (or don't care), I'll move anything remaining on Maintenance Costs to the Base Facilities page, then delete Maintenance Costs and re-route links. And if somebody does care, then please move my new section to Maintenance Costs, and move all the links, etc. Oh also I put in more words on your Manufacturing Limit Bug - how does it look? - [[User:MikeTheRed|MikeTheRed]] 16:37, 8 October 2007 (PDT)

:Looks pretty good, although it'll wrap fully; if you ask for 120000 hours, it won't be displaying 'almost no' time. The way I discovered it was when building two Avengers; I ordered two, paid for two, waited for two...and got one. But as said, haven't managed to repeat it, so until I do, we'll leave it like that. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:00, 8 October 2007 (PDT)

::I just revised and put in your specific example, because it's certainly possible some of us die-hard players will order up more than 1 Avenger at a time - and it's guaranteed it'd be a pain if 1 of them disappeared, laugh. I wasn't sure how concrete you were on that example but now I hear you say, you are sure it happened at least once. - [[User:MikeTheRed|MikeTheRed]] 18:33, 8 October 2007 (PDT)

:I have a question concerning the manufacturing "bug" which eats a craft in production due to wrap-over of the byte. Arrow (or whoever did the test), did you have a large quantity of craft already built at your bases? If so, I think this bug has more to deal with clogging up [[CRAFT.DAT]]. See, that file has a limit of 50 entries. Each craft takes up one record and each base you have built also consumes one spot. 8 bases allows 42 craft to be housed, while 6 bases allow 44. If you try to buy or manufacture craft once the file is full, nothing shows up in the game even if you have hangar space available. --[[User:Zombie|Zombie]] 19:00, 8 October 2007 (PDT)

::Huh, I never knew that. I don't see it listed on the Bugs page... I'll stick it in there. I've never approached that number, but some folks might. - [[User:MikeTheRed|MikeTheRed]] 19:07, 8 October 2007 (PDT)

:I was able to continue building other Avengers after that project, and they appeared correctly, so I do not believe that is the issue. In any event, I have a very bad case of 'archivism' and probably still have the save game and the CRAFT.DAT file around on my system; in fact, I think I was playing it a few days ago. I can see if I can find it and upload it; it created a 'hole' in the Avenger fleet numbers, where Avenger's x and x+2 were built, but x+1 was not. I'll look for it tonight and tomorrow and upload it to the wiki if I find it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:10, 8 October 2007 (PDT) EDIT: I found the file; I have 28 Avengers and 1 Skyranger in my employ. All Avenger numbers EXCEPT #2(Avenger-2) are accounted for, and I have not sacked or lost any Avengers. So this is where the hole and 'eaten' Avenger is. If anyone wants the CRAFT.DAT file from this game, I'd be happy to forward it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:20, 8 October 2007 (PDT)

::Sure, send it my way and I'll take a look at it. (Might as well send me the whole saved game as I may want to look at the other files too). I have tried to recreate this bug by manufacturing 1, 2 and 3 Avengers at a clip but all of them always show up. Don't know what else I could do to get this problem to crop up. --[[User:Zombie|Zombie]] 21:32, 8 October 2007 (PDT)

:File emailed. On the side, I've tried the same thing, and never been able to repeat the bug. It's been months since the first discovery, so I can't recall whether it was the first or the second Avenger that didn't appear. So maybe it was just a fluke. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:57, 8 October 2007 (PDT)

== Unconscious Enemy in Equipment Screen ==

The following happened to me repeatedly over the last few days.

In the last tactical Mission a live alien has been captured. When now beginning an UFO crash recovery mission this type of alien (same race and rank) appears in the equipment screen before the mission starts, meaning I can give it to any of my soldiers.
If I do so I can store the alien in the skyranger for the duration of the mission and, if it gains consciousness, kill or stun it at the end of it. A pile of equipment without a corpse will be in the UFO, indicating that the stunned alien is not some kind of duplicate but instead has been taken from the aliens of this mission. This is supported by the fact that in those missions the maximum number of crew members has not been surpassed.
If I do not do so the Alien will be placed in the crashed UFO. Whether it is unconscious or not I do not know, but the fact that it is completely disarmed when encountered in the battle suggests that it is.

So far it seems the following is necessary for the bug to occur:
# An alien has to be captured alive in the last tactical combat
# It has to be of the same race and rank as one of the aliens in the new tactical combat

So far this only worked...:
# If the new tactical combat was an UFO crash recovery of a medium scout.
# For floaters and mutons
# For soldiers and navigators
# If the alien in the last mission was stunned by normal weapon fire (although I do not think this is important) and not picked up (again, not likely to be important) or destroyed (which would mean it has to be actually captured)

It seems NOT to depend on the following:
# The type of the last mission (were, so far: Ground assault battleship, crash recovery large scout, base defense)
# Which squad or vessel was involved capturing the alien
# Where it is locked up
# If it has been transferred since capture or not

Would be interesting to know:
# What happens if the alien in the inventory screen is the only survivor
# If the alien in the invenory screen is one of the aliens randomly killed in the crash or not (it is likely to be one of the killed aliens, so far the equipment piles were always within the UFO)
# If this is not limited on crashed medium scouts: Does this work with terror units? What about large ones?

Maybe this is related to the proximity grenade bug (transfer of item properties to next tactical combat).

Additionally, in one of those mission a part of the terrain was not generated correctly. It was in farm terrain (The house on the right square, or north east square, in [[Image:Terrain-cult.gif|this pic]]). The outer wall right to the right window of the southern wall (1st Floor) was missing. Directly outside of the hole was a floor tile. I could walk a soldier through the wall, but he fell right through the tile. Dunno if this has to do with the stunned alien bug.

Version is collectors edition (the one from abandonia.com).

----------------

When a mission starts, the GeoScape engine generates the unit and object tables (in MissDat's [[OBPOSREF.DAT]], [[UNIPOS.DAT]], and [[UNIREF.DAT]]) before "shutting down". The Tactical engine then generates the maps, places the aliens on it, and blows up the UFO (if need be). Whether or not map generation and the subsequent events happen before you equip your soldiers I don't yet know.

The test would be to check the aforementioned files to see if they contain an unconcious alien, and/or the body.

Note that you can't see the bodies of large units on the ground (they count as four seperate objects covering four seperate tiles, so allowing the user to pick one up would essentially let you rip them apart).

- [[User:Bomb Bloke|Bomb Bloke]] 06:35, 5 August 2007 (PDT)

----------------

I honestly have no idea of how all those files work. But I still have a savegame in battlescape that is in one of those missions. So if anyone wants to have a look at those files...

I forgot to mention: I reloaded a geoscape savegame shortly before the battle to recreate the bug, but it seems that reloading in geoscape before the buggy battle eliminates the bug. I guess his should narrow down the possible reasons...

--------

Next time it happens, backup the aforementioned files before you start another mission. I'm afraid a savegame wouldn't be of much help.

- [[User:Bomb Bloke|Bomb Bloke]] 00:54, 7 August 2007 (PDT)

== Soldiers moved to outside of combat screen ==

Hi, I've got a DOS version of UFO:EU, and I've encountered a bug in the tactical combat. Sometimes (rarely) a X-COM soldier changes its location on the map on player's turn start and is placed on outside of the map, one tile north from the (north) border of the field. AFAIR the unit is then selectable (you get the flashing highlight when cursor is above), but is stuck outside of the field. Has anybody encountered this bug? It seems to happen randomly, but more frequently during the terror missions and on early turns (so maybe it's caused by high number of player/alien/civilian units?). --[[User:Maquina|Maquina]] 08:16, 3 September 2007 (PDT)

:I've never encountered this bug in CE of UFO. Presuming AFAIR means "As Far As I Recall," what exactly was the soldier doing? Any equipment data, location, or stat info might help us pin it down. Were afflicted soldiers always carrying a specific equipment set or weapon? Where were they on the map before they got moved? Did they get bumped a few spaces, or teleported halfway across the Battlescape? Does it happen more often on a specific difficulty?(Your theory would suggest this would happen most commonly on Superhuman) Against a certain type of alien? Best of all, if you can recreate the situation in a game, save the game and then you could upload the save file to the forums or this wiki, and the rest of us could take a look for ourselves and the code divers could root around for the cause. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:03, 3 September 2007 (PDT)

:: I've had this happen to me several times in UFO and TFTD. I don't know if it's specific to the Dos version or if it can happen in the CE as well. Sometimes the soldier ends up beyond the boundary of the map right at the start of the mission, at other times it happens after you load a game. This game is glitchy, which is the source for so many of its bugs, so your soldier's coordinates are probably getting corrupted to the point where they are -1 on either the X or Y axis of the maps's normal boundaries. For me it's commonly along the top edge of the map. I don't ever recall it happening mid-mission, only at the start or after a load. I cannot faithfully say whether it happened with or without XComutil, but that could be one of the possibly many causes for this. - [[User:NKF|NKF]]

:: I don't play UFO often, so I rely on just several campaigns played. This happens rarely (I've encountered this bug twice in my last campaign with ~80 missions played), but if you haven't seen this happen then it probably doesn't show up in the CE edition. In my experience the soldier is moved always beyond the north/top map border. I think (but I'm not sure) that this affects the first soldier from the team more commonly than others (or maybe even exclusevily?). The equipment/armor carried is probably not relevant, since the units moved this way don't have any special stuff, and this bug shows up on different stages of the gameplay (ie. sometimes when you have ordinary rifles, sometimes when all your units got heavy plasmas and power suits). --[[User:Maquina|Maquina]] 04:12, 4 September 2007 (PDT)

'''MY ramblings have been moved to my discussion page''' [[User:EsTeR|EsTeR]]

==Great Circle Route==

Should we have the Great Circle Route bug noted on this page at all? [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:33, 6 October 2007 (PDT)

: what is the great circle route? [[User:Jasonred|Jasonred]] 07:56, 31 March 2009 (EDT)

:: Pick two points on a globe, then hold a thread or string taut at those two points. That practically minimizes the length of the thread/string on the globe. You're now looking at a great circle arc (or route), the shortest distance between two points on a globe. -- [[User:Zaimoni|Zaimoni]] 11:15 March 2009 (CDT)

: Just as a line is the shortest distance between 2 points on a flat plane, a great circle is the shortest distance between 2 points on the surface of a sphere. The bug, by the way, is that aircraft in the game ''don't'' follow this shortest, "great circle" route. [[User:Spike|Spike]] 12:38, 31 March 2009 (EDT)

:: What a grand sounding name, for something so simple, lol. ... I thought you were talking about when you tell your soldiers to go from point A to point B, and for some reason they figure that Zone A and Zone B are really far apart, despite actually being side by side. (I shot a hole through a wall, clicked to walk to the other side, and my idiot soldier walked one big circle... to use the door! And got ambushed and killed by an alien. ... dum dum DUMB DUMB.)
:: Even the more modern games have problems with their pathfinding algorythms. Admittedly, games like Baldur's Gate had to do it in realtime.
:: On a semi-related note, I remember this guy called E-man, he was chasing a guided laser beam that was going to kill his girl, around the world, but he couldn't outrun it since he couldn't break the speed of light, only equal it by changing into a Laser himself. So... inspiration! He turned into a very powerful laser, and made a shortcut THROUGH THE EARTH... the straight line beats the great circle route, lol.
:: Thanks for the reply guys [[User:Jasonred|Jasonred]] 15:56, 31 March 2009 (EDT)

Added to article. [[User:Spike|Spike]] 16:41, 3 September 2012 (EDT)

==Bug not listed: Missing soldiers during base defense==

I encountered an interesting bug concerning base defense missions:
My base got attacked while about 30 soldiers and 10 HWPs were present. The usual equipment assignment screen was skipped and the mission started instantly with only the HWPs spawned at the map. Not even a single soldier bothered to show up... *sigh*
Although this turned out to be in my favor (you should have seen the puzzled Ethereals trying to panic my tanks) I´d like to avoid this bug if possible. I was able to reproduce this bug several times and with different bases.
Can anyone explain this bug and/or tell me how to avoid it?

Game version: Collectors edition. - [[User:NewJoker|NewJoker]]

-----

Well, ideally, we need to know what your base's construction was to be sure of this, but I think the most likely circumstance is that the HWPs took up all the spawn points. HWPs have maximum priority for spawning(followed by Soldiers, and then Aliens), so if you have enough of them garrisoning a base, it's entirely possible that soldiers and aliens won't spawn. However, this doesn't explain why the soldiers didn't start stealing the Alien spawn points...in any event, you might want to take the save game file, zip it up, and get ready to email it. I'm sure [[User:Zombie|Zombie]] would be quite interested. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:28, 13 November 2007 (PST)

-----

It's not the spawn points, it's a [[UNITPOS.DAT]] limitation. A maximum of forty records (out of the total of eighty) are allocated for your units, and tanks (which take up four records each) get first pick. Having ten tanks means there's no room left for anything else.

Ditch one HWP and you should see four units take it's place. - [[User:Bomb Bloke|Bomb Bloke]] 16:42, 13 November 2007 (PST)

-----

I´ll try with a decreasing number of tanks and report the results. As I wrote above having only HWPs isn´t too bad dependent on what enemy is attacking. [[User:NewJoker|NewJoker]]

----

This should be mentioned in the [[ExploitsE#Base Defence Mission Spawning Issues]] section. The Bugs/Exploits really need to be sorted and consolidated. - [[User:NinthRank|NinthRank]] 16:57, 13 November 2007 (PST)

-----

The limitation to 40 records seems to be the case; each tank I dumped got replaced by four soldiers.
So this can be used to effectively manage unit combination. Thanks for the quick replies! [[User:NewJoker|NewJoker]]

==Bug not listed: Ufo Gold (Windows Vers. abandonia.com) crashing when plasma defense is finished==

I recordnized this bug a few times now. (with hacked AND unhacked game)
If i place a plasma defense in 7 bases at the same Time and they are finished at the same Time, the game crashes sometimes.
In hacked game, it seems to crash even more when Alien containment is finished, plasma defense, shield defense...etc.
couldnt find it here...greetz

: I somehow doubt the sourcing is the issue. [You may want to fund the next XCOM series game with a Take2 re-release of UFO :)] More generally: the game only reports the construction of a given type of facility once, no matter how many bases it completes at simultaneously. I've only tested this in vivo with three-of-a-kind at once across six bases, however. It does seem reasonable that some sort of counter of undisplayed completions would "overflow" (attaining crash). -- [[User:Zaimoni|Zaimoni]] 10:05, Feb. 28 2008 CST

::I've encountered this bug myself with General Stores, actually, not just Plasma Defense(which I never build). EDIT: Some quick tests seem to show that there's a chance the game will crash any time two base facilities are done at the same time, regardless of whether they're in the same base or not or if they're the same facility.(although it seems to happen MUCH more in the event they're in different bases.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:13, 28 February 2008 (PST)

== Soldier Recruiting Bugs Tested ==

Just to note that I have positively tested and replicated the bugs listed under the new(ish) section [[Known Bugs#Soldier Recruiting Bugs|Soldier Recruiting Bugs]]. [[User:Spike|Spike]] 18:08, 19 March 2008 (PDT)

==Floater Medic Bug==

I have not thus far encountered the Floater Medic Bug; in fact, Floater Medics are often used to fill up my Rogue Gallery with interrogations. [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:50, 24 April 2008 (PDT)

Strange, it would always occur in my version. I don't remember where I got it from, but I
know it was a download from the internet. Using the XCom Hack v2.5, I viewed the alien in
the Alien Containment edit. I now have Type (race):____, and a Rank: Soldier for the
Floater Medic. It might just be corruption, but I do not have the resources to look into
it. [[User:Muton commander|Muton commander]] 19:24, 12 May 2008 (Pacific Time Zone)

I've never encountered it either. [[User:Magic9mushroom|Magic9mushroom]] 07:47, 23 July 2009 (EDT)

I think this only happens in the CE version. A disassembly of the code reveals that the stack to hold the matrix for what topics have not yet been researched is too short. It seems that those who ported the code from DOS doubled the local variable sizes blindly. There is already a problem that there are two-few bytes necessary for the entire alien organism section of the UFOpaedia, but double the expected size of the registers and it fills up quite easily unless a lot of autopsies and interrorgations have already been done. The only other situations that are handled by the same routine are the navigator revealing mission data or engineers revealing ship data, but there isn't enough topics in either section to overflow the stack variables. - [[User:Morgan525|Tycho]] 08:27, 22 June 2013 (EDT)

==Strength Overflow==

During one of my games with TFTD I noticed a really annoying thing happen during battles.
As my troops rose up the 'stat.' ladder they got better and better (as you'd expect), until they hit about 50 strentgh and completely lost the ability to throw anything.
Even trying to throw something tiny like a grenade or flare into the adjacent tile resulted in the 'Out of Range' message being displayed.

Anyone come across this before?
This was in TFTD CE.
[[User:Tifi|Tifi]] 07:55, 27 April 2008 (PDT)

:This is fairly well documented. The pathfinding algorithm for throwing objects will balk if anything is in the way of the throw and refuse to allow you to throw. What's happening is that your soldiers have become so strong that their throws are intercepting the 'ceiling' of the Battlescape(the top of L3), and as such the game thinks that the throw is blocked(because in order for the throw to complete, the object would have to be tossed up to the nonexistant L4). There's two ways around this:

:The Normal Way: Try shorter throws, throwing from lower heights, or throwing while kneeling. Beyond that, possibly get some new troops.

:The Sneaky Way: Manually edit the Strength scores of your soldiers in [[SOLDIER.DAT]] so that they're back to a usable strength level. If you set "Initial Strength" (offset 46 decimal or 2E hex) to 0 and "Strength Improvement" (offset 57 decimal or 39 hex) to a value of 50, you can permanently lock the soldiers at 50 strength. (You can lock them higher than that if you so choose, but not lower.

:Other than this, there's no workarounds I can think of offhand. [[User:Arrow Quivershaft|Arrow Quivershaft]] 08:10, 27 April 2008 (PDT)

:: There's normally no problem with the max level of 70 in open settings. However TFTD has a lot of low ceilings such as in the shipping lane missions and colonies, and the lower ceilings impairs your throwing quite a bit. In addition to shorter throws/kneeling, try moving out from under any overhangs if there is one just above you. - [[User:NKF|NKF]] 12:33, 27 April 2008 (PDT)

== Bug not listed: Sticking your head through the ceiling ==
This is something I just discovered: When you step on a small object inside of a building your soldier sticks his/her head through the ceiling and can see what's upstairs. You can even see the soldiers head coming out of the floor and that soldiers can shoot aliens upstairs. When I did this the alien I saw/shot was facing the other way, but I guess you could get shot if the alien was facing you. [[User:RedNifre|RedNifre]] 17:34, 11 May 2008 (PDT)

:That's not listed under "Bugs" because it's covered under "Exploits", right here: [[Exploiting_Collison_Detection#See_Through_A_Ceiling]] [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:26, 11 May 2008 (PDT)

:: I don't know if it was ever covered anywhere, but there's this neat trick that might sound similar to the walk-through-'wall object'-wall trick except that it involves your unit climbing slopes. They'll appear as though they've gone up a level, but are actually not on that level. They only visually appear to be there, but are really still on the bottom level.

:: It happens a lot when walking up the desert or forest slopes. I think the trick involves standing on ground level, and then ordering the unit to 'move' into the hill rather than setting the waypoint while on level 1. The soldier will move up the slope and perhaps stop on the slope or even reach the top of the slope, but will still appear when you're only viewing the ground map layer. The soldier is really still on the ground level, but will have elevation offset.

:: One really interesting way of using this trick is in the mountain region. If you can find a cliff face and a low hill nearby, you can literally have your soldier scale the cliff by standing the soldier on the hill, and then walking towards the cliff. It's ridiculous, but your soldier never quite reaches the top of the cliff tiles, so ends up walking up a slope.

:: On a side note, standing at the top of the ramp of the Skyranger is the same as standing on ground level - you're only offset a bit. This means that smoke on level 1 and the sides of the Skyranger will not provide protection when you're at the top of the ramp.

:: On another related note in relation: In TFTD (doesn't happen a lot in UFO), you might find it difficult to toss grenades onto underwater slopes. To remedy this, raise the level up by one. It might look like you're tossing at air(and you are), but it'll get the grenade where you want it. Odd, but true. I must remember to put this in the grenade explanation section. -[[User:NKF|NKF]] 23:11, 11 May 2008 (PDT)

== Base Defence bug that causes a crash? ==

Does anyone know about a bug in a base defence mission that causes the game to crash? The game keeps crashing on the 4th or 5th alien turn.

:I've encountered that myself, but it should be noted that overall, X-COM is not the most stable game and is prone to crashing often at anytime. The differences between the hardware it was designed for and the hardware we're running it on cannot be helping matters at all; it's really a small miracle it even runs without an emulator in the first place(I've got games from 1999 that will bluescreen my machine instantly). As such, I'm not sure it's worth noting as a bug, since it's a 'game feature'(albeit a detrimental one). In any case, what're you doing letting the aliens attack you anyways? ;) [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:33, 18 July 2008 (PDT)

:It sounds like an alien is in one of the outlying locations and attempting to destroy the top floor item. Possibly a radar or defense station. - [[User:Morgan525|Tycho]]

== Sources for a DOS4GW transplant ==

I was specifically thinking of the LucasArts Dark Forces demo, but I half-recall the actual source I used when testing that ~1999 was Id's DOOM. -- [[User:Zaimoni|Zaimoni]] 16:03, 7 August 2008 (CDT)

== Phantom Carried Casualty ==

You are carrying an unconscious soldier in one hand, and the soldier dies of his/her wounds. The dead soldier remains visible on the "left hand / right hand object" battlescape display, but is no longer visible in the inventory display. The problem can be fixed by moving another object into the same hand.

I've seen this bug with UFO Extender by [[User:Seb76|Seb76]] - possibly might be something to do with his manipulation of the inventory screen, rather than a general bug. I believe I've also seen this with other objects that were being carried in the hands, disappearing from the Inventory screen, but I'm not sure. I don't think it's an item limit bug, as XcomUtil shows 40 item slots free. [[User:Spike|Spike]] 08:58, 21 September 2008 (PDT)

:I think it has to do with the KO units KIA mod. Its doesn't take into account units held so when it tries to detemine where to place the corpse, there is no location. The routine doesn't undo the item-carried-sprite-ID byte for the holder. -[[User:Morgan525|Tycho]]

== Civilians As Enemies to MC'd Aliens ==

I ran across this issue a few times and just wondered if you guys experienced this. I MC'd a part of a Reaper (I always do the lower left for large aliens) on a Terror Site, then moved it a few squares. It suddenly stopped dead in it's tracks and then the alien spotted indicator increased by 1. When I clicked on the indicator to see where the enemy unit was, it brought me to L2 of the large apartment complex. However, nothing was there. When I sent a Flying-Suited soldier up there to peek in the window (eeek! A peeping tom!) he saw a female civilian standing there. This type of problem has happened numerous times to me so it's not a once-off thing. Maybe it's a LOS issue? Or maybe an alien indicator problem? Or a combination of the two? Don't know, but I'm curious if you guys have seen it. --[[User:Zombie|Zombie]] 23:40, 19 December 2008 (CST)

:There are a lot of major issues with MC'ing 4 square aliens. One of them being that you could accidentally MC an alien far off in the corner of the map, IIRC? Anyhow, maybe you should have tried MC'ing all 4 squares of the reaper and see if that changed things. -[[User:Jasonred|Jasonred]]

The long-range MC of other aliens when Mind-Controlling large aliens is only present in Terror From The Deep, due to a workaround to try and resolve the earlier bugs(and exploits) associated with controlling one square of a large unit at the time. In TFTD, successfully MC'ing part of a Large unit will also grant you control of the next three units in UNITPOS.DAT, in order. If you didn't MC the upper left portion of the large unit(the first UNITPOS entry for any large unit), you can potentially wind up in control of other aliens. So this doesn't apply to UFO. As for Zombie's issue, never seen it. And finally...Jasonred, on Talk pages, please indent your statement with colons so it differentiates from other people's comments, and sign your posts with 4 ~'s, like I will now do. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==Elerium Base Bug==

Jasonred: This bug has long since been known about. Elerium units on the Battlescape can be picked up by shooting away the power source; this one item counts as 50 units, and as such ANY elerium item spawned on any Battlescape counts as 50 Elerium. This issue with your own Elerium spawning as collectable loot in a Base Defense mission only occurs in older DOS versions, and is at the whim of the 80 item limit. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:55, 18 February 2009 (CST)

:Base defense does not seem to follow the 80 item limit in that DOS version. There are a lot of bugs that have long been known about. However this one was not included in the ufopedia for some reason.
:Also, the main thing about this bug is that it does not potentially double your elerium stores. It potentially multiplies them 50 times.
:... First time this happened to me, I was pretty flabbergasted. Here I was being conservative with my limited Elerium, refraining from blowing up UFOs when possible, when I perform a base defense and gain 3000 Elerium from it. Holy spit. -[[User:Jasonred|Jasonred]]

Alright, my error. Thanks for clarifying. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==HWP Fusion Bomb and SWS PWT Displacer Ammo Manufacturing Cost Bug==

At a cost of $15000, 400 Tech hours, 5 Zrbite, and 8 Aqua Plastics, this is the exact same cost as the HWP Fusion Bomb from X-COM EU, converted over to the equivalent TFTD resources. As such, it shouldn't be counted as a bug, since it is clearly what Mythos intended. [[User:Arrow Quivershaft|Arrow Quivershaft]] 09:55, 15 November 2008 (CST)

:Hmm, in that case maybe it should be treated as a generic game engine issue and not a TFTD specific issue - but I still think it's a design error. Can you think of any logical reason why the SWS/HWP version of the ammo should be more expensive (in cost and in materials) than both the craft ammo and the (more powerful) personal ammo? It makes no logical sense. Hence I think it's a design error. Nothing can be inferred from the fact it's unchanged from XCOM-EU, that doesn't imply any deliberate decision. It could just be the replication of an original error in XCOM-EU. [[User:Spike|Spike]] 11:17, 15 November 2008 (CST)

:: I can think of a logical reason to justify this: X-Com doesn't understand the technology as well as the aliens do (which is obvious, given the length of time each side has known the tech). Handheld Blaster/Blaster Bombs are just a copy of the alien design and therefor relatively cheap and efficient, but that can't be mounted on a turret. So X-Com has to make a new design, and they obviously didn't do that good a job as the aliens would have done. This explains Tank/Plasma being weaker than Heavy Plasma too. (Why is FBL Craft ammo cheaper than the tank ammo though? Maybe X-Com gave up on/simplified the guidance system and made it just a "dumb" cannon shell/torpedo instead which doesn't have multiple waypoints? Or maybe they just did a better job there?). [[User:Cesium|Cesium]] 04:07, 25 November 2009 (EST)

:Whilst we discuss it, I'll park my original text in here:

* ''Displacer/PWT ammo cost bug - at over $100,000 total cost per round, the ammunition for this SWS weapon is far more expensive to manufacture (both in money and rare materials) than the equivalent ammo for the Aquanaut-carried Disruptor Pulse Launcher, or the craft-based Pulse Wave Torpedo, despite being less powerful than either. This would seem to be a design mistake.''

See Also [[Talk:Displacer/PWT]]

:: I don't like the higher cost either, but I think it's a tradeoff of expense and quality for the convenience of portability. Sort of like an MP3 player to the gramophone... or maybe that's not a good comparison. -[[User:NKF|NKF]] 13:43, 15 November 2008 (CST)

A better comparison might be a desktop computer to a laptop. As a general rule, laptops are more expensive, but a similarly priced desktop gives you more power. Desktops are cheaper and offer power, laptops are more expensive and offer portability(though the gap is rapidly narrowing). [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:49, 15 November 2008 (CST)

:I think those are good analogies. But they don't apply in this case. To continue your analogies: We are paying mainframe prices for a clunky desktop that has only laptop processing power, and we're buying a mainframe for desktop prices. The vehicle version ("desktop") - is ''less'' portable and ''less'' powerful than the personal version (DPL = "laptop"), ''less'' capable than the craft version ("mainframe") - 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 SWS use up ''more'' of both Zrbite and Aqua Plastics than the Craft version. Do we really think it's logical that a tactical battlefield round, less powerful than its man-carried equivalent, takes more explosive and structural material to produce than both the more powerful man-carried version and also more than the air-to-air round that has 60km range and can take down a major alien combat craft? There is a clearly perverse bang-per-buck here, on every measure. My sincere belief is that this was an original mistake in the XCOM-EU engine that got copied into TFTD as well. The craft round should have the higher base price, but 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. But what I don't think is debatable is that is not logical for the SWS/HWP rounds to be more expensive than the craft rounds. It's clearly a mistake. Even in game balance terms, the only thing the HWP/SWS rounds have going for them is conserving "80-Item Limit" space, which I severely doubt was ever a game design consideration since it's just an awkward programming compromise. Any advantage inherent in the HWP/SWS is already reflected in the very high platform cost - there is no need to inflate the ammo costs as well. The bottom line is that a round for a (mini-)tank does not cost more, does not use more materials, than the same type of round for a long range anti-aircraft weapon that has much greater damage capacity and penetrating capacity. [[User:Spike|Spike]] 14:35, 15 November 2008 (CST)

I'm going to add this to the bug list now. [[User:Spike|Spike]] 16:06, 25 February 2009 (CST)

:Still don't think this is a bug though. Just because it's more expensive to manufacture than the hand-held or craft-mounted ammo, it doesn't mean the stats are wrong. Perhaps the programmers wanted to balance the tactical portion of the game a little more by making the ammo cost more for tanks. It doesn't have to be logical to be intended. Now if you had proof which said that the ammo was supposed to cost less but the stats were wrong, then yes, I'd agree. So if you boil it all down it comes to a disparate logic issue, not a bug.--[[User:Zombie|Zombie]] 21:31, 25 February 2009 (CST)

::I have to side with Zombie here. While the ammo may be disproportionately expensive, by the definition used on the rest of the page for bug, it doesn't fit. All the other bugs are errors in program logic or function or routines that are unintentional problems with the game, most of which are not warned of ahead of time. The ammo for the tank costs exactly what is listed and operates entirely as intended, whereas the rest of the bugs are not intended game features. Even if the numbers were entered wrong, that would be a data entry error, not a program bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:28, 26 February 2009 (CST)

:If it was a data entry error, I'd consider that a type of bug... assuming we had proof of the goof so to speak. LOL. --[[User:Zombie|Zombie]] 00:49, 26 February 2009 (CST)

:: It feels too specific an entry to be a data entry error.

:: I'm reminded of the high explosive. I know, I know - it's not an exact parallel to the FBL issue. A High Explosive is practically two grenades. Double weight, double bulk. Slightly above two times the damage. However, it costs five times the price of a standard grenade. Even though you're paying more for not-as-much, I don't think that could be considered a bug. A rip off, yes, but not a bug.

:: Here's a thought: Think about the immediate benefits each of the two controversial ammo types give back to you. Aircraft ammo = activity points. Tank ammo = loot. Yes, I know that aircraft ammo also generate crash sites, but you still have the ground combat to contend with.

:: One other thought: With careful management of your ammo, you'll probably never spend any elerium on the handheld version's ammo. Could it be the handheld that's really at issue here rather than the others? In the end I feel that it doesn't really matter. -[[User:NKF|NKF]] 03:38, 26 February 2009 (CST)

: I'm with Zombie that a data entry error is a bug (we have other examples), but also agree some proof is probably needed. And I agree with NKF that in the scheme of things, it doesn't really matter much. I don't think the HE pack is a good comparison (though the HE pack should be heavier) as it's reasonable to pay disprortionately more to get additional power at the same tech level. The fusion weapons are a case of paying more to actually get ''less'' power. I am not bothered by the handheld vs vehicle balance, not least because the game generally makes handheld weapons better than their vehicle equivalents, so I can accept that as an across-the-board design decision.

: I can also see a game balance argument ''if'' we believe that Fusion Tank ammo is more of an overall game-winning weapon than craft Fusion Bombs. But I'm not sure I agree with that statement. And even if it's true, and there's a game balance argument (in which case it would apply equally to handheld Fusion launchers), it's still illogical. The less powerful, battlefield warhead should not cost massively more in exotic materials than the much more powerful air to air warhead that brings down Battleships. I agree though that just because it's illogical does not prove it's a bug (i.e. unintended). [[User:Spike|Spike]] 07:48, 26 February 2009 (CST)

Ok we more or less seem to be in agreement that this isn't a bug, but it is very confusing/illogical. Maybe we can shift the "bug" text from the article page and roll that into the [[Hovertank/Launcher]] and [[Displacer /P. W. T.]] pages now. Feel free to combine any text from the discussion above if necessary. --[[User:Zombie|Zombie]] 09:22, 26 February 2009 (CST)

: Unless we can ''prove'' it's a data entry error (unlikely), how about calling it an "Anomaly" instead of a bug? [[User:Spike|Spike]] 10:59, 26 February 2009 (CST)

Looks like plain old game imbalance to me.
The way I see it, Hovertank Plasma and Launcher were meant to be stronger. Much much stronger. Let's look at Tank Cannon, Launcher and Laser. The logic is that it's a tank mounted weapon, so the tank can carry a much larger and more powerful version of the same weapon, right?
It's pretty stupid that a Hovertank Plasma is weaker than the Heavy Plasma... you could just mount a Heavy Plasma on a Hovertank and get them exactly equal. In fact, I suspect that the hovertanks were ALSO meant to have more powerful weapons than the man-portable versions.
Unfortunatly, the game designers then realised that this made the hovertanks far too powerful. So... the programmers nerfed the power of the hovertank weapons. BUT they forgot to lower the ammo costs. [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 11:20, 26 February 2009 (CST)

: Well you are opening up a much larger issue there. The Fusion weapons are an anomaly, an inconsistency. But handheld weapons are more powerful than equivalent vehicle weapons across the board, consistently. So that looks like a deliberate design decision, not a mistake. [[User:Spike|Spike]] 17:33, 26 February 2009 (CST)

:: There are two exceptions to the rule: Tank/Cannon: 60AP vs. Heavy Cannon 56AP. Tank/Laser: 110 Laser vs. Heavy Laser: 85 Laser. The hovertank\plasma only differs by a measly 5 (an extra 0 - 10 damage, which means a lot vs. UFO inner hull armour). I guess the trend here was to moderate the area effect tank strengths. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

I'd have to agree with you there Spike. This wasn't a mistake, however odd it may seem. It was a deliberate attempt to try and balance the game. Below is a table I created ages ago for my (now defunct) strategy guide detailing the HWP's and what handheld weapon corresponds to it. When you stick them side-by-side, it really becomes apparent that the programmers were trying to base the HWP weapons off the handheld weapons somewhat. The only thing that doesn't follow a nice and distinct scheme is the damage. That's what is the clincher. --[[User:Zombie|Zombie]] 20:26, 26 February 2009 (CST)
 
<table {{StdCenterTable}} class="sortable">
<tr {{StdDescTable_Heading}}><th align="left" width="150">Tank Type</th><th width="70">DAM</th><th width="80">Snap</th><th width="90">Aimed</th><th width="90">Aimed</th><th width="80">Snap</th><th width="70">DAM</th><th align="right" width="140">Handheld</th></tr>
<tr><th align="left">Tank/Cannon</th><td>60</td><td>60%</td><td>90%</td><td>90%</td><td>60%</td><td>561</td><th align="right">Heavy Cannon</th></tr>
<tr><th align="left">Rocket Launcher</th><td>85</td><td>55%</td><td>115%</td><td>115%</td><td>55%</td><td>87.52</td><th align="right">Rocket Launcher</th></tr>
<tr><th align="left">Laser Cannon</th><td>110</td><td>50%</td><td>85%</td><td>84%</td><td>50%</td><td>85</td><th align="right">Heavy Laser</th></tr>
<tr><th align="left">Hovertank/Plasma</th><td>110</td><td>85%</td><td>100%</td><td>100%</td><td>86%</td><td>80</td><th align="right">Plasma Rifle</th></tr>
<tr><th align="left">Hovertank/Launch</th><td>140</td><td>--%</td><td>120%</td><td>120%</td><td>--%</td><td>200</td><th align="right">Blaster Launcher</th></tr>
</table>
1AP rounds. 
2Average between the Small and Large Rocket.

: Hold up! Tank rounds do 60AP. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

So what's wrong? The table says 60 for the Tank/Cannon and 56 for HC-AP. Those are correct, no? --[[User:Zombie|Zombie]] 23:41, 26 February 2009 (CST)

: Sorry, didn't realise it was two tables side by side (or rather mirrored). Eyes only noticed the left side of the table. -[[User:NKF|NKF]] 23:53, 26 February 2009 (CST)

:: If the Hovertank Launcher did 200 damage, or worse if the Hovertank Launcher did EVEN MORE damage than the Blaster Launcher... that would make them easily the most deadly things on the map. As it is, the hovertank launcher is already pretty overpowered, even with 140 power.

I might be six years late here, but I think there could be an explanation for this in RL physics — indeed, in RL nuclear weapons programs. Incoming wall of text.

There are two sorts of nuclear reactions that produce energy: fission of large nuclei, and fusion of small nuclei. Fission can occur under normal temperatures and pressures, but involves a neutron chain reaction. As such, fission devices have to have a certain mass of fissionable material (the ''critical mass'') so that the neutrons stay in the material and cause more fission rather than escaping; this means that such devices cannot be scaled down below about suitcase or large backpack size (not all of this is actually nuclear material; rather, most of it is conventional explosives used to rapidly assemble the supercritical mass from subcritical masses). They also produce large quantities of radioactive fallout, which is problematic. Fusion, on the other hand, requires extreme temperatures and pressures, but does not necessarily require a neutron chain reaction. This means that they can theoretically be scaled down to much smaller sizes... except that the only available compact source (ie, not building-sized) of those extreme temperatures and pressures is the detonation of a fission bomb. Thus, all known fusion weapons currently in existence involve a relatively-small fission stage that detonates a much more powerful fusion stage.

The "Holy Grail" of nuclear weapons research is what's called a [[wikipedia:Pure fusion weapon|pure-fusion weapon]]. Because it has no fission stage, a pure-fusion weapon would release little fallout (note here that fallout is material that emits radiation long '''after''' the detonation; a pure-fusion weapon would emit copious amounts of deadly neutron radiation when actually used, but that would dissipate within seconds) and could be scaled down to grenade-launcher size (though it would obviously be far more powerful than a conventional grenade). They would be far easier to produce, as well; producing weapons-grade uranium and plutonium requires large and powerful isotopic separation equipment and/or a full-sized nuclear reactor, whereas deuterium can be extracted from water with trivial ease and lithium and tritium are relatively simple to obtain and make respectively. The main issue is that while the pressures required to confine the fusion material during the reaction are achievable with chemical explosives, the temperatures necessary for fusion are emphatically not. You need a stronger initiator; some material with a higher energy density even than plutonium. In RL the only initiator strong enough is antimatter — hard to produce and contain, to say the least — but the aliens in X-Com have a source that's stored far more easily... Elerium.

I posit that the "fusion" line of weapons in X-Com are exactly what they're named: tactical fusion bombs, made possible by an Elerium detonator. (A more controlled reaction on those lines — a fusion reactor with Elerium-spiked fuel — in UFO Power Sources would also explain the discrepancy between the calculations based on fuel efficiency and the lack of city-killer blasts when a Power Source's Elerium cooks off.)

Given the assumption that "fusion" weapons are indeed fusion weapons, with Elerium serving only as a detonator, the oddly high Elerium cost of the Hovertank/Launcher's ammunition is finally explainable. The HWP Fusion Bombs are, literally, smaller than Blaster Bombs and craft Fusion Balls (presumably because of size constraints in the launching mechanism in tanks). Having less explosives to compress the fuel means you need an even higher temperature to compensate — thus, more Elerium detonator — but because the actual power of the bomb is mostly from fusion and not Elerium decomposition, the yield is still lower.

I intend to remove this from the list of Known Bugs on this basis if nobody can find a hole in my logic. [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 02:03, 17 April 2015 (EDT)

:I'll have to disagree. Your argument while interesting, is just supposition and an attempt to give validation by taking ideas (that the developers probably never considered) to justify a flaw, very much in the same manner as those who try to explain why UFOs do not respond in interceptions. In truth, like many of the other bugs listed here, they are the result of issues caused by the time constraints the Gallops where under. Much of the production/buying/selling aspects of the game have game balance issues and don't make sense when cross referenced to other similar elements in the game and/or their overall effect to either combat or the strategy layer, especially in regards to the game's economics. [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]]) 05:06, 17 April 2015 (EDT)

::Why would they match up in terminology with the actual use to which any military would put Elerium by accident? Because, no shit, if a military got their hands on a substance with Elerium's properties this is literally exactly what they'd do (at least as far as explosives go). I can cite a paper talking about the superiority of antimatter-fusion weapons to pure antimatter weapons if you want; the title is "Fourth Generation Nuclear Weapons: Military effectiveness and collateral effects". [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 05:21, 17 April 2015 (EDT)

:quote all the sources you like, it still doesn't explain the waste in the manufacture process. With elerium being such a "scarce" resource, there is no logic in producing something that require more elerium and delivers less of a battlefield effect. It would be more logical and efficient to have had the platform fire regular blaster bombs, since they only require 3 elerium not 5.[[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])
::IMHO, any logic argument can be presented to why those HWP Elerium Bombs should cost less/more or be more efficient. That is not the point here. A bug is when a game feature is working improperly or/and is causing technical issues, either due to limitations, insufficient testing, whatever. Design choices are a completely different matter: the Heavy Laser is a nearly useless weapon due to its stats but no one ever considers it to be bugged due to its stats. It was a choice, that was slightly changed on TFTD with the Heavy Gauss. To consider the stats of the HWP Fusion a bug then you'd have to label a lot of choices as bugs when they are simply design choices. You may not agree with them but that doesn't make them bugs in the generally accepted definition of the term. And quoting Arrow Quivershaft on the top comment of this discussion: "At a cost of $15000, 400 Tech hours, 5 Zrbite, and 8 Aqua Plastics, this is the exact same cost as the HWP Fusion Bomb from X-COM EU, converted over to the equivalent TFTD resources. As such, it shouldn't be counted as a bug, since it is clearly what Mythos intended"[[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 19:35, 25 April 2015 (EDT)
::Also, the consensus until now expressed by several people that previously discussed this is that this is not a bug. The main supporter of the bug argument seems to be Spike at the beginning but during the discussion but halfway the discussion he says: "I agree though that just because it's illogical does not prove it's a bug (i.e. unintended)" [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 20:54, 25 April 2015 (EDT)
You don't get to claim benefit of the doubt here, Tycho. All game features are assumed to not be bugs unless there is compelling evidence presented otherwise. You claim this is a bug based on the suppositional logic that more powerful weapons should cost more and almost nothing else. The price wasn't altered (and neither was the power) in TFTD, so there's no evidence of mistake there (as an aside, the Displacer/Sonic having its power listed as 130 when it's 110 in the game engine clearly ''is'' a bug). The only bit you might be able to interpret that way would be the description of the Hovertank/Launcher's weapon as causing "immense devastation" compared to the description of the Blaster Bomb as "highly powerful" (the potential implication being that the HWP Fusion Bomb is stronger), but that's iffy at best since there's hardly a graded table of adjectives in use and on those very same pages in the UFOpaedia it lists the damage of each weapon as what it actually is.

The claim that it's a bug is based entirely on theorising about yields. I've given alternate theorising that would explain the yields (and I already explained that the semi-automatic nature of the Hovertank/Launcher and physical space for its high ammo could justify the need for a smaller round), which undercuts that claim. We can't know who's right, but the assumption should always be that the designers knew what they were doing; to assume until proven otherwise that they had no clue is extreme hubris and contempt. Moreover, you are in a minority of one or perhaps of two against a majority of several. Your claim to representing consensus is blatantly false.

Now, I'm going to wait a couple more days to see if anyone comes forward with anything substantive, as I waited a week after my reply to your original non-refutatory dismissal, and then reinstate the removal if nobody puts forward a cogent objection. [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 22:57, 25 April 2015 (EDT)
:Now that I think of it, though, an "oddities" page where we talk about this, the shitty Heavy Laser/Heavy Gauss, the No More Soldiers limit, and other not-bug things might be in order. It would help to make this page about actual bugs and not about weirdness that is nevertheless clearly as intended. Thoughts? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 23:04, 25 April 2015 (EDT)

:At the time, I didn't continue the argument as my point was that removing something based on one person's belief, no matter how cleverly thought out, wasn't good enough to warrant removing from the list. (I would have pointed out all the different theories on UFO interception AI, but I see that has already been removed.) I hadn't read all the discussions because I assumed that no consensus had been reached, similar to the Interception AI discussion. Mushroom, could have just pointed out that this issue was already settled years ago but no one bothered to removed it from the list, instead of resurrecting a "dead" discussion as though it had not been settled and just stated that the developers intended to discourage the use of this HWP by making the cost of its ammo high. I still don't agree that the HWP ammo is more efficient and thus justification for its production cost, especially since the developers would have never needed this level of justification or would have had the time to devote to so small an aspect of the game.

:I definitely agree that this page needs to be updated. Another reason I argued so strongly is because so many topics on this page do not fall into the category of bug as has been defined. I thought this page was also devoted to listing all the illogical aspects of the game due to the lack of enforcement on the definition. [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])

::If I only had a dime for each time someone proposes to change something on this wiki, everyone agrees, and then nobody ends up taking action... :) It's always better to take initiative and edit things. I agree also with an update to this page, and separating bugs from limitations. But definitely no more 'this should have been done this way' arguments to present design decisions as 'bugs' [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 17:43, 26 April 2015 (EDT)

:Okay. I'm planning to rip out the following and stick them on a separate page:

:Great Circle "bug" (this isn't really a "bug" so much as unoptimised code)
:Side-on Intercept "bug" (ditto, but given UFOs' tendency to alter course suddenly it's not even particularly unoptimised)
:Head-on Intercept "bug" (come on, this is just bitching)
:Instant Getaway "bug" (more an anomaly than a bug)
:80-item limit (intentional and the rationale is obvious to boot)
:Purchase limit (working as intended)
:Soldier recruiting limit (being charged for attempting to buy more is a bug, but the limit itself isn't)
:Soldier battlescape limit (there's a consequence of this which is a bug, the CtD with 10+ tanks, but not the limit itself)
:Manufacturing Completion Time Display "bug" (you can look at it and see what time it finishes, and it goes down at the right rate; it may seem a little unintuitive but it isn't "wrong")
:Manufacturing Rate Interruption Loss "bug" (more bitching)
:Manufacturing Rate limit (working as intended; the attempt to get around it in TFTD is bugged, but the EU behaviour isn't)
:HWP Fusion Bomb Ammo Cost "bug" (we're in agreement here it seems)

:There's plenty that need a tidyup on top of that but as far as the page split itself goes, are we agreed? Also, I'm thinking of calling the page "Anomalies and Game Limits", opinions? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 01:58, 3 May 2015 (EDT)

== DOS4GW - What the heck is it? ==

It's been ages since I had to remember this stuff, so those who remember clearer than I do, forgive me if my descriptions aren't accurate. Hopefully the general idea will come across.

Back in ye olde days of computere gamynge - and where there were more E's to go around, memory handling was a tricky beast to handle. Computer memory is divided into several different categories. Conventional, extended and I think expanded. I might be jumbling the terminologies for the last two a bit. Doesn't matter - memory was just cut up into small segments. The two most common memory types to PCs at the time were pretty small but were readily available. The third one - the most expandable (aka the chip with its massive 4 Megs of RAM you just spent your whole month's allowance on!), wasn't as easy to get at.

To get access to the higher memory that was available to the computer, special memory handlers had to be used. Drivers like HIMEM, emm386, etc were used.

DOS4GW is one such handler that lets the game access the computer's available expanded memory. Lots of games that came out at the time use this. Doom, Duke Nukem 3d, Syndicate, Ultima Underworld, X-Com UFO/TFTD, etc. LOTS of games. Any time you ran a game from the dos console and you saw the Dos4GW message flash by briefly it would be assisted by it (well, it stayed on the screen for ages back when processors were slower!).

It took the hassle out of memory handling and let the game access the available memory on the computer as one big flat block of memory to play with.

So what was meant in the article was to simply replace the dos4gw.exe with a more up-to-date version from another game. I think the way to tell its version was just in the message that it displayed. You can just run the dos4gw.exe file in a console window. It'll give an error, but the message it shows will indicate its version. UFO 1.4 uses Dos4gw 1.95, for example.

-[[User:NKF|NKF]] 01:22, 6 March 2009 (CST)
:DOS4GW also switched the processor from 16bit to 32bit mode. [[User:Seb76|Seb76]] 13:58, 6 March 2009 (CST)

== Clipping ==
I have a new bug. Its harmless. I have a savegame (EU CE - modified game) which has a sectoid within another sectoid. In the alien turn, one secturd walked off the roof and dropped down <s>onto</s> into another. (I guess there DNA is indentical afterall, so they 'become one' with the world). If you want the savegame (superhuman edited using UFOloader, UFO Mod v1, xcomed, Khor Chin WeapEdit v0.1) drop me a request on the my page somewhere. [[User:EsTeR|EsTeR]] 01:40, 18 September 2009 (EDT)

: Not something many would encounter, but definitely something that can happen. Units can occupy the same physical space, but the game cannot display them all. It'll only draw one of them. Actually saw this effect happen back in the early days of XComutil when it gained the ability to manually add new aliens into a battlescape. It did this by slotting them into the same spaces occupied by existing aliens. Then the fun would happen when you saw a couple of Mutons suddenly walk out of a sectoid. Not sure how the game determines who gets hurt when struck by a bullet. May very well depend on the order they are stored in the unitpos.dat file.

: There are a couple of ways you can replicate this in-game, but I can only provide theories on how you could do it. Such as shooting the ceiling above you and letting the unit drop through, or moving a tank off a ledge and getting its non-primary segments land directly on top of another unit. By the way, the rear end of tanks get stuck in walls if you attempt to move north or east off any ledges. -[[User:NKF|NKF]] 02:18, 18 September 2009 (EDT)

: Ok, so as long as others know about this, then all is good. I had never seen it and was doing alot of head scratching until I shot the alien.

== Berserk HWP crashes the game ==
In the article page it mentions that aliens which go berserk with their integrated weapons will crash the game. This is only true for Mind Controlled aliens (or units under X-COM control) - alien controlled units which go berserk do not crash the game. I tested an MC'd Celatid just now and it doesn't crash the game either, though it doesn't immediately go berserk - it waits another turn for some odd reason. Someone want to check this to verify my results? --[[User:Zombie|Zombie]] 20:31, 27 December 2009 (EST)

==HWP Morale Loss==

HWPs have 110 Bravery, which [[Morale#Effect_of_Bravery|normally prevents morale loss]], but I wonder if they can still lose morale due to loss of units with a morale-loss modifier. It'd depend on how the math is done. If, for, example, the -20 to morale for a dead unit is static, then multiplied by any [[Morale#Officers|morale loss modifier]], then reduced by 2 for every ten point of bravery, any officer death without another officer on the field will necessarily reduce HWP Morale.

It all depends on how the equation plays out and when modifiers are added. For sake of this post, I propose the following as the morale-loss equation: 20*(rank death modifier)-((Bravery-10)/5)*(1.00-Leadership bonus)=Morale Lost. (Rather than using 22 as a base, I'm going to assume Bravery is internally decremented by 10 for this equation as 0 Bravery is impossible without editing and it makes the math easier for the purpose of the example.)

It makes sense to me that rather than having 110 bravery hard-coded as an exception to "No morale lost", it simply works the same way in the normal equation, but is high enough that it negates most morale loss events, as even if an officer is killed, another officer is usually left on the field to help negate the penalty. That said, if a large portion of the team is wiped out at once, any surviving officers may not be able to negate it all, allowing tanks to start having noticeable morale loss.

So with the death multipliers, we can determine that every XCOM officer killed has a set death value. Rookies and Squaddies are -20, Sergeants are -24, Captains are -26, Colonels -30, and Commanders -35.

For example, under this theory, if a Sergeant is killed with no other ranked units on the field, a Squaddie with 50 Bravery would lose 16 Morale. (20*1.2-(50-10)/5*1.00=16). A HWP would, at the same time, lose 4 morale. The Sergeant's death is worth -24 Morale, and without another officer on the field to ameliorate the loss, the Tank's bravery only can 'absorb' 20 points of the morale lost. If it was instead the Commander lost, with no other officers on the field, the HWP would lose instead 15 points of morale, given that a Commander's death (20*1.75) is worth a whopping 35 points of morale loss if no other officers are present.

And if you have, say, four colonels and the Commander on rear/psi duty, and some alien flings a grenade or a blaster bomb into the back of the Skyranger and blows all three of them up and they were the only officers, the HWP has now lost 55 morale, which gives it a 10% chance of panicking/berserking on the next turn!

In the end this'll probably need to be tested for accuracy, but those are my thoughts right now.

Also, for the record, most units that berserk go to 255 TUs while still using the original TU-expenditure calculations; it's part of what makes berserk units so dangerous. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:34, 11 January 2012 (EST)

:Tested it under vanilla CE. Took a squad out containing just about every rank there is (commander + colonel + captions + sergeants), plus a tank. Blew up and killed all soldiers with a single blaster bomb shell, leaving just the tank, which lost no morale (sorry).

:I also brought a group of rookies along with a single commander + tank, and killed just the ranked unit. Tank lost no morale. A rookie with 60 bravery lost 17 (which matches the loss predicted by the formula currently on the morale page), whereas under your formula he should've lost 25.

:Still, you're on the right track. I've long had my own theory as to why tanks have been known to lose morale. Take a look at [[UNITREF.DAT#42|UNITREF.DAT[42]]] - this is the offset that stores a unit's rank. Notice something? The value gets higher as the X-COM unit's rank gets higher. Works in ''reverse'' for aliens, for whatever reason. I sorta figure it's so killing a mind controlled alien commander doesn't mess with your morale too badly, but there's a big problem with that theory and you can probably tell what it is...

:If the highest this figure gets for an X-COM unit is 5 (commander rank), then a killing a mind controlled alien ''terrorist'' with a rank value of ''7'' should net an even higher morale loss penalty. And indeed it does - I took a rookie and a tank to a terror mission, mind controlled and killed a terrorist, and the tank lost 10 morale. Guess it would've lost six if I'd taken a commander instead of a rookie, but that's still something.

:Note that the formula on the morale page does ''not'' account for this - it states that at bravery 110 the alien's death loss multiplier would always be applied to a base morale loss of 0, but that's obviously wrong. You're spot on in saying that the base morale loss figures are not totally dependant on bravery, and the "death loss" penalty is applied first. Would probably require a few more trials to determine what that penalty ''is'' for alien soldiers and terrorists though.

:Just for kicks, I edited a plasma tank to have 0 morale. It panicked in the normal way (either sitting still or charging off to the SE). When it berserked, the game crashed as soon as I dismissed the status message. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 18:54, 12 January 2012 (EST)

:: Thought I'd give it a spin. I sent a laser tank in with a squad and had it start shooting at team members. Each time it killed an ally, it would lose morale. Once it was under 50 morale, I waited until it panicked. Since I was playing the dos version, the game didn't crash but I suspect a memory leak of some sort may have occurred that would normally shut down the CE version. What would happen in CE if a soldier were to be edited and granted a tank turret, and then made to panic? Would the game crash? I'm just wondering if it's related to the weapon as opposed to the fact the tank is a treated as a large unit. -[[User:NKF|NKF]] 00:43, 13 January 2012 (EST)

::: Ah, friendly fire! Thought I'd tested for that, but obviously not...

::: Oddly enough, now that I try it, I see that the twenty point hit for killing a unit on the same side can be adjusted by the leadership bonus of the victim. Eg, kill a lone commander and his 35% penalty reduction takes the extra morale lost from 20 down to 13 (which is exactly how much a tank will lose, given that it otherwise wouldn't lose any at all).

::: Of course, this completely messes up my theory about alien soldier/terrorist ranks overriding the 110 bravery score. It doesn't. My tank "only" lost 10 morale because the alien's rank acted as a 50% leadership bonus... Though I suppose that's still interesting to know, because it suggests that keeping a simple alien soldier under mind control is more effective then risking your own commander in the field.

::: I took an otherwise unarmed rookie and assigned him a tank cannon + ammo. He could manually fire this weapon in much the same way a tank can. Forcing him to berserk crashed CE, under DOS he just spun around. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 21:20, 13 January 2012 (EST)

== 80-items limit on CE edition ==

I have the feeling that the 80-items limit does not apply to the CE edition and is instead a 110-items limit (at least during base defence). Can anyone confirm? [[User:Seb76|Seb76]] 16:24, 24 February 2010 (EST)

:I believe this limit was increased for TFTD. Maybe it was also increased for the CE edition of UFO, and only ever applied to the DOS edition of UFO?? [[User:Spike|Spike]] 20:03, 11 March 2010 (EST)

== Paying for Dirt in TFTD ==

I have the steam version of TFTD and am unable to replicate this bug. Testing with the starting base, I dismantled a few modules, added up my income and expenses, and it reconciled with my cash at the beginning of the next month. I even tried again, dismantling every module except the access lift, and once again saw no income discrepancy. Am I missing something, or is it possible this bug was actually fixed in TFTD? --[[User:Jewcifer|Jewcifer]] 12:18, 16 March 2012 (EDT)

:'twas probably fixed. It would indeed be helpful to add a small note to bugs on this page which are EU-specific but not obviously so (like this one). -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 17:14, 16 March 2012 (EDT)

::Every now and then I get the urge to test some of the more important bugs myself in my steam version of TFTD. Perhaps I will make a more complete effort and record the results somewhere on the wiki. --[[User:Jewcifer|Jewcifer]] 12:08, 21 March 2012 (EDT)

== Paying for dirt: Source of bug discovered! ==

Well, I never have read this anywhere (which kind of strikes me as odd, thinking of how obvious this one seemed to me... And i have NO programming background whatsoever), so I'll post it here, hoping that there are still some active members willing to try and verify my findings. If so, please comment here, because then I will inform bladefirelight to include this in any upcoming xcomutil release. If it had been discovered before, well then I just wasted some time here. Comment below, I will delete this entry.

As the main bug page mentions, when dismantling a facility still under construction the premium will only be paid once it would have been finished. This suggests some connection between paying the premium and building time. Looking into the infos here: [[BASE.DAT]], I quickly discovered what the problem was: When a facility is dismantled, the Bytes related to the location of base facilities are updated correctly. HOWEVER the game omits to update build time to FF (which is "will never finish", an entry only found on unused squares). If the facility is finished when it is dismantled (or destroyed during combat), then the 00 in the build time byte will stand. If it was under construction, the value indicating the remainig build time will continue to tick down towards 00 as if the facility was still there.

Now at the end of the month the following seems to happen: The game checks for ANY 00 entry in the build time bytes, and if there are 00 entries, it will look up in the location bytes the type of structure to determine the amount of maintenance for that 00-construction-time-square. When it finds "dirt", then it will charge the 80 grand (my guess would be that those are somewhere hard-coded).

This explains all phenomena related to this bug, like a dismantled hangar costing 320.000 grand or the premium only popping up after the build time of a dismantled facility that was under construction has expired.

Now the fix is pretty easy: Open the BASE.DAT in a hex-editor and change the bytes in question to FF!

== Minimized Interceptor Bug (Ufo CE) ==

Maybe this bug is not just related to saving, because I had a similar problem last night. The game didn't crash, but it kept restarting the same Battlescape mission.
One Avenger (A-3) was pacing a Battleship, while another Avenger (A-1) was sent to pick up the pieces of a Terror Ship that had been shot down by an Interceptor. Despite having no weapons (oversight on my part), A-3 wanted to attack the Battleship, but I minimized the screen, hoping it would land.
While the screen was minimized, A-1 landed at the Crash Site from the Terror Ship and started this mission. Right after finishing it, I got the message that A-3 was ready to land next to the Battleship. Happy that I'd get the loot, I started the mission.
After cleaning it out, I got the usual Loot and Promotion screens and went back to the Geoscape. A few seconds later, I was back in the equipment screen and the Battleship Mission started again. I played it once more, because - hey - additional loot, right? Err... no. At the end, I got the correct Loot screen for this attempt and the very same promotion I had gotten in the first attempt (A Rookie from another base promoted to Sergeant).
Got back to Geoscape and a few seconds later back to the Equipment screen. I aborted this mission (same Battleship again), got back to Geoscape and - you guessed it - back to the Equipment screen. After aborting this mission as well and getting back to Geoscape, I used the few seconds I had to go to 'Options' and 'Abort Game'. Maybe I could have made A-3 disengage from the Battleship since I think I saw them both on the Geoscape, a yellow diamond and a red plus, but it was pretty late by that time.
--[[User:Matzebrei|Matzebrei]] 15:06, 15 May 2012 (EDT)

This is a known bug. There is a work around. You should patrol the ship with troops and not land... Finish shooting down the other airborne ships first. Then when the ships doing the shooting are returning to base, change patrolling ship with troops to advance to downed ship in order to commence ground combat mission.
--[[User:JGF|JGF]] ([[User talk:JGF|talk]]) 07:55, 9 November 2016 (UTC)

== Activity Overflow Bug ==

This is a potentially campaign-ending bug. This was seen in the Steam distribution, DOS version (on Windows 2003 Server EE). Not sure if UFO Extender was being used - probably it was. End of Jan 1999 turn shows an extreme negative/underflow Monthly Rating score, which in turn is caused by extreme overflow of UFO Activity levels. Note that that funding "score" - the increased funding by countries - was very positive at the same time!:

[[File:dissatisfied customers.png]]

UFO Activity, by Areas and by Countries, is literally off the chart. Clearly some kind of integer overflow:

[[File:ufo-areas.png]]
[[File:ufo-countries.png]]

X-Com activity is also off the chart:

[[File:xcom-areas.png]]
[[File:xcom-countries.png]]

In addition to the likely outcome that I will lose the game in Feb 1999, it means I can't use the graphs to detect UFO activity outside of my radar coverage.

I have only seen this bug once, and (probably very unusually) I am running under Windows 2003 Server EE (!!). My hunch would be that's the cause, Windows 2003 Server is not the best games platform. :)

[[User:Spike|Spike]] 07:22, 3 September 2012 (EDT)

Further information:

I don't necessarily lose the game in Feb or March 1999. The Monthly Ratings from Feb onward are just based on the current month, not historical score to-date. However it still greatly increases the risk of suffering from the [[Known_Bugs#Losing_My_Favourite_Game|Losing My Favourite Game]] bug - which also greatly complicates doing too many controlled experiments on this Activity Overflow bug, because a few restores of the saved game quickly leads to X-Com Project termination (and humanity's doom).

Possibly the Activity Overflow bug is caused by an initial value of the score (or an array of score values) not being correctly zeroed at the start of the game. See this graph, which shows a negative score in May 1998, prior to the start of the game in Jan 1999.

[[File:Prehistoric_negative_score.png]]

[[User:Spike|Spike]] 08:48, 3 September 2012 (EDT)

I encountered the same Activity Overflow Bug in Windows 7 using Steam version, Windows option with UFOExtender latest version.

[[User:Humbe|humbe]] 2012.10.04 09:05 UTC

I encountered the same bug at end of january with latest xcomutil patched CE version (with only bug fixes patched) with ufo extender newest version running (close to default options). Got many saves from that first month. Even if loading very early save where I had done no missions yet, and just did stuff in base, graphs still show negative for various periods in 1998. Sounds more like corruption than something actually overflowing to me.

[[User:Archlight|Archlight]] 18:34, 24 September 2012 (EDT)

== Bad Paths Bug ==

I suggest to add bad paths on UFOs maps to the article, as another bug in the game.

[[User:Sherlock|Sherlock]] 09:25, 26 December 2012 (EST)
:That sounds reasonable to me. [[User:Spike|Spike]] 10:03, 26 December 2012 (EST)

==Expenditure Graph==
The economy graph for "Expenditure" neglects funds spent on new facilities. I noticed this in my current (DOS) game when I built eight Psi-Labs at the start of April and it didn't increase. I know it counts everything on the Purchase screen; I'm not yet sure whether it counts manufacturing costs.

Is this enough of a bug to be mentioned? Can anyone confirm whether or not it occurs in CE, and whether it counts manufacturing costs? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 02:40, 17 May 2016 (UTC)

==Workshop Crowding==
It seems there is a bug whereby you can allocate more projects/engineers than available workshop space. This can be triggered by setting up two concurrent manufacturing jobs, setting one of them to have 0 engineers working on it, then set the other to have as many engineers as you can assign to it, filling the workshop space. Then go to the other job with 0 engineers, and it will show a negative workshop space available, now if you assign at least one engineer to this project, you can assign the rest of your engineers however you please.

This is my first edit. I find it hard to believe I'd be the first to find this bug after so many years, can someone please confirm a reproduction and that it isn't documented somewhere I've missed? I am running the DOS version of UFO, but I'm also running XComUtil, not sure if that has an impact, or what patch level I'm on. - [[User:Uncertainty|Uncertainty]] 11:00, 20 Dec 2016 (AEDT) Update: Cannot reproduce on the CE version, still unsure of the patch level of the DOS version I'm running and don't know how to accurately determine that. - [[User:Uncertainty|Uncertainty]] 22:00, 29 Dec 2016 (AEDT)

: An easy way to check is whether you can research Magnetic Navigation after collecting one from an alien sub, or if you have to research a Lobsterman Navigator beforehand. If you can research it right away then you have v2, which is what the CE version is mostly based on. If you can't research it and must get the navigator, then it's the unpatched copy of the game. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 22:24, 29 December 2016 (UTC)

Update 2: Thanks NKF, I'm not running TFTD, but I figured out that I was running v1.2 of XCOM1. I cannot reproduce the bug on v1.4 so the bug only applies to v1.2 and has been patched in newer versions. - [[User:Uncertainty|Uncertainty]] 16:45, 31 Dec 2016 (AEDT)

= Unconfirmed bugs =

== Alien mission succeeds despite Ground Assault ==

Suppose aliens decide to do a mission. So they send a scout UFO. If you shoot it down, the alien mission gets derailed and the next scout becomes delayed, sometimes a little, sometimes a lot. Seems like the headquarters are waiting for the first scout to report back home or something. But eventually the second scout shows up so you shoot it down too. The third one also takes a long while to arrive and if you shoot that down too, the aliens either give up on the mission completely or send their big ships which only aimlessly fly to and fro, never land and leave soon, empty handed. This way or that way, the alien mission is a failure.

On the other hand if you wait for the scout to land, assault it with your Skyranger and win the mission, the alien's mission continues as if nothing happened. The second scout appears on time. So you ground-assault it too but the third and fourth scout also appear on time. Then the larger UFOs show up and land as if nothing happened to the scouts. You ground-assault them too, including the last Battleship that happens. But guess what? The alien mission is a SUCCESS even despite none of the UFOs making it back to base. Really annoying if the mission is an Infiltration, you can't take their juicy big UFOs because if you do, you are going to lose a country. But on the other hand all these Alien Harvests and Alien Abductions? Lots of juicy spoil and tons of points despite the aliens achieving what they wanted.

I need to add that I was playing some weird version of the game whose data was rejected by OpenXCom with "an invalid CHRYS.PCK file, please update to the latest version" message. So I don't know if this bug exists only there or is present in the latest version of the game too or even whether this is a bug or an expected behavior. - [[User:TowigOs|TowigOs]] ([[User talk:TowigOs|talk]]) 00:24, 3 August 2025 (UTC)

=Cleanup needed=
Hmm this whole Talk page needs a cleanup. A lot of the Not Listed bugs, should be listed, or are listed. [[User:Spike|Spike]] 10:03, 26 December 2012 (EST)

:So, before it will be made, yet three more observations.

:1. There is no possibility to give back (to stop hiring) a plane without craft weapon.

:2. Alien Reproduction is unavailable in a normal game without hacking/save editing. This is probably connected to further errors on maps. A bug/error/programmers' oversight of the some kind is present in TFTD where it is impossible to obtain Examination Room. It is so because many tiles on maps are wrongly assigned to game's objects. Namely, [[Examination Room (TFTD)]] is treated as Alien Implanter - but there is plenty of errors of this type, on various maps (perhaps also in UFO: EU).

:3. Among soldiers in UFO:EU, there are Russians. Some non-Slavs may not know that Slavic (also Russian) family names have different masculine and feminine forms. For example, Petrov, Belov, Likhachev, Gorokhov, Chukarin, Andianov, Voronin, Maleev are all masculine names; women must be called Petrova, Belova, Likhacheva, Gorokhova, Chukarina, Andianova, Voronina, Maleeva respectively (however, a rule that the feminine form is always made by adding -a is wrong, e.g. Tolstoy - Tolstaya). The soldier's name Mikhail Gorokhova (which is possible in UFO: EU) is just ridiculous (for everyone who has even little knowledge about Russian things). Tatyana Petrov is also an impossible combination. X-Com creators probably assumed that family names are the same for men and women in all languages, and, as a result, they made only mechanisms for storing masculine and feminine forms of first names, not family names. But taking reality under consideration, this is a bug.

: [[User:Sherlock|Sherlock]] 16:22, 26 December 2012 (EST)

== Common bugs vs. UFO EU specific bugs ==

I believethere is one more thing that needs to be cleaned. Namely, both EU and TFTD share the same game engine, so some bugs are common for them both. However, there exists a page with a list of TFTD bugs, and it is clear (or: should be clear) which of the bugs are specific for TFTD. I think the same should be done with EU specific bugs: to hold them apart from bugs common for both games. Some bugs exist in both games but manifest themselves differently (like problems with mind-controlling of big aliens) - they are not true common bugs.

Or even more: one could expect a clear information by each bug, in which game and in which version of the game the bug occurs. And whether a patch exists or not. Sometimes such information is given now, and sometimes it is not. And if one does not know exactly which versions are affected by the bug, it should also be mentioned clearly.

[[User:Sherlock|Sherlock]] 04:13, 27 December 2012 (EST)

== Rename page title to indicate which game this refers to? ==

I was looking for a list of bugs related to XCOM Apocalypse, and it took me a while to realize this was about a totally different game. There are 4 games (not counting the 2 opensource projecrs) here on UFOP - maybe that could be reflected in the article aswell?
[[User:Panzerlol|Panzerlol]] 20:35, 31 March 2013 (EDT)

==New "bugs" submitted directly to main page with no apparent explanation==

WakkaDakka, have you actually managed to replicate this "missing time units" bug, or was it just a one-off freak occurrence? I'm not sure it merits main-page space until we have some idea how to replicate it.

N21, how were you seeing the future to begin with? It's only a bug if it occurs in the normal course of play.

[[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 03:36, 28 May 2015 (EDT)

== Enemy Unknown 1994: Save game bug mid mission. ==

Effect : Loading saved game mid mission just displays a black screen with the cursor at the top left, whilst the music continues to play in the background.
I don't believe the game has crashed out to DOS, having tried both CLS and DIR to no avail. Your can no longer interact with the game, making you force quit the app.

[[File:Screen_shot_2016-11-07_at_19.39.31.png|thumb|left]] 

I'm using Boxer 1.40 on a Mac - which in turn is built off Dosbox 0.74.
I remember seeing this bug years ago on Windows XP too, so I don't think it is platform specific.
I'm currently running it with some of the XCOMUtil patches too - but have had the issue crop up without any of the patches.

Playing on Superhuman level, I use a Skyranger with 14 soldiers equipped with Laser Rifles.

Cause : Hard to be specific. But here are the facts.
I have my suspicions it may be do to with fog of war rendering issues.
I've had it occur frequently when going to the NW edge of a map.

I also had issue on Alien base 1. I have a save game and can suggest moving a unit and saving it in another slot - that alone causes the issue. So if someone knows how to debug this I can supply that. Not sure if the combined number of aliens and yourself casue this.. I managed to eventually work thru a series of corrupted saves that wouldn't load to one that worked again).

Here is a sample save game where the game only needs one specific movement to corrupt a game when you save after the move.

[[File:GAME_10.zip]]
I've uploaded two images to show the move for S Bradley
[[File:Screen_shot_2016-11-11_at_13.50.13.png|thumb|left]] 
and the destination square to move him too. When you complete that move and save the game it corrupts.
[[File:Screen_shot_2016-11-11_at_13.50.17.png|thumb|left]] 

Incidentally there were two downed UFO's at this time, with a second Skyranger en-route to UFO 42. This mission was for UFO 43 with another Skyranger.

The problem frequently occurs.
Ive had it occur recently on the following types of mission:
Terror, Alien Base, Supply ship, Large Scout, predominantly with Sectoids and Cyberdiscs, but also with Mutons and Floaters.
The only thing all these missions have had in common was lots of units on both sides. For example 13 Floaters on a Scout mission, 9 Cyberdiscs on a Terror mission etc.

--

Other quirky things I've seen relating to Stunned units:

1) You can't stun a unit, forcing you to shoot it to complete the mission.
The target being stunned drops to the ground in a heap, but the game says you can still see it and can re-stun unit....

2) Celatids. You stun it, then it wakes up and moves away. The unit no longer renders correctly. It's like a sheet of garbled colored/transparent dots.

3) A stunned unit, other than a Celatid wakes up, and is invisible but you get the '1' in red square for visible enemy. You can stun unit and get the animation for it falling to the ground again.

--

Teleported unit off screen (notice the yellow arrow over the unit, which alas is invisible at the split second I took screenshot - OS/X rendering crap-shoot).
[[File:Screen_shot_2016-11-12_at_14.18.07.png|thumb|left]] 
The unit was teleported from the top of the stairs in an entirely different building, rendering the unit unusable for the mission. I ended up reloading it and doing over.... - [[User:JGF|JGF]]

:Stop spamming [[Special:RecentChanges|the changelog]], please - if you're working on a page and want to see the results of your edits midway through, use the Preview button. Don't hit Save until you are ''done''.

:I can't replicate any issues with your provided save. Bradley doesn't have enough TUs to "complete" the requested move, but asking him to make the attempt anyway, then saving / reloading, works fine for me under 1.4 as well as CE. For what it's worth, as far as I'm aware the game in no way keeps track of the number of actions you've performed during a given turn; at least, I haven't been able to find any such counter embedded in the save files.

:I do suggest you leave your units with more time units - when ending turn, any agents who ''might'' spot an alien during the enemy's turn should ideally have some cover, a kneeling stance, and enough action points to defend themselves with a reaction shot. Using your full TU allocation on movement is somewhat suicidal, and even when you can get away with it, it tends to leave agents without enough energy to move when they really need to.

:Your invisible units may be related to [[Known_Bugs#Invisible_Chryssalids|this bug]] - presumably you can trigger similar behaviour by knocking out all instances of a given alien species within a map, saving / reloading, and then waiting for one of the aliens to awake. I was able to replicate it with an Ethereal, for example.

:Difficult to comment on your garbled Celatid without seeing it first-hand. Ditto for your un-stunnable target. I'd quite like to inspect them with my save editor, though, and ditto for the teleported unit. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 05:46, 13 November 2016 (UTC)

Thanks for scaling the images nice to see the wiki syntax.
It's odd to here you say he didn't have enough Time Units left, because for me the move is allowed.
Where did you get your 1.4 patch?
I applied 1.4 too and am wondering if I got a bad version.
Also did you get your original XCOM off GOG or some place like that?
I have the original CD. I think it's the US version as I used to live there.

== Time Units reset to 0 when soldier reaches 255 TUs ==

I have been playing an old version of UFO: Enemy Unknown, where there is no limit on TUs for soldiers. At certain point, two of my best soldiers reached the limit of 255 TUs, which rendered them useless at now they have 0 TUs.
I tried to reduce their TUs by editing Soldier.DAT, but it did not help. If I check soldiers from the base menu, I can see that the value has been changed, but in the battle their stats are still the same and thus they have 0 TUs and cannot be moved with.

Do any of you know, how to fix this bug? Where is the limiter located, can I change it so that is will be as in the new versions? In any case, I believe this bug should be mentioned on the page. It is mentioned here though: http://www.ufopaedia.org/index.php/Time_Units --[[User:Achernar|Achernar]] ([[User talk:Achernar|talk]]) 21:13, 9 May 2017 (UTC)

: Feel free to add the issue - the page is a hodge podge of whatever issues folks have at the time or as they come across them.

: While I'm no expert on the file structure of the executable for the first release of the game, I suspect you'll find the cause for the byte roll-over feature is that there were no stat limiters to begin with. Best way to cope with it is to either retire anyone approaching supersoldier status to base defence duty, buy more soldiers and spread the experience out more evenly, or update to 1.4 and find a sound patch to restore the original sound samples.

: For your broken soldier: I'm, assuming you edited the soldier.dat file. If you saved the game while in the battlescape, the game creates a temporary copy of the soldier stats and keeps them in unitref.dat. This is to keep track of in-battle status changes, experience, etc. You'll need to edit the current TU levels in this file as well. Or beat the mission with the soldiers that can move and you'll see your edits reflected in the next battle. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 05:45, 11 May 2017 (UTC)

== Fire rate bug & German version footsteps ==

These don't seem to be documented for some reason: (DOS Version)

The fire rate always resets to 3 if an alien or an alien mind controlled unit throws a grenade.

If German is chosen as language to play, the footsteps of all soldiers, regardless of the terrain they walk on, will sound as if they are walking on a metal surface like the inside of the Skyranger, UFO or the base. [[User:Bard|Bard]] ([[User talk:Bard|talk]]) 05:38, 8 April 2019 (CEST)

== Direct incendiary hit causing no reaction fire? ==

On the Incendiary page, it is reported that a direct hit will not cause an alien to spin around and return fire. I have tested this in OpenXcom and find that the aliens do, in fact, return fire. If this can be confirmed in original X-Com, it would be good to add to known bugs.

: It's safe to say everything you find on this wiki relating to the classic game pages were gleaned from the original games. OpenXcom, being an independently developed fan project, will have its own list of fixes and changes chronicled in its own documentation. In fact I would not be surprised that good deal of the more technical information on this wiki has been contributed by those that had some input into the OpenXcom project. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 05:16, 8 June 2021 (UTC)

:: Thanks, good to know. Would still love to know if anyone has tested this in classic game. If not, I will when I can, so it can be added to known bugs [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 22:05, 15 June 2021 (UTC)

==Alien weapon loadouts bug/anomaly==
There are actually 10 alien weapon loadout sets, not 9. The actual first set is 70% "early"/20% "mid"/10% "late". This loadout set never appears in-game, though, because the setup at game start counts as a month rollover which means that weapon loadouts (which are called when the mission occurs, not at month start when the mission is scheduled) are called from the second set during January, the third set during February, and so on. This is probably an oversight by the Gollops (note that race weights reach their final values in October; were it not for this quirk, weapon loadouts also would), but it's hard to be sure. Should this be added? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 15:02, 28 April 2025 (UTC)

Talk:Known Bugs

2025-08-03T00:24:13Z

TowigOs: New section for unconfirmed bugs plus one I remember

= Classification etc =

== Bugs vs Exploits ==

Could someone comment please on the distinction between a bug and an exploit, and where to put each one? I would guess that a bug is something that undesirable and an exploit "might be" desirable, if you want to cheat. But what about exploits that happen by accident, or bugs that need to be forced to happen?

I was going to add the Research Rollover bug to the Exploits sections, but they seem to all be under construction. What's the agreed approach?

[[User:Spike|Spike]] 04:16, 15 March 2008 (PDT)

* i think that an exploit is somthing you can trigger and gain an advantage from. a bug may or may not have a known trigger, and does not give an advantage if it does.
: All exploits are bugs, either in implementation or design. When using a bug to gain advantages that bug is used as an exploit (you are exploiting the bug). [[User:FrederikHertzum|FrederikHertzum]] 13:39, 10 May 2011 (EDT)

:: IMHO, Laser Pistols Gifts to train reactions is an exploit, but it does not involve any bugs. It merely exploits the fact that laser pistols will not penetrate the front armor of Flying Suits. [[User:Jasonred|Jasonred]] 16:31, 10 May 2011 (EDT)

::: I guess the point is to differentiate if it's a bug that's being exploited to your advantage, or it it's something confined within the game mechanics that you are exploiting to your advantage (even if using it as intended). -[[User:NKF|NKF]] 02:31, 11 May 2011 (EDT)

:::: Another definition: An exploit is
::::: a) a move allowed by game interface
::::: b) that sidesteps another part of the game mechanics
::::: c) and creates inadequate advantage for the moving player in the process.
::::: An exploit is not a bug, but it can be connected with a bug, if the latter allows a move mentioned in a). Most obvious exploits render whole parts of game mechanics obsolete (see b) above), because they are always more advantageous. In games that feature equal terms for AI and the player, an exploit can be discerned simply by the fact that AI does not use it (sadly this is not true in X-COM). Clear exploit in X-COM: Transfer soldiers = no monthly payment. Suspect exploits: grenade layout. Most probably not an exploit: Sniping (although the inequality with AI is suspect). Clearly not an exploit: dropping weapons to prevent Psi mass murder (this one is made exploitable by the AI unable to pick up weapons, but is not an exploit per se).--[[User:Kyrub|kyrub]] 05:30, 11 May 2011 (EDT)

The dropping weapons sort of turns into an exploit if you do the "everyone suspect of being a psi weakling drops their weapons at the end of the turn. They all pick up their weapons again if unpsied in the next turn." The grenade layout or grenade hot potato is probably not what the game designers had in mind, but I shudder at the thought of someone who only played X-com then joined the army pulling the pin out of his grenade and then dropping it into his haversack or slinging it on his belt. [[User:Jasonred|Jasonred]] 07:43, 11 May 2011 (EDT)

: Yeah, I think we agreed somewhere that shoving live grenades in your pockets and not having them go off is madness. The relay however is not sensible but certainly possible if only a very short one (if with a live grenade), or to toss a grenade forward and prime it at the second to last person. Or more reasonably, something like a stick of dynamite with an extra long fuse. Even that's very dangerous.

: By the way, what does everyone here think of using the mind probe to check if it's safe to attack an alien while standing in full view of it, or if you're right up next to it? I've been using it a lot lately (in lieu of the psi amp), so you could say I've been exploiting the mind probe to my advantage to help me with my decision making. But is that counted as a cheat since I'm picking my moments to attack up close when the enemy cannot return fire? -[[User:NKF|NKF]] 03:30, 12 May 2011 (EDT)

:: When identifying a mechanic as an "unfair exploit" (as opposed to just a "tactic"), perhaps a simpler checklist is this (though Kyrub's is spot-on):

:: a) Is this something the developers should've expected players to do?
:: b) Is this something the developers could've easily prevented?

:: If the answer to both is "yes", then it seems fair game to me. For eg, sniping at aliens: The game KNOWS whether the soldier can see the target (you get a flashing indicator if so), and so it would've been trivial to prevent it. Is it something the regular gamer will try? Certainly; therefore it can be considered expected behaviour. Ditto for using the Mind Probe to make attacks without fear of reaction fire; those things aren't cheap, they sell for a bunch, so it stands to reason that they'd have tactical value!

:: Things like the transfer bug are clear exploits. The devs would've implemented that system so that, if you order personal near the end of the month, you don't end up paying for them twice before they ever arrive - but in the process, they forgot that "purchase" transfers are treated in the same way as "between-base" transfers. To fix one scenario without breaking the other, they'd've needed to code in some extra stuff so the game could tell the difference - they probably just figured the regular gamer would never notice, assuming they ever realised the problem existed.

:: The "dropping weapons" thing is a little trickier to work out - yes, the devs should've seen it coming, but would it've been easy to fix? Aliens could've been twigged to either ignore un-armed soldiers... but those soldiers could re-equip next turn. Aliens could also've been twigged to attack randomly... but that would make their psi powers far LESS effective! I suppose the fix, if any, would've been unarmed melee attacks, but the implementation they went with seems to be the next best thing IMO.

:: In regards to the "grenades in inventory" thing, it's probably common knowledge by now, but they DO go off in the alpha of the game. Presumably someone made a conscious decision to change that, though it could still just be an accidental bug. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:02, 12 May 2011 (EDT)

Sniping at aliens is a very bizarre case, since almost all players will fall prey to the aliens sniping at you long before they snipe the aliens. The behaviour of the aliens to step within sight radius, take one step back, then fire without fear of retaliation *looks* and *feels* like clear exploitation of the rules, but the computer can't be a cheater, can it? So we humans carry that one step further. Mind you, I think X-com would be in trouble if the aliens could snipe you from across the map once they know your positions... especially since the aliens have cheating "if I spot 1 human, I spot ALL of them" abilities. Especially on maps where the aliens get Blaster Bombs...

An interesting note about sniping and LOS: When I first played Xcom, my first mission was in the jungle. Because of all those plants, when my first soldiers spotted an alien, after he shot at him, I tried to make my 2nd soldier open fire and was informed "NO Line of Fire". I could only get my 2nd soldier to fire by positioning him in such a way that I got the flashing number. Henceforth, I assumed that you could ONLY fire at the aliens when the flashing number was there. LOL. LOF. LOS.

Transfer bug wise, I thought that the devs merely programmed the game to count how many staff were currently in the base, then deduct that from Xcom coffers? As far as ordering personnel near month end goes, you end up paying salary for them if you order them more than 48 hours from month end, right? "realistically", they should make staff draw salaries based on when they were hired, but this would be too much effort.

"dropping weapons" would have been easy enough to fix... just teach alien AI how to pick up weapons. Like they did in Apocalypse.

As far as grenade relays go, if you ever join the army, and you toss a live grenade at your squadmate, you're gonna be court martialled! lol. Xcom grenades are weird cause they presumably come with a computer console where you program them or something that takes a lot of TU, if I already have a grenade in my hand I don't think it takes long to prime it compared to throwing it...

Pretty clear exploit/bug is tossing grenades through the ceiling? That breaks all laws of realism/logic/whatever, and I'm sure the devs didn't plan for THAT to happen! [[User:Jasonred|Jasonred]] 18:18, 12 May 2011 (EDT)

: Turns out the "spot one, spot all" thing was wrong all these years. However, units can be "spotted" by sniping an alien, hitting it, but failing to outright kill it; this may have contributed to the misconception.

: The game considers the base to have the correct amount of personal as soon as you initiate a transfer - if a base has room for ten people, you can't send two groups of ten, as soon as the first is in transit the game will correctly recognise that the destination is now filled up and won't allow you to send any more. Likewise, if you hire soldiers, they'll count towards the allowance of more promotions in your ranks before they ever arrive at a base. That is to say, the payment system deals with personal counts in a different way to every other system in the game, making it look like it's intentional (if badly exploitable) behaviour. In terms of transit times, those seem to vary, I know a purchase of scientists takes 72 hours to arrive.

: Er, yes, getting aliens to pick up weapons would've indeed fixed the dropping thing. Shoulda thought of that...

: The grenade thing is indeed unrealistic however you look at it. Certainly throwing the things through ceilings is a bug, and its use is a large exploit. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 20:02, 12 May 2011 (EDT)

:: Then how do the aliens "spot" the psi weakling to target him for psi attacks? Doesn't the game ALWAYS start blasting the juiciest target, regardless of LOS? Or is it just coincidence? [[User:Jasonred|Jasonred]] 22:22, 12 May 2011 (EDT)

::: They really have to "[[UNITPOS.DAT#8|spot]]" the target before they can blast them (however, it appears that later in a campaign this rule gets broken). If they've only spotted a psi-''resistant'' trooper, they typically won't bother to make attacks at all. There's a lot of relevant information in [http://www.strategycore.co.uk/forums/Can-alien-attempt-Mind-control-Pani-t8115.html this thread]. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 23:28, 12 May 2011 (EDT)

: Your talking about your post on http://www.strategycore.co.uk/forums/Can-alien-attempt-Mind-control-Pani-t8115.html&pid=96123&mode=threaded#entry96123 ? Well, I'd just like to point out a massive flaw in your testing logic. You forgot that aliens will launch psi attacks based on chance of success, and chance of success varies based on distance from aliens. In other words, it could easily be that the aliens only attempted psi when your soldier was within sight of them because your soldier was now NEAR to them and therefore they had a strong chance of success.

: Also, as you have noted, it appears that your rule gets broken. In fact, it is not uncommon at all for the Ethereal Commander who is boxed up in the Command Center to launch psi attacks on victims who are separated from him by several layers of walls, as long as their proximity to him is near enough. [[User:Jasonred|Jasonred]] 21:19, 13 May 2011 (EDT)

:: Those are valid points. I've hence built a somewhat more robust testing scenario, which you may wish to [[:Image:Alien Psi Demonstration 1.rar|try for yourself]].

:: The save game consists of cloned Ethereal soldiers (all cranked up to 100 psi strength/skill), and many clones of a single trooper (most of whom have the same psi values). The Ethereals are all cooped up in a sealed room in the SW of the map, with a single trooper who has 140 psi strength/skill.

:: Directly outside the building is another trooper who only has 1 strength/skill. In the NE of the map, in another sealed room, is a soldier with 40 strength/skill. Before placing him there, I had him shoot one of the Ethereals just once, resetting index 8 of his UnitPos record to 0. Only he and the trooper inside the room with the Ethereals have hence been "exposed" to the aliens, but the "best chance of success" is obviously the psi-weakling directly outside the building.

:: If you load the map and end turn, the aliens will first attempt to take control of the dude on the other side of the map, then get to work on the guy in the room with them. Once they've taken these two, they'll completely ignore all other units.

:: In short, aliens can't use psi attacks on a unit UNLESS their UnitPos[8] index is set to less then that of the alien's intelligence stat. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 05:41, 14 May 2011 (EDT)

::: Good one. That test definitely proves a lot, rather conclusively. [[User:Jasonred|Jasonred]] 06:53, 14 May 2011 (EDT)

== Bugs vs Limits ==

''(Discussion continued from [[Talk:Known Bugs#Soldier Recruiting Bugs Tested|Soldier Recruiting Bugs Tested]])''

The "Soldier Recruiting Limit" is not a bug, it is a limitation of the game. Therefore, this should be removed from the page. If we want it somewhere else (like a new page such as [[Game Limitations]]), that would be appropriate. --[[User:Zombie|Zombie]] 01:42, 9 November 2008 (CST)

::Not sure that's necessarily the best idea, Zombie, since many of the entries on the Known Bugs article(as well as some entries on the Exploits pages) are limitations of the game engine. On just a brief glance through, the following caught my eye as engine limitations: Manufacturing limit, Storage limit, Purchase limit, 80-item limit, Proximity Grenade limit, Large units not waking up from stun, Interception last shot bug, Alien UFL radar blitz-through bug(Passing through the detection range of a radar before the detection check comes up), Free manufacturing, free wages, UFO Redux, point-scoring with Ctrl-C, permanent MC of chryssalids, Zombie-MC resurrection of agents, alien inventory exploits, anything involved with bad collision detection, extinguishing fire with a Smoke Grenade, and even your personal favorite, denying the aliens access to their own spawn points. So in conclusion, maybe it should just be left as it is; conversely, all of these entries could be kept where they are and also on a Game Limitations page, or we could leave the headers there and link them over to the appropriate topics on Game Limitations. What do you think? [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:21, 9 November 2008 (CST)

: I agree with AQ (great list of examples by the way - and the Smoke/Fire limit would be another). Many, if not most, of the bugs are "Limitations" but they are logically inconsistent and not what a player would expect to happen: they are imposed by (at best) memory limitations or (at worst) design/programming oversights. I think the easiest thing to do would be to change the title of the page to Known Bugs and Limitations, or put an explanatory note at the beginning of the section to explain that "Bugs" is taken to included "Limitations". [[User:Spike|Spike]] 13:16, 9 November 2008 (CST)

By the strictest sense of meaning, a "bug" is a mistake or error on the programmers part. Limitations imposed by design or memory are not the same creature as the people involved were consciously aware of the decision. I suppose that to the normal player, any type of behavior which is unexpected/unwanted is automatically dumped in the bug category because to them there is no difference. To those of us who study the game files however, the two are unequivalent. Programming oversights, yes, those are bugs.

Some of those limitations AQ mentions are (to me at least) bugs: free manufacturing, free wages, permanent MC of Cryssies (or actually any alien for that matter), Zombie resurrections and collision detection. Large aliens not waking up from stun is again, a bug. The programmers obviously had some issues when dealing with large units in general and never quite got it right. They made some progress in TFTD by trying to fix mind controlling each section of a large unit, but royally screwed it up by selecting the next 3 entries in UNITPOS.DAT no matter what they pointed to.

Perhaps it's just my background in logic which makes me want to push for a separate category for limitations. Then again, as long as everything is listed somewhere I'm happy. --[[User:Zombie|Zombie]] 22:06, 9 November 2008 (CST)

: Actually, taking a look through the page as a whole there are various other Limits described, and the distinction between Bugs and Limits is made quite rigorously throughout - not just in the Soldier Limits and Bugs section, where the Soldier Recruiting Limit is referred to as a Limit whereas other bugs (such as paying salaries for soldiers you can't recruit) are referred to as Bugs. So we maybe just need to rename the pages "Bugs and Limits" and add an explanatory note on the distinction. From a user point of view, rather than a programmer point of view, a bug is an unexpected (inconsistent or illogical) behaviour, so for that reason I think it makes sense to keep them on the same page but try to ensure they are all correctly classified as Bug or Limit.

: By the way, it could be hard to absolutely distinguish Bugs from Limits as I suspect there are going to be some grey areas where you would have to second-guess the intentions and decisions of the coders to know for sure if something was a designed-in Limit, or just an oversight (Bug). [[User:Spike|Spike]] 06:50, 10 November 2008 (CST)

::If we distinguish in this manner, I suggest the definition of "Limit" should be, "Something imposed by the game files or engine as a limitation, most likely in context to the capabilites of the then-current personal computer." More succinctly, anything that was done to allow the game to run acceptably on what was then a PC. This would include both the Soldier and 80-Item limits, the spawn limit(40 units per side), Smoke/Fire limit, and some of the others listed. (The Purchase limit was probably more of a convienence for the programmers than anything, but it is clearly an intended feature.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:11, 10 November 2008 (CST)

: I would add to this that sometimes a Limit may be imposed as a game design / gameplay decision, rather than in order to conserve a constrained resource in the platform (=PC). Also, I would suggest that ''intended'' Limits are Limits, but ''unintended'' consequences of Limits are Bugs. Obviously, making this distinction involves some guesswork. But I would guess that while the limit on total smoke/fire hexes was an intended Limit (to conserve PC resources), the ability to put out fires with smoke grenades and disperse smoke with IC rounds is probably an unintended consequence of the Limit, and so should probably be considered a Bug. Similarly, Base Defence spawn points are probably an intended limit, but the ability to flood spawn points is an unintended consequence of this, and thus a Bug (and an Exploit). (Spawn points should have been shared out 50/50, not humans-first). [[User:Spike|Spike]] 12:07, 11 November 2008 (CST)

::The limit on Soldier and Interception craft were probably more of a limit imposed because they capped the file and figured that X-COM wouldn't ever need more than 40 interception craft or 250 soldiers. (And I've never needed that many, case in point.)

::As for spawns, its actually difficult to take advantage of it in any reasonably established base. X-COM can spawn up to 40 soldiers in a base defense mission(tanks count as 4 soldiers), as a limit of LOC.DAT. Aliens have the same limit. So in order to take advantage of the bug, the base needs 40 or less spawns total. The Access Lift has 8 spawn points, General Stores(weapon-handling) has 11, Living Quarters has 8 more. This is 27 Spawns just getting soldiers in a base and armed. (Although the General Stores can be cut out if you perform the bug properly). Large Radar and HWD have 6 spawns(Small Radar has 2), and Hangar has 15. So overall, the "Spawn prevention" can be hard to take advantage of with all but the smallest bases. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:48, 11 November 2008 (CST)

Just to clarify, X-COM interception craft are not capped at 40 ships. LOC.DAT has a cap of 50 "things" on the geoscape screen at a time. This is shared between X-COM bases, X-COM ships, alien bases, seen or unseen UFO's, terror sites, crash sites, landing sites and waypoints. In a perfect game world with little alien activity and normally constructed bases, the max number of X-COM craft possible is 44: 5 bases with 8 hangars each plus one base with 4 hangars (or any combination thereof). If you illegally modify your base layout with an editor to get rid of the access lift, the max can be increased to 45 ships (9 hangars in 5 bases). Once clogged, all alien activity will cease.

The base defense limit of 40 units exists because of UNITPOS.DAT which has a cap of 80 entries total (tanks occupy 4 entries in this file). Auto-win missions in a base defense mission by clogging all the spawn points with X-COM units isn't as tough as it sounds, especially if your base is small or doesn't contain hangars. The main thing is getting your full quota of 40 units to spawn (meaning you should try not to have any tanks as they count as 4 units but only occupy one spawn point). This limits the base size to something like 5-6 modules depending on what you build. Still, even having more than 6 modules isn't bad as it forces aliens to spawn intermingled between your troops. With 40 armed guys staring in every direction, you can get positions of all the aliens in the first round and possibly even kill them all (depends on weapons and alien race of course). --[[User:Zombie|Zombie]] 20:12, 11 November 2008 (CST)

: I would say that Limits are the CAUSE of bugs... also, I feel that fire/smoke limit can be called a bug, because a player normally has no way to tell this, other than observation. Whereas the game DIRECTLY and CLEARLY informs you whenever you hit the 80 item or 250 soldier limits, which is more fair. [[User:Jasonred|Jasonred]] 15:22, 23 March 2009 (EDT)

Also IMHO it is not true that, say, 250-soldiers limit is a real game bug. In fact, it is not, it is just a rule of the game, or its limitation. And it is unimportant what its reason is (such or another way to store game data).

A bug is, by definition, an unexpected and involuntary result of programmers' work. However, we can only guess what the programmers wanted to attain, so this definition is both unpractical and impossible to be applied. It would be better to assume that a bug is a feature which has negative influence in the game. To clarify: the (un)famous 250-soldiers limitation does not harm in practice, as the number is really enough to play the game. But the even-more-unfamous 80-item limitation does harm and it has negative consequences - it is enough to recall the disappearing of bodies during some missions.

OK, there is no objective criteria to judge whether a feature of the game is a bug or just a limitation. But sometimes subjective criteria have to be enough. Otherwise, we would have to consider the 8-bases limit a bug. Does it make any sense? And if no, what is the difference between the 8-bases limit and the 250-soldiers limit? I feel neither is a bug. Because neither leads to further negative consequences.

And further, IMHO the buggy nature of some game features is quite obvious. If you cannot send more than 100 "parcels" of items at the same time, it is still not the bug. But if you must pay for an item you are trying to send but you cannot do it - it is a bug, perhaps everybody will agree. And similarly: the 255-scientists limitation is not a bug. But the strange behaviour of the game when you bought the 256th scientist is a bug. It would be just a limitation if the game did not allow to buy another scientist. But it allows while it cannot serve the 256th scientist properly, and that is why it is a bug.

So, I vote for removing the 250-soldiers limit from the bug list. If I am wrong in it, please add to the list also:
# 8-bases limit,
# maps with limited terrain (why should they be limited?),
# base area and base facilities limit (why wouldn't we be able to have 10 hangars in a base?),
# etc.

In yet other words, in my opinion it is not enough to show that the game does not allow to have more certain items or to do more certain actions. In order to count this among bugs, we should show that it really harms during playing the game, or just bears negative consequences.

[[User:Sherlock|Sherlock]] 03:52, 27 December 2012 (EST)

= Specific Bug Discussions =

== Misc Technical Bug ? ==

''(The context of this discussion seems to have been lost)''

This is a technical bug that doesn't happen to everyone and one this article wasn't really meant to chronical - but we won't turn away helping a fellow player if it can't be helped. It's just that there are so many random crash points in this game that it would take far too long to find them all or come up with solutions for them.

Certainly, the transfer crash can happen to some players, but it's not one that can be reproduced easily. It's just like the random crash that some players get when they research a floater medic. It crashes the game for some of us, but others don't seem to notice it at all.

It really depends on your hardware and OS setup, whether or not your copy of the game is damaged or your savegame is damaged, etc.

Does it happen in all games or just this one savegame?

- [[User:NKF|NKF]]

-----

== "Invisible Muton" bug ==

Upon shooting repeatedly a Muton, it sometimes plays its "death" animation without sound (as if falling unconscious) and it is no longer displayed in the screen, while remaining visible to my soldiers (I can center the screen and the cursor appears yellow over them). Under this state, they cannot be targeted by Stun Rods. They may play their death animation anytime they get shot, until they truly die, when they emit their characteristic sound and leave a corpse (along with any items carried).

I'm quite fond of laser weapons, maybe this happens more often with those.

Also, though I remember experiencing this quite often fighting Mutons, it may happen to any other high health race.--[[User:Trotsky|Trotsky]] 02:59, 2 July 2006 (PDT)

-----

Never seen that one myself. Another "unpatched game" thing maybe?

There's a (very rare) bug that allows your soldiers to live if they become stunned by an explosion that happens to kill them. Sometimes the game will register their death, and THEN register that they've been stunned. In every case I've seen this happen, however, the unit will have such a low amount of health that a single fatal wound will render it dead (again) on the next turn. I have a vague memory that other players may have been able to get a medkit to the scene on time...

I dunno if that's related to your issue at all (I doubt it, but... meh). I'd advise using a Mind Probe on the alien the next time it happens so you can check the aliens stun/health levels.

- [[User:Bomb_Bloke|Bomb Bloke]]

----

I'm pretty sure I've seen this with Mutons. Possibly Chrysallids as well, another high health, high armor creature. They were still readily killed by shooting the place they are. Good thought on the MP, BB

---[[User:MikeTheRed|MikeTheRed]] 08:51, 2 July 2006 (PDT)

----

I've been known to have a dying muton(in fire) to spin around and then switch to the female civilian death animation. With the scream and everything. Even got a civilian death registered at the end of the mission. And this didn't just happen once, but on another separate occasion.

Hmm. shape-shifting reptilians in the game! LOL! Happens alot [[User:EsTeR|EsTeR]]

Unusually enough, I once had a sectopod die and then drop a tank corpse. I was using the Lightning at the time for my troop carrier, so you can imagine my surprise.

Then there was one occasion where a floater dropped a snakeman corpse. Let's not even get into the sort of things the aliens like to stuff themselves with.

Your invisible alien bug is quite common, although there appears to be many causes for it. I think one involves a full object table when it comes to invisible aliens in bases. But it can also happen in ordinary missions as well. I'm guessing the game may have tried to do something in the wrong order, and sprite information for the unit may have been lost or corrupted along the way.

Having had an experience where all the chryssalids become invisible in one base defence mission was quite a shocker. I fixed this by saving the game, quitting and then restarting the game. If you ever get an invisible alien again, try this and see if it helps. If it doesn't, well, just keep a careful watch on your map and any alerts that pop up as you play.

There's a similar but less severe bug where a dead alien will still leave its centre-on-unit alert button, but this goes away shortly after you move or turn.

- [[User:NKF|NKF]]

----

That last bug happens when exploding Cyberdiscs kill nearby Sectoids, doesn't it?--[[User:Trotsky|Trotsky]] 23:56, 2 July 2006 (PDT)

----

This is a pretty easy one. I guess this bug occured on UFO recovery on a battleship, an alien base assault or a base defense mission? As soon as there are too many items on the map, the game saves some item slots for the equipment to be displayed (since it is more valuable and more important to research). This would also make stun weapons lethal if the stunned aliens would vanish. therefore the game has a failsafe if an alien is stunned (or badly wounded and becoming uncontious). The downed alien's stun level is set exactly on its left health points therefore resurrecting it instantly. This cycle is broken when the alien is finally killed. This means if you want to stun an alien in such a situation you have to destroy some items first.

- by tequilachef (April 4th 2007)

== Vanishing snakemen ==

I've known snakemen to become invisible when standing on a hay bale. On the first occassion I had a poor tank getting shot while spending numerous turns looking for it. On the second occasion I had an alien under Psi-control, left it on the hay bale, and couldn't find it next turn. - Egor

---

This is not limited to snakemen. Hay bale block visibility quite much when a unit is standing on it. Two possible solutions:
- Destroy the hay before entering
- Shoot at the hay. If it is destroyed any unit on it will become visible (as long as no other bales are blocking the line of sight). You might also hit the enemy directly.

I Dnt know if the aliens are affected by this diminished sight, too. My guess would be no.

- By tequilachef (April 4th, 2007)

== Blaster Bomb Bug ==

I'm currently playing through X-com UFO Defense, I have the collectors edition version. I'm in the process of trying to catch a live alien commander and the blaster bomb bug is making this very difficult. If i remember correctly a commander is always in the command center of the the alien bases. The problem is anytime i get close there is always a dude with a blaster launcher up there that tries to kill my troops. When they try to fire it down at me the bug kicks in and they blow up the whole command room and all the aliens in it because they can't figure out how to get the blaster bomb down the grav lift thing in there. This is making it very dificult to actually catch a live commander. Anyone have any ideas for tactics or anything to breach that room without the aliens trying to fire a blaster launcher up there? - eL Hector

: I can suggest two possible solutions. The first is to wait outside the command room for the alien to move closer to you. If it comes out of the room or if you know it has moved down the lift, you then burst in and stand right next to it to stop it from firing the blaster. This is risky because there could very well be a heavy plasma toting alien in there. The other is to use a small launcher and launch it up at the ceiling near where you think the alien with the blaster is standing. -[[User:NKF|NKF]]

== Disappearing Ammunition ==

I have observed that problem with X-COM 1.2, modded with XCOMUTIL. My stun bombs and heavy rocket missiles, along with clips for the auto cannon went missing.
[[User:Vagabond|Vagabond]]

------

Just run a test using my 1.4 DOS version with XComUtil but my stun bombs didn't disappear: 30 + 1 back in the base they came from, same number after I went tactical and I dusted-off immediately. Are you running XComUtil with Runxcom.bat or did you simply run Xcusetup?

[[User:Hobbes|Hobbes]] 22:12, 22 February 2007 (PST)

:Is it a case of hitting the 80-item limit?--[[User:Ethereal Cereal|Ethereal Cereal]] 12:28, 23 February 2007 (PST)

------
With runxcomw.bat, as everytime. Apologies, I retested and it seems like I was mistakened, but I could have sworn that I lost them dang stunbombs. Had to manufacture some. I will test some more, using four heavy weapons and seeing whether their ammunition disappears at all. Thanks. [[User:Vagabond|Vagabond]]

==MC at end = MIA?==

I am sure I have seen this again recently, where I won a mission with no casualties (I thought), but the last thing I killed was a Commander that had been chain MC'ing a psi-attack-magnet trooper, and that trooper was listed as MIA at the end (presumably because he was on the enemy side at the end of combat). Is this a bug, or is there another way to get MIA's on a completed mission that I might have missed?

Since then I have been waiting for the leaders to panic at the end before killing them (or waiting for a rare resist), so I can safely exit, but am I being overcautious?

--[[User:Sfnhltb|Sfnhltb]] 13:45, 27 February 2007 (PST)

If the trooper was mind controlled on the turn you killed the last alien it will be listed as MIA. No bug there :)

[[User:Hobbes|Hobbes]] 18:16, 1 March 2007 (PST)

Huh, why would that happen - your soldier should recover the very next round, why would he go MIA?

--[[User:Sfnhltb|Sfnhltb]] 18:20, 1 March 2007 (PST)

Doesn't make sense to me as well but that's how the game works.

[[User:Hobbes|Hobbes]] 15:05, 2 March 2007 (PST)

----

It seems that regaining control of units under enemy mind control works different for alien and human players. My guess: aliens under human MC are reverted to alien control AFTER THE ALIEN AND BEFORE THE HUMAN TURN while human units under alien control are reverted RIGHT AT THE BEGINNING OF THE HUMAN TURN. This explains three different phenomenons:

- The discussed MIA "bug" (he unit would be returned in the next human turn, but since it never starts it is lost. The mission is still won since no unit with a "genuine alien" marking is left)

- The fact that a mission is lost when the last human falls under MC while it is not won when this happens to the last standing alien (the aliens get their unit back before their turn starts and therefore have a unit left to pass the "anyone alive?" check, the humans would have no unit left to start a turn with. They WOULD have as soon as the turn starts, but no unit left before turn means bust)

- The fact that aliens still can see all an MCed human saw at the end of the human turn that follows the MC while this is not vice versa (The MCed human can give information to the alien side before reverted while an MCed alien is reverted too early). The result is that aliens can control a human indefinitely without having any alien seeing him until the MC is disrupted for one turn.

All confused? Then I did a good job! No seriously, this must be the explanation, I couldn't think of any other way.

- By tequilachef (April 4th, 2007)

: You're absolutely correct on the first two points. It's a sequence issue - you never get round to recovering the unit before the new turn starts, so you end without any units whatsoever. Makes senses too since the aliens would continue to continue to mind control that same unit over and over indefinitely.

: The third point however: The aliens don't need to know the location of the last MC'd unit. They know the location of all your troops whether they've seen them or not from the very start. They appear to give you a few turns of grace where they won't attack you outright (unless, from my observation, all your soldiers are incredibly weak). This is evident because all of the aliens will eventually make their way towards the nearest soldier even though their movement pattern may seem semi-random. Also, they know where you are because they can initiate psionic attacks without having seen any of your troops. They generally go after the weakest troops first.

: Just to add a semi-related point, but from the alien's perspective. If an MC'd alien unit is in the exits when you abort the mission, this alien is not recovered and in fact simply vanishes. Any equipment it was carrying is recovered, unknown artefacts or otherwise. You could possibly think of this as their version of MIA. However, the aliens differ ever so slightly in that if it's the last alien standing and under temporary mind control by the player, the mission doesn't end straight away. But I guess this is only because the player has everything under control, whereas in the other scenario, the Ai is in control.

: -[[User:NKF|NKF]]

My observations show that, at least in some versions of the game (tested with clean DOS 1.4 version, under DOSBox), the game crashes at the end of the human turn if all alien units which are still alive, are Mind-Controlled. If it was confirmed, it would be another not-listed-yet (serious) bug.

[[User:Sherlock|Sherlock]] 17:52, 26 December 2012 (EST)

== Crash Site in the atlantic ocean ==

That's right, my game generated a crash site on water. Here are the details:

- Crash Site a bit southeast of the USA (which was infiltrated a few days before by sectoids, resulting base had already been taken out), but certainly not on land.

- UFO: battleship, floater, alien harvest

- Geoscape: 8 X-Com Bases, 1 (known) Alien base, 2 other crash sites, 1 other (known) flying UFO (though almost worldwide decoder coverage), 3 X-Com Crafts out, 1 waypoint

- Date: January 2000

- Most Interesting: The Craft that downed the ship was a recently finished Firestorm (first human-alien hybrid craft I had built, I know this is lame for that date. Limited myself on 25 Scientists to improve the challenge) equipped with twin plasma. I had it built and equipped in Antarctica and then transferred to Europe. This base had no Elerium, a fact that enabled me to use the infinite fuel exploit which was in effect when downing the UFO. My craft was only slightly damaged when doing so. The battleship was the first target assigned to the craft, it came directly from my base.

- When shot down, the UFO was not targetted by any other craft.

- I had not lost or sold a single craft to that point.

- When sending a squad to the crash site the game didn't crash but generated a farm land ground combat terrain.

- I was not able to reproduce the bug from the savegame dated 2 hours before downing the UFO

Well guys, any intelligent guesses? I still have the savegames (before and after downing)! If you want to have a look, write here.

- By tequilachef (April 5th 2007)
----
: Well I'm sure you know about crash sites that are near land can sometimes actually be on water, so I'm going to assume that this site is well far away from any land mass. Could it be a weird entry in GEODATA\WORLD.DAT that has a land mass out in the ocean? Also are you sure the game didn't crash? Sometimes when it does it will load the previous mission (and usually 90% are at farm terrain). Are you sure it generated a new map and not load the last one?
:No real guesses but maybe some starting points to look at. I've probably stated some obvious situations you know about and have accounted for, but it never hurts to double check :D
- [[User:Pi Masta|Pi Masta]] 14:23, 5 April 2007 (PDT)

== Inconsistencies in MCing Cyberdiscs and Sectopods ==

I experienced, that when MCing one quadrant of a large terror unit any action it does only affects this quadrant (especially use of time units). That means, when TUs are up for one part, MC another one and continue firing. This however does not work out when moving the unit while it is not under complete control. The TUs used up by the resulting reaction fire from the rest of the unit is also deducted from the TUs "your" part has left (making it impossible for the controlled parts to return fire). This however only happens under reaction fire, not if "your" part fires on it's own. I don't know if this comes up when uncontrolled parts shoot by themselves in the alien turn, since this is hard to find out.

: That's because large units literally are made up of four separate units. They only share the same set of general stats (in unitref.dat). Unfortunately the 'under mind control flag' is unique to the four units, not the shared stats! So you in effect have multiple units under different control sharing the same stats. So if you move and it results in a reaction from the unit, it will spend the TUs you're using.
: Successful mind control automatically fills up the unit's TUs, so each mind controlled sector gets to move or attack again until there are no more sectors to mind control. Useful way of turning reapers into long range scouts!
: In TFTD, they attempted to fix this bug, but in fact made it much-much worse! The only way to mind control the unit properly is to control the upper left quadrant. Only! Any other quadrant will result in a partial (clockwise) control, and you may gain control of units other than that unit, or may even get into situations where you gain permanent 'partial control' of a large unit you haven't even sited. Wackiness all around!

:- [[User:NKF|NKF]]

== Facility Dismantle Bug ==

Boba: I've never experienced this bug myself in all my games in the Collectors Edition. It may very well vary from computer to computer.

-[[User:NKF|NKF]]
:I, however, have experienced it. I lost an entire month's worth of playtime because I couldn't solve it. [[User:Arrow Quivershaft|Arrow Quivershaft]]

::Anyone, any ideas on why it might vary from PC to PC? -[[User:MikeTheRed|MikeTheRed]]

:::I'd check other factors before blaming a given system. Assuming no mods are being used the most obvious is the order in which you initiated the construction of the modules. Then we've got which one was due to be completed first, and I'm sure there's a few other things to test out. Usually, a player won't cancel in-progress modules on a regular basis, so you wouldn't expect this bug to turn up often. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

:Easy way to reproduce: build 2 General Stores. Now delete the "second one" (see offset 16-39 in [[BASE.DAT]] for the order). Wait for the first one to complete. It'll crash immediately after the "end of construction" dialog. A fix is available [[User:Seb76#Bug_Fixes | here]]. [[User:Seb76|Seb76]] 15:52, 22 July 2008 (PDT)

== Manufacturing Limit Bug ==

Unfortunately, Mike, no you did not get it correct. It is the raw number of hours needed to complete the project, not the projected hours. I discussed this on the X-Com Forums a few months back at the following link: http://www.xcomufo.com/forums/index.php?showtopic=242027760&st=0&#entry164411

I did tests at the time in regard to the accuracy of the data given there, but I've lost the results. I'll quickly redo the tests in the next hour or so. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:00, 8 June 2007 (PDT)

:Tests complete. The breakpoints for every item were exactly where I predicted, regardless of number of engineers assigned. (I ran up a huge queue of items at my dedicated factory base on an old game, and then assigned whatever engineers would fit onto one project at a time, canceling projects as data was confirmed. This is only semi-random, but it serves our purposes.) I did run into a single issue, though. It appears that despite having 5 empty hangars at a (different!) base, the workshop there could not queue up more than 3 of any one craft at a time, thus making this bug impossible to replicate with the Firestorm or Lightning, as you must be producing more than three for the bug to occur. However, it still works with the Avenger. Later, I shall see about constructing a dedicated Hangar base with 7 hangars in order to attempt to replicate the bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:33, 8 June 2007 (PDT)

::Sounds great, Arrow. Why not post a simple example that shows how the problem works. As in, "with 1 Eng and 2 Avengers you might think X, but no, it's Y". And please delete my example. And it's a fine pleasure to meet you! Cool - [[User:MikeTheRed|MikeTheRed]]

:::When you say the usual resources are used by the "lost" resources, that includes cash, right? It sounds like if you're willing to foot the extra bill [[Buying/Selling/Transferring#Manufacturable_Prices|money/component-wise]], this could be used to build Avengers slightly faster then normal.

::: The usual time is 34000 hours. Double that and subtract 65535 and you're left with a paltry 2465 hours. Even a single workshop squad of 10 engineers will pull that off in a little over ten days. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

::::Sadly, this exploit doesn't work, because the high bit is stored SOMEWHERE. I lack a hex reader and have no code reading skills to speak of, so I'm a bit limited here. If you set up a Workshop as you described, the game would take all the time for 2 Avengers, all the resources for the same, but in the end only produce 1 Avenger. Meanwhile, I'll run more tests on the resources thing. I could swear it consumes the resources, but I'll double check.

:::::There is no need to store the high bits if the actual completion condition (assuming adequate money) is "number made is number ordered", which wouldn't reference the hours remaining at all. - [[User:Zaimoni|Zaimoni]] 01:49, 9 Oct 2007 (CDT)

::::Tests done; I was unable to replicate the 'disappearing item' trick,(Which I didn't test for last night) even with Avengers! It appears I was wrong; this still counts as a bug, though, because the wraparound is a problem.

::::Ironic that so much of this discussion centers around Avengers, because that's where I discovered this in the first place! [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:48, 9 June 2007 (PDT)

----

I'm revisiting XCOM and was working on [[Manufacturing Profitability]]... Arrow, can you (or anyone else) say a little bit more on the Known Bugs page about this [[Known_Bugs#Manufacturing_Limit_Bug]]? It's not clear to me exactly what the bug does, except that it understates hours. Is that all?... does it still take the (non-buggy) amount of time, still use all the same resources, still make the same number, etc.? It sounds like it could be a drastic bug - or is it only a very superficial one, a display bug for the hours? It sounds like you're leaning toward this latter.

Also on a semi-related note... I could swear I saw much more detailed info on the [[Known_Bugs#Facility_Maintenance_Costs]] issue... IIRC, the incorrect amount that's charged for maintenance, depends on exactly where a facility is in the base. IOW, different "rows" of the base cost different amounts. Could somebody provide a link there, and/or flesh the bug out better?

Thanks! - [[User:MikeTheRed|MikeTheRed]] 11:22, 8 October 2007 (PDT)

:I've actually seen the bug work both ways, but I've only been able to actually replicate the more superficial version of the bug. So the bug report up is about a superficial bug that drastically understates production time. If you wish to make this clearer, you have my blessings. As well, that 'different charging based on location' is dealt with here: http://ufopaedia.org/index.php?title=Talk:Base_Facilities ; however, the table has been broken with the Wikiupgrade, and I lack sufficient knowledge of HTML table code to fix it. But it should be of use to you. [[User:Arrow Quivershaft|Arrow Quivershaft]] 11:26, 8 October 2007 (PDT)

::Cool, I fixed [[Talk:Base Facilities]] but also re-organized and expanded [[Base Facilities]] so that it includes that bug in detail, as per Talk... this is an important issue that should be up front. I see that there's a separate [[Maintenance costs]] page, but I can't see having something so important (the maintenance bug explanation) all on its own page (which makes for a rather short page) rather than together with all the rest of the base facility info. If others agree (or don't care), I'll move anything remaining on Maintenance Costs to the Base Facilities page, then delete Maintenance Costs and re-route links. And if somebody does care, then please move my new section to Maintenance Costs, and move all the links, etc. Oh also I put in more words on your Manufacturing Limit Bug - how does it look? - [[User:MikeTheRed|MikeTheRed]] 16:37, 8 October 2007 (PDT)

:Looks pretty good, although it'll wrap fully; if you ask for 120000 hours, it won't be displaying 'almost no' time. The way I discovered it was when building two Avengers; I ordered two, paid for two, waited for two...and got one. But as said, haven't managed to repeat it, so until I do, we'll leave it like that. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:00, 8 October 2007 (PDT)

::I just revised and put in your specific example, because it's certainly possible some of us die-hard players will order up more than 1 Avenger at a time - and it's guaranteed it'd be a pain if 1 of them disappeared, laugh. I wasn't sure how concrete you were on that example but now I hear you say, you are sure it happened at least once. - [[User:MikeTheRed|MikeTheRed]] 18:33, 8 October 2007 (PDT)

:I have a question concerning the manufacturing "bug" which eats a craft in production due to wrap-over of the byte. Arrow (or whoever did the test), did you have a large quantity of craft already built at your bases? If so, I think this bug has more to deal with clogging up [[CRAFT.DAT]]. See, that file has a limit of 50 entries. Each craft takes up one record and each base you have built also consumes one spot. 8 bases allows 42 craft to be housed, while 6 bases allow 44. If you try to buy or manufacture craft once the file is full, nothing shows up in the game even if you have hangar space available. --[[User:Zombie|Zombie]] 19:00, 8 October 2007 (PDT)

::Huh, I never knew that. I don't see it listed on the Bugs page... I'll stick it in there. I've never approached that number, but some folks might. - [[User:MikeTheRed|MikeTheRed]] 19:07, 8 October 2007 (PDT)

:I was able to continue building other Avengers after that project, and they appeared correctly, so I do not believe that is the issue. In any event, I have a very bad case of 'archivism' and probably still have the save game and the CRAFT.DAT file around on my system; in fact, I think I was playing it a few days ago. I can see if I can find it and upload it; it created a 'hole' in the Avenger fleet numbers, where Avenger's x and x+2 were built, but x+1 was not. I'll look for it tonight and tomorrow and upload it to the wiki if I find it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:10, 8 October 2007 (PDT) EDIT: I found the file; I have 28 Avengers and 1 Skyranger in my employ. All Avenger numbers EXCEPT #2(Avenger-2) are accounted for, and I have not sacked or lost any Avengers. So this is where the hole and 'eaten' Avenger is. If anyone wants the CRAFT.DAT file from this game, I'd be happy to forward it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:20, 8 October 2007 (PDT)

::Sure, send it my way and I'll take a look at it. (Might as well send me the whole saved game as I may want to look at the other files too). I have tried to recreate this bug by manufacturing 1, 2 and 3 Avengers at a clip but all of them always show up. Don't know what else I could do to get this problem to crop up. --[[User:Zombie|Zombie]] 21:32, 8 October 2007 (PDT)

:File emailed. On the side, I've tried the same thing, and never been able to repeat the bug. It's been months since the first discovery, so I can't recall whether it was the first or the second Avenger that didn't appear. So maybe it was just a fluke. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:57, 8 October 2007 (PDT)

== Unconscious Enemy in Equipment Screen ==

The following happened to me repeatedly over the last few days.

In the last tactical Mission a live alien has been captured. When now beginning an UFO crash recovery mission this type of alien (same race and rank) appears in the equipment screen before the mission starts, meaning I can give it to any of my soldiers.
If I do so I can store the alien in the skyranger for the duration of the mission and, if it gains consciousness, kill or stun it at the end of it. A pile of equipment without a corpse will be in the UFO, indicating that the stunned alien is not some kind of duplicate but instead has been taken from the aliens of this mission. This is supported by the fact that in those missions the maximum number of crew members has not been surpassed.
If I do not do so the Alien will be placed in the crashed UFO. Whether it is unconscious or not I do not know, but the fact that it is completely disarmed when encountered in the battle suggests that it is.

So far it seems the following is necessary for the bug to occur:
# An alien has to be captured alive in the last tactical combat
# It has to be of the same race and rank as one of the aliens in the new tactical combat

So far this only worked...:
# If the new tactical combat was an UFO crash recovery of a medium scout.
# For floaters and mutons
# For soldiers and navigators
# If the alien in the last mission was stunned by normal weapon fire (although I do not think this is important) and not picked up (again, not likely to be important) or destroyed (which would mean it has to be actually captured)

It seems NOT to depend on the following:
# The type of the last mission (were, so far: Ground assault battleship, crash recovery large scout, base defense)
# Which squad or vessel was involved capturing the alien
# Where it is locked up
# If it has been transferred since capture or not

Would be interesting to know:
# What happens if the alien in the inventory screen is the only survivor
# If the alien in the invenory screen is one of the aliens randomly killed in the crash or not (it is likely to be one of the killed aliens, so far the equipment piles were always within the UFO)
# If this is not limited on crashed medium scouts: Does this work with terror units? What about large ones?

Maybe this is related to the proximity grenade bug (transfer of item properties to next tactical combat).

Additionally, in one of those mission a part of the terrain was not generated correctly. It was in farm terrain (The house on the right square, or north east square, in [[Image:Terrain-cult.gif|this pic]]). The outer wall right to the right window of the southern wall (1st Floor) was missing. Directly outside of the hole was a floor tile. I could walk a soldier through the wall, but he fell right through the tile. Dunno if this has to do with the stunned alien bug.

Version is collectors edition (the one from abandonia.com).

----------------

When a mission starts, the GeoScape engine generates the unit and object tables (in MissDat's [[OBPOSREF.DAT]], [[UNIPOS.DAT]], and [[UNIREF.DAT]]) before "shutting down". The Tactical engine then generates the maps, places the aliens on it, and blows up the UFO (if need be). Whether or not map generation and the subsequent events happen before you equip your soldiers I don't yet know.

The test would be to check the aforementioned files to see if they contain an unconcious alien, and/or the body.

Note that you can't see the bodies of large units on the ground (they count as four seperate objects covering four seperate tiles, so allowing the user to pick one up would essentially let you rip them apart).

- [[User:Bomb Bloke|Bomb Bloke]] 06:35, 5 August 2007 (PDT)

----------------

I honestly have no idea of how all those files work. But I still have a savegame in battlescape that is in one of those missions. So if anyone wants to have a look at those files...

I forgot to mention: I reloaded a geoscape savegame shortly before the battle to recreate the bug, but it seems that reloading in geoscape before the buggy battle eliminates the bug. I guess his should narrow down the possible reasons...

--------

Next time it happens, backup the aforementioned files before you start another mission. I'm afraid a savegame wouldn't be of much help.

- [[User:Bomb Bloke|Bomb Bloke]] 00:54, 7 August 2007 (PDT)

== Soldiers moved to outside of combat screen ==

Hi, I've got a DOS version of UFO:EU, and I've encountered a bug in the tactical combat. Sometimes (rarely) a X-COM soldier changes its location on the map on player's turn start and is placed on outside of the map, one tile north from the (north) border of the field. AFAIR the unit is then selectable (you get the flashing highlight when cursor is above), but is stuck outside of the field. Has anybody encountered this bug? It seems to happen randomly, but more frequently during the terror missions and on early turns (so maybe it's caused by high number of player/alien/civilian units?). --[[User:Maquina|Maquina]] 08:16, 3 September 2007 (PDT)

:I've never encountered this bug in CE of UFO. Presuming AFAIR means "As Far As I Recall," what exactly was the soldier doing? Any equipment data, location, or stat info might help us pin it down. Were afflicted soldiers always carrying a specific equipment set or weapon? Where were they on the map before they got moved? Did they get bumped a few spaces, or teleported halfway across the Battlescape? Does it happen more often on a specific difficulty?(Your theory would suggest this would happen most commonly on Superhuman) Against a certain type of alien? Best of all, if you can recreate the situation in a game, save the game and then you could upload the save file to the forums or this wiki, and the rest of us could take a look for ourselves and the code divers could root around for the cause. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:03, 3 September 2007 (PDT)

:: I've had this happen to me several times in UFO and TFTD. I don't know if it's specific to the Dos version or if it can happen in the CE as well. Sometimes the soldier ends up beyond the boundary of the map right at the start of the mission, at other times it happens after you load a game. This game is glitchy, which is the source for so many of its bugs, so your soldier's coordinates are probably getting corrupted to the point where they are -1 on either the X or Y axis of the maps's normal boundaries. For me it's commonly along the top edge of the map. I don't ever recall it happening mid-mission, only at the start or after a load. I cannot faithfully say whether it happened with or without XComutil, but that could be one of the possibly many causes for this. - [[User:NKF|NKF]]

:: I don't play UFO often, so I rely on just several campaigns played. This happens rarely (I've encountered this bug twice in my last campaign with ~80 missions played), but if you haven't seen this happen then it probably doesn't show up in the CE edition. In my experience the soldier is moved always beyond the north/top map border. I think (but I'm not sure) that this affects the first soldier from the team more commonly than others (or maybe even exclusevily?). The equipment/armor carried is probably not relevant, since the units moved this way don't have any special stuff, and this bug shows up on different stages of the gameplay (ie. sometimes when you have ordinary rifles, sometimes when all your units got heavy plasmas and power suits). --[[User:Maquina|Maquina]] 04:12, 4 September 2007 (PDT)

'''MY ramblings have been moved to my discussion page''' [[User:EsTeR|EsTeR]]

==Great Circle Route==

Should we have the Great Circle Route bug noted on this page at all? [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:33, 6 October 2007 (PDT)

: what is the great circle route? [[User:Jasonred|Jasonred]] 07:56, 31 March 2009 (EDT)

:: Pick two points on a globe, then hold a thread or string taut at those two points. That practically minimizes the length of the thread/string on the globe. You're now looking at a great circle arc (or route), the shortest distance between two points on a globe. -- [[User:Zaimoni|Zaimoni]] 11:15 March 2009 (CDT)

: Just as a line is the shortest distance between 2 points on a flat plane, a great circle is the shortest distance between 2 points on the surface of a sphere. The bug, by the way, is that aircraft in the game ''don't'' follow this shortest, "great circle" route. [[User:Spike|Spike]] 12:38, 31 March 2009 (EDT)

:: What a grand sounding name, for something so simple, lol. ... I thought you were talking about when you tell your soldiers to go from point A to point B, and for some reason they figure that Zone A and Zone B are really far apart, despite actually being side by side. (I shot a hole through a wall, clicked to walk to the other side, and my idiot soldier walked one big circle... to use the door! And got ambushed and killed by an alien. ... dum dum DUMB DUMB.)
:: Even the more modern games have problems with their pathfinding algorythms. Admittedly, games like Baldur's Gate had to do it in realtime.
:: On a semi-related note, I remember this guy called E-man, he was chasing a guided laser beam that was going to kill his girl, around the world, but he couldn't outrun it since he couldn't break the speed of light, only equal it by changing into a Laser himself. So... inspiration! He turned into a very powerful laser, and made a shortcut THROUGH THE EARTH... the straight line beats the great circle route, lol.
:: Thanks for the reply guys [[User:Jasonred|Jasonred]] 15:56, 31 March 2009 (EDT)

Added to article. [[User:Spike|Spike]] 16:41, 3 September 2012 (EDT)

==Bug not listed: Missing soldiers during base defense==

I encountered an interesting bug concerning base defense missions:
My base got attacked while about 30 soldiers and 10 HWPs were present. The usual equipment assignment screen was skipped and the mission started instantly with only the HWPs spawned at the map. Not even a single soldier bothered to show up... *sigh*
Although this turned out to be in my favor (you should have seen the puzzled Ethereals trying to panic my tanks) I´d like to avoid this bug if possible. I was able to reproduce this bug several times and with different bases.
Can anyone explain this bug and/or tell me how to avoid it?

Game version: Collectors edition. - [[User:NewJoker|NewJoker]]

-----

Well, ideally, we need to know what your base's construction was to be sure of this, but I think the most likely circumstance is that the HWPs took up all the spawn points. HWPs have maximum priority for spawning(followed by Soldiers, and then Aliens), so if you have enough of them garrisoning a base, it's entirely possible that soldiers and aliens won't spawn. However, this doesn't explain why the soldiers didn't start stealing the Alien spawn points...in any event, you might want to take the save game file, zip it up, and get ready to email it. I'm sure [[User:Zombie|Zombie]] would be quite interested. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:28, 13 November 2007 (PST)

-----

It's not the spawn points, it's a [[UNITPOS.DAT]] limitation. A maximum of forty records (out of the total of eighty) are allocated for your units, and tanks (which take up four records each) get first pick. Having ten tanks means there's no room left for anything else.

Ditch one HWP and you should see four units take it's place. - [[User:Bomb Bloke|Bomb Bloke]] 16:42, 13 November 2007 (PST)

-----

I´ll try with a decreasing number of tanks and report the results. As I wrote above having only HWPs isn´t too bad dependent on what enemy is attacking. [[User:NewJoker|NewJoker]]

----

This should be mentioned in the [[ExploitsE#Base Defence Mission Spawning Issues]] section. The Bugs/Exploits really need to be sorted and consolidated. - [[User:NinthRank|NinthRank]] 16:57, 13 November 2007 (PST)

-----

The limitation to 40 records seems to be the case; each tank I dumped got replaced by four soldiers.
So this can be used to effectively manage unit combination. Thanks for the quick replies! [[User:NewJoker|NewJoker]]

==Bug not listed: Ufo Gold (Windows Vers. abandonia.com) crashing when plasma defense is finished==

I recordnized this bug a few times now. (with hacked AND unhacked game)
If i place a plasma defense in 7 bases at the same Time and they are finished at the same Time, the game crashes sometimes.
In hacked game, it seems to crash even more when Alien containment is finished, plasma defense, shield defense...etc.
couldnt find it here...greetz

: I somehow doubt the sourcing is the issue. [You may want to fund the next XCOM series game with a Take2 re-release of UFO :)] More generally: the game only reports the construction of a given type of facility once, no matter how many bases it completes at simultaneously. I've only tested this in vivo with three-of-a-kind at once across six bases, however. It does seem reasonable that some sort of counter of undisplayed completions would "overflow" (attaining crash). -- [[User:Zaimoni|Zaimoni]] 10:05, Feb. 28 2008 CST

::I've encountered this bug myself with General Stores, actually, not just Plasma Defense(which I never build). EDIT: Some quick tests seem to show that there's a chance the game will crash any time two base facilities are done at the same time, regardless of whether they're in the same base or not or if they're the same facility.(although it seems to happen MUCH more in the event they're in different bases.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:13, 28 February 2008 (PST)

== Soldier Recruiting Bugs Tested ==

Just to note that I have positively tested and replicated the bugs listed under the new(ish) section [[Known Bugs#Soldier Recruiting Bugs|Soldier Recruiting Bugs]]. [[User:Spike|Spike]] 18:08, 19 March 2008 (PDT)

==Floater Medic Bug==

I have not thus far encountered the Floater Medic Bug; in fact, Floater Medics are often used to fill up my Rogue Gallery with interrogations. [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:50, 24 April 2008 (PDT)

Strange, it would always occur in my version. I don't remember where I got it from, but I
know it was a download from the internet. Using the XCom Hack v2.5, I viewed the alien in
the Alien Containment edit. I now have Type (race):____, and a Rank: Soldier for the
Floater Medic. It might just be corruption, but I do not have the resources to look into
it. [[User:Muton commander|Muton commander]] 19:24, 12 May 2008 (Pacific Time Zone)

I've never encountered it either. [[User:Magic9mushroom|Magic9mushroom]] 07:47, 23 July 2009 (EDT)

I think this only happens in the CE version. A disassembly of the code reveals that the stack to hold the matrix for what topics have not yet been researched is too short. It seems that those who ported the code from DOS doubled the local variable sizes blindly. There is already a problem that there are two-few bytes necessary for the entire alien organism section of the UFOpaedia, but double the expected size of the registers and it fills up quite easily unless a lot of autopsies and interrorgations have already been done. The only other situations that are handled by the same routine are the navigator revealing mission data or engineers revealing ship data, but there isn't enough topics in either section to overflow the stack variables. - [[User:Morgan525|Tycho]] 08:27, 22 June 2013 (EDT)

==Strength Overflow==

During one of my games with TFTD I noticed a really annoying thing happen during battles.
As my troops rose up the 'stat.' ladder they got better and better (as you'd expect), until they hit about 50 strentgh and completely lost the ability to throw anything.
Even trying to throw something tiny like a grenade or flare into the adjacent tile resulted in the 'Out of Range' message being displayed.

Anyone come across this before?
This was in TFTD CE.
[[User:Tifi|Tifi]] 07:55, 27 April 2008 (PDT)

:This is fairly well documented. The pathfinding algorithm for throwing objects will balk if anything is in the way of the throw and refuse to allow you to throw. What's happening is that your soldiers have become so strong that their throws are intercepting the 'ceiling' of the Battlescape(the top of L3), and as such the game thinks that the throw is blocked(because in order for the throw to complete, the object would have to be tossed up to the nonexistant L4). There's two ways around this:

:The Normal Way: Try shorter throws, throwing from lower heights, or throwing while kneeling. Beyond that, possibly get some new troops.

:The Sneaky Way: Manually edit the Strength scores of your soldiers in [[SOLDIER.DAT]] so that they're back to a usable strength level. If you set "Initial Strength" (offset 46 decimal or 2E hex) to 0 and "Strength Improvement" (offset 57 decimal or 39 hex) to a value of 50, you can permanently lock the soldiers at 50 strength. (You can lock them higher than that if you so choose, but not lower.

:Other than this, there's no workarounds I can think of offhand. [[User:Arrow Quivershaft|Arrow Quivershaft]] 08:10, 27 April 2008 (PDT)

:: There's normally no problem with the max level of 70 in open settings. However TFTD has a lot of low ceilings such as in the shipping lane missions and colonies, and the lower ceilings impairs your throwing quite a bit. In addition to shorter throws/kneeling, try moving out from under any overhangs if there is one just above you. - [[User:NKF|NKF]] 12:33, 27 April 2008 (PDT)

== Bug not listed: Sticking your head through the ceiling ==
This is something I just discovered: When you step on a small object inside of a building your soldier sticks his/her head through the ceiling and can see what's upstairs. You can even see the soldiers head coming out of the floor and that soldiers can shoot aliens upstairs. When I did this the alien I saw/shot was facing the other way, but I guess you could get shot if the alien was facing you. [[User:RedNifre|RedNifre]] 17:34, 11 May 2008 (PDT)

:That's not listed under "Bugs" because it's covered under "Exploits", right here: [[Exploiting_Collison_Detection#See_Through_A_Ceiling]] [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:26, 11 May 2008 (PDT)

:: I don't know if it was ever covered anywhere, but there's this neat trick that might sound similar to the walk-through-'wall object'-wall trick except that it involves your unit climbing slopes. They'll appear as though they've gone up a level, but are actually not on that level. They only visually appear to be there, but are really still on the bottom level.

:: It happens a lot when walking up the desert or forest slopes. I think the trick involves standing on ground level, and then ordering the unit to 'move' into the hill rather than setting the waypoint while on level 1. The soldier will move up the slope and perhaps stop on the slope or even reach the top of the slope, but will still appear when you're only viewing the ground map layer. The soldier is really still on the ground level, but will have elevation offset.

:: One really interesting way of using this trick is in the mountain region. If you can find a cliff face and a low hill nearby, you can literally have your soldier scale the cliff by standing the soldier on the hill, and then walking towards the cliff. It's ridiculous, but your soldier never quite reaches the top of the cliff tiles, so ends up walking up a slope.

:: On a side note, standing at the top of the ramp of the Skyranger is the same as standing on ground level - you're only offset a bit. This means that smoke on level 1 and the sides of the Skyranger will not provide protection when you're at the top of the ramp.

:: On another related note in relation: In TFTD (doesn't happen a lot in UFO), you might find it difficult to toss grenades onto underwater slopes. To remedy this, raise the level up by one. It might look like you're tossing at air(and you are), but it'll get the grenade where you want it. Odd, but true. I must remember to put this in the grenade explanation section. -[[User:NKF|NKF]] 23:11, 11 May 2008 (PDT)

== Base Defence bug that causes a crash? ==

Does anyone know about a bug in a base defence mission that causes the game to crash? The game keeps crashing on the 4th or 5th alien turn.

:I've encountered that myself, but it should be noted that overall, X-COM is not the most stable game and is prone to crashing often at anytime. The differences between the hardware it was designed for and the hardware we're running it on cannot be helping matters at all; it's really a small miracle it even runs without an emulator in the first place(I've got games from 1999 that will bluescreen my machine instantly). As such, I'm not sure it's worth noting as a bug, since it's a 'game feature'(albeit a detrimental one). In any case, what're you doing letting the aliens attack you anyways? ;) [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:33, 18 July 2008 (PDT)

:It sounds like an alien is in one of the outlying locations and attempting to destroy the top floor item. Possibly a radar or defense station. - [[User:Morgan525|Tycho]]

== Sources for a DOS4GW transplant ==

I was specifically thinking of the LucasArts Dark Forces demo, but I half-recall the actual source I used when testing that ~1999 was Id's DOOM. -- [[User:Zaimoni|Zaimoni]] 16:03, 7 August 2008 (CDT)

== Phantom Carried Casualty ==

You are carrying an unconscious soldier in one hand, and the soldier dies of his/her wounds. The dead soldier remains visible on the "left hand / right hand object" battlescape display, but is no longer visible in the inventory display. The problem can be fixed by moving another object into the same hand.

I've seen this bug with UFO Extender by [[User:Seb76|Seb76]] - possibly might be something to do with his manipulation of the inventory screen, rather than a general bug. I believe I've also seen this with other objects that were being carried in the hands, disappearing from the Inventory screen, but I'm not sure. I don't think it's an item limit bug, as XcomUtil shows 40 item slots free. [[User:Spike|Spike]] 08:58, 21 September 2008 (PDT)

:I think it has to do with the KO units KIA mod. Its doesn't take into account units held so when it tries to detemine where to place the corpse, there is no location. The routine doesn't undo the item-carried-sprite-ID byte for the holder. -[[User:Morgan525|Tycho]]

== Civilians As Enemies to MC'd Aliens ==

I ran across this issue a few times and just wondered if you guys experienced this. I MC'd a part of a Reaper (I always do the lower left for large aliens) on a Terror Site, then moved it a few squares. It suddenly stopped dead in it's tracks and then the alien spotted indicator increased by 1. When I clicked on the indicator to see where the enemy unit was, it brought me to L2 of the large apartment complex. However, nothing was there. When I sent a Flying-Suited soldier up there to peek in the window (eeek! A peeping tom!) he saw a female civilian standing there. This type of problem has happened numerous times to me so it's not a once-off thing. Maybe it's a LOS issue? Or maybe an alien indicator problem? Or a combination of the two? Don't know, but I'm curious if you guys have seen it. --[[User:Zombie|Zombie]] 23:40, 19 December 2008 (CST)

:There are a lot of major issues with MC'ing 4 square aliens. One of them being that you could accidentally MC an alien far off in the corner of the map, IIRC? Anyhow, maybe you should have tried MC'ing all 4 squares of the reaper and see if that changed things. -[[User:Jasonred|Jasonred]]

The long-range MC of other aliens when Mind-Controlling large aliens is only present in Terror From The Deep, due to a workaround to try and resolve the earlier bugs(and exploits) associated with controlling one square of a large unit at the time. In TFTD, successfully MC'ing part of a Large unit will also grant you control of the next three units in UNITPOS.DAT, in order. If you didn't MC the upper left portion of the large unit(the first UNITPOS entry for any large unit), you can potentially wind up in control of other aliens. So this doesn't apply to UFO. As for Zombie's issue, never seen it. And finally...Jasonred, on Talk pages, please indent your statement with colons so it differentiates from other people's comments, and sign your posts with 4 ~'s, like I will now do. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==Elerium Base Bug==

Jasonred: This bug has long since been known about. Elerium units on the Battlescape can be picked up by shooting away the power source; this one item counts as 50 units, and as such ANY elerium item spawned on any Battlescape counts as 50 Elerium. This issue with your own Elerium spawning as collectable loot in a Base Defense mission only occurs in older DOS versions, and is at the whim of the 80 item limit. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:55, 18 February 2009 (CST)

:Base defense does not seem to follow the 80 item limit in that DOS version. There are a lot of bugs that have long been known about. However this one was not included in the ufopedia for some reason.
:Also, the main thing about this bug is that it does not potentially double your elerium stores. It potentially multiplies them 50 times.
:... First time this happened to me, I was pretty flabbergasted. Here I was being conservative with my limited Elerium, refraining from blowing up UFOs when possible, when I perform a base defense and gain 3000 Elerium from it. Holy spit. -[[User:Jasonred|Jasonred]]

Alright, my error. Thanks for clarifying. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==HWP Fusion Bomb and SWS PWT Displacer Ammo Manufacturing Cost Bug==

At a cost of $15000, 400 Tech hours, 5 Zrbite, and 8 Aqua Plastics, this is the exact same cost as the HWP Fusion Bomb from X-COM EU, converted over to the equivalent TFTD resources. As such, it shouldn't be counted as a bug, since it is clearly what Mythos intended. [[User:Arrow Quivershaft|Arrow Quivershaft]] 09:55, 15 November 2008 (CST)

:Hmm, in that case maybe it should be treated as a generic game engine issue and not a TFTD specific issue - but I still think it's a design error. Can you think of any logical reason why the SWS/HWP version of the ammo should be more expensive (in cost and in materials) than both the craft ammo and the (more powerful) personal ammo? It makes no logical sense. Hence I think it's a design error. Nothing can be inferred from the fact it's unchanged from XCOM-EU, that doesn't imply any deliberate decision. It could just be the replication of an original error in XCOM-EU. [[User:Spike|Spike]] 11:17, 15 November 2008 (CST)

:: I can think of a logical reason to justify this: X-Com doesn't understand the technology as well as the aliens do (which is obvious, given the length of time each side has known the tech). Handheld Blaster/Blaster Bombs are just a copy of the alien design and therefor relatively cheap and efficient, but that can't be mounted on a turret. So X-Com has to make a new design, and they obviously didn't do that good a job as the aliens would have done. This explains Tank/Plasma being weaker than Heavy Plasma too. (Why is FBL Craft ammo cheaper than the tank ammo though? Maybe X-Com gave up on/simplified the guidance system and made it just a "dumb" cannon shell/torpedo instead which doesn't have multiple waypoints? Or maybe they just did a better job there?). [[User:Cesium|Cesium]] 04:07, 25 November 2009 (EST)

:Whilst we discuss it, I'll park my original text in here:

* ''Displacer/PWT ammo cost bug - at over $100,000 total cost per round, the ammunition for this SWS weapon is far more expensive to manufacture (both in money and rare materials) than the equivalent ammo for the Aquanaut-carried Disruptor Pulse Launcher, or the craft-based Pulse Wave Torpedo, despite being less powerful than either. This would seem to be a design mistake.''

See Also [[Talk:Displacer/PWT]]

:: I don't like the higher cost either, but I think it's a tradeoff of expense and quality for the convenience of portability. Sort of like an MP3 player to the gramophone... or maybe that's not a good comparison. -[[User:NKF|NKF]] 13:43, 15 November 2008 (CST)

A better comparison might be a desktop computer to a laptop. As a general rule, laptops are more expensive, but a similarly priced desktop gives you more power. Desktops are cheaper and offer power, laptops are more expensive and offer portability(though the gap is rapidly narrowing). [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:49, 15 November 2008 (CST)

:I think those are good analogies. But they don't apply in this case. To continue your analogies: We are paying mainframe prices for a clunky desktop that has only laptop processing power, and we're buying a mainframe for desktop prices. The vehicle version ("desktop") - is ''less'' portable and ''less'' powerful than the personal version (DPL = "laptop"), ''less'' capable than the craft version ("mainframe") - 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 SWS use up ''more'' of both Zrbite and Aqua Plastics than the Craft version. Do we really think it's logical that a tactical battlefield round, less powerful than its man-carried equivalent, takes more explosive and structural material to produce than both the more powerful man-carried version and also more than the air-to-air round that has 60km range and can take down a major alien combat craft? There is a clearly perverse bang-per-buck here, on every measure. My sincere belief is that this was an original mistake in the XCOM-EU engine that got copied into TFTD as well. The craft round should have the higher base price, but 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. But what I don't think is debatable is that is not logical for the SWS/HWP rounds to be more expensive than the craft rounds. It's clearly a mistake. Even in game balance terms, the only thing the HWP/SWS rounds have going for them is conserving "80-Item Limit" space, which I severely doubt was ever a game design consideration since it's just an awkward programming compromise. Any advantage inherent in the HWP/SWS is already reflected in the very high platform cost - there is no need to inflate the ammo costs as well. The bottom line is that a round for a (mini-)tank does not cost more, does not use more materials, than the same type of round for a long range anti-aircraft weapon that has much greater damage capacity and penetrating capacity. [[User:Spike|Spike]] 14:35, 15 November 2008 (CST)

I'm going to add this to the bug list now. [[User:Spike|Spike]] 16:06, 25 February 2009 (CST)

:Still don't think this is a bug though. Just because it's more expensive to manufacture than the hand-held or craft-mounted ammo, it doesn't mean the stats are wrong. Perhaps the programmers wanted to balance the tactical portion of the game a little more by making the ammo cost more for tanks. It doesn't have to be logical to be intended. Now if you had proof which said that the ammo was supposed to cost less but the stats were wrong, then yes, I'd agree. So if you boil it all down it comes to a disparate logic issue, not a bug.--[[User:Zombie|Zombie]] 21:31, 25 February 2009 (CST)

::I have to side with Zombie here. While the ammo may be disproportionately expensive, by the definition used on the rest of the page for bug, it doesn't fit. All the other bugs are errors in program logic or function or routines that are unintentional problems with the game, most of which are not warned of ahead of time. The ammo for the tank costs exactly what is listed and operates entirely as intended, whereas the rest of the bugs are not intended game features. Even if the numbers were entered wrong, that would be a data entry error, not a program bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:28, 26 February 2009 (CST)

:If it was a data entry error, I'd consider that a type of bug... assuming we had proof of the goof so to speak. LOL. --[[User:Zombie|Zombie]] 00:49, 26 February 2009 (CST)

:: It feels too specific an entry to be a data entry error.

:: I'm reminded of the high explosive. I know, I know - it's not an exact parallel to the FBL issue. A High Explosive is practically two grenades. Double weight, double bulk. Slightly above two times the damage. However, it costs five times the price of a standard grenade. Even though you're paying more for not-as-much, I don't think that could be considered a bug. A rip off, yes, but not a bug.

:: Here's a thought: Think about the immediate benefits each of the two controversial ammo types give back to you. Aircraft ammo = activity points. Tank ammo = loot. Yes, I know that aircraft ammo also generate crash sites, but you still have the ground combat to contend with.

:: One other thought: With careful management of your ammo, you'll probably never spend any elerium on the handheld version's ammo. Could it be the handheld that's really at issue here rather than the others? In the end I feel that it doesn't really matter. -[[User:NKF|NKF]] 03:38, 26 February 2009 (CST)

: I'm with Zombie that a data entry error is a bug (we have other examples), but also agree some proof is probably needed. And I agree with NKF that in the scheme of things, it doesn't really matter much. I don't think the HE pack is a good comparison (though the HE pack should be heavier) as it's reasonable to pay disprortionately more to get additional power at the same tech level. The fusion weapons are a case of paying more to actually get ''less'' power. I am not bothered by the handheld vs vehicle balance, not least because the game generally makes handheld weapons better than their vehicle equivalents, so I can accept that as an across-the-board design decision.

: I can also see a game balance argument ''if'' we believe that Fusion Tank ammo is more of an overall game-winning weapon than craft Fusion Bombs. But I'm not sure I agree with that statement. And even if it's true, and there's a game balance argument (in which case it would apply equally to handheld Fusion launchers), it's still illogical. The less powerful, battlefield warhead should not cost massively more in exotic materials than the much more powerful air to air warhead that brings down Battleships. I agree though that just because it's illogical does not prove it's a bug (i.e. unintended). [[User:Spike|Spike]] 07:48, 26 February 2009 (CST)

Ok we more or less seem to be in agreement that this isn't a bug, but it is very confusing/illogical. Maybe we can shift the "bug" text from the article page and roll that into the [[Hovertank/Launcher]] and [[Displacer /P. W. T.]] pages now. Feel free to combine any text from the discussion above if necessary. --[[User:Zombie|Zombie]] 09:22, 26 February 2009 (CST)

: Unless we can ''prove'' it's a data entry error (unlikely), how about calling it an "Anomaly" instead of a bug? [[User:Spike|Spike]] 10:59, 26 February 2009 (CST)

Looks like plain old game imbalance to me.
The way I see it, Hovertank Plasma and Launcher were meant to be stronger. Much much stronger. Let's look at Tank Cannon, Launcher and Laser. The logic is that it's a tank mounted weapon, so the tank can carry a much larger and more powerful version of the same weapon, right?
It's pretty stupid that a Hovertank Plasma is weaker than the Heavy Plasma... you could just mount a Heavy Plasma on a Hovertank and get them exactly equal. In fact, I suspect that the hovertanks were ALSO meant to have more powerful weapons than the man-portable versions.
Unfortunatly, the game designers then realised that this made the hovertanks far too powerful. So... the programmers nerfed the power of the hovertank weapons. BUT they forgot to lower the ammo costs. [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 11:20, 26 February 2009 (CST)

: Well you are opening up a much larger issue there. The Fusion weapons are an anomaly, an inconsistency. But handheld weapons are more powerful than equivalent vehicle weapons across the board, consistently. So that looks like a deliberate design decision, not a mistake. [[User:Spike|Spike]] 17:33, 26 February 2009 (CST)

:: There are two exceptions to the rule: Tank/Cannon: 60AP vs. Heavy Cannon 56AP. Tank/Laser: 110 Laser vs. Heavy Laser: 85 Laser. The hovertank\plasma only differs by a measly 5 (an extra 0 - 10 damage, which means a lot vs. UFO inner hull armour). I guess the trend here was to moderate the area effect tank strengths. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

I'd have to agree with you there Spike. This wasn't a mistake, however odd it may seem. It was a deliberate attempt to try and balance the game. Below is a table I created ages ago for my (now defunct) strategy guide detailing the HWP's and what handheld weapon corresponds to it. When you stick them side-by-side, it really becomes apparent that the programmers were trying to base the HWP weapons off the handheld weapons somewhat. The only thing that doesn't follow a nice and distinct scheme is the damage. That's what is the clincher. --[[User:Zombie|Zombie]] 20:26, 26 February 2009 (CST)
 
<table {{StdCenterTable}} class="sortable">
<tr {{StdDescTable_Heading}}><th align="left" width="150">Tank Type</th><th width="70">DAM</th><th width="80">Snap</th><th width="90">Aimed</th><th width="90">Aimed</th><th width="80">Snap</th><th width="70">DAM</th><th align="right" width="140">Handheld</th></tr>
<tr><th align="left">Tank/Cannon</th><td>60</td><td>60%</td><td>90%</td><td>90%</td><td>60%</td><td>561</td><th align="right">Heavy Cannon</th></tr>
<tr><th align="left">Rocket Launcher</th><td>85</td><td>55%</td><td>115%</td><td>115%</td><td>55%</td><td>87.52</td><th align="right">Rocket Launcher</th></tr>
<tr><th align="left">Laser Cannon</th><td>110</td><td>50%</td><td>85%</td><td>84%</td><td>50%</td><td>85</td><th align="right">Heavy Laser</th></tr>
<tr><th align="left">Hovertank/Plasma</th><td>110</td><td>85%</td><td>100%</td><td>100%</td><td>86%</td><td>80</td><th align="right">Plasma Rifle</th></tr>
<tr><th align="left">Hovertank/Launch</th><td>140</td><td>--%</td><td>120%</td><td>120%</td><td>--%</td><td>200</td><th align="right">Blaster Launcher</th></tr>
</table>
1AP rounds. 
2Average between the Small and Large Rocket.

: Hold up! Tank rounds do 60AP. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

So what's wrong? The table says 60 for the Tank/Cannon and 56 for HC-AP. Those are correct, no? --[[User:Zombie|Zombie]] 23:41, 26 February 2009 (CST)

: Sorry, didn't realise it was two tables side by side (or rather mirrored). Eyes only noticed the left side of the table. -[[User:NKF|NKF]] 23:53, 26 February 2009 (CST)

:: If the Hovertank Launcher did 200 damage, or worse if the Hovertank Launcher did EVEN MORE damage than the Blaster Launcher... that would make them easily the most deadly things on the map. As it is, the hovertank launcher is already pretty overpowered, even with 140 power.

I might be six years late here, but I think there could be an explanation for this in RL physics — indeed, in RL nuclear weapons programs. Incoming wall of text.

There are two sorts of nuclear reactions that produce energy: fission of large nuclei, and fusion of small nuclei. Fission can occur under normal temperatures and pressures, but involves a neutron chain reaction. As such, fission devices have to have a certain mass of fissionable material (the ''critical mass'') so that the neutrons stay in the material and cause more fission rather than escaping; this means that such devices cannot be scaled down below about suitcase or large backpack size (not all of this is actually nuclear material; rather, most of it is conventional explosives used to rapidly assemble the supercritical mass from subcritical masses). They also produce large quantities of radioactive fallout, which is problematic. Fusion, on the other hand, requires extreme temperatures and pressures, but does not necessarily require a neutron chain reaction. This means that they can theoretically be scaled down to much smaller sizes... except that the only available compact source (ie, not building-sized) of those extreme temperatures and pressures is the detonation of a fission bomb. Thus, all known fusion weapons currently in existence involve a relatively-small fission stage that detonates a much more powerful fusion stage.

The "Holy Grail" of nuclear weapons research is what's called a [[wikipedia:Pure fusion weapon|pure-fusion weapon]]. Because it has no fission stage, a pure-fusion weapon would release little fallout (note here that fallout is material that emits radiation long '''after''' the detonation; a pure-fusion weapon would emit copious amounts of deadly neutron radiation when actually used, but that would dissipate within seconds) and could be scaled down to grenade-launcher size (though it would obviously be far more powerful than a conventional grenade). They would be far easier to produce, as well; producing weapons-grade uranium and plutonium requires large and powerful isotopic separation equipment and/or a full-sized nuclear reactor, whereas deuterium can be extracted from water with trivial ease and lithium and tritium are relatively simple to obtain and make respectively. The main issue is that while the pressures required to confine the fusion material during the reaction are achievable with chemical explosives, the temperatures necessary for fusion are emphatically not. You need a stronger initiator; some material with a higher energy density even than plutonium. In RL the only initiator strong enough is antimatter — hard to produce and contain, to say the least — but the aliens in X-Com have a source that's stored far more easily... Elerium.

I posit that the "fusion" line of weapons in X-Com are exactly what they're named: tactical fusion bombs, made possible by an Elerium detonator. (A more controlled reaction on those lines — a fusion reactor with Elerium-spiked fuel — in UFO Power Sources would also explain the discrepancy between the calculations based on fuel efficiency and the lack of city-killer blasts when a Power Source's Elerium cooks off.)

Given the assumption that "fusion" weapons are indeed fusion weapons, with Elerium serving only as a detonator, the oddly high Elerium cost of the Hovertank/Launcher's ammunition is finally explainable. The HWP Fusion Bombs are, literally, smaller than Blaster Bombs and craft Fusion Balls (presumably because of size constraints in the launching mechanism in tanks). Having less explosives to compress the fuel means you need an even higher temperature to compensate — thus, more Elerium detonator — but because the actual power of the bomb is mostly from fusion and not Elerium decomposition, the yield is still lower.

I intend to remove this from the list of Known Bugs on this basis if nobody can find a hole in my logic. [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 02:03, 17 April 2015 (EDT)

:I'll have to disagree. Your argument while interesting, is just supposition and an attempt to give validation by taking ideas (that the developers probably never considered) to justify a flaw, very much in the same manner as those who try to explain why UFOs do not respond in interceptions. In truth, like many of the other bugs listed here, they are the result of issues caused by the time constraints the Gallops where under. Much of the production/buying/selling aspects of the game have game balance issues and don't make sense when cross referenced to other similar elements in the game and/or their overall effect to either combat or the strategy layer, especially in regards to the game's economics. [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]]) 05:06, 17 April 2015 (EDT)

::Why would they match up in terminology with the actual use to which any military would put Elerium by accident? Because, no shit, if a military got their hands on a substance with Elerium's properties this is literally exactly what they'd do (at least as far as explosives go). I can cite a paper talking about the superiority of antimatter-fusion weapons to pure antimatter weapons if you want; the title is "Fourth Generation Nuclear Weapons: Military effectiveness and collateral effects". [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 05:21, 17 April 2015 (EDT)

:quote all the sources you like, it still doesn't explain the waste in the manufacture process. With elerium being such a "scarce" resource, there is no logic in producing something that require more elerium and delivers less of a battlefield effect. It would be more logical and efficient to have had the platform fire regular blaster bombs, since they only require 3 elerium not 5.[[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])
::IMHO, any logic argument can be presented to why those HWP Elerium Bombs should cost less/more or be more efficient. That is not the point here. A bug is when a game feature is working improperly or/and is causing technical issues, either due to limitations, insufficient testing, whatever. Design choices are a completely different matter: the Heavy Laser is a nearly useless weapon due to its stats but no one ever considers it to be bugged due to its stats. It was a choice, that was slightly changed on TFTD with the Heavy Gauss. To consider the stats of the HWP Fusion a bug then you'd have to label a lot of choices as bugs when they are simply design choices. You may not agree with them but that doesn't make them bugs in the generally accepted definition of the term. And quoting Arrow Quivershaft on the top comment of this discussion: "At a cost of $15000, 400 Tech hours, 5 Zrbite, and 8 Aqua Plastics, this is the exact same cost as the HWP Fusion Bomb from X-COM EU, converted over to the equivalent TFTD resources. As such, it shouldn't be counted as a bug, since it is clearly what Mythos intended"[[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 19:35, 25 April 2015 (EDT)
::Also, the consensus until now expressed by several people that previously discussed this is that this is not a bug. The main supporter of the bug argument seems to be Spike at the beginning but during the discussion but halfway the discussion he says: "I agree though that just because it's illogical does not prove it's a bug (i.e. unintended)" [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 20:54, 25 April 2015 (EDT)
You don't get to claim benefit of the doubt here, Tycho. All game features are assumed to not be bugs unless there is compelling evidence presented otherwise. You claim this is a bug based on the suppositional logic that more powerful weapons should cost more and almost nothing else. The price wasn't altered (and neither was the power) in TFTD, so there's no evidence of mistake there (as an aside, the Displacer/Sonic having its power listed as 130 when it's 110 in the game engine clearly ''is'' a bug). The only bit you might be able to interpret that way would be the description of the Hovertank/Launcher's weapon as causing "immense devastation" compared to the description of the Blaster Bomb as "highly powerful" (the potential implication being that the HWP Fusion Bomb is stronger), but that's iffy at best since there's hardly a graded table of adjectives in use and on those very same pages in the UFOpaedia it lists the damage of each weapon as what it actually is.

The claim that it's a bug is based entirely on theorising about yields. I've given alternate theorising that would explain the yields (and I already explained that the semi-automatic nature of the Hovertank/Launcher and physical space for its high ammo could justify the need for a smaller round), which undercuts that claim. We can't know who's right, but the assumption should always be that the designers knew what they were doing; to assume until proven otherwise that they had no clue is extreme hubris and contempt. Moreover, you are in a minority of one or perhaps of two against a majority of several. Your claim to representing consensus is blatantly false.

Now, I'm going to wait a couple more days to see if anyone comes forward with anything substantive, as I waited a week after my reply to your original non-refutatory dismissal, and then reinstate the removal if nobody puts forward a cogent objection. [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 22:57, 25 April 2015 (EDT)
:Now that I think of it, though, an "oddities" page where we talk about this, the shitty Heavy Laser/Heavy Gauss, the No More Soldiers limit, and other not-bug things might be in order. It would help to make this page about actual bugs and not about weirdness that is nevertheless clearly as intended. Thoughts? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 23:04, 25 April 2015 (EDT)

:At the time, I didn't continue the argument as my point was that removing something based on one person's belief, no matter how cleverly thought out, wasn't good enough to warrant removing from the list. (I would have pointed out all the different theories on UFO interception AI, but I see that has already been removed.) I hadn't read all the discussions because I assumed that no consensus had been reached, similar to the Interception AI discussion. Mushroom, could have just pointed out that this issue was already settled years ago but no one bothered to removed it from the list, instead of resurrecting a "dead" discussion as though it had not been settled and just stated that the developers intended to discourage the use of this HWP by making the cost of its ammo high. I still don't agree that the HWP ammo is more efficient and thus justification for its production cost, especially since the developers would have never needed this level of justification or would have had the time to devote to so small an aspect of the game.

:I definitely agree that this page needs to be updated. Another reason I argued so strongly is because so many topics on this page do not fall into the category of bug as has been defined. I thought this page was also devoted to listing all the illogical aspects of the game due to the lack of enforcement on the definition. [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])

::If I only had a dime for each time someone proposes to change something on this wiki, everyone agrees, and then nobody ends up taking action... :) It's always better to take initiative and edit things. I agree also with an update to this page, and separating bugs from limitations. But definitely no more 'this should have been done this way' arguments to present design decisions as 'bugs' [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 17:43, 26 April 2015 (EDT)

:Okay. I'm planning to rip out the following and stick them on a separate page:

:Great Circle "bug" (this isn't really a "bug" so much as unoptimised code)
:Side-on Intercept "bug" (ditto, but given UFOs' tendency to alter course suddenly it's not even particularly unoptimised)
:Head-on Intercept "bug" (come on, this is just bitching)
:Instant Getaway "bug" (more an anomaly than a bug)
:80-item limit (intentional and the rationale is obvious to boot)
:Purchase limit (working as intended)
:Soldier recruiting limit (being charged for attempting to buy more is a bug, but the limit itself isn't)
:Soldier battlescape limit (there's a consequence of this which is a bug, the CtD with 10+ tanks, but not the limit itself)
:Manufacturing Completion Time Display "bug" (you can look at it and see what time it finishes, and it goes down at the right rate; it may seem a little unintuitive but it isn't "wrong")
:Manufacturing Rate Interruption Loss "bug" (more bitching)
:Manufacturing Rate limit (working as intended; the attempt to get around it in TFTD is bugged, but the EU behaviour isn't)
:HWP Fusion Bomb Ammo Cost "bug" (we're in agreement here it seems)

:There's plenty that need a tidyup on top of that but as far as the page split itself goes, are we agreed? Also, I'm thinking of calling the page "Anomalies and Game Limits", opinions? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 01:58, 3 May 2015 (EDT)

== DOS4GW - What the heck is it? ==

It's been ages since I had to remember this stuff, so those who remember clearer than I do, forgive me if my descriptions aren't accurate. Hopefully the general idea will come across.

Back in ye olde days of computere gamynge - and where there were more E's to go around, memory handling was a tricky beast to handle. Computer memory is divided into several different categories. Conventional, extended and I think expanded. I might be jumbling the terminologies for the last two a bit. Doesn't matter - memory was just cut up into small segments. The two most common memory types to PCs at the time were pretty small but were readily available. The third one - the most expandable (aka the chip with its massive 4 Megs of RAM you just spent your whole month's allowance on!), wasn't as easy to get at.

To get access to the higher memory that was available to the computer, special memory handlers had to be used. Drivers like HIMEM, emm386, etc were used.

DOS4GW is one such handler that lets the game access the computer's available expanded memory. Lots of games that came out at the time use this. Doom, Duke Nukem 3d, Syndicate, Ultima Underworld, X-Com UFO/TFTD, etc. LOTS of games. Any time you ran a game from the dos console and you saw the Dos4GW message flash by briefly it would be assisted by it (well, it stayed on the screen for ages back when processors were slower!).

It took the hassle out of memory handling and let the game access the available memory on the computer as one big flat block of memory to play with.

So what was meant in the article was to simply replace the dos4gw.exe with a more up-to-date version from another game. I think the way to tell its version was just in the message that it displayed. You can just run the dos4gw.exe file in a console window. It'll give an error, but the message it shows will indicate its version. UFO 1.4 uses Dos4gw 1.95, for example.

-[[User:NKF|NKF]] 01:22, 6 March 2009 (CST)
:DOS4GW also switched the processor from 16bit to 32bit mode. [[User:Seb76|Seb76]] 13:58, 6 March 2009 (CST)

== Clipping ==
I have a new bug. Its harmless. I have a savegame (EU CE - modified game) which has a sectoid within another sectoid. In the alien turn, one secturd walked off the roof and dropped down <s>onto</s> into another. (I guess there DNA is indentical afterall, so they 'become one' with the world). If you want the savegame (superhuman edited using UFOloader, UFO Mod v1, xcomed, Khor Chin WeapEdit v0.1) drop me a request on the my page somewhere. [[User:EsTeR|EsTeR]] 01:40, 18 September 2009 (EDT)

: Not something many would encounter, but definitely something that can happen. Units can occupy the same physical space, but the game cannot display them all. It'll only draw one of them. Actually saw this effect happen back in the early days of XComutil when it gained the ability to manually add new aliens into a battlescape. It did this by slotting them into the same spaces occupied by existing aliens. Then the fun would happen when you saw a couple of Mutons suddenly walk out of a sectoid. Not sure how the game determines who gets hurt when struck by a bullet. May very well depend on the order they are stored in the unitpos.dat file.

: There are a couple of ways you can replicate this in-game, but I can only provide theories on how you could do it. Such as shooting the ceiling above you and letting the unit drop through, or moving a tank off a ledge and getting its non-primary segments land directly on top of another unit. By the way, the rear end of tanks get stuck in walls if you attempt to move north or east off any ledges. -[[User:NKF|NKF]] 02:18, 18 September 2009 (EDT)

: Ok, so as long as others know about this, then all is good. I had never seen it and was doing alot of head scratching until I shot the alien.

== Berserk HWP crashes the game ==
In the article page it mentions that aliens which go berserk with their integrated weapons will crash the game. This is only true for Mind Controlled aliens (or units under X-COM control) - alien controlled units which go berserk do not crash the game. I tested an MC'd Celatid just now and it doesn't crash the game either, though it doesn't immediately go berserk - it waits another turn for some odd reason. Someone want to check this to verify my results? --[[User:Zombie|Zombie]] 20:31, 27 December 2009 (EST)

==HWP Morale Loss==

HWPs have 110 Bravery, which [[Morale#Effect_of_Bravery|normally prevents morale loss]], but I wonder if they can still lose morale due to loss of units with a morale-loss modifier. It'd depend on how the math is done. If, for, example, the -20 to morale for a dead unit is static, then multiplied by any [[Morale#Officers|morale loss modifier]], then reduced by 2 for every ten point of bravery, any officer death without another officer on the field will necessarily reduce HWP Morale.

It all depends on how the equation plays out and when modifiers are added. For sake of this post, I propose the following as the morale-loss equation: 20*(rank death modifier)-((Bravery-10)/5)*(1.00-Leadership bonus)=Morale Lost. (Rather than using 22 as a base, I'm going to assume Bravery is internally decremented by 10 for this equation as 0 Bravery is impossible without editing and it makes the math easier for the purpose of the example.)

It makes sense to me that rather than having 110 bravery hard-coded as an exception to "No morale lost", it simply works the same way in the normal equation, but is high enough that it negates most morale loss events, as even if an officer is killed, another officer is usually left on the field to help negate the penalty. That said, if a large portion of the team is wiped out at once, any surviving officers may not be able to negate it all, allowing tanks to start having noticeable morale loss.

So with the death multipliers, we can determine that every XCOM officer killed has a set death value. Rookies and Squaddies are -20, Sergeants are -24, Captains are -26, Colonels -30, and Commanders -35.

For example, under this theory, if a Sergeant is killed with no other ranked units on the field, a Squaddie with 50 Bravery would lose 16 Morale. (20*1.2-(50-10)/5*1.00=16). A HWP would, at the same time, lose 4 morale. The Sergeant's death is worth -24 Morale, and without another officer on the field to ameliorate the loss, the Tank's bravery only can 'absorb' 20 points of the morale lost. If it was instead the Commander lost, with no other officers on the field, the HWP would lose instead 15 points of morale, given that a Commander's death (20*1.75) is worth a whopping 35 points of morale loss if no other officers are present.

And if you have, say, four colonels and the Commander on rear/psi duty, and some alien flings a grenade or a blaster bomb into the back of the Skyranger and blows all three of them up and they were the only officers, the HWP has now lost 55 morale, which gives it a 10% chance of panicking/berserking on the next turn!

In the end this'll probably need to be tested for accuracy, but those are my thoughts right now.

Also, for the record, most units that berserk go to 255 TUs while still using the original TU-expenditure calculations; it's part of what makes berserk units so dangerous. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:34, 11 January 2012 (EST)

:Tested it under vanilla CE. Took a squad out containing just about every rank there is (commander + colonel + captions + sergeants), plus a tank. Blew up and killed all soldiers with a single blaster bomb shell, leaving just the tank, which lost no morale (sorry).

:I also brought a group of rookies along with a single commander + tank, and killed just the ranked unit. Tank lost no morale. A rookie with 60 bravery lost 17 (which matches the loss predicted by the formula currently on the morale page), whereas under your formula he should've lost 25.

:Still, you're on the right track. I've long had my own theory as to why tanks have been known to lose morale. Take a look at [[UNITREF.DAT#42|UNITREF.DAT[42]]] - this is the offset that stores a unit's rank. Notice something? The value gets higher as the X-COM unit's rank gets higher. Works in ''reverse'' for aliens, for whatever reason. I sorta figure it's so killing a mind controlled alien commander doesn't mess with your morale too badly, but there's a big problem with that theory and you can probably tell what it is...

:If the highest this figure gets for an X-COM unit is 5 (commander rank), then a killing a mind controlled alien ''terrorist'' with a rank value of ''7'' should net an even higher morale loss penalty. And indeed it does - I took a rookie and a tank to a terror mission, mind controlled and killed a terrorist, and the tank lost 10 morale. Guess it would've lost six if I'd taken a commander instead of a rookie, but that's still something.

:Note that the formula on the morale page does ''not'' account for this - it states that at bravery 110 the alien's death loss multiplier would always be applied to a base morale loss of 0, but that's obviously wrong. You're spot on in saying that the base morale loss figures are not totally dependant on bravery, and the "death loss" penalty is applied first. Would probably require a few more trials to determine what that penalty ''is'' for alien soldiers and terrorists though.

:Just for kicks, I edited a plasma tank to have 0 morale. It panicked in the normal way (either sitting still or charging off to the SE). When it berserked, the game crashed as soon as I dismissed the status message. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 18:54, 12 January 2012 (EST)

:: Thought I'd give it a spin. I sent a laser tank in with a squad and had it start shooting at team members. Each time it killed an ally, it would lose morale. Once it was under 50 morale, I waited until it panicked. Since I was playing the dos version, the game didn't crash but I suspect a memory leak of some sort may have occurred that would normally shut down the CE version. What would happen in CE if a soldier were to be edited and granted a tank turret, and then made to panic? Would the game crash? I'm just wondering if it's related to the weapon as opposed to the fact the tank is a treated as a large unit. -[[User:NKF|NKF]] 00:43, 13 January 2012 (EST)

::: Ah, friendly fire! Thought I'd tested for that, but obviously not...

::: Oddly enough, now that I try it, I see that the twenty point hit for killing a unit on the same side can be adjusted by the leadership bonus of the victim. Eg, kill a lone commander and his 35% penalty reduction takes the extra morale lost from 20 down to 13 (which is exactly how much a tank will lose, given that it otherwise wouldn't lose any at all).

::: Of course, this completely messes up my theory about alien soldier/terrorist ranks overriding the 110 bravery score. It doesn't. My tank "only" lost 10 morale because the alien's rank acted as a 50% leadership bonus... Though I suppose that's still interesting to know, because it suggests that keeping a simple alien soldier under mind control is more effective then risking your own commander in the field.

::: I took an otherwise unarmed rookie and assigned him a tank cannon + ammo. He could manually fire this weapon in much the same way a tank can. Forcing him to berserk crashed CE, under DOS he just spun around. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 21:20, 13 January 2012 (EST)

== 80-items limit on CE edition ==

I have the feeling that the 80-items limit does not apply to the CE edition and is instead a 110-items limit (at least during base defence). Can anyone confirm? [[User:Seb76|Seb76]] 16:24, 24 February 2010 (EST)

:I believe this limit was increased for TFTD. Maybe it was also increased for the CE edition of UFO, and only ever applied to the DOS edition of UFO?? [[User:Spike|Spike]] 20:03, 11 March 2010 (EST)

== Paying for Dirt in TFTD ==

I have the steam version of TFTD and am unable to replicate this bug. Testing with the starting base, I dismantled a few modules, added up my income and expenses, and it reconciled with my cash at the beginning of the next month. I even tried again, dismantling every module except the access lift, and once again saw no income discrepancy. Am I missing something, or is it possible this bug was actually fixed in TFTD? --[[User:Jewcifer|Jewcifer]] 12:18, 16 March 2012 (EDT)

:'twas probably fixed. It would indeed be helpful to add a small note to bugs on this page which are EU-specific but not obviously so (like this one). -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 17:14, 16 March 2012 (EDT)

::Every now and then I get the urge to test some of the more important bugs myself in my steam version of TFTD. Perhaps I will make a more complete effort and record the results somewhere on the wiki. --[[User:Jewcifer|Jewcifer]] 12:08, 21 March 2012 (EDT)

== Paying for dirt: Source of bug discovered! ==

Well, I never have read this anywhere (which kind of strikes me as odd, thinking of how obvious this one seemed to me... And i have NO programming background whatsoever), so I'll post it here, hoping that there are still some active members willing to try and verify my findings. If so, please comment here, because then I will inform bladefirelight to include this in any upcoming xcomutil release. If it had been discovered before, well then I just wasted some time here. Comment below, I will delete this entry.

As the main bug page mentions, when dismantling a facility still under construction the premium will only be paid once it would have been finished. This suggests some connection between paying the premium and building time. Looking into the infos here: [[BASE.DAT]], I quickly discovered what the problem was: When a facility is dismantled, the Bytes related to the location of base facilities are updated correctly. HOWEVER the game omits to update build time to FF (which is "will never finish", an entry only found on unused squares). If the facility is finished when it is dismantled (or destroyed during combat), then the 00 in the build time byte will stand. If it was under construction, the value indicating the remainig build time will continue to tick down towards 00 as if the facility was still there.

Now at the end of the month the following seems to happen: The game checks for ANY 00 entry in the build time bytes, and if there are 00 entries, it will look up in the location bytes the type of structure to determine the amount of maintenance for that 00-construction-time-square. When it finds "dirt", then it will charge the 80 grand (my guess would be that those are somewhere hard-coded).

This explains all phenomena related to this bug, like a dismantled hangar costing 320.000 grand or the premium only popping up after the build time of a dismantled facility that was under construction has expired.

Now the fix is pretty easy: Open the BASE.DAT in a hex-editor and change the bytes in question to FF!

== Minimized Interceptor Bug (Ufo CE) ==

Maybe this bug is not just related to saving, because I had a similar problem last night. The game didn't crash, but it kept restarting the same Battlescape mission.
One Avenger (A-3) was pacing a Battleship, while another Avenger (A-1) was sent to pick up the pieces of a Terror Ship that had been shot down by an Interceptor. Despite having no weapons (oversight on my part), A-3 wanted to attack the Battleship, but I minimized the screen, hoping it would land.
While the screen was minimized, A-1 landed at the Crash Site from the Terror Ship and started this mission. Right after finishing it, I got the message that A-3 was ready to land next to the Battleship. Happy that I'd get the loot, I started the mission.
After cleaning it out, I got the usual Loot and Promotion screens and went back to the Geoscape. A few seconds later, I was back in the equipment screen and the Battleship Mission started again. I played it once more, because - hey - additional loot, right? Err... no. At the end, I got the correct Loot screen for this attempt and the very same promotion I had gotten in the first attempt (A Rookie from another base promoted to Sergeant).
Got back to Geoscape and a few seconds later back to the Equipment screen. I aborted this mission (same Battleship again), got back to Geoscape and - you guessed it - back to the Equipment screen. After aborting this mission as well and getting back to Geoscape, I used the few seconds I had to go to 'Options' and 'Abort Game'. Maybe I could have made A-3 disengage from the Battleship since I think I saw them both on the Geoscape, a yellow diamond and a red plus, but it was pretty late by that time.
--[[User:Matzebrei|Matzebrei]] 15:06, 15 May 2012 (EDT)

This is a known bug. There is a work around. You should patrol the ship with troops and not land... Finish shooting down the other airborne ships first. Then when the ships doing the shooting are returning to base, change patrolling ship with troops to advance to downed ship in order to commence ground combat mission.
--[[User:JGF|JGF]] ([[User talk:JGF|talk]]) 07:55, 9 November 2016 (UTC)

== Activity Overflow Bug ==

This is a potentially campaign-ending bug. This was seen in the Steam distribution, DOS version (on Windows 2003 Server EE). Not sure if UFO Extender was being used - probably it was. End of Jan 1999 turn shows an extreme negative/underflow Monthly Rating score, which in turn is caused by extreme overflow of UFO Activity levels. Note that that funding "score" - the increased funding by countries - was very positive at the same time!:

[[File:dissatisfied customers.png]]

UFO Activity, by Areas and by Countries, is literally off the chart. Clearly some kind of integer overflow:

[[File:ufo-areas.png]]
[[File:ufo-countries.png]]

X-Com activity is also off the chart:

[[File:xcom-areas.png]]
[[File:xcom-countries.png]]

In addition to the likely outcome that I will lose the game in Feb 1999, it means I can't use the graphs to detect UFO activity outside of my radar coverage.

I have only seen this bug once, and (probably very unusually) I am running under Windows 2003 Server EE (!!). My hunch would be that's the cause, Windows 2003 Server is not the best games platform. :)

[[User:Spike|Spike]] 07:22, 3 September 2012 (EDT)

Further information:

I don't necessarily lose the game in Feb or March 1999. The Monthly Ratings from Feb onward are just based on the current month, not historical score to-date. However it still greatly increases the risk of suffering from the [[Known_Bugs#Losing_My_Favourite_Game|Losing My Favourite Game]] bug - which also greatly complicates doing too many controlled experiments on this Activity Overflow bug, because a few restores of the saved game quickly leads to X-Com Project termination (and humanity's doom).

Possibly the Activity Overflow bug is caused by an initial value of the score (or an array of score values) not being correctly zeroed at the start of the game. See this graph, which shows a negative score in May 1998, prior to the start of the game in Jan 1999.

[[File:Prehistoric_negative_score.png]]

[[User:Spike|Spike]] 08:48, 3 September 2012 (EDT)

I encountered the same Activity Overflow Bug in Windows 7 using Steam version, Windows option with UFOExtender latest version.

[[User:Humbe|humbe]] 2012.10.04 09:05 UTC

I encountered the same bug at end of january with latest xcomutil patched CE version (with only bug fixes patched) with ufo extender newest version running (close to default options). Got many saves from that first month. Even if loading very early save where I had done no missions yet, and just did stuff in base, graphs still show negative for various periods in 1998. Sounds more like corruption than something actually overflowing to me.

[[User:Archlight|Archlight]] 18:34, 24 September 2012 (EDT)

== Bad Paths Bug ==

I suggest to add bad paths on UFOs maps to the article, as another bug in the game.

[[User:Sherlock|Sherlock]] 09:25, 26 December 2012 (EST)
:That sounds reasonable to me. [[User:Spike|Spike]] 10:03, 26 December 2012 (EST)

==Expenditure Graph==
The economy graph for "Expenditure" neglects funds spent on new facilities. I noticed this in my current (DOS) game when I built eight Psi-Labs at the start of April and it didn't increase. I know it counts everything on the Purchase screen; I'm not yet sure whether it counts manufacturing costs.

Is this enough of a bug to be mentioned? Can anyone confirm whether or not it occurs in CE, and whether it counts manufacturing costs? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 02:40, 17 May 2016 (UTC)

==Workshop Crowding==
It seems there is a bug whereby you can allocate more projects/engineers than available workshop space. This can be triggered by setting up two concurrent manufacturing jobs, setting one of them to have 0 engineers working on it, then set the other to have as many engineers as you can assign to it, filling the workshop space. Then go to the other job with 0 engineers, and it will show a negative workshop space available, now if you assign at least one engineer to this project, you can assign the rest of your engineers however you please.

This is my first edit. I find it hard to believe I'd be the first to find this bug after so many years, can someone please confirm a reproduction and that it isn't documented somewhere I've missed? I am running the DOS version of UFO, but I'm also running XComUtil, not sure if that has an impact, or what patch level I'm on. - [[User:Uncertainty|Uncertainty]] 11:00, 20 Dec 2016 (AEDT) Update: Cannot reproduce on the CE version, still unsure of the patch level of the DOS version I'm running and don't know how to accurately determine that. - [[User:Uncertainty|Uncertainty]] 22:00, 29 Dec 2016 (AEDT)

: An easy way to check is whether you can research Magnetic Navigation after collecting one from an alien sub, or if you have to research a Lobsterman Navigator beforehand. If you can research it right away then you have v2, which is what the CE version is mostly based on. If you can't research it and must get the navigator, then it's the unpatched copy of the game. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 22:24, 29 December 2016 (UTC)

Update 2: Thanks NKF, I'm not running TFTD, but I figured out that I was running v1.2 of XCOM1. I cannot reproduce the bug on v1.4 so the bug only applies to v1.2 and has been patched in newer versions. - [[User:Uncertainty|Uncertainty]] 16:45, 31 Dec 2016 (AEDT)

= Unconfirmed bugs =

== Alien mission succeeds despite Ground Assault ==

Suppose aliens decide to do a mission. So they send a scout UFO. If you shoot it down, the alien mission gets derailed and the next scout becomes delayed, sometimes a little, sometimes a lot. Seems like the headquarters are waiting for the first scout to report back home. So you shoot down the second scout. The third one also takes a long while to arrive and if you shoot that down too, the aliens either give up completely or send their big ships which only aimlessly fly to and fro, never lands and leaves soon, empty handed. The alien mission is a failure.

On the other hand if you wait for the scout to land, assault it with your Skyranger and win the mission, the alien's mission continues as if nothing happened. The new scout appears on time. So you ground-assault it too but the third and fourth scout also appear on time. Then the larger UFOs show up and land as if nothing happened to the scouts. You ground-assault them too, including the last Battleship that happens. But gues what? The alien mission is a SUCCESS even despite none of the UFOs making it back to base. Really annoying if the mission is an Infiltration, you can't take their juicy big UFOs because if you do, you are going to lose a country.

I need to add that I was playing some weird version of the game whose data was rejected by OpenXCom with "an invalid CHRYS.PCK file, please update to the latest version" message. So I don't know if this bug exists only there or is present in the latest version of the game too or even whether this is a bug or an expected behavior. - [[User:TowigOs|TowigOs]] ([[User talk:TowigOs|talk]]) 00:24, 3 August 2025 (UTC)

=Cleanup needed=
Hmm this whole Talk page needs a cleanup. A lot of the Not Listed bugs, should be listed, or are listed. [[User:Spike|Spike]] 10:03, 26 December 2012 (EST)

:So, before it will be made, yet three more observations.

:1. There is no possibility to give back (to stop hiring) a plane without craft weapon.

:2. Alien Reproduction is unavailable in a normal game without hacking/save editing. This is probably connected to further errors on maps. A bug/error/programmers' oversight of the some kind is present in TFTD where it is impossible to obtain Examination Room. It is so because many tiles on maps are wrongly assigned to game's objects. Namely, [[Examination Room (TFTD)]] is treated as Alien Implanter - but there is plenty of errors of this type, on various maps (perhaps also in UFO: EU).

:3. Among soldiers in UFO:EU, there are Russians. Some non-Slavs may not know that Slavic (also Russian) family names have different masculine and feminine forms. For example, Petrov, Belov, Likhachev, Gorokhov, Chukarin, Andianov, Voronin, Maleev are all masculine names; women must be called Petrova, Belova, Likhacheva, Gorokhova, Chukarina, Andianova, Voronina, Maleeva respectively (however, a rule that the feminine form is always made by adding -a is wrong, e.g. Tolstoy - Tolstaya). The soldier's name Mikhail Gorokhova (which is possible in UFO: EU) is just ridiculous (for everyone who has even little knowledge about Russian things). Tatyana Petrov is also an impossible combination. X-Com creators probably assumed that family names are the same for men and women in all languages, and, as a result, they made only mechanisms for storing masculine and feminine forms of first names, not family names. But taking reality under consideration, this is a bug.

: [[User:Sherlock|Sherlock]] 16:22, 26 December 2012 (EST)

== Common bugs vs. UFO EU specific bugs ==

I believethere is one more thing that needs to be cleaned. Namely, both EU and TFTD share the same game engine, so some bugs are common for them both. However, there exists a page with a list of TFTD bugs, and it is clear (or: should be clear) which of the bugs are specific for TFTD. I think the same should be done with EU specific bugs: to hold them apart from bugs common for both games. Some bugs exist in both games but manifest themselves differently (like problems with mind-controlling of big aliens) - they are not true common bugs.

Or even more: one could expect a clear information by each bug, in which game and in which version of the game the bug occurs. And whether a patch exists or not. Sometimes such information is given now, and sometimes it is not. And if one does not know exactly which versions are affected by the bug, it should also be mentioned clearly.

[[User:Sherlock|Sherlock]] 04:13, 27 December 2012 (EST)

== Rename page title to indicate which game this refers to? ==

I was looking for a list of bugs related to XCOM Apocalypse, and it took me a while to realize this was about a totally different game. There are 4 games (not counting the 2 opensource projecrs) here on UFOP - maybe that could be reflected in the article aswell?
[[User:Panzerlol|Panzerlol]] 20:35, 31 March 2013 (EDT)

==New "bugs" submitted directly to main page with no apparent explanation==

WakkaDakka, have you actually managed to replicate this "missing time units" bug, or was it just a one-off freak occurrence? I'm not sure it merits main-page space until we have some idea how to replicate it.

N21, how were you seeing the future to begin with? It's only a bug if it occurs in the normal course of play.

[[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 03:36, 28 May 2015 (EDT)

== Enemy Unknown 1994: Save game bug mid mission. ==

Effect : Loading saved game mid mission just displays a black screen with the cursor at the top left, whilst the music continues to play in the background.
I don't believe the game has crashed out to DOS, having tried both CLS and DIR to no avail. Your can no longer interact with the game, making you force quit the app.

[[File:Screen_shot_2016-11-07_at_19.39.31.png|thumb|left]] 

I'm using Boxer 1.40 on a Mac - which in turn is built off Dosbox 0.74.
I remember seeing this bug years ago on Windows XP too, so I don't think it is platform specific.
I'm currently running it with some of the XCOMUtil patches too - but have had the issue crop up without any of the patches.

Playing on Superhuman level, I use a Skyranger with 14 soldiers equipped with Laser Rifles.

Cause : Hard to be specific. But here are the facts.
I have my suspicions it may be do to with fog of war rendering issues.
I've had it occur frequently when going to the NW edge of a map.

I also had issue on Alien base 1. I have a save game and can suggest moving a unit and saving it in another slot - that alone causes the issue. So if someone knows how to debug this I can supply that. Not sure if the combined number of aliens and yourself casue this.. I managed to eventually work thru a series of corrupted saves that wouldn't load to one that worked again).

Here is a sample save game where the game only needs one specific movement to corrupt a game when you save after the move.

[[File:GAME_10.zip]]
I've uploaded two images to show the move for S Bradley
[[File:Screen_shot_2016-11-11_at_13.50.13.png|thumb|left]] 
and the destination square to move him too. When you complete that move and save the game it corrupts.
[[File:Screen_shot_2016-11-11_at_13.50.17.png|thumb|left]] 

Incidentally there were two downed UFO's at this time, with a second Skyranger en-route to UFO 42. This mission was for UFO 43 with another Skyranger.

The problem frequently occurs.
Ive had it occur recently on the following types of mission:
Terror, Alien Base, Supply ship, Large Scout, predominantly with Sectoids and Cyberdiscs, but also with Mutons and Floaters.
The only thing all these missions have had in common was lots of units on both sides. For example 13 Floaters on a Scout mission, 9 Cyberdiscs on a Terror mission etc.

--

Other quirky things I've seen relating to Stunned units:

1) You can't stun a unit, forcing you to shoot it to complete the mission.
The target being stunned drops to the ground in a heap, but the game says you can still see it and can re-stun unit....

2) Celatids. You stun it, then it wakes up and moves away. The unit no longer renders correctly. It's like a sheet of garbled colored/transparent dots.

3) A stunned unit, other than a Celatid wakes up, and is invisible but you get the '1' in red square for visible enemy. You can stun unit and get the animation for it falling to the ground again.

--

Teleported unit off screen (notice the yellow arrow over the unit, which alas is invisible at the split second I took screenshot - OS/X rendering crap-shoot).
[[File:Screen_shot_2016-11-12_at_14.18.07.png|thumb|left]] 
The unit was teleported from the top of the stairs in an entirely different building, rendering the unit unusable for the mission. I ended up reloading it and doing over.... - [[User:JGF|JGF]]

:Stop spamming [[Special:RecentChanges|the changelog]], please - if you're working on a page and want to see the results of your edits midway through, use the Preview button. Don't hit Save until you are ''done''.

:I can't replicate any issues with your provided save. Bradley doesn't have enough TUs to "complete" the requested move, but asking him to make the attempt anyway, then saving / reloading, works fine for me under 1.4 as well as CE. For what it's worth, as far as I'm aware the game in no way keeps track of the number of actions you've performed during a given turn; at least, I haven't been able to find any such counter embedded in the save files.

:I do suggest you leave your units with more time units - when ending turn, any agents who ''might'' spot an alien during the enemy's turn should ideally have some cover, a kneeling stance, and enough action points to defend themselves with a reaction shot. Using your full TU allocation on movement is somewhat suicidal, and even when you can get away with it, it tends to leave agents without enough energy to move when they really need to.

:Your invisible units may be related to [[Known_Bugs#Invisible_Chryssalids|this bug]] - presumably you can trigger similar behaviour by knocking out all instances of a given alien species within a map, saving / reloading, and then waiting for one of the aliens to awake. I was able to replicate it with an Ethereal, for example.

:Difficult to comment on your garbled Celatid without seeing it first-hand. Ditto for your un-stunnable target. I'd quite like to inspect them with my save editor, though, and ditto for the teleported unit. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 05:46, 13 November 2016 (UTC)

Thanks for scaling the images nice to see the wiki syntax.
It's odd to here you say he didn't have enough Time Units left, because for me the move is allowed.
Where did you get your 1.4 patch?
I applied 1.4 too and am wondering if I got a bad version.
Also did you get your original XCOM off GOG or some place like that?
I have the original CD. I think it's the US version as I used to live there.

== Time Units reset to 0 when soldier reaches 255 TUs ==

I have been playing an old version of UFO: Enemy Unknown, where there is no limit on TUs for soldiers. At certain point, two of my best soldiers reached the limit of 255 TUs, which rendered them useless at now they have 0 TUs.
I tried to reduce their TUs by editing Soldier.DAT, but it did not help. If I check soldiers from the base menu, I can see that the value has been changed, but in the battle their stats are still the same and thus they have 0 TUs and cannot be moved with.

Do any of you know, how to fix this bug? Where is the limiter located, can I change it so that is will be as in the new versions? In any case, I believe this bug should be mentioned on the page. It is mentioned here though: http://www.ufopaedia.org/index.php/Time_Units --[[User:Achernar|Achernar]] ([[User talk:Achernar|talk]]) 21:13, 9 May 2017 (UTC)

: Feel free to add the issue - the page is a hodge podge of whatever issues folks have at the time or as they come across them.

: While I'm no expert on the file structure of the executable for the first release of the game, I suspect you'll find the cause for the byte roll-over feature is that there were no stat limiters to begin with. Best way to cope with it is to either retire anyone approaching supersoldier status to base defence duty, buy more soldiers and spread the experience out more evenly, or update to 1.4 and find a sound patch to restore the original sound samples.

: For your broken soldier: I'm, assuming you edited the soldier.dat file. If you saved the game while in the battlescape, the game creates a temporary copy of the soldier stats and keeps them in unitref.dat. This is to keep track of in-battle status changes, experience, etc. You'll need to edit the current TU levels in this file as well. Or beat the mission with the soldiers that can move and you'll see your edits reflected in the next battle. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 05:45, 11 May 2017 (UTC)

== Fire rate bug & German version footsteps ==

These don't seem to be documented for some reason: (DOS Version)

The fire rate always resets to 3 if an alien or an alien mind controlled unit throws a grenade.

If German is chosen as language to play, the footsteps of all soldiers, regardless of the terrain they walk on, will sound as if they are walking on a metal surface like the inside of the Skyranger, UFO or the base. [[User:Bard|Bard]] ([[User talk:Bard|talk]]) 05:38, 8 April 2019 (CEST)

== Direct incendiary hit causing no reaction fire? ==

On the Incendiary page, it is reported that a direct hit will not cause an alien to spin around and return fire. I have tested this in OpenXcom and find that the aliens do, in fact, return fire. If this can be confirmed in original X-Com, it would be good to add to known bugs.

: It's safe to say everything you find on this wiki relating to the classic game pages were gleaned from the original games. OpenXcom, being an independently developed fan project, will have its own list of fixes and changes chronicled in its own documentation. In fact I would not be surprised that good deal of the more technical information on this wiki has been contributed by those that had some input into the OpenXcom project. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 05:16, 8 June 2021 (UTC)

:: Thanks, good to know. Would still love to know if anyone has tested this in classic game. If not, I will when I can, so it can be added to known bugs [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 22:05, 15 June 2021 (UTC)

==Alien weapon loadouts bug/anomaly==
There are actually 10 alien weapon loadout sets, not 9. The actual first set is 70% "early"/20% "mid"/10% "late". This loadout set never appears in-game, though, because the setup at game start counts as a month rollover which means that weapon loadouts (which are called when the mission occurs, not at month start when the mission is scheduled) are called from the second set during January, the third set during February, and so on. This is probably an oversight by the Gollops (note that race weights reach their final values in October; were it not for this quirk, weapon loadouts also would), but it's hard to be sure. Should this be added? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 15:02, 28 April 2025 (UTC)

Where to Get the Games

2025-07-31T23:06:01Z

TowigOs: Replace GOG search with direct links to the games

The entire X-COM series is now owned by Take Two's 2K Games division and is no longer abandonware. Here's a list of retailers where you can buy the original Microprose games legally, either in a bundle or individually:

== Digital Versions ==

=== Activated on Steam ===
* [http://store.steampowered.com/sub/964/ Steam Store]
* [http://www.amazon.com/XCOM-Complete-Pack-Online-Steam/dp/B00846E6X4/ Amazon]
* [http://www.gamersgate.com/DD-XCOMCP/x-com-complete-pack GamersGate]
* [http://www.greenmangaming.com/s/pt/en/pc/games/strategy/x-com-complete-pack/ Green Man Gaming]
* [https://www.humblebundle.com/store/xcom-complete-pack Humble Store]

For more info, see [[Steam Versions]].

=== Standalone from [https://www.gog.com/ GOG.com]: ===
* UFO Enemy Unknown is called [https://www.gog.com/en/game/xcom_ufo_defense "X-COM: UFO Defense"] there.
* [https://www.gog.com/en/game/xcom_terror_from_the_deep X-COM: Terror From The Deep]
* [https://www.gog.com/en/game/xcom_apocalypse X-COM: Apocalypse]

== Physical Versions ==

If you don't mind paying more for something more old-fashioned, there's always [http://www.ebay.com eBay] and [http://www.amazon.com Amazon].

[[Category:Enemy Unknown/UFO Defense]]
[[Category:TFTD]]
[[Category:Apocalypse]]