UFOpaedia - User contributions [en]

Talk:Known Bugs

2016-11-13T05:46:33Z

Bomb Bloke: /* Enemy Unknown 1994: Save game bug mid mission. */

= Classification etc =

== Bugs vs Exploits ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Bugs vs Limits ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

= Specific Bug Discussions =

== Misc Technical Bug ? ==

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

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

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

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

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

- [[User:NKF|NKF]]

-----

== "Invisible Muton" bug ==

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

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

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

-----

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

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

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

- [[User:Bomb_Bloke|Bomb Bloke]]

----

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

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

----

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

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

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

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

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

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

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

- [[User:NKF|NKF]]

----

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

----

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

- by tequilachef (April 4th 2007)

== Vanishing snakemen ==

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

---

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

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

- By tequilachef (April 4th, 2007)

== Blaster Bomb Bug ==

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

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

== Disappearing Ammunition ==

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

------

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

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

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

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

==MC at end = MIA?==

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

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

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

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

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

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

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

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

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

----

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

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

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

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

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

- By tequilachef (April 4th, 2007)

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

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

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

: -[[User:NKF|NKF]]

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

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

== Crash Site in the atlantic ocean ==

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

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

- UFO: battleship, floater, alien harvest

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

- Date: January 2000

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

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

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

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

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

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

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

== Inconsistencies in MCing Cyberdiscs and Sectopods ==

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

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

:- [[User:NKF|NKF]]

== Facility Dismantle Bug ==

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

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

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

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

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

== Manufacturing Limit Bug ==

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

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

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

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

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

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

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

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

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

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

----

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

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

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

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

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

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

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

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

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

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

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

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

== Unconscious Enemy in Equipment Screen ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--------

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

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

== Soldiers moved to outside of combat screen ==

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

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

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

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

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

==Great Circle Route==

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

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

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

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

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

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

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

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

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

-----

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

-----

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

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

-----

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

----

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

-----

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

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

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

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

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

== Soldier Recruiting Bugs Tested ==

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

==Floater Medic Bug==

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

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

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

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

==Strength Overflow==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Sources for a DOS4GW transplant ==

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

== Phantom Carried Casualty ==

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

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

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

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

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

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

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

==Elerium Base Bug==

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

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

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

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

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

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

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

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

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

See Also [[Talk:Displacer/PWT]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

==HWP Morale Loss==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== 80-items limit on CE edition ==

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

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

== Paying for Dirt in TFTD ==

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

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

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

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

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

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

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

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

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

== Minimized Interceptor Bug (Ufo CE) ==

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

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

== Activity Overflow Bug ==

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

[[File:dissatisfied customers.png]]

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

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

X-Com activity is also off the chart:

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

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

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

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

Further information:

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

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

[[File:Prehistoric_negative_score.png]]

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

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

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

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

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

== Bad Paths Bug ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Corruption of the save, seems to coincide with crossing a threshold of a number of actions on a number of soldiers within a turn. After the threshold is crossed each attempt to save on subsequent turns mid mission are all corrupted, leading to the possibility of filling all 10 game slots with trashed saves, forcing a restart of the game from turn 1!
As long as you don't cross the threshold before saving, and there is one remaining action that would corrupt the game on a given turn, progressing to the next turn seems to reset the count on the number of actions, so you can perform multiple actions instead of one the next turn.

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

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

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

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

--

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

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

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

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

--

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

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

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

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

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

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

Talk:Known Bugs

2016-11-11T03:06:28Z

Bomb Bloke: /* Enemy Unknown 1994: Save game bug mid mission. */

= Classification etc =

== Bugs vs Exploits ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Bugs vs Limits ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

= Specific Bug Discussions =

== Misc Technical Bug ? ==

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

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

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

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

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

- [[User:NKF|NKF]]

-----

== "Invisible Muton" bug ==

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

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

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

-----

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

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

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

- [[User:Bomb_Bloke|Bomb Bloke]]

----

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

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

----

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

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

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

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

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

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

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

- [[User:NKF|NKF]]

----

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

----

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

- by tequilachef (April 4th 2007)

== Vanishing snakemen ==

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

---

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

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

- By tequilachef (April 4th, 2007)

== Blaster Bomb Bug ==

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

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

== Disappearing Ammunition ==

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

------

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

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

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

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

==MC at end = MIA?==

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

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

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

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

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

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

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

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

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

----

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

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

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

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

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

- By tequilachef (April 4th, 2007)

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

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

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

: -[[User:NKF|NKF]]

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

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

== Crash Site in the atlantic ocean ==

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

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

- UFO: battleship, floater, alien harvest

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

- Date: January 2000

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

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

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

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

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

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

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

== Inconsistencies in MCing Cyberdiscs and Sectopods ==

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

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

:- [[User:NKF|NKF]]

== Facility Dismantle Bug ==

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

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

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

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

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

== Manufacturing Limit Bug ==

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

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

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

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

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

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

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

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

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

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

----

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

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

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

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

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

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

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

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

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

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

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

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

== Unconscious Enemy in Equipment Screen ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--------

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

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

== Soldiers moved to outside of combat screen ==

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

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

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

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

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

==Great Circle Route==

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

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

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

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

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

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

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

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

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

-----

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

-----

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

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

-----

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

----

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

-----

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

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

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

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

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

== Soldier Recruiting Bugs Tested ==

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

==Floater Medic Bug==

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

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

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

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

==Strength Overflow==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Sources for a DOS4GW transplant ==

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

== Phantom Carried Casualty ==

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

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

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

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

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

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

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

==Elerium Base Bug==

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

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

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

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

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

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

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

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

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

See Also [[Talk:Displacer/PWT]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

==HWP Morale Loss==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== 80-items limit on CE edition ==

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

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

== Paying for Dirt in TFTD ==

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

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

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

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

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

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

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

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

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

== Minimized Interceptor Bug (Ufo CE) ==

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

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

== Activity Overflow Bug ==

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

[[File:dissatisfied customers.png]]

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

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

X-Com activity is also off the chart:

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

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

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

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

Further information:

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

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

[[File:Prehistoric_negative_score.png]]

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

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

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

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

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

== Bad Paths Bug ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Effect : Loading saved game mid mission just displays a black screen with the cursor at the top left.
[[File:Screen_shot_2016-11-07_at_19.39.31.png]]
It forces you to have to kill the DOS app, because there is no longer any way to interact with the program.
Cause : Unknown. I had blown up a Cyberdisc and I don't know if that somehow corrupts the terrain in the save game.
Had previously thought it was because of placing units at the top edge of the screen, but replaying I managed to still get bug, from earlier in the mission and avoiding northernmost tiles.

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

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

To answer your questions:
1) I'm using Boxer 1.40 on a Mac - which in turn is built off Dosbox 0.74.
I remember seeing this bug years ago on Windows XP too, so I don't think it is platform specific.
I'm currently running it with some of the XCOMUtil patches too - but have had the issue crop up without any of the patches.
2) I don't believe the game has crashed out to DOS, because the sound still plays in the background when you load the corrupted save.
I did also try CLS and DIR to no avail.
When the corruption occurs you can perform a certain number of operations and save and restore ok. But once you go one operation past this point on any soldier future attempts to save cause the corruption.
Consequently I'm wondering if it's some sort of buffer overflow that causes the problems.
I'm wondering if there's some sort of old DOS Config.sys setting that needs to be applied like BUFFERS. Possibly even missing SMARTDRV after Googling the manual... But further Googling infers DOSBOX did away with need for SMARTDRV https://www.gog.com/forum/general_archive/help_with_dosbox/post17

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

I've also since experienced the error with a Sectoid Supply ship and a Muton Alien base.
The only thing these missions have all had in common is lots of units on both sides....
It doesn't seem to manifest itself on missions as far as I can tell with say scout ships. Surprisingly not had it happen on Battleships or city Terror missions yet....
Playing on Superhuman level. - with the patch to make that work. The time I played after restart I had 9 Cyberdiscs with the Terror ship.
And to clarify - when you save a game that has reached corrupted status at start of next turn and all turns thereafter it will be corrupted. So you have to be sure to restore often just to ensure all 10 slots aren't hosed! - [[User:‎JGF|‎JGF]]

:There's never been a "need" for SmartDrv. It chews up RAM in order to provide faster disk access (basically it's write-back caching).

:It'd be a lot easier to comment on what might be going on if you provided an affected save. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 03:06, 11 November 2016 (UTC)

Talk:INTICON.PCK

2015-12-25T00:45:17Z

Bomb Bloke:

Files with this name are present both in GEOGRAPH and UFOGRAPH, and are different. Both accompanied by .TAB - which is also different. Any information on this?
 - [[User:TBeholder|TBeholder]] ([[User talk:TBeholder|talk]]) 16:42, 22 December 2015 (EST)

I ran the UFOGRAPH version through falko's Xcom Sprite Converter (http://falkooxc2.pythonanywhere.com/spriteconvert)
This is the result: http://ufopaedia.org/images/2/2d/UFOGRAPH_INTICON.png
I don't off the top of my head know where this is used... maybe in the minimized interception buttons? --[[User:IvanDogovich|IvanDogovich]] ([[User talk:IvanDogovich|talk]]) 17:20, 22 December 2015 (EST)

:Yep, that's what they are.

:There may've been plans to give the player access to them while performing a ground battle. Since the palette used there is different to the one used in the geoscape, the files wouldn't be identical. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 19:45, 24 December 2015 (EST)

Sniper (Long War)

2015-12-24T22:58:26Z

Bomb Bloke: Couple of links.

[[File: CLASS SNIPER.png|left|frame|64px|Sniper]]
<div style="float:right">{{Header (Long War)}}__TOC__</div>
Long War '''Snipers''' are akin to the vanilla Sniper. With '''Squadsight''' as their first ability, they're able to inflict long range damage on enemy targets from a position of safety. Note that the Long War version of the perk does not function alongside [[Overwatch_(EU2012)|Overwatch]], unlike [[Abilities_(EU2012)#Sniper_Abilities|its base-game counterpart]].

:'''Primary Weapon:''' Sniper Rifles, Marksman Rifles, Assault Rifles, Carbines, SMGs.
:'''Secondary Weapon:''' Pistols, Machine Pistols.
:'''Class-Limited items:''' Alloy Bipod, Sniper Rifles.

== Abilities ==
{{Class Tree (Long War)|
|Specialist1={{Squadsight (Long War) |text=1}}
|SpecialistE1=''No other bonuses.''
|LCorporal1={{Low Profile (Long War) |text=1}}
|LCorporal2={{Deadeye (Long War) |text=1}}
|LCorporal3={{Lone Wolf (Long War) |text=1}}
|LCorporalE1=''No other bonuses.''
|LCorporalE2=''No other bonuses.''
|LCorporalE3=''No other bonuses.''
|Corporal1={{Disabling Shot (Long War) |text=1}}
|Corporal2={{Precision Shot (Long War)|text=1 }}
|Corporal3={{Snapshot (Long War) |text=1}}
|CorporalE1=''No other bonuses.''
|CorporalE2=''No other bonuses.''
|CorporalE3=''No other bonuses.''
|Sergeant1={{Damn Good Ground (Long War) |text=1}}
|Sergeant2={{Ranger (Long War) |text=1}}
|Sergeant3={{Sharpshooter (Long War) |text=1}}
|SergeantE1='''+2 Will.'''
|SergeantE2=''No other bonuses.''
|SergeantE3=''No other bonuses.''
|TechSgt1={{Executioner (Long War)|text=1}}
|TechSgt2={{Vital Point Targeting (Long War) |text=1}}
|TechSgt3={{Platform Stability (Long War) |text=1}}
|TechSgtE1=''No other bonuses.''
|TechSgtE2=''No other bonuses.''
|TechSgtE3=''No other bonuses.''
|GunSgt1={{Tactical Sense (Long War) |text=1}}
|GunSgt2={{Bring Em On (Long War) |text=1}}
|GunSgt3={{Lock N Load (Long War)|text=1}}
|GunSgtE1=''No other bonuses.''
|GunSgtE2=''No other bonuses.''
|GunSgtE3=''No other bonuses.''
|MSgt1={{In The Zone (Long War) |text=1}}
|MSgt2={{Mayhem (Long War) |text=1}}
|MSgt3={{Double Tap (Long War) |text=1}}
|MSgtE1=''No other bonuses.''
|MSgtE2='''+2 Aim.'''
|MSgtE3=''No other bonuses.''
}}

== Stat Progression ==
{| class="wikitable"
!Rank!!{{Health (Long War)}}/level!!{{Health (Long War)}}total!!{{Aim (Long War)}}/level!!{{Aim (Long War)}}total!!{{Will (Long War)}}/level*!!{{Will (Long War)}}total*
|-
|Specialist|| 0 || 0 || 4 || 4|| 5(6)||5(-6)
|-
|Lance Corporal|| 0 || 0 || 4 || 8 ||5(6)||10(-12)
|-
|Corporal|| 1 || 1 || 4 || 12|| 3(4)|| 13(-16)
|-
|Sergeant|| 0 || 1 || 4 || 16|| 2(3)|| 15(-19)
|-
|Tech Sergeant|| 0 || 1 || 4 || 20 || 2(3)||17(-22)
|-
|Gunnery Sergeant|| 0 || 1 || 4 || 24||2(3) ||19(-25)
|-
|Master Sergeant|| 1 || 2 || 4 || 28|| 2(3)||21(-28)
|}

* Note that, even without Hidden Potential turned on, there is a chance of gaining 1 extra will per level (shown in parentheses above). Psionic soldiers can also gain 1-6 extra will per psi level (<code>1 + rand(6)</code>).

== Tactical Advice ==
Long War Snipers are quite similar to vanilla Squadsight snipers, but there are a few differences. Overwatch only works up to limited range, even with '''Squadsight''' and snipers no longer have access to the '''Opportunist''' perk, making them considerably less good defensively - you'll find snipers can't demolish enemy packs on sight before they can even take cover like they can in vanilla. Squadsight is gained immediately and unconditionally, so there are no more "snap shot" skirmishing snipers (that role goes to the [[Scout (Long War)|Scout]]). With '''In The Zone''' and '''Double Tap''' still available, snipers are still some of your highest damage soldiers. Watch your ammo consumption with Double Tap and ITZ; high cap mags are a good item for them.

Snipers can use sniper rifles, which act like vanilla sniper rifles, and only allow firing if the user hasn't moved unless they are Snap Shot trained, but they can also use Marksman Rifles, which are shorter range sniper rifles that can be fired after moving. Snipers can use assault rifles as well, but this isn't particularly useful in practice, since the [[Infantry (Long War)|Infantry]] class generally performs better with assault rifles. As in vanilla, Snipers gain the most aim per rank, ending with 7 more aim than any other class at Master Sergeant.

