UFOpaedia - User contributions [en]

Talk:Known Bugs

2011-05-10T17:39:43Z

FrederikHertzum: /* Bugs vs Exploits */

= Classification etc =

== Bugs vs Exploits ==

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

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

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

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

== Bugs vs Limits ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

= Specific Bug Discussions =

== Misc Technical Bug ? ==

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

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

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

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

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

- [[User:NKF|NKF]]

-----

== "Invisible Muton" bug ==

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

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

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

-----

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

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

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

- [[User:Bomb_Bloke|Bomb Bloke]]

----

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

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

----

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

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

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

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

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

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

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

- [[User:NKF|NKF]]

----

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

----

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

- by tequilachef (April 4th 2007)

== Vanishing snakemen ==

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

---

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

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

- By tequilachef (April 4th, 2007)

== Blaster Bomb Bug ==

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

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

== Disappearing Ammunition ==

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

------

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

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

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

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

==MC at end = MIA?==

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

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

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

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

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

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

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

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

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

----

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

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

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

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

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

- By tequilachef (April 4th, 2007)

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

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

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

: -[[User:NKF|NKF]]

== Crash Site in the atlantic ocean ==

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

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

- UFO: battleship, floater, alien harvest

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

- Date: January 2000

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

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

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

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

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

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

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

== Inconsistencies in MCing Cyberdiscs and Sectopods ==

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

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

:- [[User:NKF|NKF]]

== Facility Dismantle Bug ==

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

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

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

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

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

== Manufacturing Limit Bug ==

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

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

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

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

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

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

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

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

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

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

----

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

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

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

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

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

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

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

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

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

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

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

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

== Unconscious Enemy in Equipment Screen ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--------

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

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

== Soldiers moved to outside of combat screen ==

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

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

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

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

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

==Great Circle Route==

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

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

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

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

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

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

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

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

-----

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

-----

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

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

-----

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

----

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

-----

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

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

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

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

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

== Soldier Recruiting Bugs Tested ==

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

==Floater Medic Bug==

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

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

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

==Strength Overflow==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Sources for a DOS4GW transplant ==

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

== Phantom Carried Casualty ==

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

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

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

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

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

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

==Elerium Base Bug==

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

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

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

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

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

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

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

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

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

