Revision as of 10:54, 9 November 2016

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?

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). 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. 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). -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).--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. 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? -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. - Bomb Bloke (Talk/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! 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. - Bomb Bloke (Talk/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? Jasonred 22:22, 12 May 2011 (EDT)

They really have to "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 this thread. - Bomb Bloke (Talk/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. 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 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. - Bomb Bloke (Talk/Contribs) 05:41, 14 May 2011 (EDT)

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

Bugs vs Limits

(Discussion continued from 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. --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? 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". 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. --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). 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.) 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). 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. 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). --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. 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.

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?

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

- 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

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

- NKF

That last bug happens when exploding Cyberdiscs kill nearby Sectoids, doesn't it?--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. -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. 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?

Hobbes 22:12, 22 February 2007 (PST)

Is it a case of hitting the 80-item limit?--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. 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?

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

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?

--Sfnhltb 18:20, 1 March 2007 (PST)

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

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.

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

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

- 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!

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

-NKF

I, however, have experienced it. I lost an entire month's worth of playtime because I couldn't solve it. Arrow Quivershaft

Anyone, any ideas on why it might vary from PC to PC? -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. - 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 here. 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. 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. 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 - 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 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. - 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. - 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! 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! - 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. 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? - 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. 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. - 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. --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. - 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. 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. 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. --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. 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 ). 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).

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

- 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?). --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. 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. - 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). --Maquina 04:12, 4 September 2007 (PDT)

MY ramblings have been moved to my discussion page EsTeR

Great Circle Route

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

what is the great circle route? 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. -- 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. 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 Jasonred 15:56, 31 March 2009 (EDT)

Added to article. 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. - 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 Zombie would be quite interested. 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. - 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. NewJoker

This should be mentioned in the ExploitsE#Base Defence Mission Spawning Issues section. The Bugs/Exploits really need to be sorted and consolidated. - 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! 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). -- 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.) 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 Soldier Recruiting Bugs. 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. 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.  Muton commander 19:24, 12 May 2008 (Pacific Time Zone)

I've never encountered it either. 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. - 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. 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. 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. - 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. 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 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. -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? ;) 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. - 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. -- 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 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. 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. -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. --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. -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. 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. 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. -Jasonred

Alright, my error. Thanks for clarifying. 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. 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. 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?). 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.

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.

-NKF 01:22, 6 March 2009 (CST)

DOS4GW also switched the processor from 16bit to 32bit mode. 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 ~~onto~~ 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. 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. -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? --Zombie 20:31, 27 December 2009 (EST)

HWP Morale Loss

HWPs have 110 Bravery, which 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 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. 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] - 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. - Bomb Bloke (Talk/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. -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. - Bomb Bloke (Talk/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? 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?? 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? --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). - Bomb Bloke (Talk/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. --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. --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. --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!:

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

X-Com activity is also off the chart:

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

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

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.

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.

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.

Sherlock 09:25, 26 December 2012 (EST)

That sounds reasonable to me. 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? Magic9mushroom (talk) 02:40, 17 May 2016 (UTC)

Cleanup needed

Hmm this whole Talk page needs a cleanup. A lot of the Not Listed bugs, should be listed, or are listed. 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.

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.

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

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. It forces you to have to kill the DOS app, because there is no longer any way to interact with the program. Cause : Unknown. I had blown up a Cyberdisc and I don't know if that somehow corrupts the terrain in the save game. Had previously thought it was because of placing units at the top edge of the screen, but replaying I managed to still get bug, from earlier in the mission and avoiding northernmost tiles.

It may just be saving after killing the Cyberdisc that creates the issue. Maybe the smoke cloud it kicks up prevents the terrain from rendering correctly. But then again it may be something odder like performing a certain number of actions on a number of soldiers within a turn that causes the corruption. It seems I can get up to a threshold at which point the game corrupts. I did this by saving after each step then reloading.

This is one of those bugs that I've seen happen in the past, but have no idea what is happening. Does this happen often and are you able to replicate it consistently with the mid-battle saves? Also have you tried just pressing a few keys and see if a message like 'cannot fit Y axis' pops up? Alternately, try running a few dos commands and see if it does anything like CLS. If that does something, then game's crashed and dropped you to the command prompt but hasn't reset the graphics mode. The other question is, how have you set up your game to run? NKF (talk) 06:16, 8 November 2016 (UTC)

To answer your questions: 1) 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. 2) I don't believe the game has crashed out to DOS, because the sound still plays in the background when you load the corrupted save. I did also try CLS and DIR to no avail. When the corruption occurs you can perform a certain number of operations and save and restore ok. But once you go one operation past this point on any soldier future attempts to save cause the corruption. Consequently I'm wondering if it's some sort of buffer overflow that causes the problems. I'm wondering if there's some sort of old DOS Config.sys setting that needs to be applied like BUFFERS. Possibly even missing SMARTDRV after Googling the manual... But further Googling infers DOSBOX did away with need for SMARTDRV https://www.gog.com/forum/general_archive/help_with_dosbox/post17