The three main 'trick' shots, '''Precision Shot''' (aka: Headshot), '''Disabling Shot''', and '''Snapshot''' are now all on the same tier of Corporal, and thus, mutually exclusive. Thus, you may find yourself desiring more snipers than other classes in your campaign, to have a number of each to go out on missions. And, if you use multiple snipers in a squad, consider if to have them be the same kind, or mix n' match. For example, Disablers help out greatly for doing alien captures, Precision Shooters are for bringing down heavy alien units, and Snapshot Snipers could be played like Scouts (with more accurate/potent shots, can hit from full Squadsight range, but less defensive abilities). You may want to customize their names to easily distinguish between them in the Barracks and squad deployment screens (for example: #eadshot, Dis@bling, and $napshot, and putting #, @, or $ at the start of their first name).

==Sample Builds==
===In the Zone Cleaner===
Role: Long Range Offense

Classic In the Zone build - finish off multiple (up to 8, in theory) weakened and exposed enemies each turn, from the back line or in the air. Relies on cover destruction to expose enemies and bring their health into range of a guaranteed kill, especially as each kill with ITZ reduces the next shot's damage by 1 and critical chance by 10%. Snapshot and Lock N' Load allow a string of kills followed by reloading and continuing the chain, especially useful with the Gauss Sniper Rifle's small magazine. Ranger and Vital Point Targeting give reliable damage over crit chance, which is essential in planning an ITZ chain. Snap Shot allows reloading and more firing, as well as repositioning to get more flanks.

Sample Sniper:
''Lone Wolf -> SnapShot -> Ranger -> Vital Point Targeting-> Lock N' Load -> In The Zone.''

Note: Lock N' Load can be used to continue an ITZ chain after the original magazine is emptied. As Lock N' Load only works together with Snap Shot (you cannot shoot after taking a costly action, reloading included), the two perks go together. When using ITZ, use explosives to remove the cover of aliens. Use ITZ to clean up the exposed aliens. Flying targets also count as exposed.

===Assassin===
Role: Long Range Offense.

The Sniper in this role stays behind and relies on its Squad Sight. It is the classical "one shot - one kill" role where you focus on doing maximum damage per shot and landing every possible shot. For this, high aim soldiers are preferred and perks are centered around gaining more aim and damage. Can guarantee a kill against a squishy enemy every turn, or crack a seemingly invulnerable late-game mech enemy.

Sample Sniper:
''Lone Wolf -> Precision Shot -> Ranger -> Vital Point Targeting -> Bring 'Em On -> Mayhem.''

Note: Ranger + VPT + Mayhem provide you with +7 average damage, which should be enough to guarantee you one shot kills even without a critical. Precision Shot and Lone Wolf provide you with additional critical chance, which get boosted damage from Bring 'Em On. Precision Shot adds extra damage on crits. With flying armor and the Depth Perception Gene Mod, this sniper can achieve close to 100% critical chance on regular shots against exposed enemies.

===Double Tap Crit Monster===
Role: Long Range Offense.

A sniper that prefers to dish out two high damage crit shots each turn, versus one extreme damage shot. Kill two squishy enemies each turn, or focus both shots on one tough enemy. Potentially highest damage output of all builds, but has to stop to reload often. Give him flying armor and Depth Perception late game to rain death down on the battlefield.

Sample Sniper:
''Lone wolf -> Precision Shot -> Sharpshooter -> Platform Stability -> Bring 'Em On -> Double Tap''

===Skirmisher===
Role: Mid to Long Range Offense, with Utility in Disabling Shot

A sniper that can play at mid or long range, and can save the squad with a clutch Disabling Shot to take a Cyberdisc or Mectoid out of commission for a turn. Low Profile and Tactical Sense allow safe use of the Marksman Rifle to get closer and in position to land a crucial shot.

Sample Sniper:
''Low Profile -> Disabling Shot -> Ranger -> Vital Point Targeting -> Tactical Sense -> Double Tap''

==See also==
{{Soldiers (Long War) Navbar}}
[[Category: Long War]]
[[Category: Soldiers (Long War)]]

Talk:MAPS

2014-08-13T06:33:26Z

Bomb Bloke: /* Extra/unused .MAP files? */ Added the tileset files for map3/map4 + messed with the mess a bit.

Errr... need a bit of formatting help... see the page? I want to put on all the separate levels so that they are easily seen to readers. I managed to get the Skyranger showing as thumbnails, but the next heading should be below the thumbs, but isn't... :o( How can I get it to format right, or any other ideas would be appreciated! Cheers ---- [[User:Phoenix|Phoenix]] 18 April 2006 09:59 BST

-----

One possible option would be to put a '''<nowiki> </nowiki>''' after the image, so that all text that follows the image will continue underneath it.

For more image manipulators, check out [http://meta.wikimedia.org/wiki/Help:Magic_words Magic Words].

- [[User:NKF|NKF]]

----

Excellent! Cheers NKF!

- [[User:Phoenix|Phoenix]]

== Extra/unused .MAP files? ==

Hi all,

I've been looking at UFO's .MAP files in quite a bit of depth and I've found a few that don't seem to be used in the game. I've done a cursory examination of them in Hex Workshop and listed some of their attributes below. In a plain steam distribution, the files are:

''The below has been heavily edited by myself. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 02:33, 13 August 2014 (EDT)''

*MAP3.MAP - ''Seems to be a selection of buildings, unknown MCDs''
:32X48X3
<table><tr><td>[[Image:map3_1.png|Level 1|thumb]]</td><td>[[Image:map3_2.png|Level 2|thumb]]</td><td>[[Image:map3_3.png|Level 3|thumb]]</td></tr></table>

*MAP4.MAP - ''Seems to be a larger complex, unknown MCDs''
:32X48X3
<table><tr><td>[[Image:map4.png|Level 1|thumb]]</td></tr></table>

''[[:File:SpareMaps.zip|Here]] are the files I've built to view the above two maps in MapView, which must be independently configured to display them. Neither should be considered playable as they are. Both maps use the "map3" image set. MAP3.MAP has been edited to remove a few rubbish bytes from its header. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 02:33, 13 August 2014 (EDT)''

*PABDUCT.MAP - ''What appears to be two pyramids linked together, unknown MCDs''
:10X20X4
<table><tr><td>[[Image:PABDUCTMAP-L1.png|Level 1|thumb]]</td><td>[[Image:PABDUCTMAP-L2.png|Level 2|thumb]]</td><td>[[Image:PABDUCTMAP-L3.png|Level 3|thumb]]</td><td>[[Image:PABDUCTMAP-L4.png|Level 4|thumb]]</td></tr></table>

*PHARVEST.MAP - ''Dome shaped craft, unknown MCDs''
:20X20X4
<table><tr><td>[[Image:PHARVESTMAP-L1.png|Level 1|thumb]]</td><td>[[Image:PHARVESTMAP-L2.png|Level 2|thumb]]</td><td>[[Image:PHARVESTMAP-L3.png|Level 3|thumb]]</td><td>[[Image:PHARVESTMAP-L4.png|Level 4|thumb]]</td></tr></table>

*PSCOUT.MAP - ''Pyramid shaped craft, unknown MCDs'' persevering
:10X10X4
<table><tr><td>[[Image:PSCOUTMAP-L1.png|Level 1|thumb]]</td><td>[[Image:PSCOUTMAP-L2.png|Level 2|thumb]]</td><td>[[Image:PSCOUTMAP-L3.png|Level 3|thumb]]</td><td>[[Image:PSCOUTMAP-L4.png|Level 4|thumb]]</td></tr></table>

''[[:File:PyramidShipMCDs.rar|Here]] are the files I've built to view the above ships in MapView, which must be independently configured to display them (read further down in the below discussion for details). None should be considered playable as they are, though [http://www.strategycore.co.uk/forums/topic/9869-openxcom-mods/page__st__40#entry134928 luke83 has been working on rebuilding them for OpenXcom]. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 02:33, 13 August 2014 (EDT)''

*TEMP.MAP - ''Lowest level of [[MAPS_Terrain#City_Terror_Site|URBAN17]], same MCDs''
:10X10X1

*TEMP1.MAP - ''VERY simplistic design looks a little like the medium scout, probably just a test like the other TEMP maps, unknown MCDs''
:10X10X1

*TEMP2.MAP - ''Middle level of [[MAPS_Terrain#City_Terror_Site|URBAN08]], same MCDs''
:20X20X1

*TEMP3.MAP - ''Same as TEMP2 but without stairs''
:20X20X1

*NOSHIP.MAP - ''It's empty.'' created by xcomutil, no? ''Whoops, you're right... this map isn't included with the game''
:10X10X2

*UFO_000.MAP - ''Smaller version of the medium scout, unknown MCDs''
:10X10X2
<table><tr><td>[[Image:UFO_000MAP-L1.png|Level 1|thumb]]</td><td>[[Image:UFO_000-L2.png|Level 2|thumb]]</td></tr></table>

*UFO_010.MAP - ''A smaller abductor, unknown MCDs''
:20X20X2
<table><tr><td>[[Image:UFO_010MAP-L1.png|Level 1|thumb]]</td><td>[[Image:UFO_010-L2.png|Level 2|thumb]]</td></tr></table>

''[[:File:UFO000_UFO010_Alt_Maps.rar|Here]] are the files I've built to view the above ships in MapView, which must be independently configured to display them. In this instance, the files are edited versions of the original maps built so that they work with the released game's tileset files. In theory they should be nearly playable, though they lack route nodes. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 02:33, 13 August 2014 (EDT)''

*UFO_1B.MAP - ''[http://www.strategycore.co.uk/forums/Unused-Small-Scout-t7220.html Smallest scout], MCD is a modified version of UFO1 that's fairly easy to determine - just subtract an index''
:2X2X3

Anybody know what they are? The first two are especially weird; there's no way they could fit into an X-Com map unless it was the same map every time, like a TFTD ship attack. [[User:Off the Rails|Off the Rails]] 11:02, 8 February 2011 (EST)

:There's also UFO_010, UFO1A and UFO1B. Obviously, some of these are early UFO designs (for which we haven't been able to determine a correct set of MCD files to use - we'd probably have to build an MCD from scratch if we ever wanted to see them), but some I'm outright unsure about. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 17:25, 8 February 2011 (EST)

::Although I'm new here, I've been lurking for a while and, for a month or so, learning to make .MAP data my bitch. I've an idea: assuming the MCD array starts with BLANKS.MCD, we can figure out whether a particular map tile is empty or not (ie if the relevant byte in the file is 00, the tile contains nothing; otherwise it must contain something...) and therefore come up with a basic floorplan for the terrain. I'll have a crack at it and put the results on my user page. [[User:Off the Rails|Off the Rails]] 16:04, 10 February 2011 (EST)

:::There's an easier way to actually 'see' what the files might contain using Daishiva's MapView. The question is that you don't know which MCD sets are required for each map (except for the UFOs) so it would take a lot of trial and error and mostly likely they are simply garbage (I've checked UFO_000, and it never made any sense, regardless of the MCD combination I tried). [[User:Hobbes|Hobbes]] 16:38, 10 February 2011 (EST)

::::Indeed, that's what I meant when I said we may need to build new MCDs; the ones needed to load the old UFO MAPs simply weren't included, best I can make out. I suspect we might be able to do wonders with a bit of tile re-ordering, but if may be we're outright missing some of the graphics we need. Anyway, Rails, I've taken the liberty of adding some additional info to your initial list. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 18:15, 10 February 2011 (EST)

::actually UFO1A is the small scout it uses UFO1.MCD, UFO_010 is the medium scout. UFO1B.MAP (2x2x3) and UFO_000.MAP (10x10x2) are the two unknown ufos. - [[User:Daiky|Daiky]]

:::Whoops, careful with the history buttons... attempting to edit a page while viewing an older version performs a revert to that version. Anyway, yes, my mistake with UFO1A, but you're confusing UFO_010 with UFO_110. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 18:43, 11 February 2011 (EST)

So it occurred to me late last night that rebuilding the MCDs was too much like hard work... Rebuilding the MAPs to work with existing MCDs would be much faster. I've performed a quick conversion of the PSCOUT map and added pics above. Not sure if the original hull was yellow (it probably would've been alloy-coloured), and I'm uncertain whether those are supposed to be seats in the hall on the lowest level, but other then those two points it should be nearly accurate.

Different wall tiles were used where the north-walls meet the west-walls, which typically isn't the case with the maps used in the finished game. When these two tiles meet, the game crops the sprites on the fly in order to prevent the overlap effect you get in Daishiva's MapView. I'm thinking this map was designed before the cropping feature was added, and so it would've used pre-cropped sprites. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 19:01, 12 February 2011 (EST)

:Is MapView available for download anywhere? I've tried Daishiva's site and it hits me with a 404 every time. [[User:Off the Rails|Off the Rails]] 19:24, 12 February 2011 (EST)

::[http://www.strategycore.co.uk/files/index.php?dlid=413 Here]. I've done the Abductor now, images are above. It seems this one uses diagonal joins which have no equal in any of the tilesets I have access to; new sprites would need to be drawn to display the entire thing correctly. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 19:33, 12 February 2011 (EST)

I'm a bit stuck with the harvester; The hull and so on is obvious enough (the same converter proggie I used on the other two craft was able to deal with that in an instant), but the internals aren't quite so obvious. It seems to have its own unique walls, and a lot more unique sprites then the final version of the craft has.

After a bit of messing about, it struck me that I'd seen a rotated version of the dissected deer somewhere before, and it'd be perfect for a certain mass of unidentified tiles in the NW area of the craft (the usual deer is near the north end, but there's much more then that in there). Catch is, I can't remember WHERE I'd seen the rotated deer!! For all I know it's a figment of my imagination, or perhaps it was one of Hobbes' tweaks... I thought it might've been up on XCommand, but no... (that sounds like a tile I have for one my modded maps, where I took the cow image, and edited it to make it look like it is hanging from a chain [[User:Hobbes|Hobbes]] 14:02, 13 February 2011 (EST))

Anyways. I'll need to start my conversion script from scratch for the other craft (which are somewhat dissimilar to the ones I've looked at in terms of tile usage), but I thought I'd upload my work thus far and scribble out a brief tutorial on how to check it in MapView.

First off, [[:Image:AlphaUFOsConv1.zip|extract this]] straight into your game folder. Now goto your MapView install folder and open "Images.dat" in Notepad or similar; you'll see a whole bunch of MCD sets listed, you need to add this line down the bottom:

U_PYRA:${ufoImg}

This is a butchered version of the U_BITS tileset that contains just the pyramid tiles from Cydonia, which I've been using for the craft hulls (they're the only shape that makes sense).

Now load the program and goto the Edit menu, select Paths. Select the Map Files tab, navigate to UFO's Alien Ships, and left click it once - so it's highlighted blue - then right click it. Use the context menu to add an "existing" map, then select one of the "P" ships (I've added a "2" onto the filenames of my edits, so they won't overwrite the original garbled versions).

If, after pressing the Open button, the craft doesn't appear on the alien ship list, then just repeat the process. Daishiva's proggy has a few bugs that were never ironed out, unfortunately. When you've got it listed, you can then select it and select MCD files for it to use. You can copy/paste MCD lists from other craft or define them manually.

*PSCOUT2 uses U_EXT02, U_WALL02 and U_PYRA.
*PABDUCT2 uses U_EXT02, U_WALL02, U_PYRA and U_OPER2.
*PHARVEST2 uses U_EXT02, U_WALL02, U_PYRA and U_DISEC2.

Presumably the original craft maps used U_EXT01, but we don't have that set, so... -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 20:51, 12 February 2011 (EST)

:Completed UFO_000 and UFO_010. These two are much closer to the craft designs we're used to, though there was some weirdness with the hulls that makes me think the externals didn't quite look like these conversions do. With the larger of the two, I'm unsure if the two siderooms should contain vats or not - the ship is certainly an abductor, though those items are indexed above the ranges of all the other abductor items the ship uses... so I just took my best guess. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 07:00, 13 February 2011 (EST)
::Are there any chances to see them in mapeditor? I mean, appropriate tilesets for these UFOs, like U_EXT01 would be nice.--[[User:Volutar|Volutar]] 02:08, 12 October 2011 (EDT)

:::[[:Image:UFO000_UFO010_Alt_Maps.rar|Here]]. Rather then build MCD files for them, though, I just used a "search-and-replace" script to rebuild the MAP files to work with the pre-existing MCD files. You could, for eg, simply switch the medium scout map (UFO_110.MAP) with the converted version of UFO_000.MAP (UFO_0002.MAP), and it would probably work "as is" in-game (except for elerium placement, probably).

:::The conversion of UFO_010.MAP doesn't match the MCD combinations of any other craft, unfortunately. Could still be implemented in-game, would just require a tiny bit more work to get the game to load the correct MCDs. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 21:41, 12 October 2011 (EDT)

Giving up on the pyramid ships for now. Think they're about as well done as possible without starting to make outright guesses as to how they were intended to appear. The Harvester is really the only incomplete one anyways. [[:Image:U_PYRA2.zip|Here's the terrain set I came up with]]. Not at all playable, but it gives a pretty good picture as to what the original tileset would've looked like.

MAP3 turned out to have the map dimensions repeated at the start of the file, offsetting all the tile indexes by three bytes. Moving them back makes the file a bit more clear - it's filled with buildings, same as MAP4. They also obviously use the same terrain set.

The outside area of of MAP3 contains what appears to be ice pools from the polar terrain. At first I thought they were craters from Mars, but some are too large, and others are of irregular shape - the pools are the only match.

But arctic terrain doesn't include buildings. The buildings we've got are alien, X-COM's, farm-style, and urban style... But the buildings in MAP3 use staircases ''and'' grav lifts. The lifts suggest alien architecture, but no alien tilesets have stairs... and no terrains with stairs have lifts! The internals are sparsely furnished, but strike me as too irregular to be of alien design.

[http://web.archive.org/web/20010606165240/www.mythosgames.com/ufoenemyunknow.htm Julian] dropped mention that there had been plans for another alien-hunting group to show up in the game, similar to the Men in Black (keeping in mind that movie came out some years after the game...). At this stage I'm suspecting that these maps were going to be their bases. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 07:10, 20 February 2011 (EST)

:[[:Image:PyramidShipMCDs.rar|A better set of MCDs for the pyramid ships]]. These ones are more or less playable, or would be if the game were to use them. Load them in the order of: U_EXT01.MCD, U_WALL01.MCD, U_DISEC1.MCD then U_OPER1.MCD. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 07:46, 16 May 2012 (EDT)

I've added mock-ups of MAP3.MAP and MAP4.MAP. Fairly simple structures. The art may've been much different originally - the only tiles I'm near-certain would've looked as they do here would be the wallpaper ones. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 07:15, 18 May 2012 (EDT)
:Great work. This definitely has to be an additional unused terrain. Both maps are very similar to Laser Squad's set piece maps, so I'm guessing these would be for the missions that got dropped out. I'm guessing that on MAP3 should be either for to locate *something* that can be on either both large structures, with the small sniper towers, or could be to simply clear both buildings. On MAP4 you'd start on the central area and would have to find the cell which contained hostages/prisioners. The layout reminds me of the Rescue From The Mines scenario of Laser Squad. Both maps can also be a two-part mission, like TFTD. Clear the first map then go below to find the prisoners/hostages/doomsday device, etc. [[User:Hobbes|Hobbes]] 18:24, 21 June 2012 (EDT)
::A little more speculation: on MAP4 the doors must be sliding doors. Otherwise the doors of the small corridor close to the central area would open and replace the wall on its opposite side. The white arctic ground should be dirt blocks like those found on alien/XCOM bases. The crates on those 4 rooms are another enigma - it is possible that another part of the mission would be to destroy them.
:: Another question, where do the XCOM craft land - MAP3 around 50x30, so you'd most likely start on the down left or upper right sides - those half lakes that you see on MAP3 you'd have the missing half on a hypothetical MAP1/2. [[User:Hobbes|Hobbes]] 10:07, 22 June 2012 (EDT)

==Map Combination Example==
I've looked at the example provided and there are quite a few details missing on how the game builds the Battlescape map. I'm going to try to reproduce the list of steps for map array building process. There are 2 options possible:

1) Game determines terrain, Dropship and UFO (if it's present)

2 a) Game places Dropship and UFO, then fills remaining empty spaces by picking randomly from the maps available for that terrain (with some exceptions on what it can choose) OR b) Game fills empty spaces by choosing randomly then places dropship and UFO.

2 b) is what is described on the example (extrapolating that when the game is determining the MCD array it is also building the map) but there are a few issues by using that method (based on my experience with battlefield generation rules on UFO2000):