See Also [[Talk:Displacer/PWT]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== 80-items limit on CE edition ==

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

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

Talk:Known Bugs

2011-05-10T17:38:51Z

FrederikHertzum: /* Bugs vs Exploits */

= Classification etc =

== Bugs vs Exploits ==

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

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

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

* i think that an exploit is somthing you can trigger and gain an advantage from. a bug may or may not have a known trigger, and does not give an advantage if it does.
* All exploits are bugs, either in implementation or design. When using a bug to gain advantages that bug is used as an exploit (you are exploiting the bug).

== Bugs vs Limits ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

= Specific Bug Discussions =

== Misc Technical Bug ? ==

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

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

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

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

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

- [[User:NKF|NKF]]

-----

== "Invisible Muton" bug ==

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

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

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

-----

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

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

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

- [[User:Bomb_Bloke|Bomb Bloke]]

----

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

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

----

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

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

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

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

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

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

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

- [[User:NKF|NKF]]

----

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

----

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

- by tequilachef (April 4th 2007)

== Vanishing snakemen ==

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

---

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

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

- By tequilachef (April 4th, 2007)

== Blaster Bomb Bug ==

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

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

== Disappearing Ammunition ==

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

------

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

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

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

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

==MC at end = MIA?==

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

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

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

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

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

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

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

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

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

----

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

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

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

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

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

- By tequilachef (April 4th, 2007)

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

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

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

: -[[User:NKF|NKF]]

== Crash Site in the atlantic ocean ==

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

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

- UFO: battleship, floater, alien harvest

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

- Date: January 2000

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

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

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

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

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

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

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

== Inconsistencies in MCing Cyberdiscs and Sectopods ==

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

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

:- [[User:NKF|NKF]]

== Facility Dismantle Bug ==

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

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

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

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

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

== Manufacturing Limit Bug ==

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

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

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

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

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

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

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

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

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

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

----

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

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

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

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

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

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

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

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

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

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

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

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

== Unconscious Enemy in Equipment Screen ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--------

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

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

== Soldiers moved to outside of combat screen ==

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

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

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

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

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

==Great Circle Route==

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

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

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

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

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

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

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

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

-----

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

-----

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

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

-----

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

----

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

-----

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

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

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

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

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

== Soldier Recruiting Bugs Tested ==

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

==Floater Medic Bug==

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

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

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

==Strength Overflow==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Sources for a DOS4GW transplant ==

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

== Phantom Carried Casualty ==

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

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

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

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

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

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

==Elerium Base Bug==

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

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

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

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

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

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

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

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

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

See Also [[Talk:Displacer/PWT]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== 80-items limit on CE edition ==

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

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

Talk:SOLDIER.DAT

2011-01-24T22:22:08Z

FrederikHertzum: /* Offset 64/0x41 Promotion flag */

Why would Missions and Kills be signed? You're never going to have negative values. Shouldn't they be unsigned??

- Danial

----

You would think that, wouldn't you? At least that's what I would've done in their place. You can't owe a few kills or missions!

But if you enter values of 0xFFFF into each, the base screen shows -1. Hence why they're signed.

- [[User:NKF|NKF]]

----

Zombie, I've changed back your recent change to offset 63, as you've been mislead a bit by corrupt data...

The files MAN_A.SPK through to MAN_N.SPK do not exist in a normal install of UFO, I'm afraid, and it was never intended for Soldier.Dat to point to them. They are simply the file names I chose when I coded my [http://www.strategycore.co.uk/files/index.php?dlid=428 custom uniform mod], so that aliens wouldn't display as troopers in the inventory screens anymore. I later added the same effect to my [http://www.strategycore.co.uk/files/index.php?dlid=470 map editer] as well. This affected the inventory screens and nothing else, by tweaking [[UNITREF.DAT|UnitRef[1]]] - The installation of either of my programs obviously adds the required MAN files to your game (as referring to any MAN file that does not exist causes a crash).

On the other hand, modifying Soldier[63] apparently changes the way the unit appears in the battlescape display, as well as what it turns into when it dies! This means that it is not only used to determine UnitRef[1] when battle begins, but UnitRef[0]/[38] as well, and most likely others...

That is to say, this byte gets set when you give a trooper armor. Armor dictates how a unit appears. However, it also indicates a units defensive values, and what item it will turn into when it dies. You didn't mention defense in your edit, but I would assume it also gets set to garbage when you fiddle with this offset.

I'll check this with a byte comparer when I get the time. With any luck, this'll also show me any remaining UnitRef offsets that are affected by this one. I'll update the article when I get some results.

- [[User:Bomb Bloke|Bomb Bloke]] 05:41, 6 November 2006 (PST)

----
My fault, but problems like these could easily be avoided with a readme file indicating what modifications are made to the game files. Never thought that an editor had modding chunks tossed in. That'll teach me a lesson.

Changing the armor field in soldier.dat ([63] or [062] or whatever the darn offset is), changes the image sprite in the battlescape without too many problems, but running through your unit list in the equip screen will crash the game if the number here is greater than 3 as there aren't any MAN.spk images to refer back to. Like you mention, the actual armor attributes are garbage (albeit '''''consistent''''' garbage as the numbers do not change). Just for giggles I did a couple dry runs with varying values to see what would happen to the death item and armor attributes. This may or may not be useful.

<table {{StdCenterTable}}>
<tr {{StdDescTable_Heading}}><th>Value</th><th>Unit</th><th>Death Item</th><th>Fr</th><th>Le</th><th>Ri</th><th>Re</th><th>Un</th></tr>
<tr><td>4</td><td>Sectoid</td><td>HP Clip</td><td>127</td><td>0</td><td>115</td><td>116</td><td>117</td></tr>
<tr><td>5</td><td>Snakeman</td><td>Plasma Rifle</td><td>118</td><td>119</td><td>120</td><td>121</td><td>122</td></tr>
<tr><td>6</td><td>Ethereal</td><td>PR Clip</td><td>123</td><td>124</td><td>125</td><td>126</td><td>18</td></tr>
<tr><td>7</td><td>Muton</td><td>Plasma Pistol</td><td>4</td><td>16</td><td>8</td><td>15</td><td>10</td></tr>
<tr><td>8</td><td>Floater</td><td>PP Clip</td><td>14</td><td>20</td><td>20</td><td>0</td><td>0</td></tr>
<tr><td>9</td><td>Celatid</td><td>Blaster Launcher</td><td>0</td><td>0</td><td>25</td><td>0</td><td>35</td></tr>
<tr><td>10</td><td>Silacoid</td><td>Blaster Bomb</td><td>0</td><td>24</td><td>18</td><td>0</td><td>10</td></tr>
<tr><td>11</td><td>Chryssalid</td><td>Small Launcher</td><td>15</td><td>6</td><td>0</td><td>8</td><td>8</td></tr>
<tr><td>12</td><td>Reaper</td><td>Stun Bomb</td><td>0</td><td>7</td><td>8</td><td>9</td><td>0</td></tr>
<tr><td>13</td><td>Sectopod</td><td>Alien Grenade</td><td>5</td><td>10</td><td>0</td><td>8</td><td>21</td></tr>
<tr><td>14</td><td>Cyberdisc</td><td>Elerium-115?</td><td>8</td><td>0</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td>15</td><td>Male Civilian</td><td>Variable</td><td>1</td><td>3</td><td>5</td><td>5</td><td>5</td></tr>
<tr><td>16</td><td>Female Civilian</td><td>Psi-Amp</td><td>0</td><td>0</td><td>52</td><td>0</td><td>80</td></tr>
<tr><td>17</td><td>Zombie</td><td>Unknown</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td>18</td><td>Invisible</td><td>Mind Probe</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td>19</td><td>Invisible</td><td>Sectoid Corpse</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td>20</td><td>Invisible</td><td>Snakeman Corpse</td><td>80</td><td>0</td><td>104</td><td>0</td><td>80</td></tr>
<tr><td>21</td><td>Invisible</td><td>Ethereal Corpse</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td>22</td><td>Invisible</td><td>Muton Corpse</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td>23</td><td>Invisible</td><td>Crashes (FLT?)</td><td>0</td><td>80</td><td>0</td><td>104</td><td>0</td></tr>
<tr><td>24</td><td>Invisible</td><td>Celatid Corpse</td><td>0</td><td>0</td><td>104</td><td>0</td><td>160</td></tr>
<tr><td>25</td><td>Invisible</td><td>Silacoid Corpse</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td>26</td><td>Invisible</td><td>Chryssalid Corpse</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td>27</td><td>Invisible</td><td>Reaper1 Corpse</td><td>0</td><td>160</td><td>0</td><td>104</td><td>0</td></tr>
<tr><td>28</td><td>Invisible</td><td>Reaper2 Corpse</td><td>0</td><td>0</td><td>104</td><td>0</td><td>160</td></tr></table>
I couldn't find out what item the Cyberdisc "unit" gives up when it dies, as the explosion happens even with Stun Bombs. I assume it's Elerium-115 as it follows the normal item list. The male civilian is a tough nut to crack also. I saw a death item of a Laser Rifle and a Small Rocket a few times - it's probably random or semi-random. Still, you can't stand over the "corpse" and pick up the item as it is invisible in the equip soldier screen. The Zombie is also strange as it cannot be killed by incendiary, most likely a hacked armor value will make the game assume you are wearing a suit of armor greater than Personal and apply the 0% modifier. A value of 23 will crash the game if you try and kill the unit so it's just an assumption that the death item is a Floater corpse.

I should also mention that some of the invisible units higher up on the list are probably tanks as the sound usually correlates to image. This doesn't hold for units lower in the list as I heard a movement noise of a Pistol or Rifle shooting rapidly for one of them! Strange stuff, but it can probably all be tied together once we know where the pointers are going.

- Zombie

-----

That's an easy one at least. As you mentioned, they follow the normal [[OBDATA.DAT|item list]] when turning into death items. Simply put, a unit will turn into object X, where X is 31 + Soldier[63]. That is to say, by default, a unit with no armor (value 0) will turn into a normal corpse (31). But if you crank the value up to, say, 19 (an illegal value), you get a sectoid corpse (31 + 19 = object 50). Pointers to items in the list that were never implemented in the game create weird results.

As for why the floater crashes when dying, perhaps it uses an illegal death scream or something. The corpse value seems legal enough.

The units which sound like tanks, aren't. The reason they makes those noises is because each unit has it's own movement [[SOUND|sound set]], which is determined by some value in [[UNITREF.DAT|UnitRef]]. It's one of the values I've been meaning to hunt down but never got around to...

Furthermore, some units slide, and some units walk. This is another value I've yet to hunt down, but it's important, because sliding units (snakemen, tanks) sound the same regardless of the terrain they're moving over. They also incur different TU costs as per [[MCD|MCD[39]-[41]]].

So obviously one or both of those values are also being determined by Soldier[63]. That'll make them easier to find in UnitRef.

Remember that a soldier is a soldier whether he's in armor or out of it. His armor does change the way he appears, and a few other things, but he's still a soldier at the end of the day. That said, a mod could easily be made that turns units wearing certain (hacked) armor types into aliens when combat begins, hence allowing you to easily deploy them at will. But there's no way it can be done just by tweaking values in save files, I'm afraid.

- [[User:Bomb Bloke|Bomb Bloke]] 14:45, 6 November 2006 (PST)

== Base Reference ==

As I was tinkering around with some files, namely for my Python XCOM 'editor' I noticed that on some of my soldiers the base reference was set to a crash site in loc.dat. So I'm thinking it got mislabled as a base referense when it should be a current location reference.

I haven't completely verified this yet, but just wanted to throw it out there.
-[[User:Pi Masta|Pi Masta]] 20:13, 6 February 2007 (PST)

== Book of the Dead ==

So after reading [http://www.quartertothree.com/game-talk/showthread.php?t=32835&page=4 this excellent XCOM thread] I was reminded I'd like to have some way of logging the names of who actually died in a mission. You forget the rookies so quickly...and there's all those letters to write. After a while you even forget your heroes, custom names or no. This would keep track of the names for the memorial.

I can see one way of doing this would be to just compare SOLDIER.DAT (or UNITREF.DAT) in two different saved games, pull out the names of the dead soldiers (along with rank, missions, kills info), and append it to a text file. Is a record in SOLDIER.DAT changed when the soldier dies, or what's the best way to determine who has died? Any advice from the experts? I see a bit in UNITREF.DAT but that's only for Battlescape saves, right?

Maybe later this could be linked to the DOS game's batch file, so every transition between Battlescape and Geoscape updates the Book of the Dead. --[[User:JellyfishGreen|JellyfishGreen]] 08:47, 7 May 2008 (PDT)

----

I'm sure that with a little bit of tweaking, Bomb Blokes logger could be programmed to do this. It might be a bit of work, but it's certainly possible. --[[User:Zombie|Zombie]] 09:07, 7 May 2008 (PDT)

----

Yes. SOLDIER.DAT is updated without destroying most of the information (not quite sure what is lost as I don't have a savegame with dead soldiers on hand), think rank is lost (first two bytes reset to FF FF) but soldier value and missions are not lost so that can be recalculated for non-hacked games). The kill count won't include any kills on the mission before being killed.

Hiring a new soldier will overwrite all of this.

--[[User:Zaimoni|Zaimoni]] 13:39, 7 May 2008 (CDT)

----

In a technical sense it's easy enough, the main problem is when the logging should be done...

My first thought would be to do it at the end of combat (by checking [[UNIREF2.DAT]] and [[UNITPOS.DAT (MISSDAT)]]), but the problem with doing that is that if the players save then quit mid-mission (with the intention of resuming later), most of their squad would mistakenly be listed as MIA. It gets even messier should the game crash.

On the other hand, doing the check when the player quits the game entirely is even harder to swing, because how does is know which save games to check?

Perhaps prompting the user whenever combat ends as to whether they wish to log or not? This isn't exactly transparent, but it's the best I can think up. Any thoughts?

- [[User:Bomb Bloke|Bomb Bloke]] 02:27, 8 May 2008 (PDT)

== Offset 6 ==

To test Seb76's theory I wounded 4 soldiers on a mission (close range pistol shots in the Skyranger) and flew straight back to base. From a save file taken as soon as they were back at base, all 4 soldiers showed positive wound recovery time, offset 4 = FF FF, offset 6 = FF FF. So apparently no record of what craft they were in unfortunately. [[User:Spike|Spike]] 14:19, 12 November 2008 (CST)
:This is quite unfortunate indeed because the code is crytal clear: offset 4 is copied into offset 6 before being cleared (offset 0xc is set inbetween but it is a detail) :( Maybe there is a bug in the game and the craft is already cleared elsewhere? What happens when the soldiers recover, do they get back to their original craft? [[User:Seb76|Seb76]] 14:37, 12 November 2008 (CST)

Maybe something changes between tactical.exe and geoscape.exe, I'll go back and check. By the time they get back to base, the wounded soldiers are indistinguishable from other unassigned soldiers, apart from Offset 0xC (wound recovery time). - No, in the tactical save, the offset 4, 6 and 12 values are unchanged from what they were pre-mission. So the update to these fields is done at the end of combat - as you have probably found out. I will check if I'm using XcomUtil, that might be interfering with the files somehow. Also, I checked and recovered soldiers don't get reassigned to a craft, they are assigned to NONE. This does sound like you have discovered the intended behaviour, but it's failing due to a bug. There would be a logical difficulty - if the craft is already full when you try to re-assign a recovered soldier to that craft, how would the game handle that situation? (I made sure I had enough free slots on my craft but still no re-assignment). [[User:Spike|Spike]] 15:07, 12 November 2008 (CST)

Hmm. Even if I hack the craft value (copied from the unwounded soldiers) into offset 6 of the wounded soldiers, they still don't re-assign back to the craft once they are recovered from their wounds. [[User:Spike|Spike]] 15:23, 12 November 2008 (CST)

Oops! It was XcomUtil that was interfering with the behaviour you deduced. Probably Scott Jones did not understand this behaviour? When I remove XcomUtil (actually I used a virgin re-install), I can see the changes you are reporting in Soldier.Dat - offset 6 is set to the craft number, offset 4 is FFFF. I've used different craft to confirm it is the craft number that gets written to offset 6. However, when the soldier recovers from wounds, they are still assigned to NONE - they don't get reassigned to the previous craft. Even with the correct values in offset 4, placed there by the game, there doesn't seem to be any behaviour that uses that data. So it seems like this is a half-implemented feature? [[User:Spike|Spike]] 16:18, 12 November 2008 (CST)
:They probably removed it because it is too error prone: as you mentionned, if the craft is full when the soldier comes back, it must not be reassigned to the ship. Also the ship may no longer exist (the entry could even be reassigned to another craft, which could be fighter only or worst: a UFO). That must be why the feature was not kept. [[User:Seb76|Seb76]] 16:45, 12 November 2008 (CST)

== Offset 64/0x41 Promotion flag ==

This generally flags as 1 if the soldier was last promoted in the last combat.

I was just checking a soldier listing and had a rookie with this field flagged. Does this field get flagged if the soldier was eligible for promotion even though there was no room? -[[User:NKF|NKF]] 08:46, 19 July 2009 (EDT)
: Sounds reasonable: the flag could be a signal for geoscape.exe to promote the soldier, rather than a flag that tells whether or not a soldier was promoted after his last mission (which really is useless information).[[User:FrederikHertzum|FrederikHertzum]] 17:22, 24 January 2011 (EST)

== the NAME field ==

I've just been testing with TFTD, and ran the same tests here.

The NAME field is a cstring, or "ASCIIZ" field. Care must be taken not to overwrite the last character of the name with anything but a 0 (NUL) character, otherwise the game will happily continue loading and rendering bytes past that point. Fortunately, the transfer fields (which follow name) are usually 0 as the soldiers are not usually transferring, so those ''usually'' act as a terminating null.

Thus, although one can get away with using that last byte, it's definitely not 'best practice' in any way.

Meh..forgot to sign. ~ [[User:Renegrade|Renegrade]] 07:40, 16 August 2010 (EDT)

Talk:Missile Defences

2011-01-19T03:20:15Z

FrederikHertzum: /* Notes about missiles in comparison with other modules */ new section

== Are Missile Defences worth building? ==

I cannot recall the last time I built those. Laser Defences come quite early, and for the gap between I find it better to rely on a garrison with a couple rocket HWP's.--[[User:Trotsky|Trotsky]] 03:39, 26 June 2006 (PDT)

----

It's arguable that none of the defence modules are worth building - except the mind shields. Well, that's not entirely true. Defences don't stop an attack. They just slow them down.

The aliens will just send another battleship continuously until one gets through. You can only suffer so many battleships that you'll end up dismantling your defences just to let them through. Also damage to the battleship has no control on the aliens that actually enter the base.

But for the missile module... Let's see. The main one would be to build a huge battery of missiles. This is cheap (in relation to a huge battery of fusion modules) and can be incredibly effective when coupled with a grav shield. It unnecessarily expands your base, but with so many missiles firing, it'll be very hard for any battleship to break through. It also makes each ufo attack take a long time to complete, and as the aliens will just send another battleship, it's never ending.

Now, its other use, check the lower level corridor layout of the missile defence module. It's quite unique when compared to most of the other modules. With careful planning, you can use this to control movement through the base.

It's sad, but the missile module is more useful in a purpose other than what it's there fore.

- [[User:NKF|NKF]]

----

Thanks for confirming that damage upon incoming battleships has no effect on the tactical battle - I have been wondering about that.
As for defences not being worth building: I agree with the idea of defences being only useful as slowing the aliens down (I remember playing a TFTD game in which they would send more than a ship an hour - I would love an option to "turn defences off", so that one could just put an invasion off until ready to face it). However, missile denfences are double worthless, since not only they are only capable of delaying an invading force, but also very poor at doing so.
I found that bit about the module being valuable in tactical combat quite interesting - perhaps it should be added to the main article?--[[User:Trotsky|Trotsky]] 06:33, 26 June 2006 (PDT)

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

I had frequent crashes when running base defence missions with missile defences built. I now don't use them and don't miss them. I heard a rumour that base defences reduced the number of attacking aliens when they hit but since I don't use missiles any more I can't confirm that. Egor

----

There can be any number of reasons for a base crash, and it's hardly just the missile defence module that's at fault. But this will vary from player to player.

As for the number of aliens - don't worry about it. This has already been tested and confirmed that the damage done to the battleship doesn't affect alien numbers.

- [[User:NKF|NKF]]

== Notes about missiles in comparison with other modules ==

I did a few calculations and found that you need 7 missile modules + grav shield to have the same effect as 2 fusion ball defences + grav shield (in terms of chance to destroy a battleship). This makes it less economically viable to build missiles for defences than fusion balls. In fact, fusion ball defences are by a small margin, the cheapest defences structures to set up. The following is a table of chances to kill a battleship
{| {{StdDescTable}}
| {{StdDescTable_Heading}} | Structure
| {{StdDescTable_Heading}} | Min
| {{StdDescTable_Heading}} | Min + 1
| {{StdDescTable_Heading}} | Min + 2
| {{StdDescTable_Heading}} | Min + 3
| {{StdDescTable_Heading}} | Min + 4
| {{StdDescTable_Heading}} | Min + 5
| {{StdDescTable_Heading}} | Min + 6
| {{StdDescTable_Heading}} | Min + 7
|-
| Missile || 7 || 0.39% || 1.95% || 5.47% || 11.33% || 19.38% || 29.05% || 39.53%
|-
| Laser || 6 || 3.80% || 10.64% || 23.18% || 38.23% || 53.28% || 66.52% || 77.12%
|-
| Plasma || 4 || 16.81% || 42.02% || 64.71% || 80.59% || 90.12% || 95.27% || 97.84%
|-
| Fusion || 3 || 40.96% || 73.73% || 90.11% || 96.67% || 98.96% || 99.69% || 99.91%
|}
(Min is the minimum required to kill a battleship -- the chance of these succeeding are virtually 0).

Clearly, you a lot less fusion ball defences to get to the same level of protection as with missiles. With 14 (Min + 7: costs $70.000/month) missile structures you have a slightly worse chance of killing a battleship than you do with only 4 (Min + 1: costs $56.000/month) Fusion ball defences. Even factoring in that missiles need only 7 modules ($35.000/month) and a grav shield ($15.000/month for a total of $50.000/month) and that fusion ball only need 2 modules ($28.000/month) and a grav shield (for a total of $43.000/month) for the equivelant protection level, the economy is definetly on the side of fusion ball (and all the XCOM games are basicaly just economy), especially considering that just having 3 fusion ball defences and a grav shield, costing 4 base slots and $57.000/month, the aliens will have a chance of less than 10% that a battleship will get through.

Known Bugs

2011-01-18T17:55:06Z

FrederikHertzum: "multiply your elerium stock by 50 times" is not correct english

== Game Destroying Bugs ==

These are the list of the worst bugs of them all, because they can render your entire game unplayable. Until a fix/ workaround is found, these bugs result in your entire X-com campaign being scuttled:
* [[Minimized interceptor bug]]
* [[Big text bug]]

== Base Construction Bugs ==

=== Base Disjoint Bug ===
Base facilities built along the right or bottom edges of the base building area may end up being cut off from each other by dirt walls, a bug in the routine meant to keep soldiers from accidentally exiting the map edges during [[Base Defense]] missions. The dirt walls can be knocked down by Blaster Bombs or excessive amount of heavy plasma fire during combat but are otherwise unbreakable.

[[image:bdb.gif|center|Base Disjoint Bug]]

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

[[XcomUtil]] works around this problem by stripping out the walls entirely in all the base modules.

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

===Displayed Base Maintenance Costs===
Although X-COM charges the right monthly fees for base modules, the maintenance fee displayed ''in the base info screen'' is always wrong. The displayed number is actually based on the placement within the base grid, '''not''' the price displayed in the in-game UFOpaedia. However, at the end of the month, the right fee is deducted. For more information, see [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]]. The Geo finance Graph shows a correct maintenance summary ([[LIGLOB.DAT]], updated once a month). Also see the next section.

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

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

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

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

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

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

===Fixes for Base Construction Bugs===

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

==Geoscape Bugs==

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

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

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

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

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

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

=== Interceptions: Last Shot Always Misses ===
When using Cautious attack when [[UFO Interception|intercepting a UFO]], your craft will stay at the maximum range of your longest-range weapon. When using Standard attack, your craft will stay at the maximum range of your shortest-range weapon. (Usually players use two weapons of the same type, so Cautious and Standard attack will behave the same in this regard.)

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

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

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

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

== Battlescape Bugs ==

=== Faulty Large Units ===
If you move a tank off a northward facing ledge, the rest of the tank will sink into a wall (if there is one), and cause the tank to get stuck. This won't happen if the tank moves off a south facing ledge as the primary quarter will fall after the rest of the tank. Aliens can also get stuck this way.

Another, potentially annoying bug occurs when a large unit's graphics become messed up. During a base defense mission, a rocket tank may end up looking like 4 silacoids bunched together.

===Unconscious Units are items===
This is actually an intentional programming choice... but it leads to several consequences which are bugs.

Firstly, any unconscious unit can be killed instantly by even a weak explosion, like being nearby an exploding AC-HE shell... even a Muton with 125 Health or an X-com agent in Flying Armor whose high armor ratings normally make him immune to AC-HE damage.
Secondly, no experience is gained for killing enemies in this manner.

You can prevent an unconscious unit's death from an explosion by picking it up... if a blaster bomb strikes the carrier and kills him, the unconscious unit will safely fall to the floor, unharmed.

Unlike a conscious unit (not wearing x-com armor), an unconscious unit can laze about in the middle of a fire without taking damage, since a UNIT standing in fire takes damage, but an unconscious unit is an item, which all ignore fire.

Forcing an MCed alien to pick up an unconscious X-com agent and carry him in its right hand can cause weird things to occur when you release the mind control. I think the game might crash when the alien tries to shove the agent into its magic pocket.

If a non-flying unconscious unit wakes up while being carried by a flying unit, it will gain some sort of temporary hover ability. (I once placed an unconscious Chryssalid in my flying agent's backpack. A few turns later, some growls and screams were heard from overhead.)

Save space! Each conscious unit takes up 1 tile (4 tiles for large units). An unconscious unit does not use up the tile... this might conceivably be useful if you wanted to abort a mission, but several panicked units were preventing other agents from boarding the skyranger...
X-com agents refuse to ride piggyback or be picked up while conscious. So, if you want a non-flying unit to reach an 2nd floor place with no stairs or elevator, you will have to knock him out, then either throw him up, or have a flying unit pick him up and drop him... and presumably administer stimulant.

This also leads to the INVISIBLE UNIT glitch. Frequently happens during Base Defence missions, since the item table is usually maxed out. Basically, the item table is so full that killed units do not leave corpses. However, this also means that unconscious units do not turn into the Unconscious Unit item. The KOed unit will disappear from sight, but will still be visible as a red number and as a blue/yellow dot on overhead map. Since the unit is still a unit and not an item, you will be able to shoot it with projectile weapons and kill it. ALSO, this method enables you to raise any unit's stun bar all the way to 255, since you can still increase the stun meter, despite them already being unconscious.

===Funky Fire===
If a unit (alien or friendly) is on fire or standing in flames, an [[Incendiary]] explosion ''anywhere else on the map'' will do a small amount of damage to it, even if you just shoot an IC round at a random patch of ground.

Similarly, if a unit (friendly units only) is standing in smoke when an incendiary explodes, it will take stun damage. This makes the combination of incendiary munitions and smoke quite hazardous until such time as all troops are armored.

There is a [[Talk:Incendiary#Incendiary_Bug|working hypothesis]] for the cause of this bug, which is that each and every Incendiary explosion triggers "end of turn processing" for Smoke and Fire - including fire damage, stun damage from smoke, fire spreading checks, and possibly "catch on fire" checks for units in fire.

Note that X-Com units wearing any kind of armor are immune to fire damage and IC-induced stun damage. Xcom HWPs are immune to stun, but take 40% damage from Incendiaries and WILL get killed quite efficiently by funky fire.

=== Collectors Edition Blaster Bomb Bug ===

Also known as Vertical Waypoint Blaster Bomb Bug.

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

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

This does not happen if you plot the waypoints at an angle. Or, if the blaster bomb flies right off the map, it will reappear at the proper waypoint as long as there are additional waypoints placed after the vertical move. The bug makes it impossible to fire Blaster Bombs up or down elevator shafts. Aliens are also affected by this bug.

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

This bug also applies to the [[Disruptor Pulse Launcher]] in TFTD.

===Blaster Launcher Dud Shells Bug===

Shots which have only one waypoint, or explode before reaching their first waypoint, leave the Blaster Launcher showing 0 rounds, but still containing a dud shell which must be unloaded before the launcher can be reloaded. On earlier versions of the game (pre-Win CE) this also happens with reaction fire, and with 1-waypoint shots that fly off the map.

=== The trouble with Mines in General ===

Proximity mines are strangely implemented in UFO and TFTD. While they behave as you would expect them to half of the time, the mines do not behave like conventional weapons.

First, experience attribution is awarded to the person that sets off the mine.

Secondly, the armed states for [[Proximity Grenade]]s in both UFO and TFTD are NOT stored in save games. If a proximity grenade is primed, then the game is saved and reloaded, the grenade will not only not go off as it should, but the "Prime Grenade" action will still be absent, so it's impossible to re-arm it.

=== Grenade Timer Behaviour ===

A primed explosive (Grenade, High Explosive, Alien Grenade) will not explode if it's still in your inventory (hand, belt etc) when the timer runs out. It will only detonate when it's on the ground. If your soldier falls unconscious or gets killed, the primed explosive will be counted as being on the ground. Then it will blow up, likely taking out your gear and body. This 'feature' allows for the hot potato or [[Grenade Relay]] strategy which is fairly unique to X-COM where a live grenade well past its use-by date can be passed from squad member to squad member.

For a more a detailed explanation on detonation conditions, see [[Understanding Grenades]].

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

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

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

For more details, see [[Explosions#Mile-High_Madness|Mountain Madness]].

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

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

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

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

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

===20 Proximity Grenade Limit===

The array used to denote armed [[Proximity Grenade]]s is limited to 20 entries, meaning you are limited to 20 active mines at a time. The 21st and subsequent Proximity grenades can be primed like normal and will give appropriate messages, but they will not detonate even when the normal trigger conditions are met. Note that Proximity Mines that have detonated or otherwise been destroyed are removed from the array, freeing up positions; the limit is 20 ACTIVE Proximity Grenades at one time. In normal gameplay, this is probably not a restriction, in light of the [[Known_Bugs#80-Item_Limit|80 Item Limit]], since you'd need to have more than 1/4th of the cargo space in the dropship filled with Proximity Grenades.

===Base Defense Elerium bug===

On DOS versions of UFO Defense, Elerium pods may spawn as items from the base stockpile during a Base Defense bug. Each pod represents 50 units of Elerium and will be normally collected after the mission, same as any other item such as Heavy Lasers or Blaster Bombs. HOWEVER. The program will potentially generate 1 elerium POD for every 1 UNIT of elerium in your inventory. Thus, if you had only 10 lasers and 50 Elerium listed in your Sell screen, you would see 10 lasers and 50 Elerium Crystals in your Soldier Equip Screen, which would translate to 50 Elerium pods and 10 lasers scattered around your base. This equals 2500 Elerium, BTW. You basically have the potential to multiply your elerium stocks by 50.

===Berserk HWP crashes the game===

Admittedly, this is unlikely to arise under normal play. But, anyhow, your HWPs can only lose morale by killing friendly units. Not much for each unit killed, either. Anyhow, a berserk HWP will crash the game. (except for the Hovertank/Launcher, which does not fire when it goes berserk.)
Likewise, if you MC a cyberdisc or Sectopod and have it kills lots of aliens, it'll go berserk and crash the game. The error happens because of an oversight from the developers: the built-in weapons of HWP are handled differently from handed weapons, no OBDATA.DAT entries exist for them. The berserk code will try to access the nonexistent entry, resulting in a crash. The Celatid has yet to be tested.

===Limited Unit Slots - Battlescape Crash===

This tends to arise during Base Defence Missions. The game is was designed to be limited to 40 soldiers/hovertanks and XXXX aliens for a total of XXXX . Having a full complement of soldiers during a Superhuman difficulty base defence will max out these limits. Thus when either side starts playing around with mind control too much, something goes wrong causing the entire game to crash.
It might also be something to do with maximum items on the battlescape.
In any case, the workaround seems to be killing aliens and destroying items on the battlescape... doesn't always work, but it seems to help.
You might want to make several in-battle saves for these situations, even if you normally play Ironman mode.

== Character Inventory Bugs ==

=== Alien Inventory Stacking Bug ===

'''WARNING:''' When examining an Alien's inventory (via an Exploit), you will see that sometimes the alien will stack multiple items of equipment on the same slot - its right leg. It's not always obvious that there are multiple objects in the slot until you 'pick up' the first object and can see other objects still in the slot.
Before you remove an item from the Alien's right leg, make sure you have enough time units to place it somewhere else. If you run out of time units, you will likely have to force a quit and cannot save your game. It '''may''' be possible to move the item to the left leg slot for 0 TUs, '''if''' the item will fit in that slot. If not, you will have to terminate the game. (Press ALT-TAB to get to any other window, then CTRL-ALT-DEL to bring up Task Manager, and then terminate the process that corresponds to the game).

=== XComUtil Inventory Stacking Bug ===

A problem similar to the Alien Inventory Stacking Bug can also occur for X-COM Soldiers, when using XComUtil. The algorithm used to assign weapons in XComUtil MUST assign all weapons to troops, so if there are more weapons than soldiers, excess weapons are stacked onto the leg slot of the first soldier in the dropship. This was a deliberate choice by Scott Jones to make this encumbrance obvious to the player. This can be readily corrected in the "equip soldiers" screen before a mission. Else, see "Alien Inventory Bug", above.

=== Item-stacking Bug ===
It is possible to put more than one item in a given spot. When an item is stacked with a [[Stun Rod]], this can make it possible for X-COM soldiers to perform "melee" attacks. See [[Item Stacking Bug]] for more details.

===Carrying Unconscious Units===
If one of your soldiers is carrying an unconscious unit in their hands and the unit either wakes up from stun or dies, they will be removed from the Inventory display, but will still appear to be in the carrying soldier's hands in the Battlescape. Clicking on the phantom body in the Battlescape will crash the game!
This error can be easily cleared by switching to the Inventory screen and moving another item into the hand that used to be carrying the body. Even swapping the gun to the other hand will do. Refer to : [[Unconscious#Bug|Unconscious]].

===Disappearing Ammo===
Partially-used clips in alien or X-COM weapons disappear at the end of a mission. This dictates that you should try to use clips that are not full. However, in DOS versions of the game, you can unload used clips to recover them as full clips with the tradeoff of all loaded clips (used or otherwise) will count as spent and disappear (this shouldn't seem to be a problem, until you start using blasters and will find that you're running out of ammo fast). You can also use [[XcomUtil]] to recover partially used clips. Even when used clips are discarded, you will still get credit ([[Scoring|score]]) at the end of missions for recovering them.

When aborting a mission, any full clips loaded in any alien weapons brought back to the transport/access lift will not be recovered unless the clips are unloaded first. This includes [[Blaster Bomb]]s and [[Stun Bomb]]s.

===Weightless Loaded Ammo===

Ammo that is already loaded into a weapon at the start of a mission does not count towards a soldier's Encumbrance. If the weapon is subsequently unloaded and reloaded during the mission, the soldiers encumbrance will increase. This would only be noticed if the unloaded clip was not discarded (e.g. because it was not fully empty). This is due to a bug in the game's weight calculation routine that was uncovered (but not caused) by Seb76's inventory screen improvements.

=== Equip Phase Ammo Load Error ===

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

Probably the only impact of this bug is that XComUtil can't detect the fact that the ammo is loaded into the weapon, for the purpose of AutoCombat. It might have other subtle effects on any utilities that deal with equipping soldiers. [[User:Spike|Spike]] 20:03, 11 March 2010 (EST)

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

== Storage and Transfer Bugs ==

=== 80-item Limit ===
When loading up your Avenger for a massive UFO assault or arming soldiers for a [[Base Defense]] from your overflowing stores, you will likely hit this limit.

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

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

Another bug concerning this limit happens when there are unresearched (alien) items in your stores during a base defense mission. Even though the item cannot be used during the mission, the game still allows you to equip your soldiers with them. This rarely happens as the alien items are very low on the item list, but if your base is lean and mean with under 80 items total, everything will spawn regardless of research.

===Sticky Craft Transfer Fee glitch===
As pointed out by [[User:Zombie|Zombie]] and [[User:Danial|Danial]], transferring any craft causes '''''all subsequent transfers to have that cost added to it''''', for as long as the craft is in transit. Additional craft in transit will add additional fees. (This has also been called the Exponential Transfer Fee bug, although it's actually additive, not exponential.)

Example (all numbers are only approximations):
Cost of pistol transfer (↔ = to or from)
EU ↔ USA 80
EU ↔ Asia 100
USA ↔ Asia 120

Cost of craft transfer
EU ↔ USA 1600 ''Notice how transfer fees always work as relative percents,
EU ↔ Asia 2000 ''probably on a distance-based formula
USA ↔ Asia 2400

Cost to transfer '''pistol''', after transferring craft from EU to Asia for $2000
EU ↔ USA 1680 (80+1600)
EU ↔ Asia 2100 (100+2000)
USA ↔ Asia 2520 (120+2400)

The cost of the craft transfer "sticks" to '''all''' subsequent transfers, until the craft arrives - although it acts on a proportionate basis, which is probably distance related.

Unfortunately, this cost is '''additive'''. That is to say, if you transferred a second craft from EU to Asia while the first was still in transit, it would cost $4000 ($2000 plus $2000 - it too suffers from the glitch!), it would then cost e.g. $4100 to transfer a pistol from EU to Asia. Having even more craft in transit would add even more fees.

This only appears to happen with aircraft, although it does happen for them all. So try to transfer aircraft individually, and not transfer anything else while you do - assuming you aren't awash in money. (The bug will cost you in the low thousands of dollars per craft being transferred.)

A related problem is that, if you are in the Transfer screen, start to transfer a craft, and then cancel because you remembered you wanted to send something else first - if you then try to Transfer something on that same screen, ''it will still get the sticky craft fee added''. Try it and see. You have to back up out to the main Base screen and hit Transfer again, to get rid of the sticky fee from a canceled craft transfer.

===Fuel dump on transfer===
Transferring a craft with 100% fuel will dump it somewhere along the way.
When it arrives at its destination, its fuel gauge will read empty (ie: 0% FUEL), but it will be listed as ready. If you launch your craft for a mission (any mission will do) its fuel gauge will still read empty.
 
This can be [[ExploitsA#Infinite_Fuel|exploited]], but it is very annoying if you want to quickly turn around a troop transport for another mission.
 
You can force a refuel by sending out the craft and immediately recalling it back to base.

===Transfer Limit cash eater===
Only 100 items can be in transit at a time. (Here, a transfer of e.g. 200 Elerium counts as one "item". Also, all soldiers are counted individually.) If you go over the limit, you will get a warning that there is no more transport capacity. If you STILL try to transport something after getting the warning, the item will stay where it is, but the transportation cost still gets deducted. Bad if you're shuffling expensive aircraft. The extra cost isn't that bad. Recovering just one alien weapon will likely cover the money you will lose to this bug over the course of a game.

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

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

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

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

===Storage Limit===
You can not store more than 9,999 of any one item in the general stores at a specific base at one time. However, this will likely only happen with [[Alien Alloys]] or [[Elerium-115]].
Still, consider yourself warned. If you're coming close to the limit, consider transferring the extra to other bases or even selling it, as any extra collected beyond the limit will 'disappear' and be wasted.

===Exceeding Storage Limits===

The storage capacity of a base is normally limited by the capacity of the General Stores. However this can be exceeded in a number of ways:

* By exploiting some of the Base Storage Anomalies (see below)
* By storing surplus equipment in transport aircraft (up to the 80 item limit). Note that if both the aircraft and the base are full, you can no longer move equipment between the aircraft and base (in either direction).
* Anything manufactured at the base will be stored there regardless of the base's General Stores capacity.
* Anything captured on a mission by an aircraft operating from the base will be stored at the base, regardless of the base's General Stores capacity.

These could perhaps be considered minor exploits.

===Base Storage Anomalies===

There are some quirks in how the game calculates, and displays, base storage capacity used and available. These quirks are not all consistent with each other, which leads to some strange behaviour. A typical example would be moving a set of items out of Stores, immediately trying to put the exact same set of items back into Stores, and this failing due to "insufficient space". A more detailed discussion is in [[Talk:Base Stores#Base Stores Anomalies]].

== Soldier Limits and Recruiting Bugs ==

=== Soldier Recruiting Limit ===

There is a hard limit in the game of 250 X-COM soldiers in total across all bases (not 250 per base).

The error message that pops up when you try to hire more is:

"NO MORE SOLDIERS ALLOWED"

"You have already recruited the maximum number of soldiers."

=== Soldier Recruiting Bugs ===

Also there are 3 bugs related to recruiting soldiers:

* You still get charged for Soldiers you try to purchase above the No More Soldiers limit.
* The error message that appears when you hire too many soldiers must be dismissed (click OK) once for each soldier over the limit, i.e. up to 255 times.
* You get also charged for Soldiers you try to purchase above the Transfer Limit (100 at a time).

=== Soldier Battlescape Limit ===

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

== Manufacturing and Research Bugs ==

=== Cancel Manufacturing Bug ===

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

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

=== Zero Unit Manufacturing Exploit ===

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

=== Research Rollover ===

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

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

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

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

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

For now:

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

=== Overcrowded Engineers And Scientists ===
In the Dos version (probably the others as well) if you hire more than 255 engineers in a single base, the number of engineers in the base will read a negative number once the 257th engineer arrives. Any Engineers engaged in projects will continue to work on them, but if you cancel the project you will lose engineers until you have lost 255 of them.
This bug also affects scientists. It may be exploitable to pay a negative salary at the end of the month.

If you hire exactly 256 scientists or engineers, the total rolls over to zero. You pay zero salaries, and the resulting free Manufacturing / Research is limited only by the capacity of your Factories / Laboratories. Also works in TFTD.
 
NOTE: you need to make sure that not all of their projects finish at the same time.
Otherwise, you would be stuck with 0 'available' workers/scientists, i.e. unable to assign them to a new project.

===Manufacturing Limit Bug===
The number of hours remaining on a [[Manufacturing_Profitability#Profit_tables|manufacturing project]] is stored in a two-byte integer. If you build enough items that the total number of Engineer Hours required for construction is above 65535 hours, it will wrap around to 0 hours and display from there. Typically this drastically understates the amount of time that will be spent working on the items, but strictly speaking, it only subtracts 65k hours (so a huge project like 120k hours would still show ~55k hours' worth of Engineer time needed).

This bug is not dependent on the number of engineers assigned to the project; it is a function of the number of engineer hours needed. You will most likely run into it when trying to build 2 Avengers at the same time or when queuing up large orders of items in bulk, such as armor or Laser Cannons. As a practical example, the number of Avengers needed to trigger the bug is 2. The number of Laser Cannons is 219. Toggle back and forth between 218 and 219 laser cannons at the beginning of a project to see the effects.

It is known with certainty that this exists as a display issue - the screen will say you need less time than you should when you go over 65536 Engineer hours. [[User:Arrow Quivershaft|Arrow Quivershaft]] is also sure he's seen it eat an Avenger... he ordered two but only got one, even though it took the time, and cost the money, for two. He's tried to replicate this and hasn't been able to, however. So it clearly is at least a superficial display issue, and may be more than that ... possibly dependent on even something else. In any event, keep an eye on projects with more than 65k Engineer hours (and report back here!)... or just avoid going that high.

===Manufacturing Completion Time Display Bug===

If you start a new manufacturing project at 00:01, and the screen displays a completion time of 5 hours, you might expect the work to complete at 05:00 or 05:01. In fact it will complete at 06:00, one hour longer than indicated.

The reason for this bug is that the time left to complete a project is decremented by the game by one hour, every hour, on the hour(XX:00).

This display behaviour is consistent with what is shown while manufacturing is in progress. For example, if time remaining is shown as 0 hours, the work will complete at the beginning of the ''next'' hour. In effect, the displayed number is the integer-truncated form of the real time remaining. In the first example given above, the real time to completion is 5 hrs 59 min, misleadingly truncated to 5 hrs.

===Manufacturing Rate Interruption Loss===

In addition, as a result of integer truncation (see previous bug, Manufacturing Completion Time Display Bug), every time production stops, you lose an hour of manufacturing. Therefore, for most efficient production, manufacture in large batches (or increase batches while they are still in progress) to keep manufacturing as continuous as possible.

===Manufacturing Rate Limit===

There is a maximum production rate of one unit of any given type per hour per base. For example, though Alien Alloys / Aqua Plastics require 100 Engineer/Technician Hours per unit, even with 250 Engineers/Technicians you can only produce 1 unit per hour.

===Manufacturing Rate Limit Bug (TFTD)===

In UFO Enemy Unknown, the Manufacturing Rate Limit is just an irritant. The game prevents you from allocating more Engineers than is useful. In Terror From The Deep, there is no such safeguard. If you allocate more Technicians than are required to produce 1 unit per hour, the excess effort is just silently wasted. The unproductive Technicians are no doubt wasting their time playing retro computer games on their engineering workstations.

===HWP Fusion Bomb Ammo Cost Bug===

The HWP Fusion Bomb ammunition type, and its TFTD equivalent the ammunition for the SWS PWT/Displacer, appear to have the wrong manufacturing costs.
The vehicle version is ''less'' portable and ''less'' powerful than the personal version (Blaster Bomb), ''less'' capable than the craft version (Fusion Bomb) - and costs ''more'' than either of the others in total cash and in materials. In particular, it makes no sense that the small missiles on the HWP/SWS use up ''more'' of both Elerium/Zrbite and Alien Alloys/Aqua Plastics than the Craft version.

To correct this error, the craft round should have the higher base price, ''and'' the material requirements that are currently assigned to the SWS/HWP round. (It's debatable whether the SWS/HWP rounds should be more expensive than the man-carried rounds.) More discussion is on the talk page of this article.

== Other Bugs ==

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

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

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

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

In the dos version, the text that you see is simply a memory dump in mode-13h (the 320x200x256 colour screen resolution) and the text colour is based off the changes to the palette that the game made. The batch file coordinating the two main programs [[Geoscape]] and [[Battlescape]] often succeeds in soldiering on after a crash. In the Windows version of the game, the game simply crashes back to the desktop, unless you're using the [[XcomUtil]] split executable variant (which uses a batchfile).

Some things which will tend to cause this problem:
* Overzealous use of Psi

At least some of the instability crashes can be fixed by replacing the DOS/4GW dos extender with a later version from another DOS game.

[http://syndicate.lubie.org/synd/html/synd_patches.php One of these], for example. Link to Syndicate fansite, instructions included.

=== Cash Rollover Bug ===

When your cash balance goes over $2,147,483,647, it will rollover and become $-2,147,483,647. Which means your game is done for, unless you use an editor. Fortunately, by the time you accumulate this much cash, you have usually completed all necessary research to win the game.

=== UFOPaedia Craft Weapon Hit Probability Bug ===

There is a bug in the in-game UFOPaedia. It mistakenly reads the damage value field when reporting the hit chance for a craft weapon. Hence:

* Cannon shows 10% not 25%
* Avalanche shows 100% not 80%
* Laser Cannon shows 70% not 35%
* Plasma Beam shows 140% not 50%
* Fusion Ball shows 230% (!!!) not 100%

Possibly the reason this bug was missed during testing is that the first weapon in the data files, Stingray, actually does have Damage equal to its hit probability.

=== Losing My Favourite Game ===

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

== See Also ==

=== [[Known Bugs (TFTD)]] ===
For bugs that '''only''' affect X-COM: Terror From The Deep.

[[Category: Oddities and bugs]]

Talk:Retribution Missile Launcher (Apocalypse)

2011-01-18T04:50:50Z

FrederikHertzum: Created page with "I find it likely that this weapon was ment to be ''the'' weapon against overspawns -- unfortunately, the overspawn is hardly a threat to anything but itself and the alien all..."

I find it likely that this weapon was ment to be ''the'' weapon against [[overspawn]]s -- unfortunately, the overspawn is hardly a threat to anything but itself and the alien allies.

Talk:Overspawn (Apocalypse)

2011-01-18T04:28:46Z

FrederikHertzum: /* Possible reason for the existance of the live research entry. */ new section

The overspawn seems to be a vehicle, if you look at the hostile VEHICLES pane when one is released. If it were a UFO, it could basicly be recoverable once badly enough damaged? Unnamed vehicle...?

Otherwise I can only think of a special weapon or desperate agents on the ground with stun grapples trying to avoid being stomped all night...

--[[User:Karpatius|Karp]] 04:17, 18 August 2008 (PDT)

: The Overspawn is definitely implemented as a vehicle in the game. Through a little game editing trickery with XED, you can gain control of one. In fact, it has hardpoints that mimic the Annihilator, although the shape of its option space differ somewhat (it's wide, but roughly the same amount of space). It has a few weird controls when you try to manually control it. It has an automatic wander command that kicks in every so often where it'll wander randomly in either four compass directions and crush anything in its way. This always happens no matter what control mode you're in. Oddly enough, this attack is treated as an alien attack. If you try to use the home/end/pgup/pgdn keys, things get weird. Usually they'll crash the game, or maybe make the overspawn destroy whatever building it's standing next to and teleport it to the other side of the building (as if it charge dthrough building?). Basically it's just another incomplete part of the game. I'm guessing if there was a play-as-aliens portion to the game, you'd probably get control one of these big guys. - [[User:NKF|NKF]] 05:42, 18 August 2008 (PDT)

::Whoa... play as the aliens? Sounds cool and incredibly frustrating at the same time ( presuming automated X-COM is atleast somewhat effective ). Too bad that didn't make it into the game.

::Still, I'd hate to competely level such an attractive city. ( Yes, I love Mega Primus looks )

::--[[User:Karpatius|Karp]] 06:18, 18 August 2008 (PDT)
::: I'm guessing it was set up to act uncontrolled because you might get to run it when you went to the next alien diminsion that was planned but not implemented.--[[User:(name here)|(name here)]] 07:01, 18 August 2008 (PDT)

I don't THINK it is possible to capture an overspawn... can an overspawn crash land??? [[User:Jasonred|Jasonred]] 08:42, 17 March 2009 (EDT)

== Possible reason for the existance of the live research entry. ==

The reason that the megaspawn has a live entry may be because the game requires a live entry and a dead entry for all aliens that have either -- i.e. no autopsy possible if there's no live data available. Essentially, it would be a (minor) design flaw of the software.
[[User:FrederikHertzum|FrederikHertzum]] 23:28, 17 January 2011 (EST)

Marsec Heavy Launcher

2011-01-18T04:17:05Z

FrederikHertzum:

The Marsec Heavy Launcher is as its name implies. Heavy. It's also the largest squad-based weapon known to X-COM.

The Heavy Launcher is one of the most powerful weapons that X-COM can initially purchase. It fires missiles that automatically lock on and chase down their targets and will automatically adjust their headings if the target moves. If the target manages to evade the rocket by means of teleportation, the rocket will continue to correct its heading to attempt and relocate the target and will not stop until it either hits the target, collides with something solid or runs out of fuel. If the rocket flies off the map, it will not explode.

Two variety of munitions are offered, standard high exposlives and incendiary. The size of the rockets are considerably smaller than the [[Rocket Launcher|rockets]] used in the [[First Alien War]], so more can be carried.

A late development of Anti Alien Gas rockets are also available as a means of dispersing anti-alien toxin over a wide area.

Do note that although this is a devestating weapon, the use of high explosive and incendiary rockets for combat of alien forces within the city in public areas is discouraged. The collateral damage that the rockets cause can induce extreme damage to property, which X-Com is advised to keep to the barest minimum.

There is also the chance that civilians might get hurt in the blasts, but that is merely an unfortunate mishap that often goes unnoticed by the building owners.

The [[Marsec Minilauncher]] is a more favourable alternative for use in populated areas.

== Stats ==
[[Image:Marsec_Heavy_Laucher_(UFOpaedia).png|frame|Heavy Launcher]]
=== Heavy Launcher ===
<table><tr><td>[[Image:Marsec_Heavy_Laucher.png|left]]</td><td>
* Size: 3 x 5
* Weight: 9
* ROF: 0.45 r/s
* Accuracy: 10%
* Manufacturer: [[Marsec]]
* Base Price: $800
* Minimum Weekly Stock: 2
* Maximum Weekly Stock: 4
* Battlescape Score: 4</td></tr></table>

* Two-handed weapon

"A guided missle launcher that can fire explosive or incendiary missles. It is an extremely devastating device and should be used with extreme caution. It is unwieldy because of its bulk and Agents with heavy launchers should at least be equipped with a supplementary weapon such as the Megapol Lawpistol."

== Ammunition ==
[[Image:Marsec_Heavy_Launcher_HE_Missle_(UFOpaedia).png|frame|Heavy Launcher HE Missle]]
=== Heavy Launcher HE Missle ===
<table><tr><td>[[Image:Marsec_Heavy_Launcher_HE_Missle.png|left]]</td><td>
* Size: 1 × 3
* Weight: 4
* Power: 90
* Damage Type: Explosive
* Blast Radius: 8
* Ammo: 1
* Range: 75m
* Manufacturer: [[Marsec]]
* Base Price: $40
* Minimum Weekly Stock: 5
* Maximum Weekly Stock: 20
* Battlescape Score: 1</td></tr></table>

"High explosive ammunition for the Heavy Launcher."
----
[[Image:Marsec_Heavy_Launcher_IN_Missle_(UFOpaedia).png|frame|Heavy Launcher IN Missle]]
=== Heavy Launcher IN Missle ===
<table><tr><td>[[Image:Marsec_Heavy_Launcher_IN_Missle.png|left]]</td><td>
* Size: 1 × 3
* Weight: 4
* Power: 90
* Damage Type: Incendiary
* Blast Radius: 8
* Ammo: 1
* Range: 75m
* Manufacturer: [[Marsec]]
* Base Price: $40
* Minimum Weekly Stock: 5
* Maximum Weekly Stock: 20
* Battlescape Score: 1</td></tr></table>

"Incendiary ammunition for the Heavy Launcher."
----

=== Heavy Launcher AG Missle ===
<Data forthcoming>

{{Equipment (Apocalypse) Navbar}}

[[Category: Apocalypse]]
[[Category: Agents Equipment (Apocalypse)]]

Controls (Apocalypse)

2011-01-18T04:05:43Z

FrederikHertzum: typo

X-COM agents can be controlled somewhat automatically in their actions and reactions to hostiles depending on the settings you choose. To see what each button does, please consult your manual.

== Attack Modes ==
'''Safe Mode = Blue'''

The agent will seek cover first (even so far as to break line of sight with the foe) then engage in combat sporadically. This is a very similar attitude when panicking. Avoidance is paramount. This mode can sometimes be unhelpful because they will ignore your movement commands.

This mode is primarily used if you want the unit to avoid combat. This mode may not be used often with agents, and is quite redundant even with non-combat units under your control.

'''Cautious Mode = Green'''

The agent will position themselves behind an object, if one is available, and start firing if allowed to do so. They will sometimes run from an explosive (which is VERY BAD if a Boomeroid is close by). Your agents are aware of enemy positions as they shuffle for a position to fire, but they won't try to break line of sight. The best aspect of using this mode is that its an equal balance of avoidance and offence.

In real-time combat, if the agent is next to a corner and is under fire from an enemy, the agent will perform an automatic strafing manoeuvre. The agent will sidestep behind the wall for cover, and then sidestep out again every so often and return fire. This is extremely useful in places like wide doorways or when you are near any pillars.

This mode is a good all-rounder that is probably used mainly for its real-time combat sidestepping feature near corners.

'''Agressive Mode = Red'''

Your agents will not seek cover or from grenades, your agents will fire towards hostiles even though there might be neutral security forces in the vicinity, your agents will happily run through a swarm of gunfire. In short, they obey your every command.

This is most common option which is used when fighting against enemy forces. You do not want your soldiers to stop firing when stationary. Offence is the best defence. If you have a defensive line outside the Alien craft on either side of the door, the last thing you want is for your Agents to get up and shuffle around for a position as the aliens bear down on them. This delay will get them killed. DON'T do the blue chicken dance.

The only time your agents will move of their own will is to escape fire or stun gas, but will shortly return to their original positions as soon as the gas or fire has cleared. It may help to move your troops to defensive positions manually instead of relying on the computer to do it for you.

This mode is best used when you want full control over the units you're currently controlling. It is by far the most popular and most players select it automatically and do not change it for the rest of the battle.

== Movement Orders==
Note: If set to walk or crawl, an agent that has no weapons will run if they see an enemy, but resume walking/crawling once any visual contact is lost.

===Crawl===
The agent will drop to the ground and will start to crawl. You need at least 2 free tiles in order to crawl. If in a confined situation, the soldier will stand instead.

Going prone reduces your size as a target and improves your weapon accuracy considerably. However you will move very slowly, and you will not be able to look over small obstacles like low walls.

In Turn based, TU movement consumption will be at its highest.

===Walk===
The agent will walk to your way point, or walk (usually, but will run sometimes) to a position when seeking cover. An agent is able to fire a weapon when walking but at reduced accuracy. Stamina drain and recovery is equal, so stamina is not consumed nor recovered while walking.

The only two reasons to walk is to fire on the move and to conserve stamina.

Your walking speed will vary depending on your speed and encumbrance levels. Single file formation and some disposition settings will override the walk and make the agent sprint in short bursts.

In Turn based, TU consumption and Stamina are consumed at the normal rate.

===Run===
The agent will run until tired. Your soldier cannot fire their weapons when moving. Running is very dependant on Stamina. The more your Agent has, the longer they can run. Once they run out of stamina, they will default to walking until they regain some stamina.

In Turn Based, the TU consumption is reduced, while Stamina consumption is increased.

===Kneel===
When ordered to kneel, agents will drop to a kneeling position as soon as they have no movement orders. Kneeling makes an agent a smaller target like crawling, but not as much and agents can peek over low objects with minimal exposure. Kneeling also makes aiming more steady so that agents get an accuracy bonus when kneeling, but again, not as much as when crawling.

Agents cannot move when kneeling and any movement orders will make them stand up and kneel again when the orders have been finished or cleared. Turning is still allowed. Agents will keep kneeling ( and standing up when moving ) for as long as the kneeling button is active.

In Turn Based, TU's are consumed whenever an agent has to stand up and kneel back down, so careless use can waste a lot of TU's as the agent kneels up and down between movement orders.

== Formations ==
The formations control how groups of agents move in the battlescape. There are only two modes, formation and single file.

===Formation===
The selected agents will move to the next waypoint and stop in a chequered formation. They will attempt to move at their best possible speed depending on how tired they are and what movement modes have been set. This can cause faster soldiers to outdistance slower soldiers.

This is the default setting and most players never switch away from this mode.

===Single File===

Single File is a very interesting formation mode that is rarely used by most players due to a small loss in control that it has over the squad.

It causes a team of agents to dynamically coordinate amongst themselves, no matter how disarrayed they may seem, to fluidly form a single file formation, with the leader or point man always being the agent nearest the way point you specify. This restructuring of the single file chain always happens when you move the team as a group.

Once a single file chain is set up, each agent will have a buddy that they'll always follow. If you were to deselect the team and select the current leader, all of the other agents will automatically wander after the leader. If you were to break the chain and pick an agent in the middle, that agent becomes the leader of his or her own smaller single file chain. All of the chained agents will keep following their lead unit until they are issued a move order.

This chaining can be used on soldiers in other teams. With clever use of chaining small single-file formations of agents from others squads together, you could move two squads about the field by only controlling one squad in formation, with each agent in a secondary squad attached to an agent in the first squad.

Chains of agents have an irregular movement pattern. See the next section for details. This irregularity affects any agent that is part of a chain. Even if the lead unit is walking in Formation mode, this movement irregularity continues to hold true until the agent is removed from a Single File chain.

While a very clever walking mode, this movement irregularity causes a small loss in control, thus making it less generally desirable to use.

This mode fails because of the awkward movement, but is a great way of micromanaging small groups. You can use it to make an agent from a different squad follow a member from another squad automatically. By walking and using aggressive, these units can walk around and automatically use reaction fire on any enemies attacking the leading unit.

====Walking and running in Single File ====
When walking in the single file mode, the agents may, for reasons unknown, vary their movement from a sluggish walk that is slower than the normal walk or may even sprint towards the nearest agent or (for the leading agent) way point in varying bursts. This is frustrating, therefore you cannot rely on them to walk or run normally when in single file.

If you must rush everyone to a particular location in a hurry, break out of single file and go to formation, and either move in formation or manually order your troops one at a time.

===Combining Single File and Formation Mode===

By using single file mode, you can link agents from any group with agents with another. For example, you can get six agents from another squad individually attach themselves to members of the main squad of six agents by making the agents in the first squad the lead unit in mini single-file formations.

Once the units are attached, you can select your main squad and then go back to formation mode. Your main squad will now be able to move about in formation, and the soldiers in the other squad will automatically follow the main squad and basically hover around the primary squad. Note however that because the soldiers are made up of mini single-file formations, your leading units may have their speed affected as if they were in single file.

You can also make longer mini-chains, however this can lead to a big mess agents getting in each others' way.

== Shot Types ==

to be continued...

[[Category: Apocalypse]]

Manufacturing Profitability

2011-01-18T01:10:32Z

FrederikHertzum: 8 bits cannot possibly store that much information! maybe the OP ment that much of the game information is stored in singular bytes, rather than a lot of the game information is stored in one byte!

There are 35 items in X-COM that can be [[manufacturing|manufactured]], but if all costs are taken into account, only 14 of them can be manufactured for a profit.

You cannot manufacture an item until you have researched it, so you begin the game unable to manufacture any items at all. Depending on your research priorities, there are several early items that can be made for a profit: Motion Scanners, Medi-Kits, Laser Pistols and Laser Rifles. For more on research times and prerequisites, see [[Research]].

Fusion Ball Launchers and Laser Cannons can be researched in the early-mid game, and are the two most profitable items that can be produced in all of X-COM. Refer to the [[#Profit tables|profit tables]] for a detailed breakdown.

== Calculating profitability ==

To calculate true (net) manufacturing profit, the following must be accounted for:

*Manufacturing cost -- the value shown on the manufacturing screen.
*Cost of [[Elerium-115]] ($5k each) and [[Alien Alloys]] ($6.5k each), if required. Also, cost of [[UFO Power Source]](s) ($500k each) and [[UFO Navigation]] ($80k each) for XCOM craft.
*Cost of Engineer salaries, at $25k per month per Engineer. Engineers work 24 hours a day, giving them an hourly wage of $35.
*Cost of [[Workshop]]s ($35k/month) and [[Living Quarters]] ($10k/month) sufficient for the number of engineers employed.*

These costs are then compared against the Sell price, to determine profitability.

== Startup costs ==

There is a startup cost associated with manufacturing: 50 Engineers cost $2.5 million to hire and require a Workshop ($800,000 to build) and a Living Quarters ($400,000), for a total of $3.7 million. Workshops also require a lead time of 32 days to build. Since you start the game with one Workshop and 10 Engineers, your first Workshop will only cost $2.4 million to fully ramp up (the cost of 40 Engineers and one Living Quarters).

There is also a time and cost factor associated with researching profitable items -- for instance, Heavy Lasers plus Laser Cannons require an average of 880 Scientist days to research (costing about $900,000 in salary). This is in addition to the 450 or so Scientist days required to research Laser Weapons, Laser Pistol, and Laser Rifle.

== Workshop space overhead ==

Each manufacturing project takes up a fixed amount of workshop space, reducing the number of Engineers you can gainfully employ. With multiple workshops, the impact of this overhead is reduced: two workshops are proportionally 5%-7% more profitable than a single workshop would be (depending on the item being produced), and five workshops are as much as 11% more profitable.

== Profit tables ==

The following is a list of selected items that are popular with players attempting to manufacture items for profit. Note that not all these items actually turn a profit, once all costs are factored in.

'''Monthly profits, based on a one-workshop operation. Figures in thousands (000's) where noted.'''

{|
|-
!align ="left"|Item
!align ="center"|Hrs. per unit
!align ="center"|Max Engrs.
!align ="center"|Unit sell price (000's)
!align ="center"|Unit cost (000's)
!align ="center"|Spec. costs (000's)
!align ="center"|Gross per unit (000's)
!align ="center"|Units per month
!align ="center"|Labor cost (000's)
!align ="center"|Net monthly profit (000's)
|-
|align ="left"|[[Laser Cannon]]
|align ="center"|300
|align ="center"|44
|align ="center"|211
|align ="center"|182
|align ="center"|0
|align ="center"|29
|align ="center"|107.4
|align ="center"|1,145
|align ="center"|1,968
|-
|align ="left"|[[Fusion Ball Launcher]]
|align ="center"|400
|align ="center"|44
|align ="center"|281.1
|align ="center"|242
|align ="center"|6.5*
|align ="center"|32.6
|align ="center"|80.52
|align ="center"|1,145
|align ="center"|1,480
|-
|align ="left"|[[Tank/Laser Cannon]]
|align ="center"|1200
|align ="center"|25
|align ="center"|594
|align ="center"|500
|align ="center"|0
|align ="center"|94
|align ="center"|15.25
|align ="center"|670
|align ="center"|763.5
|-
|align ="left"|[[Motion Scanner]]
|align ="center"|220
|align ="center"|46
|align ="center"|45.6
|align ="center"|34
|align ="center"|0
|align ="center"|11.6
|align ="center"|153.1
|align ="center"|1,195
|align ="center"|580.4
|-
|align ="left"|[[Medi-Kit]]
|align ="center"|420
|align ="center"|46
|align ="center"|46.5
|align ="center"|28
|align ="center"|0
|align ="center"|18.5
|align ="center"|80.17
|align ="center"|1,195
|align ="center"|288.2
|-
|align ="left"|[[Heavy Plasma]]
|align ="center"|1000
|align ="center"|46
|align ="center"|171.6
|align ="center"|122
|align ="center"|6.5
|align ="center"|43.1
|align ="center"|33.67
|align ="center"|1,195
|align ="center"|256.3
|-
|align ="left"|[[Laser Rifle]]
|align ="center"|400
|align ="center"|47
|align ="center"|36.9
|align ="center"|20
|align ="center"|0
|align ="center"|16.9
|align ="center"|86.01
|align ="center"|1,220
|align ="center"|233.6
|-
|align ="left"|[[Laser Pistol]]
|align ="center"|300
|align ="center"|48
|align ="center"|20
|align ="center"|8
|align ="center"|0
|align ="center"|12
|align ="center"|117.1
|align ="center"|1,245
|align ="center"|160.4
|-
|align ="left"|[[Alien Alloys]]
|align ="center"|100
|align ="center"|40
|align ="center"|6.5
|align ="center"|3
|align ="center"|0
|align ="center"|3.5
|align ="center"|292.8
|align ="center"|1,045
|align ="center"|-20.2
|-
|align ="left"|[[Personal Armor]]
|align ="center"|800
|align ="center"|38
|align ="center"|54
|align ="center"|22
|align ="center"|26
|align ="center"|6
|align ="center"|34.77
|align ="center"|995
|align ="center"|-786.4
|}

'''Legend:'''

*'''Hrs. per unit''' are the number of hours needed by one engineer to build a single unit
*'''Max Engrs.''' equals 50 minus the amount of workshop space taken up by the project
*'''Unit sell price''' is what the item will sell for on the Sell/Sack screen
*'''Unit cost''' is what each item costs to produce, on the Production screen
*'''Spec. costs''' is $6,500 for each Alien Alloy and $5,000 for each Elerium, if any
*'''Gross per unit''' is its sell price, minus production and special materials costs
*'''Units per month''' is how many units a fully-staffed workshop can turn out: 732 hours (30.5 days) divided by Engineer hours per unit, times Max Engineers employable
*'''Labor cost''' is Max Engineers times $25,000 (monthly salary) -- plus $35,000 for Workshop maintenance costs and $10,000 for Living Quarters
*'''Net monthly profit''' is Gross profit times Units per month minus Labor cost
<nowiki>*</nowiki> The table assumes you are using one Alloy per Fusion Ball Launcher; see [[Manufacturing_Profitability#Laser_Cannons_vs._Fusion_Ball_Launchers|below]].

For a detailed listing of the profitability of all items in X-COM, with figures for 1 to 5 workshops, download [[User:MikeTheRed|MikeTheRed's]] [[Media:XCOM_Profit_Tables.pdf|XCOM_Profit_Tables.pdf]]. Or for an Excel (editable) spreadsheet, get [[Media:XCOM_Profits.xls|XCOM_Profits.xls]].

== XComUtil manufacturing profitability ==

Under XcomUtil there is an option called (slightly misleadingly) "new laser weapons" that requires the use of extra alien materials in order to manufacture almost all energy beam weapons. It also makes the human manufacture of the alien plasma beam small arms impossible (research success merely allows X-COM to use captured weapons). The manufacture of craft Plasma Beams is still possible, but is made significantly more difficult (ten times the labour and workspace requirement as well as additional materials). This, as Scott Jones says, "seriously changes the economics of the game", as well as the balance of firepower in the air and (to a lesser extent) on the ground.

When this XComUtil option is active there are only 7 profitable items to manufacture instead of 14.

In order of decreasing profitability per month (indexed to 100) these are:

:Fusion Ball Launcher (100), Psi Amp (53), Motion Scanner (38), Medkit (19), Laser Pistol (10), Blaster Launcher (9), Small Launcher (9).

In fact the profitability of all these items is unchanged from the standard game; you still make 1,480,000 per month for the FBL with one workshop, etc. What changes is that 7 items, notably the Laser Cannon, disappear from the profitable list. But you can still get rich quick, even if the FBL is only 75% as profitable as the Laser Cannon in unmodified X-COM.

A spreadsheet containing the analysis is here: [[Media:XCOMUtil_Profits.xls|XComUtil Profits]].

== Laser Cannons vs. Fusion Ball Launchers ==

There is an oddity in XCOM which can make the [[Fusion Ball Launcher]] (FBL) appear to be the most profitable item. The oddity is that the first FBL you produce does not require an [[Alien Alloys|Alien Alloy]] (and thus, no Alloy requirement appears on the manufacturing screen), but subsequent FBLs do. If in doubt, watch your Alloy stores while manufacturing... the first FBL doesn't use one, but each additional FBL will use 1 Alloy. This bug is due to an oddity in the [[PRODUCT.DAT]] data at offsets 8-13.

This oddity has caused a fair bit of confusion; some folks (particularly in older docs) say Fusion Ball Launchers are the most profitable.

Without the alloy, the FBL is 1.77% more profitable than the [[Laser Cannon]] (LC). (This is regardless of the number of Workshops, because both FBL and LC have a Workspace requirement of 6.) However, when Alien Alloys are taken into account, FBLs are only 75.2% as profitable as LCs; LCs make 33.0% more profit. Due to the extreme micromanagement needed to repeatedly restart manufacturing versus the minuscule gain, probably few players will build one FBL at a time - so the Laser Cannon is the most profitable item "in real life". Still, you can play however you want!

Some have said that if you have a surplus of Alloys from missions, you might consider Alloys to be free, and make FBLs. Anyone can do what they want, but if the bottom line is ''profitability'', it is clearly more profitable to make LCs (and sell excess Alloys). As stated, this is 33% more profitable than making FBLs with Alloys. ''Unless'', of course, you want to make FBLs one at a time. Then, FBLs will be 1.77% more profitable - but only because you are not incorporating Alloys. Either way - whether you make LCs or you make FBLs one at a time - the most ''profitable'' ways do not involve using Alloys (which are simply sold, once in excess). So, anyone is welcome to make FBLs with Alloys if they want to consider Alloys as a freebie... but they will not be making the most money. (They'll make 75% as much as if they had made LCs, and sold excess Alloy.)

Some have also said that LCs are more profitable because you can make ~30% more LCs than FBLs in a month, with a given number of engineers. This is a misunderstanding. While you do make ~30% more LCs, the calculations take all factors into account - number per month, cost of parts, cost to sell, etc. Compare how the ''least'' profitable item (the [[Heavy Plasma]] clip; see Factoid 1, below) got that way '''because''' you can make a lot in a month - ''but'' the parts are very expensive, versus the resale value. You have to take all factors into consideration to be precise about profitability.

For more info on Manufacturing Profitability calculations, see the [[Media:XCOM_Profit_Tables.pdf|PDF]] or, better yet, the [[Media:XCOM_Profits.xls|spreadsheet]]. The spreadsheet lets you do things like change the number of workshops, drop the cost of Alloys from the computations, etc.

It's also important to note that Laser Cannons are much more readily researched than Fusion Ball Launchers. First of all, to produce Fusion Ball Launchers, you must capture a [[Blaster Launcher]] and [[Blaster Bomb|Bomb]]. These weapons usually don't appear until several months into the game. Secondly, the average time needed to research Laser Cannons is 1,330 hours (26.6 days for 50 Scientists), whereas Fusion Ball Launchers require 2,080 hours (41.6 days). Finally, about one third of the time needed for researching Laser Cannons is spent researching Laser Pistols and Rifles, which you are likely to research early on anyway.

In summary, Laser Cannons are available much sooner than Fusion Ball Launchers, and are clearly the most profitable item in XCOM - ''unless'' you want to micromanage FBLs and build them one at a time.

=== Simplified LC vs FBL profitability ===

Take an example where you start the month with $1,000,000 and 80 alloys, 44 engineers, 1 workshop. Manufacturing FBLs and selling them will end the month with $3,000,000 and 0 alloys. Manufacturing LCs and selling them, keeping the alloys, will end the month with $ $2,968,000 and 80 alloys. Manufacturing LCs and selling them, also selling the alloys, will end the month with $3,488,000 and 0 alloys.

It's clear which is the winner.

== Notes, Tips, Tricks, Etc. ==
*The maximum number of engineers you can assign to a project, equals the number of engineer hours it requires. In other words, the game "enforces" that '''you can only build one item per hour, at most'''. Example: You can only assign 60 engineers at most to work on a plasma pistol clip, which requires 60 engineer hours. The tables above don't take this into account, but then, small-fry products are usually not made by a large operation, anyway.
*You cannot have more than one project of the same type going at the same base. (This otherwise might have been a way "around" the limit of one per hour at most.) However, you can make that thing at some other base.
*Excess/wasted Workshop and Living Quarters are only a minuscule part of your costs. Example: A large operation (four workshops) might have 184 engineers instead of the optimal 194 for Laser Cannons (because of an occasional need to drop back and making flying suits, craft, etc. - it's a balance of constantly wasted space versus occasionally wasted engineers). The "wasted" 10 WS and LQ spaces only cost $9k/month ($45k*10/50), which is only 0.11% of the $8.3M/month that the 184 engineers make when producing LCs.
*Likewise, profits generally scale linearly according to number of workshops (two full workshops make only a little bit more than twice the profit of one full workshop, etc.). Many projects only require a handful of workspace requirements, and are almost totally linear. However, some projects have a large workspace requirement, such as the Laser Tank (25). With only one workshop, the Laser Tank only makes 39% of the profit that Laser Cannons would, whereas they make 64% of Laser Cannons with five workshops. The real reason they do so poorly with one workshop is much less due to the wasted overhead of workshop and living quarters; it is mainly because you can only assign 25 engineers with one workshop, versus 44 for Laser Cannons.
*Those who know XCOM, know that it suffers from integer truncation in a number of places. This could have hurt profitability badly if it occurred there; for example, if an item needs 100 engineer hours but you only assign 99, it might have taken twice as long, and halved your production and profit potential. Fortunately, this is not the case with manufacturing; it does not truncate production time this way.
*There is an [[ExploitsA#Free_Manufacturing|exploit]] that lets the sneaky make items for free - but only one at a time.
*Another [[ExploitsA#Free_Wages|exploit]] involves transferring staff at the end of the month to avoid salaries. Eliminating salary costs makes Laser Cannons about 50% more profitable to produce.
*Factoid 1: The Heavy Plasma Clip is the biggest loss making item, due to the facts that it can be quickly made, but requires 3 Elerium. Be careful what you ask for!
*Factoid 2: Strange as it may seem, XCOM craft are ''not'' the biggest loss making items in the game, even though they are very expensive to make, and you '''can't sell them'''. (High cost, zero sales.) This is because craft take a long time to make, whereas other items can be made quickly, but incorporate expensive components. Their extreme production time overrides the fact that they can actually be sold. :P
*Factoid 3: '''120''' [[Alien Alloys]], '''30''' [[Elerium]], '''2''' [[UFO Power Source]]s, '''1''' [[UFO Navigation]] and '''36''' ''Free workspace'', a [[Hangar]] plus $900,000 are the minimum raw resources needed at a base to begin [[manufacturing]] any item. If abusing the [[ExploitsA#Free_Manufacturing|exploit]] that's all you will ever need to start production.

== Bugs ==

* In UFO: Enemy Unknown (and most likely all the other XCOM and TFTD versions) you can overflow the variable that holds the number of engineers. It is stored in a single byte, so if you get more than 255 engineers at one base, the number will wrap around. Instead of storing the correct number of engineers, it will divide the number by 256 and store the remainder.
If you get exactly 256 engineers your base will have 0.
If you want to play the game fairly, make sure there is never more than 255 engineers at a base.
If you don't mind exploiting the bug to make lots of money, then read on.

The easiest way to start this is to assign your engineers to build something.
Wait until you have enough living quarters, and then buy enough engineers to have exactly 256 (costs $12.8 million for all the engineers, so save up to get them all in 1 month and not pay any salaries). Once the 256 engineers have all arrived, the game will call it 0. You won't need to house them any longer. You won't need to pay their salaries. You'll just need workshop space for them.

There is a second bug in UFO: Enemy Unknown where it only makes sure you don't allocate an engineer when you have 0 available engineers.
It doesn't stop you if you have a negative number of available engineers.
If you have 10 engineers building a Laser Cannon and 0 engineers at the base, you will have -10 engineers available for manufacturing items.
'''THE GAME WILL NOT CARE HOW MANY ENGINEERS YOU ASSIGN AT THIS POINT.'''
Your only limitation is how much workshop space you have. If you build 17 workshops at one base, it can produce a Laser Cannon, a Fusion Ball Launcher, and an Alien Alloy every single hour.

Personally, I recommend having most of your bases with the following: 1 Access Lift (needed), 1 Living Quarters (for soldiers), 1 Hangar (with Avenger), 1 General Stores, 1 Mind Shield, 1 Hyper-Wave Decoder, 1 Psionic Laboratory, and 26 Workshops.
Then you can manufacture 1 Laser Cannon and almost 1 Tank/Laser Cannon every hour (skip the hangar for 1 every hour). These only require money to build (watch that, because if you run out and all production stops, you can't allocate any engineers) and produce large amounts of income.

There is also a [[Known_Bugs#Manufacturing_Limit_Bug|known bug]] associated with display times.

== See Also ==

*[[Workshop]]
*[[Research]]
*[[Hiring/firing]]
*[[Buying/Selling/Transferring#Manufacturable Prices]] for a list of build and sell prices for all manufacturable items (plus special materials requried).
*[[PRODUCT.DAT]] for X-COM's "source data" on manufactured items

*[[Buying/Selling/Transferring (TFTD)#Manufacturable Prices|TFTD Manufacturing Profitabilty]]

[[Category: data tables]]

Manufacturing Profitability

2011-01-18T01:05:08Z

FrederikHertzum: fixed minor typo

There are 35 items in X-COM that can be [[manufacturing|manufactured]], but if all costs are taken into account, only 14 of them can be manufactured for a profit.

You cannot manufacture an item until you have researched it, so you begin the game unable to manufacture any items at all. Depending on your research priorities, there are several early items that can be made for a profit: Motion Scanners, Medi-Kits, Laser Pistols and Laser Rifles. For more on research times and prerequisites, see [[Research]].

Fusion Ball Launchers and Laser Cannons can be researched in the early-mid game, and are the two most profitable items that can be produced in all of X-COM. Refer to the [[#Profit tables|profit tables]] for a detailed breakdown.

== Calculating profitability ==

To calculate true (net) manufacturing profit, the following must be accounted for:

*Manufacturing cost -- the value shown on the manufacturing screen.
*Cost of [[Elerium-115]] ($5k each) and [[Alien Alloys]] ($6.5k each), if required. Also, cost of [[UFO Power Source]](s) ($500k each) and [[UFO Navigation]] ($80k each) for XCOM craft.
*Cost of Engineer salaries, at $25k per month per Engineer. Engineers work 24 hours a day, giving them an hourly wage of $35.
*Cost of [[Workshop]]s ($35k/month) and [[Living Quarters]] ($10k/month) sufficient for the number of engineers employed.*

These costs are then compared against the Sell price, to determine profitability.

== Startup costs ==

There is a startup cost associated with manufacturing: 50 Engineers cost $2.5 million to hire and require a Workshop ($800,000 to build) and a Living Quarters ($400,000), for a total of $3.7 million. Workshops also require a lead time of 32 days to build. Since you start the game with one Workshop and 10 Engineers, your first Workshop will only cost $2.4 million to fully ramp up (the cost of 40 Engineers and one Living Quarters).

There is also a time and cost factor associated with researching profitable items -- for instance, Heavy Lasers plus Laser Cannons require an average of 880 Scientist days to research (costing about $900,000 in salary). This is in addition to the 450 or so Scientist days required to research Laser Weapons, Laser Pistol, and Laser Rifle.

== Workshop space overhead ==

Each manufacturing project takes up a fixed amount of workshop space, reducing the number of Engineers you can gainfully employ. With multiple workshops, the impact of this overhead is reduced: two workshops are proportionally 5%-7% more profitable than a single workshop would be (depending on the item being produced), and five workshops are as much as 11% more profitable.

== Profit tables ==

The following is a list of selected items that are popular with players attempting to manufacture items for profit. Note that not all these items actually turn a profit, once all costs are factored in.

'''Monthly profits, based on a one-workshop operation. Figures in thousands (000's) where noted.'''

{|
|-
!align ="left"|Item
!align ="center"|Hrs. per unit
!align ="center"|Max Engrs.
!align ="center"|Unit sell price (000's)
!align ="center"|Unit cost (000's)
!align ="center"|Spec. costs (000's)
!align ="center"|Gross per unit (000's)
!align ="center"|Units per month
!align ="center"|Labor cost (000's)
!align ="center"|Net monthly profit (000's)
|-
|align ="left"|[[Laser Cannon]]
|align ="center"|300
|align ="center"|44
|align ="center"|211
|align ="center"|182
|align ="center"|0
|align ="center"|29
|align ="center"|107.4
|align ="center"|1,145
|align ="center"|1,968
|-
|align ="left"|[[Fusion Ball Launcher]]
|align ="center"|400
|align ="center"|44
|align ="center"|281.1
|align ="center"|242
|align ="center"|6.5*
|align ="center"|32.6
|align ="center"|80.52
|align ="center"|1,145
|align ="center"|1,480
|-
|align ="left"|[[Tank/Laser Cannon]]
|align ="center"|1200
|align ="center"|25
|align ="center"|594
|align ="center"|500
|align ="center"|0
|align ="center"|94
|align ="center"|15.25
|align ="center"|670
|align ="center"|763.5
|-
|align ="left"|[[Motion Scanner]]
|align ="center"|220
|align ="center"|46
|align ="center"|45.6
|align ="center"|34
|align ="center"|0
|align ="center"|11.6
|align ="center"|153.1
|align ="center"|1,195
|align ="center"|580.4
|-
|align ="left"|[[Medi-Kit]]
|align ="center"|420
|align ="center"|46
|align ="center"|46.5
|align ="center"|28
|align ="center"|0
|align ="center"|18.5
|align ="center"|80.17
|align ="center"|1,195
|align ="center"|288.2
|-
|align ="left"|[[Heavy Plasma]]
|align ="center"|1000
|align ="center"|46
|align ="center"|171.6
|align ="center"|122
|align ="center"|6.5
|align ="center"|43.1
|align ="center"|33.67
|align ="center"|1,195
|align ="center"|256.3
|-
|align ="left"|[[Laser Rifle]]
|align ="center"|400
|align ="center"|47
|align ="center"|36.9
|align ="center"|20
|align ="center"|0
|align ="center"|16.9
|align ="center"|86.01
|align ="center"|1,220
|align ="center"|233.6
|-
|align ="left"|[[Laser Pistol]]
|align ="center"|300
|align ="center"|48
|align ="center"|20
|align ="center"|8
|align ="center"|0
|align ="center"|12
|align ="center"|117.1
|align ="center"|1,245
|align ="center"|160.4
|-
|align ="left"|[[Alien Alloys]]
|align ="center"|100
|align ="center"|40
|align ="center"|6.5
|align ="center"|3
|align ="center"|0
|align ="center"|3.5
|align ="center"|292.8
|align ="center"|1,045
|align ="center"|-20.2
|-
|align ="left"|[[Personal Armor]]
|align ="center"|800
|align ="center"|38
|align ="center"|54
|align ="center"|22
|align ="center"|26
|align ="center"|6
|align ="center"|34.77
|align ="center"|995
|align ="center"|-786.4
|}

'''Legend:'''

*'''Hrs. per unit''' are the number of hours needed by one engineer to build a single unit
*'''Max Engrs.''' equals 50 minus the amount of workshop space taken up by the project
*'''Unit sell price''' is what the item will sell for on the Sell/Sack screen
*'''Unit cost''' is what each item costs to produce, on the Production screen
*'''Spec. costs''' is $6,500 for each Alien Alloy and $5,000 for each Elerium, if any
*'''Gross per unit''' is its sell price, minus production and special materials costs
*'''Units per month''' is how many units a fully-staffed workshop can turn out: 732 hours (30.5 days) divided by Engineer hours per unit, times Max Engineers employable
*'''Labor cost''' is Max Engineers times $25,000 (monthly salary) -- plus $35,000 for Workshop maintenance costs and $10,000 for Living Quarters
*'''Net monthly profit''' is Gross profit times Units per month minus Labor cost
<nowiki>*</nowiki> The table assumes you are using one Alloy per Fusion Ball Launcher; see [[Manufacturing_Profitability#Laser_Cannons_vs._Fusion_Ball_Launchers|below]].

For a detailed listing of the profitability of all items in X-COM, with figures for 1 to 5 workshops, download [[User:MikeTheRed|MikeTheRed's]] [[Media:XCOM_Profit_Tables.pdf|XCOM_Profit_Tables.pdf]]. Or for an Excel (editable) spreadsheet, get [[Media:XCOM_Profits.xls|XCOM_Profits.xls]].

== XComUtil manufacturing profitability ==

Under XcomUtil there is an option called (slightly misleadingly) "new laser weapons" that requires the use of extra alien materials in order to manufacture almost all energy beam weapons. It also makes the human manufacture of the alien plasma beam small arms impossible (research success merely allows X-COM to use captured weapons). The manufacture of craft Plasma Beams is still possible, but is made significantly more difficult (ten times the labour and workspace requirement as well as additional materials). This, as Scott Jones says, "seriously changes the economics of the game", as well as the balance of firepower in the air and (to a lesser extent) on the ground.

When this XComUtil option is active there are only 7 profitable items to manufacture instead of 14.

In order of decreasing profitability per month (indexed to 100) these are:

:Fusion Ball Launcher (100), Psi Amp (53), Motion Scanner (38), Medkit (19), Laser Pistol (10), Blaster Launcher (9), Small Launcher (9).

In fact the profitability of all these items is unchanged from the standard game; you still make 1,480,000 per month for the FBL with one workshop, etc. What changes is that 7 items, notably the Laser Cannon, disappear from the profitable list. But you can still get rich quick, even if the FBL is only 75% as profitable as the Laser Cannon in unmodified X-COM.

A spreadsheet containing the analysis is here: [[Media:XCOMUtil_Profits.xls|XComUtil Profits]].

== Laser Cannons vs. Fusion Ball Launchers ==

There is an oddity in XCOM which can make the [[Fusion Ball Launcher]] (FBL) appear to be the most profitable item. The oddity is that the first FBL you produce does not require an [[Alien Alloys|Alien Alloy]] (and thus, no Alloy requirement appears on the manufacturing screen), but subsequent FBLs do. If in doubt, watch your Alloy stores while manufacturing... the first FBL doesn't use one, but each additional FBL will use 1 Alloy. This bug is due to an oddity in the [[PRODUCT.DAT]] data at offsets 8-13.

This oddity has caused a fair bit of confusion; some folks (particularly in older docs) say Fusion Ball Launchers are the most profitable.

Without the alloy, the FBL is 1.77% more profitable than the [[Laser Cannon]] (LC). (This is regardless of the number of Workshops, because both FBL and LC have a Workspace requirement of 6.) However, when Alien Alloys are taken into account, FBLs are only 75.2% as profitable as LCs; LCs make 33.0% more profit. Due to the extreme micromanagement needed to repeatedly restart manufacturing versus the minuscule gain, probably few players will build one FBL at a time - so the Laser Cannon is the most profitable item "in real life". Still, you can play however you want!

Some have said that if you have a surplus of Alloys from missions, you might consider Alloys to be free, and make FBLs. Anyone can do what they want, but if the bottom line is ''profitability'', it is clearly more profitable to make LCs (and sell excess Alloys). As stated, this is 33% more profitable than making FBLs with Alloys. ''Unless'', of course, you want to make FBLs one at a time. Then, FBLs will be 1.77% more profitable - but only because you are not incorporating Alloys. Either way - whether you make LCs or you make FBLs one at a time - the most ''profitable'' ways do not involve using Alloys (which are simply sold, once in excess). So, anyone is welcome to make FBLs with Alloys if they want to consider Alloys as a freebie... but they will not be making the most money. (They'll make 75% as much as if they had made LCs, and sold excess Alloy.)

Some have also said that LCs are more profitable because you can make ~30% more LCs than FBLs in a month, with a given number of engineers. This is a misunderstanding. While you do make ~30% more LCs, the calculations take all factors into account - number per month, cost of parts, cost to sell, etc. Compare how the ''least'' profitable item (the [[Heavy Plasma]] clip; see Factoid 1, below) got that way '''because''' you can make a lot in a month - ''but'' the parts are very expensive, versus the resale value. You have to take all factors into consideration to be precise about profitability.

For more info on Manufacturing Profitability calculations, see the [[Media:XCOM_Profit_Tables.pdf|PDF]] or, better yet, the [[Media:XCOM_Profits.xls|spreadsheet]]. The spreadsheet lets you do things like change the number of workshops, drop the cost of Alloys from the computations, etc.

It's also important to note that Laser Cannons are much more readily researched than Fusion Ball Launchers. First of all, to produce Fusion Ball Launchers, you must capture a [[Blaster Launcher]] and [[Blaster Bomb|Bomb]]. These weapons usually don't appear until several months into the game. Secondly, the average time needed to research Laser Cannons is 1,330 hours (26.6 days for 50 Scientists), whereas Fusion Ball Launchers require 2,080 hours (41.6 days). Finally, about one third of the time needed for researching Laser Cannons is spent researching Laser Pistols and Rifles, which you are likely to research early on anyway.

In summary, Laser Cannons are available much sooner than Fusion Ball Launchers, and are clearly the most profitable item in XCOM - ''unless'' you want to micromanage FBLs and build them one at a time.

=== Simplified LC vs FBL profitability ===

Take an example where you start the month with $1,000,000 and 80 alloys, 44 engineers, 1 workshop. Manufacturing FBLs and selling them will end the month with $3,000,000 and 0 alloys. Manufacturing LCs and selling them, keeping the alloys, will end the month with $ $2,968,000 and 80 alloys. Manufacturing LCs and selling them, also selling the alloys, will end the month with $3,488,000 and 0 alloys.

It's clear which is the winner.

== Notes, Tips, Tricks, Etc. ==
*The maximum number of engineers you can assign to a project, equals the number of engineer hours it requires. In other words, the game "enforces" that '''you can only build one item per hour, at most'''. Example: You can only assign 60 engineers at most to work on a plasma pistol clip, which requires 60 engineer hours. The tables above don't take this into account, but then, small-fry products are usually not made by a large operation, anyway.
*You cannot have more than one project of the same type going at the same base. (This otherwise might have been a way "around" the limit of one per hour at most.) However, you can make that thing at some other base.
*Excess/wasted Workshop and Living Quarters are only a minuscule part of your costs. Example: A large operation (four workshops) might have 184 engineers instead of the optimal 194 for Laser Cannons (because of an occasional need to drop back and making flying suits, craft, etc. - it's a balance of constantly wasted space versus occasionally wasted engineers). The "wasted" 10 WS and LQ spaces only cost $9k/month ($45k*10/50), which is only 0.11% of the $8.3M/month that the 184 engineers make when producing LCs.
*Likewise, profits generally scale linearly according to number of workshops (two full workshops make only a little bit more than twice the profit of one full workshop, etc.). Many projects only require a handful of workspace requirements, and are almost totally linear. However, some projects have a large workspace requirement, such as the Laser Tank (25). With only one workshop, the Laser Tank only makes 39% of the profit that Laser Cannons would, whereas they make 64% of Laser Cannons with five workshops. The real reason they do so poorly with one workshop is much less due to the wasted overhead of workshop and living quarters; it is mainly because you can only assign 25 engineers with one workshop, versus 44 for Laser Cannons.
*Those who know XCOM, know that it suffers from integer truncation in a number of places. This could have hurt profitability badly if it occurred there; for example, if an item needs 100 engineer hours but you only assign 99, it might have taken twice as long, and halved your production and profit potential. Fortunately, this is not the case with manufacturing; it does not truncate production time this way.
*There is an [[ExploitsA#Free_Manufacturing|exploit]] that lets the sneaky make items for free - but only one at a time.
*Another [[ExploitsA#Free_Wages|exploit]] involves transferring staff at the end of the month to avoid salaries. Eliminating salary costs makes Laser Cannons about 50% more profitable to produce.
*Factoid 1: The Heavy Plasma Clip is the biggest loss making item, due to the facts that it can be quickly made, but requires 3 Elerium. Be careful what you ask for!
*Factoid 2: Strange as it may seem, XCOM craft are ''not'' the biggest loss making items in the game, even though they are very expensive to make, and you '''can't sell them'''. (High cost, zero sales.) This is because craft take a long time to make, whereas other items can be made quickly, but incorporate expensive components. Their extreme production time overrides the fact that they can actually be sold. :P
*Factoid 3: '''120''' [[Alien Alloys]], '''30''' [[Elerium]], '''2''' [[UFO Power Source]]s, '''1''' [[UFO Navigation]] and '''36''' ''Free workspace'', a [[Hangar]] plus $900,000 are the minimum raw resources needed at a base to begin [[manufacturing]] any item. If abusing the [[ExploitsA#Free_Manufacturing|exploit]] that's all you will ever need to start production.

== Bugs ==

* In UFO: Enemy Unknown (and most likely all the other XCOM and TFTD versions) you can overflow the variable that holds the number of engineers. It is stored in a single byte, along with much of the data in the game, so if you get more than 255 engineers at one base, the number will wrap around. Instead of storing the correct number of engineers, it will divide the number by 256 and store the remainder.
If you get exactly 256 engineers your base will have 0.
If you want to play the game fairly, make sure there is never more than 255 engineers at a base.
If you don't mind exploiting the bug to make lots of money, then read on.

The easiest way to start this is to assign your engineers to build something.
Wait until you have enough living quarters, and then buy enough engineers to have exactly 256 (costs $12.8 million for all the engineers, so save up to get them all in 1 month and not pay any salaries). Once the 256 engineers have all arrived, the game will call it 0. You won't need to house them any longer. You won't need to pay their salaries. You'll just need workshop space for them.

There is a second bug in UFO: Enemy Unknown where it only makes sure you don't allocate an engineer when you have 0 available engineers.
It doesn't stop you if you have a negative number of available engineers.
If you have 10 engineers building a Laser Cannon and 0 engineers at the base, you will have -10 engineers available for manufacturing items.
'''THE GAME WILL NOT CARE HOW MANY ENGINEERS YOU ASSIGN AT THIS POINT.'''
Your only limitation is how much workshop space you have. If you build 17 workshops at one base, it can produce a Laser Cannon, a Fusion Ball Launcher, and an Alien Alloy every single hour.

Personally, I recommend having most of your bases with the following: 1 Access Lift (needed), 1 Living Quarters (for soldiers), 1 Hangar (with Avenger), 1 General Stores, 1 Mind Shield, 1 Hyper-Wave Decoder, 1 Psionic Laboratory, and 26 Workshops.
Then you can manufacture 1 Laser Cannon and almost 1 Tank/Laser Cannon every hour (skip the hangar for 1 every hour). These only require money to build (watch that, because if you run out and all production stops, you can't allocate any engineers) and produce large amounts of income.

There is also a [[Known_Bugs#Manufacturing_Limit_Bug|known bug]] associated with display times.

== See Also ==

*[[Workshop]]
*[[Research]]
*[[Hiring/firing]]
*[[Buying/Selling/Transferring#Manufacturable Prices]] for a list of build and sell prices for all manufacturable items (plus special materials requried).
*[[PRODUCT.DAT]] for X-COM's "source data" on manufactured items

*[[Buying/Selling/Transferring (TFTD)#Manufacturable Prices|TFTD Manufacturing Profitabilty]]

[[Category: data tables]]

Bombardment Shield

2011-01-17T19:04:54Z

FrederikHertzum: it's not an opinion

== General Information ==
[[Image:Base-TFTD-bombardment.gif|right|100px]]
A Bombardment Shield doubles the potency of your offensive [[Base Defense Measures]], allowing each one to fire twice against an attacking USO.

Contrary to popular belief, the Bombardment Shield's abilities do not stack. You can build multiple facilities but only the first will allow your defenses to fire again.

This [[Base Facilities (TFTD)|base facility]] appears in ''[[TFTD|Terror from the Deep]]''. For the ''[[X-COM|UFO: Enemy Unknown]]'' equivalent, refer to the [[Grav Shield]].

<gallery widths="175">
Image:XBASES01-15-L0.PNG|Bombardment Shield Level 0
Image:XBASES12-L1.PNG|Bombardment Shield Level 1
Image:XBASES12-L2.PNG|Bombardment Shield Level 2
Image:XBASES12-L3.PNG|Bombardment Shield Level 3</gallery>

== Statistics ==

Construction Time: 38 days 
Construction Cost: $1,200,000 
Maintenance Cost: $15,000/month 

==See Also==

{{Template:Base Facilities Navbar (TFTD)}}

[[Category:Base Facilities (TFTD)]][[Category:Research (TFTD)]]

Grav Shield

2011-01-17T19:04:30Z

FrederikHertzum: it's not an opinion

== General Information ==
[[Image:Base-grav.gif|right|100px]]
A Grav Shield doubles the potency of your offensive [[Base Defense Measures]], allowing each one to fire twice against an attacking UFO.

Contrary to popular belief, the Grav Shield's abilities do not stack. You can build multiple facilities but only the first will allow your defenses to fire again.

This [[Base Facilities (EU)|base facility]] appears in ''[[X-COM|UFO: Enemy Unknown]]''. For the ''[[TFTD|Terror from the Deep]]'' equivalent, refer to the [[Bombardment Shield]].

[[Image:XBASE_12MAP-L1.JPG|Grav Shield: Level 0|250 px]] [[Image:XBASE_12MAP-L2.JPG|Grav Shield: Level 1|250 px]]

== Statistics ==

Construction Time: 38 days 
Construction Cost: $1,200,000 
Maintenance Cost: $15,000/month 

== See Also ==
{{Base Facilities Navbar}}

[[Category:Research (EU)]][[Category:Base Facilities (EU)]]