I can confirm this bug manifests itself when you do a mission on a downed Terror ship containing Sectoids and Cyberdiscs. I restarted the game when it happened last time. And 3 months game time in again it happens at same point. The mission first time round contained 6+ Cyberdiscs. My ship in both instances was a Skyranger, with a compliment of 14 soldiers. This last time I found I could save whilst moving 11 of the 14 soldiers - perhaps moving one lead scouting soldier more than once. At the point I tried to move 12th soldier the save game would not restore correctly. After the bug manifests itself the first time, the subsequent turn allowed only 2 or 3 moves before the game save bug occurs again. However, if I save at the start of a game turn, before any movement, that game will always load correctly.

Tank Type	DAM	Snap	Aimed	Aimed	Snap	DAM	Handheld
Tank/Cannon	60	60%	90%	90%	60%	56¹	Heavy Cannon
Rocket Launcher	85	55%	115%	115%	55%	87.5²	Rocket Launcher
Laser Cannon	110	50%	85%	84%	50%	85	Heavy Laser
Hovertank/Plasma	110	85%	100%	100%	86%	80	Plasma Rifle
Hovertank/Launch	140	--%	120%	120%	--%	200	Blaster Launcher

@@ Line 959: / Line 959: @@
 After the bug manifests itself the first time, the subsequent turn allowed only 2 or 3 moves before the game save bug occurs again.
 However, if I save at the start of a game turn, before any movement, that game will always load correctly.
-I've also found that if you save at the start of

Difference between revisions of "Talk:Known Bugs"

Revision as of 10:54, 9 November 2016

Classification etc

Bugs vs Exploits

Bugs vs Limits

Specific Bug Discussions

Misc Technical Bug ?

"Invisible Muton" bug

Vanishing snakemen

Blaster Bomb Bug

Disappearing Ammunition

MC at end = MIA?

Crash Site in the atlantic ocean

Inconsistencies in MCing Cyberdiscs and Sectopods

Facility Dismantle Bug

Manufacturing Limit Bug

Unconscious Enemy in Equipment Screen

Soldiers moved to outside of combat screen

Great Circle Route

Bug not listed: Missing soldiers during base defense

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

Soldier Recruiting Bugs Tested

Floater Medic Bug

Strength Overflow

Bug not listed: Sticking your head through the ceiling

Base Defence bug that causes a crash?

Sources for a DOS4GW transplant

Phantom Carried Casualty

Civilians As Enemies to MC'd Aliens

Elerium Base Bug

HWP Fusion Bomb and SWS PWT Displacer Ammo Manufacturing Cost Bug

DOS4GW - What the heck is it?

Clipping

Berserk HWP crashes the game

HWP Morale Loss

80-items limit on CE edition

Paying for Dirt in TFTD

Paying for dirt: Source of bug discovered!

Minimized Interceptor Bug (Ufo CE)

Activity Overflow Bug

Bad Paths Bug

Expenditure Graph

Cleanup needed

Common bugs vs. UFO EU specific bugs

Rename page title to indicate which game this refers to?

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

Enemy Unknown 1994: Save game bug mid mission.

Navigation menu

Search