Issue #1 - What happens in the case of a 20x20 map that the game decides to place a UFO or dropship occupying just 1 corner of it?

Answer #1 - the game would have to detect it and substitute the remaining 3/4 with 10x10 maps.

Answer #2 - the game only places dropships/UFOs on existing 10x10s but since you'll need more (just a dropship occupies 20x10 or 10x20 and a Battleship 30x30) that would make it almost impossible to place larger UFOs on battlefields that contain 20x20 individual maps because there would be no space for them!

Issue #2 - Every Terror Site map has a road but no UFOs. Following the process above, battlefield is generated (including the road), then the Dropship is placed. Same problem happens here - either the game checks so that the dropship isn't placed on a 20x20 or a road map, which could prevent that it would be placed if there isn't 2 10x10s joined. It would also have to adjust the map blocks around it to make sure that the front part of the Skyranger wasn't isn't a warehouse!

But with the 2 a) process the above issues don't happen.

Issue #1 - Game places Dropship and UFO randomly on the Battlescape. Engine then fills the remaining spaces with random 10x10 and 20x20 maps

Issue #2 - Game places Dropship on Terror Site. Engine then adds the roads and fills the remaining spaces.

My question is that I've seen Skyrangers placed over buildings and its tiles overlapping them, which is evidence for 2b). I've seen only using XComUtil though - it should have its own specific generation rules. [[User:Hobbes|Hobbes]] 11:12, 10 January 2012 (EST)

:When placing craft on a battlescape, the games dedicate certain terrain modules as "landing zones" - clear areas without structures the craft would conflict with. Usually these are modules 0 and 1, but there are exceptions. I know that Scott's generator doesn't deal with this properly (hence why you only see weird overlaps with XCU), not sure if Blade fixed it or not. But note that the craft location is determined first, and the modules it sits in are only placed there because the craft was first assigned to that position. Everything else gets positioned after.

:Anyway, the article isn't talking about how the locations of the ''modules'' are determined. It's talking about the actual combination process of the ''tile indexes'' inside these map files, which results in the final array which goes into MAP.DAT when you save the game - the one that keeps track of all the individual tiles in the battlescape, what's been blown up, and so on. It's saying that first the tiles in the terrain modules are added to the map array, then the the craft's tiles get superimposed on top. This is why if a SkyRanger IS incorrectly placed on a house, the Skyranger will take a chunk out of the building - the building won't take a chunk out of the SkyRanger.

:All the info on where the modules are positioned is currently [[Battlescape_Map_Generation#Map_Statistics|here]]. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 17:52, 10 January 2012 (EST)

:Figured you might find [[:File:UFOMapLogs.rar|this]] interesting/useful. Makes it fairly easy to spot many module placement patterns at a glance. I can give you the files needed to generate more, if you like. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 18:09, 10 January 2012 (EST)
::Makes sense everything then - maybe this should be on the Battleship Generation page. I've looked at the Maplogs, interesting, thanks. There are also specific maps assigned to be placed under the UFOs, just by looking at Farm, you can see 00, 07, 11, like for Dropships. This will actually be useful later when redesigning those terrains. [[User:Hobbes|Hobbes]] 19:11, 10 January 2012 (EST)

File:SpareMaps.zip

2014-08-13T06:14:08Z

Bomb Bloke:

User talk:Hobbes

2013-04-26T22:17:42Z

Bomb Bloke: /* Nav Boxes */

Talk:Main Page

2013-04-25T13:11:54Z

Bomb Bloke: /* Pretty Colours */

'''Welcome To All Rookies'''

This is the place to talk/ask about general issues concerning the wiki and hopefully someone will answer/reply to them.

Specific game questions should be asked on the game's individual talk pages.

For new users, in order to reduce spam you'll need to register to be able to edit pages.

To start a new topic simply press the '''edit''' button above. Then place your <nowiki>==Topic Name==</nowiki> like it is written here.
* To add a line you can either type <nowiki>----</nowiki> or use the buttons that appear on the edit screen.
* If replying to an existing topic use colons '''<nowiki>:</nowiki>''' before your answer
* Don't forget to sign your posts in the talk pages by typing '''<nowiki>~~~~</nowiki>''' at the end.
* Finally when creating/editing wiki articles have a look at the [[Guidelines to writing articles|guidelines]] page.

That's it. Happy editing!
----

Old articles have been moved to [[Talk:Main Page/Archive]] for later perusal.

__TOC__

==XCOM: UFO Defense==

Update: Well, game's about to be released and the [[Enemy Unknown (EU2012)]] page and table have been worked on, and now there will surely be more people stopping by and wanting to know more. So the question I'm asking everyone is to have a look at the current status of the new game page and think about when the new table should be moved to the UFOPaedia's Main page? [[User:Hobbes|Hobbes]] 20:23, 7 October 2012 (EDT)

== New Main Page layout. ==

I'm working on a new Main Page layout. Found here: [http://www.ufopaedia.org/index.php?title=User:Kokkan/Main_Page]. So I was wondering if it would be possible to apply something like this ([http://www.mediawiki.org/wiki/Manual:FAQ#How_do_I_hide_the_main_page_title.3F])? Preferable (http://www.mediawiki.org/wiki/Extension:NoTitle) --[[User:Kokkan|Kokkan]] 16:34, 18 September 2012 (EDT)
:Looks good to me, just one thing: why is the OpenXcom logo displayed? [[User:Hobbes|Hobbes]] 09:11, 4 October 2012 (EDT)
:: That was just a aesthetic choice. =) --[[User:Kokkan|Kokkan]] 12:36, 4 October 2012 (EDT)
::: I see :) Well the thing is that it's that placing that logo there is going to bring a lot of attention to that project. My question was if that was intentional or not. [[User:Hobbes|Hobbes]] 12:43, 4 October 2012 (EDT)
:::: Kokkan, would it be possible to squeeze the 'featured article' on the corner below the 'UFOpaedia News' (probably enlarge the corner)? I like how the new design has a compact look to it and to me it would look better if the 'featured article' was integrated with the news sections. Or probably even switch its position and put it on top rather than the 'UFOpaedia news' [[User:Hobbes|Hobbes]] 12:57, 4 October 2012 (EDT)
::::: Right now it depends on the width of the browser and the content in the Featured Article. I might be able to set some auto-width on the XCOM New window. --[[User:Kokkan|Kokkan]] 09:11, 5 October 2012 (EDT)
:::::: I was wondering if it wouldn't be better to bring up the Enemy Unknown 2012 table as the first table, at least for some time after the game is released. With my current maximum resolution both tables still appear one over the other, and I think the UFO Defense table might need a little reorganization and after it is done both games go back to being side by side. Or any other ideas. [[User:Hobbes|Hobbes]] 20:15, 8 October 2012 (EDT)
::::::: What?! This layout should work with all resolutions down to 1280x720 without stacking items. So it should be fine on everything except the smallest ( <11" ) notepads and pads. --[[User:Kokkan|Kokkan]] 04:49, 9 October 2012 (EDT)
:::::::: My resolution on my monitor is 1280x1024 and both tables are stacked. [[User:Hobbes|Hobbes]] 05:00, 9 October 2012 (EDT)

Same issue here with the overlapping tables, and my screen's 1024 pixels wide. Doesn't look any better on the tablet. Quick solution: Break the table out and have it on top ala the original's old main table, and have the original follow immediately after.

A while back I had wanted to redesign the front page but had to shelve it (and then quickly forgot about it). That was to make the main page just contain the news and a list of box art for the various games that point the users to separate main pages for the different titles, allowing the main tables for each title to be a bit more elaborate. Perhaps this might be a good time to resurrect that concept? [[User:NKF|NKF]] 07:15, 9 October 2012 (EDT)
:I'll place the EU 2012 table on top of the original game table (*sniff* *sniff*) for now until a permanent solution is found or the issue is fixed. I'm good with that solution or any other.
:Quick fix: I've moved it to the Featured section. [[User:Hobbes|Hobbes]] 08:03, 9 October 2012 (EDT)
----

:Hi folks, I think the partition to having the XCOM 2012 on its own main page is a really good one... now, folks can go to town on it, without having to keep touching the original fansite per se. But it is still kept close by having a highlighted announcement - Thanks for that, Kokkan! Some other comments:
[[File:X-COM UFOpaedia screen.jpg|100px|right|thumb|It's UFOpaedia]]
::*Do we need two "action" pictures at a time? Maybe we could have one, and use it to help balance the X-COM and the UFOpaedia news so that both "sides" of the news end at about the same place. For that matter, either side of the news could otherwise be tightened up, or expanded. But I wish they both ended at the same place so the main page looks more professional.
::*This is the time to make the standard for the new XCOM 2012 pages. Can I please ask that, for the URLs themselves, we not put parentheses around EU2012? I see it leading to a lot of hassle because ultimately there will be citations in citations in citations and other future complexities, including for other sites trying to cite us... parens just make everything more difficult and clunky. If you agree but say "but it'd be a hassle to fix it now", I say that's the wrong answer because it's about to explode (I'm sure!!!), so it's really now or never. Just append EU2012, without parens... everybody can figure out what it means. :)
::*I'm not sure just how/when it happened, but there's a lot of "Ufopaedia" on the main page. We use the original game as the convention setter, right? It's a minor thing, but still, we should have a convention, one way or the other. Does someone think it should be Ufopaedia?
::*To me, the brief OpenXcom logo nip slip (laugh) raises the issue that I wish we highlighted these efforts better... maybe they could use a little shout-out at the bottom of X-COM News section (just a very brief mention or link - little or no write-up), instead of the tiny section they now have, way at the bottom of the main UFOpaedia page.
:Again, the above points are minor... the big thing is the new place from EU2012 (great idea!). Thanks!! -[[User:MikeTheRed|MikeTheRed]] 14:24, 4 October 2012 (EDT)

:: We can set the hight at fixed values, but I really don't see a point to it. Since the size of the content will change. I prefer the parentheses in the naming, it clarifies what game the page relates to, and I don't see an extensive problem in linking to pages. Like ( [[Enemy_Unknown_(2012)|Enemy Unknown]]). On the UFOpaedia & OpenXcom logo, I fully agree. --[[User:Kokkan|Kokkan]] 09:11, 5 October 2012 (EDT)
::: One easy trick to link pages with the (EU2012) suffix is to open the top page on the category, which usually contains a list of all items related with that subject, press edit and then copy/paste the links. [[User:Hobbes|Hobbes]] 09:19, 5 October 2012 (EDT)

== XCOM Sidebar logo==
One possibility I thought of would be to replace the old logo/badge on the upper left corner of the wiki with the newer XCOM badge. Here's some options: 
[[File:Xcomnewlogo.png|100px|XCOM badge used ingame on the soldiers armor - I can't get a better pic than this one]]
[[File:Blue badge XCOM EU.png|100px|XCOM icon used on packing and ingame for menus, etc.]]
[[File:Xcom_eu_logo.jpg|100px|And there's also the game logo]] 

Anymore ideas? Which would be best? [[User:Hobbes|Hobbes]] 13:44, 4 October 2012 (EDT)

:The game logo is much cooler, while the insignias seem much more real-to-life. That said, I vote for cooler. The essence of the old X-COM was how scary cool it was. -[[User:MikeTheRed|MikeTheRed]] 14:33, 4 October 2012 (EDT)

:: I say keep the old X-logo, show the roots and lets not take over the entire wiki with EU2012. Use the new logos at appropriate EU2012 pages. --[[User:Kokkan|Kokkan]] 08:55, 5 October 2012 (EDT)

::: Not selling ourselves completely eh? ;) Well I just have to say I love the yellow and black insignia - that's probably the first XCOM logo/icon I really enjoy :) [[User:Hobbes|Hobbes]] 09:15, 5 October 2012 (EDT)

:Showing roots is good, too. The gold one does not seem as high-rez as the other... can we get it any better? -[[User:MikeTheRed|MikeTheRed]] 09:55, 5 October 2012 (EDT)

== Disambiguation of 1994 vs 2012 Entries ==

See for example the Sectoid entry, where a link to Sectoid (EU2012) has just been added as the first line of the entry. Are we going to do that for every entry that has the same name in 1994 as in 2012? That's a lot of minor edits someone will need to make! And putting these cross references under See Also would be less intrusive. But maybe a lot of enquiries from new site users are going to be related to EU 2012, and they will be confused if the cross reference is not clear and up-front. Let's agree a standard approach for this. As an alternative we could use disambiguation pages that show links to both the 1994 and the 2012 versions. Instead or as well, we could start moving 1994 pages by appending (EU1994) to the name. That's also quite a lot of work, but may be clearer in the long term. Even more work comes in if we were to use for example [[Sectoid]] as the disambiguation page, because that would mean rewriting all links to Sectoid in all the 1994 entries of the Ufopaedia. Thoughts everyone? [[User:Spike|Spike]] 03:56, 19 October 2012 (EDT)

On a related point - do we really need to append (EU2012) to every entry? I would think it's only necessary when the same term is used in both games. So it makes sense for Sectoid, but not so much sense for Gollop Chamber. I would suggest that for a term that is ''definitely'' unique to EU 2012, the (EU2012) suffix is not required. But there should always be an EU 2012 Category tag on the entry. [[User:Spike|Spike]] 06:28, 19 October 2012 (EDT)

: If we don't tag everything now, do we risk the same issue we're running into with UFO Defense? Also, the new Sectoid page has a space between EU and 2012. No other new page has that. My OCD is making me want to stab people. Is there a way to edit it to not have a space? As far as which way to go, I prefer disambiguation pages much like wikipedia does, but that typically requires tagging both. I would be happy to do the leg work and chase down all the 1994 ones but I don't like how EU1994 looks (especially since it says 1994 in the Games column to the left [sorry - fixed that - Spike] ) and I don't know how to update page names. --[[User:PixelOrange|PixelOrange]] 06:34, 19 October 2012 (EDT)

:: Yes, we do need to keep the games a part to not run into conflicting pages/links. Hence we suffix ALL pages on the NEW game ''(EU2012)''; this is the simplest and most clear way to do it. It does make it a bit of a hassle to link stuff yes. Even if some parts are unique, keep with the naming convention to keep it all as clear as possible. No, There is NO WAY we can do the same for the original game, there is just to much pages and links (and if we start and don't complete or something goes wrong, the wiki is in a fucked up state). So all pages on Enemy Unknown without the suffix refers to the original game. --[[User:Kokkan|Kokkan]] 07:12, 19 October 2012 (EDT)

:::So, if we're not going to retroactively update the old Enemy Unknown, redirects at the top of every page is my favorite choice (just as they do over at wikipedia). It gives you a quick link right at the top of the page, it's non-intrusive, and it's easy to implement across the board. --[[User:PixelOrange|PixelOrange]] 07:38, 19 October 2012 (EDT)
:::: OK but that's only going to be workable for the EU2012 pages, right? Any modification to all of the EU1994 pages is a big task, whether it's a disambiguation link at the top of the page, or a systematic rename to suffix "EU1994" on to the end of the page name - the workload is similar. I guess we could take a policy that says - anytime you create an EU2012 page, check to see if an EU1994 page of the same name exists. If so, add disambiguation links to the top of both pages. Or, for that matter, Move the EU1994 page by adding the suffix to its name. By the way, Move is how you rename a page, and the old name is preserved as a redirect to the new name. [[User:Spike|Spike]] 08:12, 19 October 2012 (EDT)

::::: I agree that disambiguation notices/links on top of pages probably is the best way to handle this (as in the [[Sectoid]] page). Moving and creating disambiguation pages is to much workload, and to have some (EU1994) pages and some without would be even more confusing. So I say no (EU1994) suffixes at all. --[[User:Kokkan|Kokkan]] 09:17, 19 October 2012 (EDT)

:::::: I don't think it's that cut and dried myself. Moving (renaming) the old pages is less workload than creating the disambiguation links. Also, adding the disambiguation links will disrupt the style / formatting of the existing EU 1994 pages which were not designed to have these links at the top, and which have had a lot of effort put into their layout over the years. Creating a disambiguation page with the "base" name, eg "Sectoid", the same name as the existing 1994 page, is a huge workload, because then all the links will break. Creating a new page called "Sectoid (disambiguation" and redirecting to it is not much better. A simple Move/rename will not break any links, meaning low workload - same as inserting a disambiguation link/notice. Keep in mind that the scope of the problem is only the pages for terms that exist in both games. "Sectoid (EU1994)" vs "Sectoid (EU2012)" is part of the required disambiguation workload. Heavy Cannon (unique to EU1994) vs Alloy Cannon (unique to EU2012) does not need to be part of the workload. It's a safe strategy to keep naming all new 2012 pages with the EU2012 suffix, but whatever method is selected does not need to be applied to all pages in both games. For example, we do not label all TFTD pages with (TFTD). We don't say "Tentaculat (TFTD)" and "Chrysallid (EU)". We do say "Zombie (TFTD)" and "Zombie (EU)" (even though the differences are only cosmetic). [[User:Spike|Spike]] 09:51, 19 October 2012 (EDT)

::::::: We already had this discussion a while ago because of Apocalypse and the common elements of the series that extend to it and TFTD. I don't recall the discussion but you guys mentioned the main topics but the idea was to start using the suffixes, specially when creating new pages, and not to worry about the existing pages because of the workload involved. It's basically to avoid the mess of the original game's pages regarding naming and to help categorize identify pages.
::::::: This method makes linking a bit harder but it's a matter of using a few tricks (which I already use when linking on the original game), like open and edit the section page (Soldiers, Weapons, Alien Life Forms, etc.) and just copy/paste the links you need. That's also why the section pages usually consist of lists of items.
::::::: Finally me and Spike can delete, move and rename pages, as an administrators so just let us know what you need :) [[User:Hobbes|Hobbes]] 11:09, 19 October 2012 (EDT)

:::::::: I've been thinking about the effects these new XCOM games (EU 2012 and the upcoming FPS) may have on the future of the series. If XCOM sees more games even further in the future that involve the aliens from the original, I don't think links at the top of the page is going to do the trick. We should make disimbaguation pages now to pave the way for recurring aliens and items that may make an appearance in any potential future installments. Just a thought!--[[User:SuicidalSectoid|SuicidalSectoid]] 21:26, 19 October 2012 (EDT)

Another option that I've been thinking over is asking Pete if he could set up a separate Wiki for the modern title(s) and keep this one for the classic titles. It would keep things tidy, and there's actually little crossover or common material between the new and old apart for historical and ancestry referential purposes. [[User:NKF|NKF]] 21:46, 19 October 2012 (EDT)

:: Personally I think all games of the series, old or new, should be all united in a single wiki. It helps this one grow, instead of just running out of material. It also shows how the series began and progressed to become what it is today. It helps people who are new to the series find older games in the series far easier and learn all their quirks and strategies. Of course there is what I mentioned above to consider, if this series really has been revived, then more games in the series may emerge and the new wiki could end up being "untidy".--[[User:SuicidalSectoid|SuicidalSectoid]] 10:54, 20 October 2012 (EDT)

== Other Wiki ==
I have recently found another wiki bearing the XCOM title. It focuses purely on the remake and frankly it is pointless considering the Ufopaedia is already established.

I'm just getting the word out.--[[User:SuicidalSectoid|SuicidalSectoid]] 14:08, 24 December 2012 (EST)

:Got a link to it? Redundant or not, it's nice to see other eager about the game. [[User:NKF|NKF]] 16:00, 24 December 2012 (EST)

::[http://xcom.wikia.com/wiki/XCOM_Wiki This one], I'd say. Most likely exists because someone thinks every new game needs to be on wikia. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 05:03, 25 December 2012 (EST)
:::I've noticed it even before the new game was out. They have nice design and content for the new game and a lot of traffic from being on wikia but all those commercial advertisements and structure and being restricted to the new games are the negative factors. [[User:Hobbes|Hobbes]] 12:13, 25 December 2012 (EST)
::::Ugh. I wouldn't describe wikia's design as "nice". It's superficially impressive, but crammed with advertising and if you try to actually get anything done on it it's horrible. There's a reason most of wowwiki deserted wikia when they imposed that format. [[User:Binkyuk|Binkyuk]] 12:45, 25 December 2012 (EST)
:::::By design I mean the navigation elements that make it easier to access game sections. Visually I also think it has too many elements. [[User:Hobbes|Hobbes]] 13:54, 25 December 2012 (EST)

== Pretty Colours ==

You know what'd be cool? Different page themes depending on the game. Say for example, yellow for TFTD, red for Apocalypse, black / dark grey for XCOM, and so on. Or maybe even custom wallpaper for each title - nothing overly eye-catching, just an easy way to differentiate what you're looking at with a glance.

We'd need an extension to do it (I've already got my eye on [http://www.mediawiki.org/wiki/Extension%3aPageCSS a simple looking one]), but before I bug Pete about it, what say ye all? The way I see it, we'd need to make one template page per "theme" - but then we'd need to edit just about every page on the wiki to implement them...

-  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 02:59, 18 January 2013 (EST)

: I wanted to do something similar many years ago when I started making the navbars so that when people went to a page, they'd go "oh, this is EU or TFTD" just by the colours. Didn't get received very well if I remember correctly. But, with todays better versions of wiki software and scripts, why not? Go for it I say. -[[User:NKF|NKF]] 17:47, 18 January 2013 (EST)
: I think that's a wonderful idea, the issue is to pick a good color design that retains readability. [[User:Hobbes|Hobbes]] 18:30, 18 January 2013 (EST)
:Great Idea! I second what Hobbes is saying about readability. If you can't read what's on the page there's no point to new colours.--[[User:SuicidalSectoid|SuicidalSectoid]] 17:45, 25 March 2013 (EDT)

{{StyleTest01}}So, yeah, I did bug Pete, and not long after he delivered: We've had the plugin online a while now...

Anyway, this afternoon I sat down and plugged some stuff into it. It works much like I hoped (though unfortunately it doesn't have much control over images - can't set them as background for eg). Adding the tag ''<nowiki>{{StyleTest01}}</nowiki>'' to a page and saving it (or, perhaps for now, previewing it - though I've applied it to THIS page for now) applies the effects within that template.

That one's just an experiment, might be a little garish maybe (I basically grabbed colour codes out of screenshots from EU2012; I won't call myself an artist), and doesn't yet override every wiki element that needs to be handled - but I reckon it's a decent start. :)

-  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 03:47, 21 April 2013 (EDT)
:I like it. [[User:Leman Russ|Leman Russ]] 04:05, 21 April 2013 (EDT) ''Thanks! -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 06:41, 21 April 2013 (EDT)''
:Nice, I like trying to replicate but the colors sure need some testing. One thing I'm wondering: is it possible to use the font used in EU2012 (it seems to be Century Gothic)? Another suggestion I'd make is to replace the XCOM logo on the top left with the new one.
:I've applied the styling to the page I'm currently working on: [[Class_Builds_(EU2012)]]. The main issue is the color of the links (dark blue isn't the best for contrast). Another thing needed would be to change the default colors used in the table templates to match the new style. [[User:Hobbes|Hobbes]] 04:36, 21 April 2013 (EDT)
::Apparently Century Gothic is not installed on most machines by default. It may be possible to load it on to the wiki somewhere and get viewers to download it as needed, but I really dunno. I'm guessing 'MS PGothic' is the best match that's widespread - I've tweaked the template to use that if Century Gothic isn't available, or to fall back to the wiki default if neither are on the viewer's machine.

::I did try switching the logo, but apparently the plugin doesn't allow it. Or the icon isn't accessible to CSS. Or I didn't know which element to tweak. What I've read specifically states I shouldn't be able to use the required "background-image" tag, but that's exactly what I needed to do to change the toolbar at the top of the page...

::I HAVE overridden the main 'wikitable' template, and there should be no blue links visible (except for ones leading off-site, I forgot about those)... In fact I'd go as far as to say the table looks great on that Class Builds page in particular (where the text matches the icons) - are you seeing what I'm seeing? [http://img.photobucket.com/albums/v213/BombBloke/StyleTest01_01_zps93e4e66e.jpg A screenshot may be in order]? I'm a little worried about browser compatibility in regards to my CSS overriding that which is already in the wiki site files.

::Depending on how I go for time I may deal with image thumbnails, the category bar, table of contents etc tonight.

::Please feel free to experiment if you feel so inclined! Either make a new ''StyleTestXX'' page and copy/paste my starter version in, or go right ahead and modify mine! If you lack any tools on your system for colour code generation, [http://www.2createawebsite.com/build/hex-colors.html here's an online one].

::-  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 06:41, 21 April 2013 (EDT)
:::On my laptop I see it like this, I think it's the same and it seems to be using Century Gothic: [[:File:style1.png|style1.png]] - [[User:Hobbes|Hobbes]]

::::Ah yes, that was a match of colours, though you're definitely using a different font (it's installed by Office, see).

::::Still not sure what you're meaning about the tables, but I've switched monitors and see what you're saying about the links. I think maybe yellowy? Dunno.

::::-  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:50, 21 April 2013 (EDT)
:::::Yellow links look better than the previous ones. What I meant about the tables is that on the Class Builds the background color of each table is table while the page background is dark grey. I got Century Gothic installed (it's a free font IIRC), is it the one being used? [[User:Hobbes|Hobbes]] 11:20, 21 April 2013 (EDT)
::::::Er...

::::::The cells should have a black background, the header cells should be grey. This is what I intended, though if you're expecting something different (or have a different suggestion) I'm more then happy to try other styles.

::::::I'd say you're indeed using Century Gothic. If you check the "font-family" line in the template, the web browser reads it from left to right, and uses the first font specified that exists on the computer (so if it can't find one, it falls back to the next, and so on). Hence if you start removing fonts from the front of the list and previewing the page you can compare each one. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 19:11, 21 April 2013 (EDT)
:::::::There were a couple of white backgrounds on table but those seen to have disappeared. Century Gothic still looks the better (and it seems to be free) since it is the one (or really close) used in Enemy Unknown 2012. [[User:Hobbes|Hobbes]] 20:43, 21 April 2013 (EDT)
::::::::Best I can make out it should be possible to use an uploaded font no worries, though I'd need to bug Pete to actually get it on to the server.

::::::::In the meantime, bold tildes are pretty much rendered blobs under PGothic ('''~'''). They looking ok to you? -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:04, 22 April 2013 (EDT)
:::::::::This is what I see using it as a font [[:File:PSGothic.png]] [[User:Hobbes|Hobbes]] 17:37, 22 April 2013 (EDT)
:::::::::I'm trying the new Style in a few pages and it is looking great. What I'm starting to wonder is what will happen to the other pages (non-EU2012). With UFO, TFTD and Apoc it should be possible to replicate it (although I have quite a few doubts about TFTD's colors...). But what about the other pages not directly related to a game? [[User:Hobbes|Hobbes]] 17:55, 22 April 2013 (EDT)

::::::::::We can currently only skin pages we manually add the template link to. That means that certain pages (like recent changes or page history) ''can't'' be skinned, not unless the skin files are changed on the server side... Which'd be a lot harder then skinning through these templates is (lots of files to modify with no simple way of previewing the changes, unless someone sets up their own wiki to play with on a home computer).

::::::::::In short, for now we may just have to leave 'em. While it might currently seem a bit jarring with just a black skin and a white skin, I think it won't seem so bad once there's a few others floating around the place.

::::::::::In particular I was thinking of leaving talk pages unskinned regardless of what game they belong to (if only because most articles don't HAVE a talk page). -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 19:05, 22 April 2013 (EDT)
:::::::::::Please tell me you're not sticking to the green background when showing a page's changes... ;) [[User:Hobbes|Hobbes]] 14:01, 23 April 2013 (EDT)
::::::::::::Can't think of anything better for it myself. :|

::::::::::::You do mean the green background that goes against added lines, yes? The bit of code to tweak goes along the lines of:

:::::::::::: td.diff-addedline {
:::::::::::: background: #559E06;
:::::::::::: }

::::::::::::-  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:11, 25 April 2013 (EDT)

Indent resetinator activated! I certainly hope this is a work in progress. It's very hard to read on my smartphone browser, and even on my laptop it's a real squint-fest. I'd probably recommend a slightly lighter dark background rather than having extreme darks or lights.

But that aside, we could ask Pete to implement a few snazzy skins that you can access from the appearance tab under your preferences screen. The skin will then apply to all the wiki pages with no specific skins assigned to them. Mind you, this change will only affect the individual accounts. [[User:NKF|NKF]] 02:36, 24 April 2013 (EDT)

:Yep, if I considered it done it'd have a rather more official looking name and I'd be slapping it onto pages left right and center. ;)

:I will say I can't see much room for improvement myself - I'm no graphic design artist. I'm more then happy to implement any mock-ups people show me if they're not interested in tweaking the colours themselves, though.

:-  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 09:11, 25 April 2013 (EDT)

2013-04-22T13:04:47Z

Bomb Bloke: /* Pretty Colours */

2013-01-31T13:06:59Z

Bomb Bloke:

For some reason, Triscenes may be present in UNITREF.DAT but not seen in the tactical game. It may be a game bug, and one of reasons for which they are so rare in some campaigns. See [[File:Nstm.zip]] savegames for testing, explanation inside the archive.

[[User:Sherlock|Sherlock]] 20:27, 30 January 2013 (EST)

:I would guess this is down to a shortage of spawn points.

:Not all route nodes work as spawn points. Of those that do, many have restrictions placed on them so that they only accept certain types of units (eg, if a node is too close to a wall, or in an enclosed area, it might not be able to support large four-tile units).

:The Triscenes are near the end of the unit list, so by the time the game gets around to spawning them, those places they could've gone have already been used up by their smaller alien brethren (nodes can't be flagged as "large units only"). With nowhere to go, they simply don't appear.

:You can actually make a killing out of node shortages during base defence. If yours lacks enough nodes to place the alien forces after your own, then some (or all) of the aliens DON'T get placed, and so you've got a much easier battle on your hands. But - and this is a big "but" - that doesn't stop you from recovering all their weapons when you win!

:-  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 02:10, 31 January 2013 (EST)

Yes, and no. As MapView shows, the Cargo00 terrain (used for the first part of a cargo terror mission) contains 24 spawn points in total (in RMP), of which 3 are "any" (all on the second level), and 1 is "flying" (4th level); the other 20 spawn points are "small" (13 on the 1st level, 3 on the 2nd, 1 on the 3rd, and 3 on the 4th level of the map). So, the rmp file is buggy as does not give enough spawn points. Both the total number of spawn points and especially the number of spawn points for large units is too small.

In the first example given in my archive (1\GAME_4) we have 2 Aquatoids, 6 Tasoths, 3 Bio-Drones, 5 (invisible) Triscenes, 1 Xarquid and 11 Civilian Males. They all would need 28 spawn points, including 6 for big units (1 Xarquid and 5 Triscenes). None of the units is flying, so there is only 23 free spawn points. Indeed, only 23 units are spawned. This explains why 5 Triscenes are not seen in the game, if we assume that they are placed last.

But in the 2nd example (2\GAME_5) we have 2 Aquatoids, 6 Tasoths, 3 Bio-Drones, 1 visible Triscene and 3 invisible ones, 1 Xarquid, 11 visible Civilian Males and 1 invisible one, so 28 units (xcomutil.exe shows only visible units why X-Com Hack v3.1 shows all units, also the invisible ones). So, 24 units have spawned even if only 23 spawn points are available. Note that in this save game 23 small units are spawned like in the previous one, and they are exactly the same types of units - but, in addition, 1 Triscene can somehow be spawned as well. Why?

Conclusions: (1) Sometimes the game can place at least one additional unit even if no span points are left (and sometimes it cannot), (2) RMP files of TFTD maps are buggy as having too small number of spawn points. I am just working on a patched versions.

[[User:Sherlock|Sherlock]] 07:21, 31 January 2013 (EST)

Oops, Bio-Drones can fly! This can explain the point (1).

:Well worth posting your findings & progress in [http://www.strategycore.co.uk/forums/topic/10264-new-patch-kit-for-tftd/ this thread], assuming you haven't spotted it already. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 08:06, 31 January 2013 (EST)

Talk:TFTDextender

2013-01-31T07:14:19Z

Bomb Bloke: /* TFTDextender and XComUtil */

=Questions or Comments=
'''A place to provide feedback or ask questions:'''
:''Thanks to Kyrub, Spike, and numerous others who help to troubleshoot problems, provide feedback on releases, and innumerable other activities to help make TFTDextender and the game better! -'' [[User:Morgan525|Tycho]]

*The zip archive does not seem to include an .ini file. Where do I get the .ini file from?

:::''If the latest release is a patch, meaning there are no new additions to the INI file, only the patcher.dll file will be updated. In this way, those who already have the current release won't have their INI settings overwritten. You will need to download the last full version, extract the files from it, and then extract file from the latest patch. When I first release the Extender and lots of problems were being reported, I was releasing fixes almost on a weekly basis and so I still continue with this idea.'' [[User:Morgan525|Tycho]]

== Bug Reports ==
===Major Bugs===
==== USOs not detected or Alien Missions not appearing ====

With the Geoscape Clock mod enabled. Few alien subs are being detected. It may be that alien subs on missions are not appearing at all.

=== Minor Bugs ===

== Things that TFTDextender does not fix ==

Just more or less as a note to the reader, TFTDextender does not fix some of the following things that are sometimes thought of as needing fixing (and this is probably deliberate?):

* Does not fix the apparent swap of the ground map for the VERY SMALL Survey Ship (1 occupant) with the SMALL Escort (half-dozen or more occupants). So you get the VERY SMALL sub occupying about 25 squares of usable area on the Battlescape, and the supposedly larger SMALL sub occupying one square of usable area on the Battlescape, begging the question of how all those aliens got inside there in the first place. XcomUtil will fix this, as will the original patches that XcomUtil incorporates.
* Does not fix the incorrect pictures for the large USO in the interception window.
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]
* Does not fix the Dart Gun to make it any less utterly useless. Though you can do this yourself via the OBDATA.DAT section of TFTDextender. (Suggestion: don't fix it. The useless Dart Gun is all part of the "oh no we're all gonna die" experience of the beginning of TFTD.)
* Does not improve the armour and effectiveness of the basic Aqua-Jet and Gas Cannon Coelecanths (it does upgrade the Coelecanth/Gauss). (Again, suggestion: this is a good thing - XCOM should start the game hopelessly outclassed, and scramble to catch up).
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.
* Does not allow you to have 360 degree vision out of your sub before exiting it. (What kind of coward would want that?). XComUtil does this.

==FYI==
*When I try to send any Leviathan to T'Leth, I get an immediate crash: "XCOM crashed at 0x458822 with error 0xC0000005 trying to access 0xFA6C8304.".
:It happens when the CE version doesn't find the RISE animation: Specifically, it needs ANIMS\RISE.IDX and ANIMS\RISE.VID - If RISE.IDX is missing, it crashes with the error code above, if RISE.VID is missing, it crashes with another error. Some experimenting suggests that RISE.VID can be any valid .VID file, while RISE.IDX can either be empty (producing a black screen that can be skipped by clicking) or the "appropriate" .IDX for the used .VID...[[User:AMX|AMX]] 13 November 2012 (EST)
*The game crashes when I start mission against a sub: "XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."
:It's [[Known_Bugs_(TFTD)#Geoscape_Bugs|an already reported bug]]. What is happening is the Alien Sub is landing on land, and the Triton is also attempting to land on land. Probably the game crashes when it fails to generate the appropriate terrain type? So the GEOSCAPE map/terrain data must be corrupted. I've seen three examples of this. In a couple of cases the landing site is clearly inland, by hundreds of kilometres. In some cases it's right on the sea/land boundary and hard to tell. I have two save games that reproduce the bug now. From memory, the previous cases all happened around North Africa, like these present cases. [[User:Spike|Spike]] 08:31, 9 September 2012 (EDT)
*'''Trojan Horse?''' AVG Anti-Virus reports that TFTDExtender.exe contains a Trojan Horse (Generic30.MKG).
:''AVG has been known to produce false positives before. I use AV software on my machine and have checked this by uploading/downloading from a site with its own AV check. In some sense Extender acts like a trojan, in that, it overwrites code in memory, just not in a malicious way. -[[User:Morgan525|Tycho]]''

=Resolved Reported Problems=
*<s> Save Equipment not working</s>
:With "Save Equipment" option enabled, the soldiers' loadout at first was always like this: grenade in leg slot, clip in backpack - and it didn't change on the next mission, despite the fact that I re-equipped the soldiers correctly (grenades and clips on the belt). When I manufactured Gauss Rifles and issued them to my soldiers, it got even worse - none of the soldiers got clips, and two of the rifles were unloaded. Next I upgraded to Sonic-Blasta Rifles and now nothing, except some grenades (still in leg slots), is issued to the soldiers at all. "Save Equipment" was known to work in UFOExtender, did something get broken? --[[User:Player701|Player701]] 09:18, 21 October 2012 (EDT)
:''Yes. Something is broken but not by the Extender. I haven't modified anything in the save equipment code, except datapoints and offsets that were necessary to match it to the executable and changes in the DAT files. Many subroutines, their order of execution, or the variables were modified in the TFTD game code. Problems resulting from this are difficult to resolve since it requires finding what changed in the game code and then determining what changes are needed to get the UFOextender code to work. I believe that TFTD has its own form of autoequip and part of the solution will probably require that I disable it. Something similar happened to the "stunned units are KIA" mod from UFOextender: TFTD has its own version that conflicted but, since it worked well, I only needed to add code to update the unit's location so the corpse would appear in the right place.-[[User:Morgan525|Tycho]] 22:38, 24 October 2012 (EDT)''
:: I just did a few tests in raw TFTD (Steam CE) and the auto equip function is pretty basic: Give everyone a loaded weapon in what is probably reverse OBDATA.DAT order, then dish out any extra clips, grenades etc. Are you thinking that the Save Equipment efforts of TFTDextender are then being overwritten or partly overwritten by the existing TFTD auto equip function? I guess that would make sense. [[User:Spike|Spike]] 11:01, 25 October 2012 (EDT)
:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

*<s> Weight Issues or "Weightless" Ammo Bug </s>
:while playing TFD with TFD extender (v. 1.05 patch 1.1) I've noticed a stange thing: some soldiers have their weight > 0 (2-5) even when their inventory is empty! Bug?... [[User:PavelB|PavelB]] 05:17, 27 September 2012 (EDT)
:If you drop a loaded weapon, even if you loaded it manually, the weight of the ammo still stays with the Aquanaut. Workaround: unload each weapon manually before dropping it. If you forget (and if you notice) it's possible to pick the weapon up again, unload it, and correctly lose the weight by dropping the weapon and clip separately. It's possible to build up huge amounts of phantom weight on a Soldier by repeatedly loading, and then dropping, different weapons. It's also possible to move lots of weapons with weightless clips to one Soldier, increasing the amount of 'free' weight that one Soldier gets. Both of these effects are probably aspects of the original bug, not anything that UFOExtender has done. [[User:Spike|Spike]] 11:15, 27 September 2012 (EDT)
::This Weight error is a side effect of an original game error that Seb never quite fixed. Removing clips from a Soldier or Aquanaut does not remove the clips' weight. This is because the clips are not correctly assigned to the Soldier or Aquanaut in the first place. See [[Talk:TFTDextender#Weightless Ammo Bug]].
:Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)
:''I found the source of the problems: None of the subroutines for inventory consider the clips in weapons so their entries in OBPOS.DAT are never updated. So when clips are autoloaded at the beginning of each battle, they have no owner. I've got the code to sync the ownership of clips with the weapon they are loaded into at the beginning of each battle and to update the clips when weapons are changed in inventory management.-''[[User:Morgan525|Tycho]] 19:00, 19 October 2012 (EDT)
:'''All fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

*<s> Items on transport floor lost on Abort</s>
:I went in to a mission with ten Sonic Cannons and came back with 3, despite retrieving them from the battlefield and dumping them on the transport floor. I only had 3 aquanauts on the transport armed with Sonic Cannon at the time of abort. The rest were stunned or unarmed. I also dumped half a dozen corpses and some alien items on the transport floor and I don't think those made it back to my base either. The transport was operating from base 2 rather than base 1, in case that's a factor. This may be an original bug of course. I just read through the multiplayer TFTD LP on StrategyCore, and they reported missing equipment on a lot of missions. I can go back and check if the missing equipment was on abort missions rather than victory missions. Sorry not to provide more specifics at this time but it was a hard mission and not exactly a controlled experiment. ;) [[User:Spike|Spike]] 21:35, 23 October 2012 (EDT)
:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

*<s> Coelacanth/Gauss mutates into Coelacanth/G.C.</s>
:In my current game (using the Steam version) I observed it twice that, when a Coelacanth/Gauss is removed from a sub due to lack of ammo, it turns into a Coelacanth/Gas Cannon.
:Note that I'm using only the Gauss Tank Ammo Fix, but not the Gauss Tank Turret Stats Fix, nor the Improved Gauss Tank mod [[User:AMX|AMX]] 09:09, 1 November 2012 (EDT)
:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

*<s> Cannot build Leviathan </s>
:Hi Tycho. I've just researched Leviathan in my TFDExtender game but cannot manufacture it! I have enough resources (Plastics, IBA, ManNav), 3 workshops, more than 100 technicans and one empty sub pen. But when starting the Leviathan manufacture task I cannot assign any technicans to it. I press the "up" button, and there are no reaction to this. I can build Manta, but not Leviathan. Don't you know what is it? [[User:PavelB|PavelB]] 06:55, 2 October 2012 (EDT)
:''I was able to replicate Pavel's problem and found the problem: the Leviathan is the only item that its tech hours exceed 0x8000. If you use the wrong command to pass the value between registers, the program handles the value as though it were negative. - [[User:Morgan525|Tycho]]''
:'''The problem is fixed with patch 3.2.''' ''Confirmed by an independent source.''

*<s> Executable directive </s>
:''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)

*<s>Extra Artefacts Reported</s>
:''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)
:'''Fixed in the patch 3.1-'''[[User:Morgan525|Tycho]]
: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)

*<s>Manufacturing Projects Minimum Production</s>
:In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)
:Tested - If I reduce the production quantity of a current production run to less than what as already been produced, the display completion time changes (incorrectly) to 'Indefinite', but production ends after completion of the next unit. So if I start by producing 10 units, wait until I have produced 2, then reduce the quantity to 2 (or probably 1), production stops after 3 units. Thies basically replicates the pre-existing behaviour when using the down arrow on the Quantity, so there has been no loss of functionality with your Mod. Also, Autosell and Autoproduce work normally when applied as changes to an existing production run. The only thing is I can't distinguish them on the Manufacturing display - both say 'unlimited' quantity and 'indefinite' period - is that intended? I suppose it makes sense, but it would be good to be able to tell which kind of production it is, *** Autoproduce or $$$ Autosell. [[User:Spike|Spike]] 08:57, 2 October 2012 (EDT)
:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)
:''' Changed the output to display "$unlimited$".'''[[User:Morgan525|Tycho]]

*<s>Stunned MC'd Aquanauts MIA on Abort </s>
:This is a subset of MC'd Aquanauts go MIA [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]. In this case Aquanauts are MC'd by the aliens, then stunned (by friendlies), then the mission is Aborted with the stunned X-Com Aquanauts aboard the transport. The Aquanauts then disappear from the roster forever. I'm not sure if it's due to Abort rather than Victory, or due to them being stunned first. This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)
:'''I now have the code in place to uncontrol any creature that has been rendered unconscious. Available in patch 3.1- -'''[[User:Morgan525|Tycho]]

**<s> Crewed Flying Sub Lost on Abort </s>
:Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)
:''I found the nature of the issue here: This only will happen with a tank present. On one hand, all parts of the tank are being counted separately but then the End of Battle routine calculates the number of units correctly (ignores three of the sections of a tank) but when it goes to locate the units on the battlefield, the three other parts of the tank are being counted and thus the last three aquanauts are not checked since the 4 areas of the tank are first in the UNITPOS.DAT file.-[[User:Morgan525|Tycho]] 09:47, 24 October 2012 (EDT)''
:'''Fixed in 105 patch 4.'''-[[User:Morgan525|Tycho]]

*<s>Grenade Resistance in INI file </s>
:''I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]

*<s> Materials deducted from wrong base </s>
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)

*<s> OBDATA / Dye Grenade mod not working? </s>
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)

*<s>Displacer/Sonic damage fix</s>
:'' I changed the damage to be 125, similar to the ratio of tank/plasma to heavy plasma in EU.-''[[User:Morgan525|Tycho]] 03:52, 13 October 2012 (EDT)

*<s> Weight Display in Inventory not Localised </s>
:At least when I run the game in German, it comes up as "Weight" and not something like "Gewicht". Reactions comes up ok as "Zeitwerte". [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)
:''Added ability for users to added their own language by copying lines from Extender's page under the equipment section to the same section in their INI, alter the text as specified, and save the INI.' [[User:Morgan525|Tycho]]

==Feature Requests and Suggestions ==

Please check the [[Known_Bugs_(TFTD)|TFTD Known Bugs]] or [[Known_Bugs|EU Known Bugs]](for bugs common to both games) and post bugs which are part of the original game in the appropriate section. Please post any general suggestions for the game here: [[Wish_List_(TFTD)]].
*Any errors that are a result of the Extender should be posted here.
*Use this section for suggestions and feedback on options currently available in the Extender or to discuss projects in Extender that are under development.

== Useful alien species research ==

Tycho, I really like this idea you proposed in the StrategyCore forum:

''I'm thinking about giving a hp bonus to all aliens until Xcom performs an autopsy on the species to learn the location of their vital organs (like in the movie "Battle of LA"). This would give more importance to performing autopsies rather than just as a stepping stone to new tech.''

Definite +1. It would be equally valid to add to UFO Extender. I suppose it could also be implemented using Vulnerabilities (no Vulnerabilities are in effect until the Autopsy is completed), or Resistances (across-the-board increased Resistances until Autopsy is completed). If that's easier.
:''The bonus to hp was an initial thought. Later, I decided against it since it would make aliens more resistant to HE and stun, which don't rely on hitting the right locations. Increasing resistances would be the most appropriate but the damage routine code is very tight and adding anything new that won't break the existing variable stack pointers is tough. Tycho ''
::''A new idea for this that I recently have been toying with, would be on the damage generation routine: Most direct fire damage is <s>0-200</s> 50-150%, with anything over 100% considered a "critical hit". If autopsy hasn't been preformed, then the base damage would be 0-100% and a small chance (maybe 25%) of another 0-50% for that lucky shot. With autopsy done, the game reverts back to the usual <s>0-200</s>% on any hit.''
That works. And it makes doing Alien Autopsies a no-brainer, as it should be. It is pretty much inconceivable that XCom wouldn't prioritise the autopsy of any newly encountered alien. And any player playing the game for the first time would do autopsies too. This mod will help experienced players to stop playing as if they've "seen it all before". Spike 10:35, 15 September 2012 (EDT)

Would it also be worth adding some kind of bonus for Live Alien research? Maybe the negation of some kind of Morale penalty and/or Psi penalty? Fear of the unknown, know your enemy, that kind of thing?

:''I thought about that but the game doesn't record live aliens that have been researched. When you finish research on a live alien, it only follows the routine to unlock the appropriate UFOpaedia articles and then checks to see if the finished research can unlock other topics.'' [[User:Morgan525|Tycho]]

I had a further thought on this while trying to guess what your new pre-requisites are for the various armours. For now it's really cool to be guessing but once people have figured it out, well, it will be more logical but still will have 'replay fatigue'. Would it be possible to randomise the pre-requisites for a lot of the key research topics, from out of a plausible list of items (or even randomise pre-requisite topics)? That would make every game fresh in terms of the research sequence, and make the research aspect of the game more challenging and less dry & predictable. As ever, just a suggestion. :) Cheers, [[User:Spike|Spike]] 16:01, 19 October 2012 (EDT)

:''I am going to do some major changes to how this is implemented and it will go hand-in-hand with changes to the interaction with armor. Currently I am doing this for EU since I've got a lot of help recently with music and video from members of the community.
:''1)For AP the armor works as it does currently: The armor value is applied as is and damage that is lower than the value is ignored but a hit that penetrates does very little damage to the armor itself.
:''2)Laser(Gauss) and Plasma(Sonic) attacks will eat away at the armor: The current armor value in the location hit is doubled and then damage is subtracted from this value. The remaining armor value (if any) is halved and saved for the next hit. For these attack types, armor is stronger but quickly is gone. A soldier in power(ion) armor can take at least one seriously good hit from a heavy plasma(sonic) from the front without damage to the soldier. In testing, I've had a lot of occasions were a soldier in coveralls was able to take a hit from a plasma pistol, although be seriously wounded in the process. ''
:''3)HE works just like laser and plasma. ''
:''4)Stun damage depends on the weapons used: the stun rod works like an AP attack vs armor (just like it does now: normal), but a stun bomb is applied against the modified armor value.
:''5)IN still works the same. Fire damage is unchanged.''

''Know thy Enemy: It affects the damage that is applied against the unit's health:
*''Headshot: full damage
*''Other: If autopsy on this unit type has been done: full damage. Otherwise half damage.

==General Tank Modding ==

I see you are interested in modding tanks (HWPs/SWPs) and that's partly what got you into updating UFO Extender. I made some suggestions for Tank Modding myself, including some of the mechanics required to make it work via a config file such as the UFO / TFD Extender config file. For example you could have cargo carrier / ambulance / casevac tanks, you could have demolition tanks, mine thrower tanks, and of course tanks with custom weapons including dual weapons. Could you have a look here: [[User:Spike#Tank_mods]] and see if any of that makes you feel like getting creative?

Thanks,
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)

==TFTDextender and XComUtil ==

I suggest adding a section on co-operating with XComUtil.
And why it should be so complicated? Is it possible to make needed changes in XComUtil? But it has support for UFOextender - why not for TFTDextender?

:''All good questions. I suggest you contact BladeFirelight, who is developing XComUtil (still?). - [[User:Morgan525|Tycho]]''

: A couple of notes;

: Getting TFTDextender to work with XcomUtil does indeed have to be handled by XcomUtil. The steps described above are not sufficient, as XcomUtil needs to know the filename for TFTDextender.

: I put together a patch for XcomUtil that adds the support, but this was close-ish to the time when TFTDextender was still named TFTDLoader. Which means you still have to rename the extender executable, but it's buried away [http://www.strategycore.co.uk/forums/topic/9751-ufo-tftd-combo-mod-beta/ here] if anyone wants to take a look. I may update it shortly and send it off to Blade again.

: For whatever reason, kryub's fix for the splitter code STILL doesn't prevent an error on exiting the geoscape to the battlescape, but ''only'' if using TFTDextender, and not if you're quitting the game completely. I've been right through the ini and disabled everything I could find (cross checking against the ini ref file - by the way, that doesn't mention the "Enhanced Tactical AI" flags), but couldn't find a way to prevent this. Oddly enough it only seems to happen on my XP machine, not my Windows 7 laptop. The error is:

:'''TFTD crashed at 0x7C9102F6 with error 0xC0000005 trying to access 0x00000002'''

:-  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 20:04, 24 January 2013 (EST)

::''After using your patch, I managed to get XComUtil to run with TFTD Extender. I'm using Windows XP Home. I get the above error when the program swaps from Geoscape to Battlescape and I get another error upon 'Quit to DOS' [TFTD crashed at 0x1 with error 0xC0000005 trying to access 0x00000001] with any version of TFTD Extender or even Xusalik's TFTDloader. --[[User:Morgan525|Tycho]] 20:26, 26 January 2013 (EST). The only thing I can think to do from this end would be add an option that would disable the debug portion of the Loader. - [[User:Morgan525|Tycho]] 08:57, 29 January 2013 (EST)''

:::I was thinking of suggesting that myself, but there are pros and cons... You'd want to leave the message prompts enabled, by default.

:::Note that disabling the code entirely is even worse, because then the default Windows debugger takes over and that takes ages to load if it's not already in RAM (and of course that still gives you an error pop-up window)... You'd want it to still catch crashes, but then just exit cleanly if it detects one. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 16:58, 29 January 2013 (EST)

::::''One could always disable the Windows Debugger, since it's of no use to anyone because XP is a "dead" OS: System Properties>Advanced Settings>Error Reporting>Select 'Disable Error Reporting' and uncheck the option to report only if there is a serious error. - I do this with every version of Windows I'm using, since I never had patience for the delay as the debugger loads. - [[User:Morgan525|Tycho]] 22:16, 29 January 2013 (EST)''

:::::Good point - I also used to do that in the past, but it seems I somehow forgot about that with my current unit.

:::::So assuming you go with this, it'd be worth mentioning that OS setting in the Extender FAQ, not because it's anything to do with the Extender as such, but because people will look for it there. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 04:15, 30 January 2013 (EST)
::::''I need to ensure that it would only be disabled in the case of Windows XP and a split executable. All other combinations seem to work correctly. BTW, thanks for the heads up about the missing entries in the INI ref file. An oversight because I'm juggling between two similar programs and I'm getting easily confused.-[[User:Morgan525|Tycho]] 00:41, 31 January 2013 (EST)''

:::::Reckon it'd be better off to make it a user-setting rather then trying to detect the environment and whatnot. Having it automatically disabled might make it tricky to diagnose other crashes later down the track. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 02:14, 31 January 2013 (EST)

Talk:Triscene

2013-01-31T07:10:40Z

Bomb Bloke:

Talk:MISSIONS.DAT

2013-01-31T07:02:44Z

Bomb Bloke: /* Non-scheduled Terror Missions */

Some questions [Zaimoni: now answered empirically]:
* What is going on with the start time for 0/0 on Research missions? The Jan 1999 one is always 2.5h, but I recently saw an Antarctica Research mission at 3d for 0/0.
* How consistently does the time to the next UFO react to a successful Battlescape game? (I just saw a Retaliation 1/1 go from 7Eh to 136h upon successful completion.)

--[[User:Zaimoni|Zaimoni]], 6:50 Sept 21 2006 CDT

I couldn't understand much of your research but it made me wonder about one question: is it possible to determine the amount of UFO missions and their types that you will see during a month (and also the areas?). Or are those set in a total random fashion?

If so this could be considered as spoilers but it could also be used for an article describing alien strategy on the field manual.

--[[User:Hobbes|Hobbes]] 18:39, 21 September 2006 (PDT)

MISSIONS.DAT is a spoiler, definitely. It stores the time (in 30-minute increments) for all non-Supply scheduled UFOs that have not arrived yet. While it won't tell you all of the UFOs arriving in the month, it will positively ID arrival time, mission, physical type, and race of each one in the queue. I'm in the middle of redocumenting it.

My current conjecture is that the 0..3 sequence indexes the "size" of the UFO. The legacy content just listing ufo-c coordinates is misleading (it seems to be enumerating the visible sequence of ufos), but I want to positively observe the entire sequence of ufo-c/ufo-sub-c pairs before updating.

At all times, the current mission types and areas are in MISSIONS.DAT...except for supply missions. You really want a Hyperwave Decoder covering each alien base you're harvesting. So far, Beginner and Superhuman schedule the same at the beginning of the months after Jan 1999: 1 Terror mission, one non-terror mission. I don't know the criteria for scheduling Retaliation missions. (I've never seen them show up except immediately after Battlescape missions, but that obviously isn't exhaustive.]

Particularly interesting: Battlescape messes with the arrival time of the next mission after the one you're cleaning up on. This needs more careful analysis (e.g., is it just mission completion?)

--[[User:Zaimoni|Zaimoni]], 22:35 Sept 21 2006 CDT

The increase in time to next UFO occurs either (or both) at shootdown, or at the start of the Battlescape mission. Since I used XCOMUtil interceptor with six soldiers for this test, I can't tell which one. No change between the beginning and the end of the Battlescape mission. [But a genuine Terrorship will happen soon enough...that gets a no-crew Interceptor and a full Skyranger.]

--[[User:Zaimoni|Zaimoni]], 23:51 Sept 21 2006 CDT
:After a shootdown, the next UFO for that mission is delayed between 1 and ~9 days ( the formula is 48+RAND()*400 half hours ). A retaliation mission will be scheduled if RAND()*100 < 4*(24-difficultyLevel).
:If RAND()*100 < (50-6*difficultyLevel), the retaliation mission will use the same zone as the shot UFO, else it'll be the zone containing the base the craft in coming from. The first UFO is scheduled in 100 half-hours (the value is taken from the table I speak of later at the bottom of this page).
:[[User:Seb76|Seb76]] 18:56, 12 July 2008 (PDT)
<hr>

I don't think I'll be continuing this savegame, but I just had a Feb 1999 that only generated a new Terror Mission. The other mission...not visible. [I may have messed it up — I did edit the Jan 1999 Terror mission from Europe to Southern Africa.]

--[[User:Zaimoni|Zaimoni]], 10:38 Dec 30 2006 CDT

== Retaliation ==

Zaimoni, I've been thinking about the comment about HWD's activating retaliation missions from the start. Are you able to check the mission types of the first couple of UFOs through mission.dat without editing the HWD stats onto the base? I'm not entirely convinced that retaliation missions are instigated by having a hyperwave decoder (stats or the module).

- [[User:NKF|NKF]]

: Yes, I can check (and have checked) that by hex editor. [It's a moderately different game with total information on arrival times and mission types...much easier to resume after a month or so hiatus.] I haven't tested with a game whose Hyperwave detection was edited.

: I normally save immediately after starting a new game to apply my custom soldier editor to the game. While I'm at it, I check MISSIONS.DAT. I have always gotten two missions: a Research mission in the same region as my starting base, and a terror mission with a decidedly non-uniform random distribution of location that I haven't bothered to try to analyze.

: I'm not sure whether there's a random component to getting a Retalation series scheduled by shooting down the first Research UFO, or whether it's just hypersensitive to some sort of detail. If the series is not significantly interfered with, the base defense mission would happen 2-3 weeks in.

: --[[User:Zaimoni|Zaimoni]], 3:23 Mar 20 2007 CDT

Just ran some quick checks, nothing too intensive.
* Editing hyperwave detection in a hex editor: no obvious effect, but would have to tweak the initial MISSIONS.DAT (move the Terror Act to within range) to be absolutely sure. The game does not transmogrify Research UFOs in real-time; I need to test Terror UFOs.
* Start a new game after abandoning one: race information is not cleared in MISSIONS.DAT, but other information is cleared. In particular, both ufo-c and subufo-c are overwritten to their defaults.

--[[User:Zaimoni|Zaimoni]], 23:11 Apr 11 2007 CDT

'''so''', the question which should be asked:

Is it too difficult to make an editor which changes the sequences? I dunno anything with hex-editors, programming, high level mathematics, etc. It would be interesting to have an opportunity to spawn multiple UFO everyday and not be able to shoot them all down as which is the case for the current mode of EU (and TFTD). The only thing that comes close to something of this current scenario is an inflitration mission where you have 5+ alien ships all at once and not having the capability to deal with them all. I dunno... i just wish having more tweaks to make it harder would be a good thing as opposite to just using editors to dull the technology of xcom to increase difficulty.

Six terror sites at once??? hell yeah! [[User:EsTeR|EsTeR]]

: It should be safe to create Retaliation acts and Terror acts by directly editing MISSIONS.DAT, there will be no internal consistency issues with other files. Editing existing entries in MISSIONS.DAT to other valid entries should be safe (note that not all mission types have been authoritatively mapped). Editing duration should be safe, but problems could happen with invalid races or UFO c/sub-c pairs. Creating other mission types will require counter-editing ACTS.DAT. I haven't specifically checked the behavior of ZONAL.DAT when spawning new acts.

: The ufo-c/ufo-sub-c pair 0/0 is always valid, at least.

: Research, Base, Terror, and Retaliation have fully documented ufo-c/ufo-sub-c pairs. I haven't done any verification at all for Abduction or Infiltration.

: Changing the relative durations between UFOs, time delays incurred when shooting down UFOs, or number of missions spawned per month, requires finding that information first. --[[User:Zaimoni|Zaimoni]], 10:16 Oct 17 2007 CDT

Just a note to add to this section lest I forget, and as late follow up to the notes that re on the page: back when I first got the idea that the first UFO was on a retaliation mission, I did not know that there was a 2% chance for every UFO to generate a retaliation mission. Armed with this knowledge, this is probably the sequence of events that happened to me at the time: I shot down the first UFO, recovered it and then got my base attacked. The 2% might've triggered then. This would very well the impression I had that UFOs could start on retaliation missions. They don't, but they can generate an attack. -[[User:NKF|NKF]] 03:10, 3 June 2010 (EDT)

== Alien missions data discovered in geoscape.exe [finally ;-)] ==

OK guys, here's a big one: alien missions data is located in the executable at offset 0x70E70 (gold edition) ; it starts with these values (all 16bit words):

.data:00470E70 structAlienMission <5, 1, 0, 12Ch>
.data:00470E70 structAlienMission <6, 1, 2, 104h>
.data:00470E70 structAlienMission <7, 2, 4, 12Ch>
.data:00470E70 structAlienMission 5 dup(<0FFFFh, 0FFFFh, 0FFFFh, 0FFFFh>)
...
It goes on for 64x4x2 bytes (7 mission types and possible data for additional 'supply' type mission).

Every mission type has 8 entries consisting of 4 words.
First word is the ship type, second is the number of ship of this type to spawn successively (each uses the same time counter), and 4th correspond to the time counter in [[MISSIONS.DAT]]. 3rd one is unknown for now.

The example below is for research mission: one small scout (type 5), then one medium scout (type 6) and finally 2 large scouts (type 7).
The time counter is calculated like this: time*RAND()+time/2.
Anyone care to hack the binaries to confirm this? [[User:Seb76|Seb76]] 10:58, 9 March 2008 (PDT)

: Time calculation looks good for those UFOs with randomized time (there are a few known exceptions). -- [[User:Zaimoni|Zaimoni]] 10:16 10 March 2008 (CDT)

: It would be very good to locate what controls fixed vs randomized times for the normal missions. -- [[User:Zaimoni|Zaimoni]] 10:59 13 July 2008 (CDT)

The 3rd word of missions is UFO_trajectory_type. It refers into table at address .data:00471070. So there are 10 types of trajectories possible, with maximum 8 waypoints.
.data:00471070 ufo_10_types_52___ dw 5 ; UFO_Waypoint_count
.data:00471070 dw 5, 0, 0, 1, 5, -1, -1, -1; UFO_Waypoint_Site
.data:00471070 dw 4, 3, 1, 1, 2, 0, 0, 0; UFO_Waypoint_Altitude
.data:00471070 dw 100, 74, 28, 47,100, 0, 0, 0; UFO_Waypoint_Speed
.data:00471070 dw 3000 ; Ground_Timer
--[[User:Volutar|Volutar]] 05:59, 14 April 2011 (EDT)

==Clarification pls==

- So all these missions, once started, will continue in the precise sequence no matter what?

:: Yes; only most of these tables have been verified by inspection of the savegame files in a hex editor, however. Infiltration has not. Matching the savegame file behavior against the in-game data Seb76 has located is tricky. -- [[User:Zaimoni|Zaimoni]]

- What about the whole thing with whether it's found the site or not (e.g. Terror Ships finding/not finding a city to raid, Battleships finding/not finding your base)? Does this apply to all missions?

:: The base assault battleships are not on the Retaliation Act sequence, they're controlled by [[XBASES.DAT]]. Reverse-engineering how the Retaliation Act ships find bases hasn't been precisely done yet (don't let the UFOs get too close to the base), mind shielding reduces the range at which a UFO can spot a base.

::: So the two battleships that don't ever spot your base are unrelated to the battleships that come if you're spotted? [[User:magic9mushroom]]

:::: Correct. I've had entire Retaliation Acts cycle without scheduling a base attack battleship, but this was with [[XBASES.DAT]] never flagging a base for retaliation.

:: As for Terror Ships: whether a UFO lands or not, appears to be controlled by its ufo-c/ufo-sub-c indexing. If they have orders to land, they won't have problems finding an appropriate site. -- [[User:Zaimoni|Zaimoni]]

::: So that means that of the two Terror Ship indexes you have listed, only one occurs in any given mission? [[User:magic9mushroom]]

:::: For all act types, the indexes are incremented in strictly increasing order (with all ufo-sub-c indexes run through before the ufo-c index is incremented). It may take more than one hour for a ufo to reach hyperwave detection with incomplete hyperwave coverage. -- [[User:Zaimoni|Zaimoni]]

:::::So are there two Terror Ships per mission or not?

:::::: The separation between Terror Ship 2/0 and Terror Ship 3/0 is a few days, so it's conceptually two missions with one Terror Ship each with the Terror Act. Empirical research into ufo behavior suggests that if they are not shot down, Terror Ship 2/0 never lands, while Terror Ship 3/0 always lands (and gives you a terror site). -- [[User:Zaimoni|Zaimoni]]

- With the infiltration, what does the "it starts again" mean? Does that mean that once an infiltration mission has started in a zone, endless infiltrations will run there until all countries there are infiltrated?

:: Infiltration is the only mission type that loops. It will continue even after all countries in the zone have been infiltrated. Russia is empirically immune to infiltration in all versions higher than DOS 1.0. -- [[User:Zaimoni|Zaimoni]]

::: So what happens at the conclusion of an Infiltration mission after all countries in the zone are infiltrated? Does a country outside the zone get infiltrated? Does no country get infiltrated? [[User:magic9mushroom]]

::::Nothing happens. Was rather fortunate to experience this a few times - and when I ran a no-funding-country scenario where I edited the save and flagged all the countries as withdrawn. Rather amusing to see them infiltrate an already infiltrated country and yield no results. In this case, the only real impact is the area activity points, which the neighbours will notice. -[[User:NKF|NKF]] 05:30, 10 August 2009 (EDT)

- It says the order for infiltrations is Terror ship -> Battleship -> Supply ship -> Battleship, but my own experience contradicts this - I shot down each UFO in an infiltration run, and the sequence was Terror ship -> Supply ship -> Battleship -> Battleship.

:: While Infiltration has not been verified by me in-game yet, the tables all assume that all UFOs in the sequence are detected. This is more interesting if this was with the Hyperwave Decoder. -- [[User:Zaimoni|Zaimoni]], 8:42, 9 August 2009 (CDT)

::: It was with a Hyper-Wave Decoder and I shot down each before the next appeared. [[User:Magic9mushroom|Magic9mushroom]] 04:07, 10 August 2009 (EDT)

:::: All eight are in the executable, in the order specified in MISSIONS.DAT. However, the four mentioned are pretty much "in a row": the sixth should arrive exactly one hour later after the fifth, and so on. That is, you have one hour to shoot down the Terror Ship to delay the three others by ~2 weeks. -- [[User:Zaimoni|Zaimoni]], 9:37, 10 August 2009 (CDT)

::::: Well, it was days between detecting each one. They definitely arrived in the order Terror Ship, Supply Ship, Battleship, Battleship.

:::::: See it in the executable, fixing that now. (Mapping duration from executable to empirical is tricky, as is estimating turning points and landing counts.) -- [[User:Zaimoni|Zaimoni]], 9:37, 10 August 2009 (CDT)

Thanks in advance. [[User:Magic9mushroom|Magic9mushroom]] 04:14, 9 August 2009 (EDT)

I understood what mean third entry in section Alien Data Missions at executable file.
As I said in forum Seeing speeds of USO sub we can determine the mission of this USO sub even without transmission resolver - even in january 2040
Every USO sub in every missions (interdiction, colony, probe and other) have unique speeds and we can determine mission of USO on their speed
And we can determine what amount of times a sub touch down on his mission - because every mission has unique rule for touch down USO subs
And we can determine what amount of time USO Sub will touch down on their mission - because every Sub in every mission has unique and ALWAYS equal amoun of time to touch down (p.s. this time we can see in file Loc.dat)

And third entry - it's index of speeds of sub.

I have table of speeds of all USO subs. Where can locate it?

== Non-scheduled Terror Missions ==

What is it known on terror missions which are NOT in MISSIONS.DAT? At least in TFTD, such missions are, as a rule, on the 1st of each month, 1:00 (are they always ship route attacks?). Saving the game before the attack but after the midnight (1st, 0:00), and next loading and continuing it, always leads to a mission in the same (exact) location, on the same type of the ship, and with the same alien race (or Mixed Crew). Only numbers of particular creatures of a given race can change. So, the mission properties must be stored somewhere between the midnight and 1:00 (when the attack occurs). The game must store this information somewhere, and it is not MISSION.DAT for sure.

Such a first-o'clock alien terror mission does not influence the normal, scheduled alien missions (so, it is even possible to have another terror mission just few hours after the first one, if only the other mission had been scheduled). Where is it stored?

Does a similar phenomenon occur in UFO:EU as well?

[[File:Nstm.zip]] - a set of savegames for tests, the explanation inside.

[[User:Sherlock|Sherlock]] 20:24, 30 January 2013 (EST)

:It's in [[LOC.DAT]]. As in, the terror site already existed before it became visible to you, so you actually saved AFTER the attack started. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 02:02, 31 January 2013 (EST)

CRAFT.DAT

2013-01-31T00:49:54Z

Bomb Bloke:

This file contains information specific to the crafts in the game. Both X-COM and Alien crafts (including hidden ones) are in this file, though the values for the alien craft are still shrouded in mystery.

Note that [[CRAFT.DAT (TFTD)|TFTD uses a different version of this file]].

==UFO Structure==
There are 50 records each having 104 bytes long for a maximum file size of 5,200 bytes. All offsets and values are in decimal.

{| class="wikitable"
|-
!Offset (Decimal)
!Offset (Hex)
!Usage
|- valign="top"
!0
!0x00
|Craft type, Possible values are the same as [[GEODATA.DAT]]:
*HUMAN* *ALIEN*
0 - [[Skyranger]] 5 - [[Small Scout]] 255 - Entry Not Used
1 - [[Lightning]] 6 - [[Medium Scout]]
2 - [[Avenger]] 7 - [[Large Scout]]
3 - [[Interceptor]] 8 - [[Harvester]]
4 - [[Firestorm]] 9 - [[Abductor]]
10 - [[Terror Ship]]
11 - [[Battleship]]
12 - [[Supply Ship]]
|- valign="top"
|colspan=3|Offsets 1 and 5 refer to the weapon placed in the left and right slots respectively. (The Lightning does not have a center weapon type, only a left). Their possible values are listed here:
0 - [[Stingray]]
1 - [[Avalanche]]
2 - [[Cannon]]
3 - [[Fusion Ball]]
4 - [[Laser Cannon]]
5 - [[Plasma Beam]]
255 - No Weapon
|- valign="top"
!1
!0x01
|Left weapon type
|- valign="top"
!2-3
!0x02-0x03
|Left ammo
|- valign="top"
!4
!0x04
|Indicates what a craft is doing.
0 - At base
1 - Airborne
2 - UFO's often get this value, have no idea what it represents.
|- valign="top"
!5
!0x05
|Right weapon type
|- valign="top"
!6-7
!0x06-0x07
|Right ammo
|- valign="top"
!8-9
!0x08-0x09
|Unused.
|- valign="top"
!1011
!0x0A-0x0B
|Damage, that is the amount it currently has taken. This value divided by the crafts damage capacity gives the percentage shown in-game.
|- valign="top"
!12-13
!0x0C-0x0D
|Altitude of craft. Is a index within [[ENGLISH.DAT]] for string.
0 = GROUND *
1 = VERY LOW
2 = LOW
3 = HIGH
4 = VERY HIGH
5 = Detected
6 = SIZE
etc
('''*NOTE''': If craft is airborne and you change it to this value the altitude will remain the same. Speed must be edited to 0 for the change to hold.)
|- valign="top"
!14-15
!0x0E-0x0F
|Speed of craft.
|- valign="top"
!16-17
!0x10-0x11
|Index into [[LOC.DAT]] referencing the destination - for example, waypoints for X-COM craft, or X-COM bases for alien craft.
|- valign="top"
!18-19
!0x12-0x13
|Index into [[INTER.DAT]] when the ship is in interception mode.
|- valign="top"
!20-21
!0x14-0x15
|Next UFO waypoint coordinate X (longitude).
|- valign="top"
!22-23
!0x16-0x17
|Next UFO waypoint coordinate Y (latitude).
|- valign="top"
!24-25
!0x18-0x19
|Fuel, amount remaining. This value divided by the crafts total fuel capacity gives the percentage shown in-game.
|- valign="top"
!26-27
!0x1A-0x1B
|Base reference as an index to [[LOC.DAT]].
|- valign="top"
!28-29
!0x1C-0x1D
|Mission type craft is on. Is an index within [[ENGLISH.DAT]] for the string (558 + this value).
0 = Alien Research
1 = Alien Harvest
2 = Alien Abduction
3 = Alien Infiltration
4 = Alien Base
5 = Alien Terror
6 = Alien Retaliation
7 = Alien Supply
|- valign="top"
!30-31
!0x1E-0x1F
|Zone where mission is being carried out. Is an index within [[ENGLISH.DAT]] for string (543 + this value).
0 = North America
1 = Arctic
2 = Antarctica
3 = South America
4 = Europe
5 = North Africa
6 = Southern Africa
7 = Central Asia
8 = South East Asia
9 = Siberia
10 = Australasia
11 = Pacific
12 = North Atlantic
13 = South Atlantic *
14 = Indian Ocean *
('''*NOTE''': Unused zones.)
|- valign="top"
!32-33
!0x20-0x21
|UFO trajectory segment (ranges from 0-7).
|- valign="top"
!34-35
!0x22-0x23
|UFO trajectory type (ranges from 0-9).
|- valign="top"
!36-37
!0x24-0x25
|Alien Race found on craft. Is index within [[ENGLISH.DAT]] for the string (466 + this value).
'''UFO''' '''TFTD'''
0 = [[Sectoid]] [[Aquatoid]]
1 = [[Snakeman]] [[Gillman]]
2 = [[Ethereal]] [[Lobsterman]]
3 = [[Muton]] [[Tasoth]]
4 = [[Floater]] [[Mixed Crew]] (Type I)
5 = Final mission mix [[Mixed Crew]] (Type II)
|- valign="top"
!38-39
!0x26-0x27
|UFO attack timer.
|- valign="top"
!40-41
!0x28-0x29
|UFO escape manuever timer.
|- valign="top"
!42-43
!0x2A-0x2B
|Craft status. Is an index within [[ENGLISH.DAT]] for the string (268 + this value).
0 - Ready
1 - Out
2 - Repairs
3 - Refueling
4 - Re-arming
|- valign="top"
|colspan=3|The rest of the known values detail the items on board of the craft. 49-98 refer to offsets 0-49 in [[OBDATA.DAT]].
|- valign="top"
!44
!0x2C
|Tank/Cannon
|- valign="top"
!45
!0x2D
|Tank/Rocket Launcher
|- valign="top"
!46
!0x2E
|Tank/Laser Cannon
|- valign="top"
!47
!0x2F
|Hover Tank/Plasma
|- valign="top"
!48
!0x30
|Hover Tank/Launcher
|- valign="top"
!49
!0x31
|PISTOL
|- valign="top"
!50
!0x32
|PISTOL CLIP
|- valign="top"
!51
!0x33
|RIFLE
|- valign="top"
!52
!0x34
|RIFLE CLIP
|- valign="top"
!53
!0x35
|HEAVY CANNON
|- valign="top"
!54
!0x36
|CANNON AP-AMMO
|- valign="top"
!55
!0x37
|CANNON HE-AMMO
|- valign="top"
!56
!0x38
|CANNON I-AMMO
|- valign="top"
!57
!0x39
|AUTO-CANNON
|- valign="top"
!58
!0x3A
|AUTO-CANNON AP-AMMO
|- valign="top"
!59
!0x3B
|AUTO-CANNON HE-AMMO
|- valign="top"
!60
!0x3C
|AUTO-CANNON I-AMMO
|- valign="top"
!61
!0x3D
|ROCKET LAUNCHER
|- valign="top"
!62
!0x3E
|SMALL ROCKET
|- valign="top"
!63
!0x3F
|LARGE ROCKET
|- valign="top"
!64
!0x40
|INCENDIARY ROCKET
|- valign="top"
!65
!0x41
|LASER PISTOL
|- valign="top"
!66
!0x42
|LASER GUN
|- valign="top"
!67
!0x43
|HEAVY LASER
|- valign="top"
!68
!0x44
|GRENADE
|- valign="top"
!69
!0x45
|SMOKE GRENADE
|- valign="top"
!70
!0x46
|PROXIMITY GRENADE
|- valign="top"
!71
!0x47
|HIGH EXPLOSIVE
|- valign="top"
!72
!0x48
|MOTION SCANNER
|- valign="top"
!73
!0x49
|MEDI-KIT
|- valign="top"
!74
!0x4A
|PSI-AMP
|- valign="top"
!75
!0x4B
|STUN ROD
|- valign="top"
!76
!0x4C
|Flare
|- valign="top"
!77
!0x4D
|empty
|- valign="top"
!78
!0x4E
|empty
|- valign="top"
!79
!0x4F
|empty
|- valign="top"
!80
!0x50
|CORPSE
|- valign="top"
!81
!0x51
|CORPSE & ARMOUR
|- valign="top"
!82
!0x52
|CORPSE & POWER SUIT
|- valign="top"
!83
!0x53
|Heavy Plasma
|- valign="top"
!84
!0x54
|Heavy Plasma Clip
|- valign="top"
!85
!0x55
|Plasma Rifle
|- valign="top"
!86
!0x56
|Plasma Rifle Clip
|- valign="top"
!87
!0x57
|Plasma Pistol
|- valign="top"
!88
!0x58
|Plasma Pistol Clip
|- valign="top"
!89
!0x59
|BLASTER LAUNCHER
|- valign="top"
!90
!0x5A
|BLASTER BOMB
|- valign="top"
!91
!0x5B
|SMALL LAUNCHER
|- valign="top"
!92
!0x5C
|STUN MISSILE
|- valign="top"
!93
!0x5D
|ALIEN GRENADE
|- valign="top"
!94
!0x5E
|ELERIUM-115
|- valign="top"
!95
!0x5F
|MIND PROBE
|- valign="top"
!96
!0x60
|>>UNDEFINED <<
|- valign="top"
!97
!0x61
|>> empty <<
|- valign="top"
!98
!0x62
|>> empty <<
|- valign="top"
!99
!0x63
|No known use for this offset.
|- valign="top"
!100-103
!0x64-0x67
|Bitfield (only 1st byte is used):
bit 0 (1): Craft is in hangar (0=craft's been flew away)
bit 1 (2): Want to go home (set after mission or when out of fuel), blocks craft
from re-targeting
bit 2 (4): [runtime] Out of elerium (0=fueled)
bit 3 (8): [runtime] Out of left ammo (0=left weapon rearmed)
bit 4 (16): [runtime] Out of right ammo (0=right weapon rearmed)
bit 5 (32): [runtime] Flag of processed UFO in interception window, to avoid
multiple escape/attack timers decrementing in case when UFO is
pursued in more than 1 window at once.
bit 6 (64): Hyperwaved extra info
|-
|}

==See Also==
* [[LOC.DAT]] - For information on the position the craft are at
* [[GEODATA.DAT]] - Contains information about the craft(s) when used as terrain objects in ground combat (Battlescape)
* [[Talk:GEOSCAPE.EXE#Craft_type_data]] Stats of XCom and UFO craft types
* [http://www.stonepool.com/xcom/hacking/craft.html Hatfarm's website] where most, if not all of this information was gathered from
* [[CRAFT.DAT (TFTD)]] - Terror From The Deep's craft file
* [[Saved Game Files]]
[[Category:Game Files]]

CRAFT.DAT

2013-01-31T00:49:24Z

Bomb Bloke: /* UFO Structure */