UFOpaedia - User contributions [en]

Talk:TFTD Strategy Guide

2012-03-30T21:31:46Z

Jewcifer: /* Initial research */

== General Comments ==

Thanks to everyone for their feedback on this comments page. When I get time I will try to update the main page with all the useful info. Or, anyone else, feel free to edit the main article. Cheers, [[User:Spike|Spike]] 14:26, 13 January 2011 (EST)

== Starting Base Location ==

For a base location I would say that the mid Atlantic or Pacific might be better. Remember you are covering the oceans, not the land masses. [[User:M52nickerson|M52nickerson]] 12:00, 28 September 2010 (EDT)

: Thanks for the help on this, I'm really not sure what the right approach is. My thinking around the Med was that you want to be as close as possible to as many Zones as you can, because it's the Zones (countries) who control your funding. The same argument as would be used in picking an Enemy Unknown starting base location. So my objective in picking a location is not so much to maximise the sea area covered, but to maximise the number of Zones protected. I did try a couple of times placing my first base in the mid Atlantic, and not much happened. But maybe that was bad luck. [[User:Spike|Spike]] 16:08, 28 September 2010 (EDT)

:: I tend to place them close to the money. First usually goes in the Caribbean somewhere, the second somewhere near Japan, the third in the Mediterranean.

:: At some point I usually build a dedicated manufacturing base, a smilar science base, and sometimes a storage base too.[[User:4th Cuirassier|4th Cuirassier]] 09:53, 11 January 2011 (EST)

::: I've redone a bit of the Funding page regarding the average starting values. The main problem with the US is that you really need 2 bases to cover it, 1 on the NW Pacific, the other on the Caribbean/Atlantic. The best places for starting bases seem to be the Indian and the South China Sea (SE of the Philippines). [[User:Hobbes|Hobbes]] 20:51, 11 January 2011 (EST)

My strategy involves the assumption that eventually I'll have 2 bases in the Atlantic, 3 in the Pacific, and 1 in the Indian (with Transmission Resolvers, there won't be many areas missed). Of those, the most profitable seem to be the West Pacific (hits E Asia and helps a bit with Australia) and the North Atlantic (US and Europe). [[User:Magic9mushroom|Magic9mushroom]] 03:17, 6 February 2012 (EST)

== Scientists or Extra Base? ==

I've pretty much decided in favour of Scientists, but for the record, here are both sides of the argument:

The quick-start procedure outlined in the article should give you about $1.7M of spare cash, $2.1M if you use an improved starting base layout or don't care about changing the standard layout.

The main two options for this money are:

*Hire additional scientists. ''Probably'' the best strategy.
*Build an additional base during the first month (wherever the Graphs show alien activity, or wherever there is Funding to be protected)

Adding a new base early can help you increase your intercept rate, which can give a big advantage to loot and research. It can also help to avoid negative score penalties that can place you in grave difficulty.

Ultimately, scientists win the game, by developing the technologies that will first resist, and then defeat, the alien menace. The faster you can acquire these technologies, the quicker the balance of power moves in your favour, and the more likely you are to survive and succeed.

For that reason, additional scientists is probably the best option.

On balance, it's probably better to build a second base from the proceeds of mission loot, rather than your starting cash. Apart from anything else, building a base can be done more or less any time of the month without major impact, whereas hiring scientists really should be done at the start of the month.

: I am getting the impression that on the harder levels, more bases - but token ones with just surveillance - may be the way to go.

: A base that consists of a hyperwave decoder, living quarters, stores, and an airlock, with a garrison of rookies, would presumably be unassailable because your guys would block out all the spawning spaces. [[User:4th Cuirassier|4th Cuirassier]] 09:56, 11 January 2011 (EST)

:: What good does it your cause if you can see the usos roaming around - if they are not in interception range the extra base just eats money. Scientists on the other hand enable you to raise your ability to deal with the threat. First better weapons to improve battlefield survivability then better detection, more better weapons and MC, better armor and better subs and finally the victory sequence. After you got your science built up you might start constructing your manufacturing base(air lock + storage + (sub pen), later living quarters,then storage, storage,storage,living quarters+workshop,... ) if the cash from the missions permits during January. Later start building a MC screening base. And much later interception bases around the globe. 3-4 bases are usually enough to provide all the storage, research and manufacturing space you need to play comfortably. Using 8 bases gives you more control and ease to respond to threats. It is possible to do with just one base. Furthermore I think I read somewhere that your base attracts uso activity to some degree (at least during Jan) which somewhat counters your need to raise the coverage. If you don't run too low on cash you won't be bothered by an early month or two without much activity. Just switch to manufacturing for profit (in your manufacturing base if set up already) and research happily away. Time works in your favor since you should have enough stuff from the first two assaults to keep your research team happy for a while and you only get stronger through research. --[[User:Tauon|Tauon]] 16:14, 11 January 2011 (EST)

:::: Well, one rational use for remote bases is interception of subs that land on the sea bed and hang about near those bases. If you send a Barracuda from (eg) the Gulf of Mexico to intercept a sub in (eg) the Sea of Japan, and the sub touches down while the B is en route, all the latter can do, when it arrives, is loiter until the sub takes off again. Usually it runs out of fuel before that happens. So you send a Triton instead, and you get an extra interception. [[User:4th Cuirassier|4th Cuirassier]] 13:27, 14 January 2011 (EST)

::: Listening outposts are very cheap and quite valuable in helping you coordinate your current and future operations. Of course, for these it's actually cheaper to use just an airlock and a sonar, and nothing else. Lose the base? 0 points for both sides are generated. Sell a sonic cannon or two and up goes the replacement in a month. Easily upgraded into intercept outposts which can then be expanded to other functions as necessary.

::: I know it's better to have some useful facility like labs or workshops - but those are functions that your first base already provides, and don't really need to be duplicated at all the other bases. Minimal facilities like the listening outpost broadens your net a bit and don't really cost a lot (money sorts itself out in time what with the deluge of sonic cannons!). And if it's in the same regional zone as one of your other bases, it adds an extra target for retaliation teams to pick from. -[[User:NKF|NKF]] 23:55, 11 January 2011 (EST)

:: If there aren't enough space on the Air-Lock/Sub Pens then the aliens will appear on other modules (cargo, etc.). That makes the whole thing even more dangerous since you won't have the advantage of the choke points. [[User:Hobbes|Hobbes]] 20:52, 11 January 2011 (EST)

::: Zombie's patented insta-win base defense setup by using up all the spawn nodes. Since your soldiers take precedence, they'll use up alien slots if there aren't enough X-COM slots to accommodate them. If you have enough soldiers to use up every single slot, you instantly win the mission after the first turn. You even get to keep all the weapons, which are still generated even if their owners aren't. -[[User:NKF|NKF]] 23:48, 11 January 2011 (EST)

I pick Extra Base, though if you're a beginner Scientists would be better. It boils down to money - an extra base will give you more money through additional interceptions and thus pay itself back, while barring manufacturing scientists will not - as such, extra bases and then scientists > scientists and then extra bases in overall speed. The exception is if you need better tech to win missions - then Scientists are better, since you don't get your loot unless you win. [[User:Magic9mushroom|Magic9mushroom]] 03:22, 6 February 2012 (EST)

== Sub Interception ==

There is one difference in the Geoscape that really sets TFTD apart from UFO. I'm always able to happily get away with arming fleets of interceptors with Plasma beams and they were the bulk of my air defenses in UFO, but with the introduction of the otherwise utterly annoying sub 'depth' in TFTD, your Barracudas are going to be stumped frequently by enemy subs ducking down to depths that the Barracudas can't reach.

This makes Mantas and Hammerheads a nice mid-game topic to put emphasis on. Luckily, the sub construction topic is a byproduct of two of the most important technologies anyway, the Transmission Resolver and Mag Ion Armor. Probably be worth mentioning that you should keep a sample of the store item. -[[User:NKF|NKF]] 01:55, 29 September 2010 (EDT)

: Great point, I will amend the suggestion to reflect that. In general TFTD is just much more challenging, I'm really getting in to it for that reason. [[User:Spike|Spike]] 09:20, 29 September 2010 (EDT)

::I've never found the depth of enemy subs to be much of a problem. They almost always come up to a "shallow" depth at some point. If anything the speed of the USO's is the main reason to build a Manta or Hammerhead. I still just wait until I can build a couple of Leviathans. [[User:M52nickerson|M52nickerson]] 20:21, 11 October 2010 (EDT)

:::It's a combination of the speed and depth that doubles the difficulty. If you do eventually catch up with the sub but it just happens to be at a deep depth, your Barracuda may just run out of fuel before the alien sub returns to shallow waters. It's not so bad if the Barracuda's home base is just nearby, but on those long cross-continent chases, it really does get frustrating. But I guess it does make the Manta useful, whereas in UFO you could easily skip the Firestorm in favour of using interceptors and Avengers. -[[User:NKF|NKF]] 06:14, 12 October 2010 (EDT)

:::Using only Barracudas seems to make it impossible to shoot down the Supply Ships since they will be out of reach due to their depth. But then you might want to wait for them to land instead of shooting them down. But if you are a bit tired of all those missions, then you'll need a Manta if you want to deal with the Supply Ships by shooting them. [[User:Hobbes|Hobbes]] 20:54, 11 January 2011 (EST)

== Downing Very Small USOs ==

Instead of arming both Barracudas with DUPs in the beginning one might want to keep one armed with dual AJAX since a DUP hit destroys the smallest Subs. This is a real waste of easily earned early income and research material. Against anything up to Heavy Cruisers a single DUP armed Barracuda is sufficient and attacking anything larger is a gamble. Of course this messes up the picket ship strategy...--[[User:Tauon|Tauon]] 18:13, 10 October 2010 (EDT)

: Yes that's a good suggestion. It's worth considering it costs $600K/month to rent that Barracuda just to tackle Very Small USO Survey Ships though. But in the first month or two I think it's a good idea. As soon as I get a second base, I transfer the 2nd Barracuda there, and from that point on it makes sense to arm with dual DUP I think. Have you tested this with dual Ajax though? From the data tables on this website, I would expect dual Ajax automatically kills a Survey Ship (damage limit 60), since 2 Ajax = 60 to 120 total damage. If you've seen Survey Ships survive attack by dual Ajax regularly, that has some implications for how sub combat works. Anyway I'll have to try that, and also Ajax + Gas Cannon, which would be pretty much guaranteed to crash a Survey Ship rather than destroy it. Thanks! [[User:Spike|Spike]] 19:56, 10 October 2010 (EDT)

::It worked for me in the majority of tiny uso intercepts. However I recall a case were it was destroyed. I guess one would have to go dual gas canon to be completely on the safe side. The single Ajax fires twice before one gets in gas canon range. However dual Ajax is usable against Cruisers(the craft which one will encounter most) as well and Gas Canon leaves the craft too open for return fire for my taste.--[[User:Tauon|Tauon]] 09:53, 11 October 2010 (EDT)

:::So just to be clear, you routinely use dual Ajax against Very Small USOs (Survey Ships, containing one alien), and only rarely do they get destroyed? If so that's very interesting, because it suggests that the processing of whether the USO is crashed or destroyed occurs between the impact of the two torpedoes, even though appear to 'the naked eye' to be simultaneous impacts. Either that, or the damage values for Ajax or wrong, or the damage process is misunderstood. On the current understanding, it should be 50%-100% of base damage (60) per Ajax torpedo (average 75% = 45 damage). The threshold for crashing should be 50% of the Survey Ship's defence strength, 60 x 50% = 30. The threshold for being destroyed should be 100% of the Survey Ship's defence strength, 60 x 100% = 60. So even if two Ajax both did minimum damage, 2 x 60 x 50% = 60, they would always or very nearly always destroy the Survey Ship. So this is curious. On the other hand if you were using the 1 Ajax + 1 Gas Cannon combo to consistently crash Survey Ships, that's more understandable. [[User:Spike|Spike]] 11:40, 11 October 2010 (EDT)

:::: Yes, I routinely use dual Ajax to deal with the Survey ships(1 alien, 1IBA,1MagNav,8AP). I do use the patch to switch the hulls in battlescape. I just run a small empirical test(new game,superhuman,prepare the Baracudas: 1 dual Ajax, 1Ajax&1GC, build large sonar) to see if I remembered right. Fast forward until I get the very small contact. Save. Intercept with Baracuda 1(dual Ajax). See what happens. Reload. Again. Out of the 10 times I went before I got bored. I downed it 10 times. 6 or 7 times with the first salvo The rest with the second. Then I repeated the cycle with Baracuda 2. I can confirm that usually one 1 Ajax hit is sufficient to down the Survey ship. Due to the inaccuracy one often needs to fire 2 or more. 2 Ajax are fired in aggressive attack mode before the GC gets to play. I managed to destroy the uso 1 time out of the 10 tries(3 Ajax and 1 GC shell fired).--[[User:Tauon|Tauon]] 14:29, 11 October 2010 (EDT)

::::: Well that is very strange. Thanks for doing those tests. At accuracy 70%, you would expect that 49% of dual Ajax salvoes would score 2 hits. For salvoes that hit at least once, in 70% of those salvoes there would be 2 hits. And as noted above, 2 Ajax hits should always destroy the Survey Ship. Yet your empirical data are nothing like that. You see destruction in only 10% of sorties using dual Ajax. This suggests either the listed damage for Ajax is wrong, or the listed damage capacity for Survey Ship is wrong. Or, worse, our understanding of the mechanics is wrong. Largely it's just assumed they are the same as Enemy Unknown air combat mechanics - maybe they are not. I think it's time we had a code dig to confirm what the USOPaedia says about USO stats and weapon stats. [[User:Spike|Spike]] 17:24, 11 October 2010 (EDT)
::::: I couldn't find a Survey Ship I could catch but I did find a BattleShip that took 20 AJAX fired to bring it down. That matches ok to 20 x 60 x 70% = 840 damage vs 1400 x 50% = 700+ damage to crash a BattleShip. Maybe the damage capacity of the Survey Ship has been increased, to make it easier to crash it? [[User:Spike|Spike]] 18:12, 11 October 2010 (EDT)

: Well, I run a more extensive test this morning using a different survey ship. There is some funny stuff happening.
Setup: dosversion 2.1,survey ship -escort battlescape hull swap patch, dye grenade patch;
Baracuda armed with dual Ajax intercepts survey ship(very small contact, I checked it had only 1 occupant by retrieving it twice);
number of intercepts:100
<table {{StdCenterTable}}>
<tr>
<td>salvo 1</td> <td>destroyed</td><td>downed</td><td>hit</td><td>missed</td><td>missed</td><td>missed</td><td>missed</td>
</tr>
<tr>
<td>salvo 2</td> <td>-</td><td>-</td><td>destroyed</td><td>destroyed</td><td>downed</td><td>hit</td><td>missed</td>
</tr>
<tr>
<td>salvo 3</td> <td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>destroyed</td><td>downed</td>
</tr>
<tr>
<td># occurences</td><td>2</td><td>70</td><td>2</td><td>2</td><td>16</td><td>1</td><td>7</td>
</tr>
</table>
If I calculate the expectation values for these events using the naive model they do not match up well. Not to mention that it should be impossible to hit the survey ship using dual Ajax without downing it. I would guess that there is some small deviation from the given Ajax damage value possible.
And the game does not seem to check the second projectile if it got over the downing threshold with the first.
Btw the 110 damage of the DUP seem to destroy it as expected. Since this value is close to the 100 destruction capacity I wonder if the deviation if it exists can be large enough to allow the rare downing of a survey ship with a single DUP.

---

Very interesting data. I've thought hard about how to fit this data. Superficially, the data above actually looks like only 1 Ajax missile launcher is being used. I don't think this is true. I think I can make most of the data fit, with a few slightly changed assumptions about craft combat mechanics.

# Salvos of the same missile type share the same "to-hit" roll. Both hit or both miss. This would predict a pattern of 30% miss on Salvo 1, 9% (of total) miss on Salvo 2, 0-1% (of total) miss on Salvo 3. This is a fairly close match for your data, especially if you take the initial 26% miss on Salvo 1 as a starting point and apply the same rules. We can be very sure this is true, because if the to-hit rolls were independent, we would see one or more hits in nearer to 91% of salvos, rather than around 70% of salvos - as was observed empirically in this data.
# As suspected, combat processing stops immediately whenever a 'crashed' or 'destroyed' condition occurs. For Ajax vs Survey Ship, this means the 2nd missile hit is irrelevant in 29/30 cases, because the USO is downed or destroyed 29/30 by the 1st missile. This is what makes this data look so similar to firing a single missile rather than dual missiles: the effect of the 2nd missile is masked in 29/30 cases.
# It's unclear whether ''damage'' is rolled seperately for each missile hit (gaussian), or if the same roll is used (linear). Because of the 'masking' effect, it's very hard to tell. Either scenario is compatible with the results seen vs larger USOs, because you have enough hits that it averages out before the craft is downed or destroyed.

The above explains the frequency of the typical case, "Ajax crashes Survey Ship", pretty well. On 70% of salvoes there is a hit (I believe it's always two hits in fact). The first hit is processed, and the Survey Ship is downed in 28/30 cases (out of 70%, ~= 65.33%), destroyed in 1/30 cases (~= 2.33%), hit but survives in 1/30 cases (~= 2.33%). The second hit is irrelevant in 29/30 cases (96.66%), as the USO is already downed or destroyed. If the first salvo missed entirely (30%), or the USO survived (1 in 30 of the other 70%), additional salvos proceed on the same basis.

So in 1 salvo in 30 the USO is destroyed, and in 1 salvo in 30 the USO is hit but keeps running. These are the outlying cases that are harder to explain.

The masking effect explains why the damage distribution appears linear (1 x d30), rather than gaussian (2 x d30). The damage is never, or almost never, cumulative, because only 1 time in 30 does processing proceed to the 2nd missile hit.

A key question is where the algorithm's exact boundaries lie. Are the 50% and 100% thresholds, for "crashed" and "destroyed", compared using "greater than" or "greater than or equal to"? Is integer rounding used, or integer truncation, or no rounding?

There are various ways of explaining the "destroyed" frequency. The observed "destroyed" frequency matches the scenario for a single launcher. This is simply because of the "masking" effect again. So, as noted above, the "destroyed" frequency is basically what would be predicted by a linear damage distribution of 1 missile hit.

The hard thing to explain is the "hit but survived" frequency. This also acts very much as it would for a single missile launcher. The problem is, regardless of whether damage distribution is gaussian (2 independent rolls) or linear (same roll used twice), it doesn't matter: the craft should always be destroyed by the second hit, since (we believe) the cumulative total can't be less than 60.

The only explanation I can see for the "hit but survived" frequency of 1 in 30 per salvo is the following

# there is some kind of "critical fail" rule at the low end of the range, something involving integer rounding or truncation, so that the frequency of it occuring is about 1 in (integer range of possible damage); eg 1 in 30 (or maybe 1 in 31) for a weapon with base damage = 60.
# distribution of damage on both missile hits is linear, i.e. the same roll is used for both hits, so they both suffer the "critical fail" at the same time
# a "critical fail" reduces the damage to consistently and significantly less than 25% of weapon base damage, most likely to zero
# alternatively, the "critical fail" or other low-end-integer result causes processing of the second missile hit to be aborted.

I don't really like the "critical fail" supposition because it creates an extra hypothesis to explain an anomaly. But without "critical fail" and a shared damage roll for both missile hits, I can't explain why the "hit but survived" rate is linear, and so closely matches the expected rate for a ''single'' missile launcher.

A good test for the "critical fail" hypothesis would be to use a weapon with a more powerful base damage, such as a DUP (110 vs 60). If "critical fail" is correct, there should be a similarly consistent, higher than expected, "hit but survived" rate, possibly 1 in 55 rather than 1 in 30, but not varying noticeably whether you have dual DUP or single DUP.

It would also be interesting to test single AJAX, and see if the "destroyed" and "hit but survived" rates change. For single missile launcher tests you want a Cannon as your second weapon, and use Cautious mode so you hold off outside cannon range.

A large number of tests with dual DUPs (55-110 damage each, 165 salvo average) vs an Escort or Cruiser (300 damage capacity) should be able to determine if the damage function of two weapons is linear or gaussian. Basically, 2nd salvo kills will be much more common if the distribution is linear, much less common if the distribution is gaussian.

The weirdness of the Survey Ship vs Ajax situation comes almost entirely from the fact that the Ajax base damage is exactly matched to the Survey Ship damage capacity, ie. both 60. But it's precisely because it's such a special case that it's able to shine light into the hidden game mechanics. It's a bit like a stroboscope or a spectrograph. A very useful experiment. [[User:Spike|Spike]] 16:55, 12 October 2010 (EDT)

:Have the AJAX's true accuracy and damage been confirmed in the single case? It would seem prudent to do so before making hypotheses about the double case. On the original question of using AJAXs instead of DUP Heads... in the early game it is difficult to distinguish between the Escort and Cruiser, and you do not want to fight a Cruiser with AJAXs. Using one DUP Head to deal with Cruisers negates the whole point of using an AJAX (because the DUP Head will blow up Survey Ships), and you stand a higher chance of a Cruiser or Escort outrunning you before you can shoot it down due to the higher DPS and range of DUP Heads. It should also be noted that destroying a Survey Ship gives more points than shooting it down, even counting the recovery. Hence I think that dual-DUP is the best loadout until you get Sonic Oscillators (which should be as soon as possible). [[User:Magic9mushroom|Magic9mushroom]] 03:39, 6 February 2012 (EST)

==Secondary base ==

I usually make my second base the manufacturing base.
: Yes I agree that it makes sense to make the 2nd base a manufacturing base.[[User:Spike|Spike]] 12:27, 11 October 2010 (EDT)
If memory serves me right I usually start with an Sub-Pen(low cost, takes a long time to build), a large sonar(improved detection) and a Store(space where one can store stuff away in case of an attack on the main base) like this.
{{TBK|=
|subpen1|subpen2|water|water|water|water|=
|subpen3|subpen4|water|water|water|water|=
|airlock|large_sonar|water|water|water|water|=
|stores|water|water|water|water|water|=
|water|water|water|water|water|water|=
|water|water|water|water|water|water|=}}
Normally one would add the living quarters south of the store next to be able to garrison the base. However if I recall right there is a chance for aliens spawning in the living quarters module - which would compromise your main defence line to be. So I usually add 2-3 more stores before I put down the living quarter. I use stores because these build fastest and a good defensive layout is unfortunately slow to develop. However it will take a few month before one has pillaged and sold enough stuff to hire a large bunch of technicians. Not to mention researched the stuff to build. Setting up the 100-150 scientists in the main base needed to research stuff at reasonable pace takes priority. And even on superhuman difficulty the aliens usually don't bother my second base before I got a garrison by mid to end February. Once the living quarter finishes I add a MC lab or two to help with the screening. Transmission resolver is next in the building queue. So this is the intermediate design.
{{TBK|=
|subpen1|subpen2|water|water|water|water|=
|subpen3|subpen4|water|water|water|water|=
|airlock|large_sonar|water|water|water|water|=
|stores|water|water|water|water|water|=
|stores|water|mclab|water|water|water|=
|stores|stores|quarters|transmission|water|water|=}}
Next add one more sub-pen living quarters and workshops as money permits, on one more store and replace the outdated sonar with a MC generator to reduce the number of base defences. The following final layout is not optimized for build time - I leave this as an exercise to the reader.
{{TBK|=
|subpen1|subpen2|subpen1|subpen2|water|workshop|=
|subpen3|subpen4|subpen3|subpen4|water|stores|=
|airlock|mcgenerator|water|water|quarters|workshop|=
|stores|water|quarters|workshop|quarters|workshop|=
|stores|water|mclab|workshop|quarters|workshop|=
|stores|stores|quarters|transmission|quarters|workshop|=}}
This layout allows to crank out those new subs fast or make tons of money. There is enough workspace for large projects and plenty of storage for the defence displacers and supplies. Only one should be needed.
In any further base I build 3 sub-pens and add 3-4 pwt defences, a bombardment shield and more storage(the zrbite keeps piling up) and more mc labs for faster screening.

: Excellent designs, I'd never got past the letter E shaped configuration or the spiral sperm configuration, so these are very helpful.

: Is it feasible to build a base with no hangar and "defend" it with unarmed rookies who block all the spawning spaces? [[User:4th Cuirassier|4th Cuirassier]] 10:03, 11 January 2011 (EST)

== Rushing MC ==

MC is undoubtedly the most powerful tactical advance - so powerful that some consider it cheating - at least if one uses MC chains.A highly skilled MC squad usually eliminates all combat casualties if used properly and allows the safe training of any soldier, maximizes loot(less unwanted destruction) and together with drills/tasers no ammunition is needed to safely kill large numbers of enemies. An it greatly helps during terror missions, night missions(alien scouts) and against lobsterman.
Once the high MC strength soldiers(80+) have been identified by the lab it usually just takes just 1-2 month with lots of intercepts to max out the the MC skill(as far as combat is concerned). This enables them to control any alien on a whim. Secondary stats are increased as well while training.
So in order to win easily one would want it as early as possible. Lets see how fast it is possible.
Usually you will manage to obtain a reader in January. By the start of February the alien containment should store a live terrorist. This could result in an active lab by end of February. Spend the rest of February researching other stuff. In March research the MC reader. If you have run into tasoth by then you are lucky. If not but you know where a colony is located you are also fine. Just send a bunch of rookies to grab one (bring tasers(or TSL if you got them), flares and something to deal with tentaculats) and get the hell out of it as soon as you got it. If half the rookies die its still a win. Then research the tasoth and disruptor and you are ready to roll in April.
If one is lacking a live terrorist for unlocking the MC lab - a live tentaculat provided by a base will do(Fire from your dropship at all other alies until one gets close enough to rush & stun it with tasers - pickup and throw/walk it into the dropship). Theoretically there should also be a reader somewhere but I don't know which aliens usually carries it.--[[User:Tauon|Tauon]] 16:28, 11 October 2010 (EDT)

: If you rush MC in this way don't you trigger the tech tree bug by researching a live alien too early? [[User:4th Cuirassier|4th Cuirassier]] 10:05, 11 January 2011 (EST)
As long as you have a MC reader in storage when you finish the research of the MC lab there is no problem and one usually captures one rather early. According to the bug avoidance guide it should be fixed in the 2.1 patch. --[[User:Tauon|Tauon]] 15:32, 11 January 2011 (EST)

== Battlescape tactics discussion ==

=== Battlefield Illumination ===

Chemical flare vs Incendiary ammunition during night missions:
In UFO it is really easy to get along with setting half a battlescape on fire for lighting using incendiary ammunition. This has the additional benefit of dealing fire damage to aliens. However in TftD most battles are underwater where the tiles contain hardly any combustible stuff and the lighting is off the turn after firing making this method of lighting rather cumbersome. I usually find it more practical to pack 4-6 chemical flares and reuse them by picking them up and throwing them again. If two are used in alternation one can can cover one direction pretty well.

:Why not just buy 20 or so flares? They cost and weigh basically nothing. That way you don't have to worry about re-use so much. [[User:Magic9mushroom|Magic9mushroom]] 03:43, 6 February 2012 (EST)

:: I'd buy 20, but taking 20 or so flares into combat does use up a big chunk of your item limit if your weapon setup consist of lots of low-ammo weapons. It's made worse if you also get into the habit of arming each aquanaut with a medikit! A good system where a few flares are used efficiently is generally more than sufficient. Of course, you can also go the best of both worlds and just bring enough to arm each aquanaut with one and recycle as you go along. [[User:NKF|NKF]] 05:12, 6 February 2012 (EST)

::: Well, this comes back to the whole Gauss vs. Sonic thing. If you're using Gauss Rifles, you need at least 2 reloads on long missions and your item limit gets eaten alive. With a Sonic Pistol you only need 1, and you often won't even need that if you brought a drill. It also depends on the rest of your loadout - using Coelacanths or Displacers cuts down on item use significantly, and you need them anyway on any mission with Tentaculats.

:::If you take a Triton with 1 Displacer, and use Sonic weaponry, each soldier can have a Sonic weapon (Pistol or Cannon), two clips, a Vibroblade, a Medi-Kit, two electroflares, and still have room for a Sonic Pulser. [[User:Magic9mushroom|Magic9mushroom]] 05:26, 6 February 2012 (EST)

=== Sniper tactics ===
I usually support my swipe teams(consisting of a front squad(lightly armed expendable spotters) and a rear team (heavily armed shooters)) by 1-3 snipers which take care of anything which survives the shooter fire. With the advent of magnetic armor I usually set one up on top of the triton until I find a better location(large hill, top of building, tower ...).

== Initial facility built ==

I would consider building an additional lab right away - its construction takes 26 days and you might want to raise the scientist number to 75 by begin of February if you can afford it. 100 during February as soon as you can afford them and after accommodation has been provided.
This is possible if you delay the sub pen relocation (400k) until the first uso assault. This should enable you to get the crucial techs sooner.

== Initial research ==

I'm don't think that the PDS is the best initial choice. The economic benefit is not that large.
Lets have a looks at the numbers:
It costs 180 scientist days to research. The 10 initial scientists reduce this by 30 before the 15 newly hired ones join them. The remaining 150 keep 25 scientists about 6 days busy. So you would expect the research to be finished around the 10th. That leaves the 10 techies with 20 days to make money. 20*10*24=4800 T hours. Since it takes 220 T hours to produce one unit about 22 get produced. These yield (45,600-34,000)*22=255,200 profit.
Thats about 1 IBA or 2 Sonic weapons or 17 pulsers. It can buy 4-5 scientists. And the tactical benefit is negligible.
Lets say we start the gauss sequence right away- with (50+100+60) we get an operational gauss pistol 1-3 days after the estimated completion day of the PDS. And since we can start producing it as soon as the pistol research finishes (Jan 9th) we can field gauss pistols by about Jan 15th maybe a bit earlier. That helps on the battlefield until we finish with the sonic research and have collected enough ammunition to make using the pistol practical.
And it can also be manufactured for a small profit.
After this we have 4 paths we could follow(I assume that we got a mission in the meantime):
-continue to gauss rifle(300+150)
-start sonic pistol(600+400)
-start mag nav for trans resolver(450+670)
-start sonic pulser(200)

Of course if one gets a uso on Jan 1st it might be tempting to switch right away. Although a gillman escort night mission(superhuman) at a that time can be challenging but beneficial(~1M extra cash).

:The reason for the PDS is that it's better than Medi-Kits if you're planning to skip Gauss, and it's quite possible to get your hands on a Sonic weapon before it finishes. If you're not planning to skip Gauss, then sure, Gauss should be researched ASAP, but the whole point of initial-researching the PDS ''is'' to skip Gauss. Me, I find that GC-HE plus Thermal Taser is often enough for those first few Alien Subs. (I also go for a second base before heavy investment in scientists, so I can't get the Gauss Rifle Clip researched early enough to have full deployment for the first terror wave anyway.)

:Also, signing your contributions would be appreciated, whoever you are. [[User:Magic9mushroom|Magic9mushroom]] 03:53, 6 February 2012 (EST)

::I'm more inclined to agree with the OP in this section. The only advantage the PDS has over either the pistol or the Medi-Kit is ~$10/hr more if you are manufacturing it solely for profit. Tactical benefit there is no question. If you're HE-happy like the strategy guide is suggesting (which I'm definitely all for!), I'd almost certainly go for the Medi-Kit instead. Low-accuracy rookies like to leave themselves and their friends with a few fatal wounds, and saving just one aquanaut life would take almost 4000 engineer-hours (~16 days with the starting 10) to make up for money-wise with the PDS approach. Of course, I guess it depends heavily on play style in battles. If you aren't liberal with HE rounds Medi-Kits might actually be even more useless than a PDS, as no one is going to survive a hit from a sonic weapon without armor.
::Personally, I don't see 'skipping gauss weapons' as a binary proposition. I typicaly go for the pistol as the first research, and then don't go back to gauss until I have nothing better to do than head towards the craft cannon, if I even ever do. The reason I go gauss pistol first is you can get it on average 30 scientist days before the PDS, which will probably translate to 1-2 actual days earlier, meaning you can put your engineers to work earlier. For each day earlier you are manufacturing pistols you get almost $10,000, which translates to 4-9 days that the gauss pistol is actually economically superior to the PDS. And I do find them quite useful for the poor rookies who have to breach sub doors, as if an alien is facing you such that you can't run up and taze, the pistol gives you a much better chance of survival, again any saved aquanaut eating another ~16 days off of the hypothetical benefits of the PDS.
::Of course, this is an entirely subjective strategy guide, and I'm just throwing my equally subjective 2 cents out there.
::--[[User:Jewcifer|Jewcifer]] 17:31, 30 March 2012 (EDT)

== Initial weapon purchase ==

I usually keep 2-4 harpoon rifles for uso close quarter assaults until I get gauss or sonic. A close quarter autoshot is usually more effective then a single GC AP shot. Which means fewer GC on the buy list.
For the first 1-2 month one wants to keep one craft armed with dual Ajay thus only 1 DUP launcher needs to be purchased.

:Thing is, at long range the GC-HE is clearly better due to the higher effective accuracy and therefore damage, and at point-blank the Thermal Taser is better. The window for the inaccurate and slow Harpoon auto-shot is only about from the close-range limit of GC-HE (about 6 squares) to the 1-2 at which you can charge with a Taser. [[User:Magic9mushroom|Magic9mushroom]] 04:04, 6 February 2012 (EST)

== Really helpful page ==

Well done folks.

I played TFTD to the point of lunacy in '95 to '96 and only stopped when my PC became incompatible. I successfully played through to the end first time and somehow dodged all the bugs. Never managed to do that since. Just downloaded it from Steam and it's addictive again.

Pleased to see I arrived at the same ideas re base layout. Mine are usually shaped like a letter E or like a sperm, i.e. one pen for building subs and everything else strung out in a single spiral line. I once had an exhausting firefight on a ship followed by a terror raid. I sent the wounded to my Hawaii base to recuperate. They were then attacked, and those who'd recovered from wounds had only legacy weapons to fight with. Nonetheless the easily-defended spiral layout saved them.

I'm interested in the economic analysis. I usually churn out medikits because they require nil resources and generate nice money from right away. I hadn't noticed the PDS was that good.

I have some suggestions for the battlefield tactics section. When an alien is stunned or wounded, I usually send a guy to stand over him, who unloads and throws his weapon away. This ensures that if the alien revives he is harmless.
::Well I would check the rank of the wounded, stunned alien - if it is not needed for research and I got Medikits I would wake it and shoot it for extra exp. If it is too dangerous (Lobster, tentaculat, Bio-drone) I would plant a grenade or shoot the ground with HE in order to ensure the sleeping beauty won't wake behind your lines. If research critical try to make sure it is in a region with smoke(not sure if it works, try droping a dye grenade). If there is a lot of loot on the ground there might be occasions where it is simpler/faster to move the alien instead of the loot. --[[User:Tauon|Tauon]] 14:40, 11 January 2011 (EST)

When I get MC over an alien I always have him shoot any nearby aliens and then throw his weapon away. If I have groups under MC then I have them all stand at one end of the battlescape while my guys form a firing squad at the other. I then "execute" them with long range fire, which is a safe way to improve combat stats.
:: Having an alien throw its weapon away is fine but unless you are really hard pressed or the situation calls for it always let your soldiers do the shooting and killing - no wasting of valuable exp. Also when you are so good at MC that you can move the aliens at will have them throw their guns away and move them next to your soldiers to ensure a hit next turn. If you are really into exp training use weak weapons to ensure you you get more hits in before your target dies autofire with gauss pistol/dart gun on lobsters works fine. MC again if still alive and and you are done shooting for the turn. Make sure that they are dead and if not use a medikit to wake them to finish the job. Make sure that the side with the highest remaining armor points is targeted to get most out of your target.
::An exception to the above are hostiles with built in long range weapons(Deep one,Bio drone,Xarquid,Triscene) which can not be fired upon without fear of reaction fire normally. Finish those from outside their sight range.
::And unfortunately the AI does not seem to be able to have Aliens pick up weapons from the ground. So once they are gone they are gone for good. But unless stunned and woken up you can never sure if there is not a pulser left. --[[User:Tauon|Tauon]] 09:37, 11 January 2011 (EST)
:::Thanks for details. Yes if time permits I usually disarm the buggers altogether, including guys on my own side whom I've had to stun. Those guys I leave with their grenades - I don't think I've ever seen an MC-controlled aquanaut use one.[[User:4th Cuirassier|4th Cuirassier]] 10:10, 11 January 2011 (EST)
:::: As long as the grenade is on the MC controlled aquanaut it will use it(Had entire reserves in my Triton killed by MC controlled guys) and pull out any other usable item which the AI can handle as well, I think it will even load any gun if suitable ammo is on the guy. If you want MC susceptible guys to contribute to the fight arm them with a Thermal Taser or later on a drill - the AI can't handle those. Or give it a MC reader or an unloaded DPL launcher(standing over the ammo enables loading and firing it on the same turn).--[[User:Tauon|Tauon]] 14:40, 11 January 2011 (EST)

DPLs are best fired on a mortar type of trajectory as this minimises the number of turns you need to make and normally means you can plant the missile in the middle of a target group. I also use DPLs to make holes in the sides of alien bases which I then "rinse" by firing more DPL rounds through the hole.

If confronted with an alien base early in the game when your weapons are rubbish, one option is a raid rather than an assault. That is, you go in the top level and get all the guys onto the lift, then quit the game. You thus get to the next level even if the aliens aren't all dead. From there you do the same underground. In this way you can destroy the control centre without having to kill every one of 50-odd aliens (which is usually impossible with jet harpoons anyway). [[User:4th Cuirassier|4th Cuirassier]] 09:10, 10 January 2011 (EST)
::Why would one want to do that - it does not hurt that much to keep the alien base around - the negative score is not that large and there is no time limit for dealing with it. If it is close to your base it allows you to assault the supply ships which is more then enough to tilt the balance in your favor. And it attracts more usos which you can assault and retrieve to fuel your war effort (Exp- and cash-wise). Furthermore you won't need to capture a lobster commander that early.Heck it is usually much easier to wait for a lobsterman dreadnaught and get all the lobster captives you need(1 navigator, 1 commander) from there or from a lobster assault on your base.Only if the lobsters fail to show up and you have already researched everything else I would go looking for them over there. If you are desperate for cash just clear the first level and bag everything you can grab before retreating and repeating if necessary. The only reason which could make me assault a alien base early(before I feel ready) is a grab and run mission for a certain research item or a personal rule where I have to assault and destroy a base as soon as it shows up. --[[User:Tauon|Tauon]] 14:40, 11 January 2011 (EST)

::: AIUI the longer an alien base is allowed to hang around unmolested, the likelier the country or countries in the area are to secede and join the aliens.[[User:4th Cuirassier|4th Cuirassier]] 13:32, 14 January 2011 (EST)

:::: The reason that happens is because each base generates 5 area activity points a day. That's a total of 150 - 155 points every month, or 140-145 in February. If the alien area activity points are greater than the X-Com activity points by the end of the month, then the nearby funding groups are displeased and may withdraw funding. This often happens if the colony is ignored. If you compensate for this and keep the X-Com activity points higher, the countries stay happy. This is often accomplished by successfully capturing every month at least one of the colony supply cruisers that dock with the base. -[[User:NKF|NKF]] 13:58, 14 January 2011 (EST)

::::: Aha, thank you. I was wondering how that worked. How on earth did people dig up this level of detail? [[User:4th Cuirassier|4th Cuirassier]] 09:19, 17 January 2011 (EST)

: There's actually no need to toss weapons away if the alien has been stunned. Unlike Apocalypse where equipment stays on an unconscious alien until it is physically 'picked up' in the inventory screen, all equipment is automatically dropped to the ground the moment a unit is stunned in UFO and TFTD. Therefore as long as they were knocked down, then they will wake up unarmed. Except lobstermen, which I must say are quite dangerous to stand over or pick up! -[[User:NKF|NKF]] 23:26, 10 January 2011 (EST)

:: I usually toss them away to be sure the alien, if it wakes up, can't simply pick up its gun and rejoin the fight. I tend to assume it would do this if its gun were still there but I've never been able to test this.

:: Also I usually unload any unused magazines, as they're lost otherwise.

:: The version I'm playing seems to have the difficulty level bug fixed. I wonder if we should say something somewhere about what difference the difficulty level makes. I haven't noticed any difficulty in combat between easy and the hard level I'm now playing on. I have noticed that I detect many fewer USOs - they practically have to fly right overhead to be picked up. When I pursue them they almost always escape. They don't hang around on the seabed for very long and terror raiders don't hang around either. Countries seem much quicker to reduce funding and one defeat - such as not reaching a terror site - basically loses you the campaign. This is a subjective list based on comparing my current game to the last time I played, which must have been in about 2002 judging by my posts to Usenet.[[User:4th Cuirassier|4th Cuirassier]] 06:04, 11 January 2011 (EST)

== Names etc ==

I tag each aquanaut's name with which batch of recruits he was part of. All aquanauts recruited before the first mission are batch 1. It is unusual for more than 1 or 2 of these to survive to the end of the game.

The list of names that I am currently drawing on is as follows:

Adam Bomm,
Adam Zappel,
Al Beano,
Andy Freese,
Art Major,
Barry Cade,
Beau Tye,
Ben Dover,
Biff Wellington,
Bill Board,
Chris P. Bacon,
Cliff Topp,
Cory Ander,
Craven Moorehead,
Dan D. Lyons,
Dan Druff,
Dan Saul Knight,
Dick Burns,
Dick Hertz,
Don Key,
Doug Graves,
Doug Hole,
Doug Witherspoon,
Duane Pipe,
Dusty Rhodes,
Earl Lee Riser,
Easton West,
Evan Keel,
Gene Poole,
Gerry Bilder,
Ginger Rayell,
Herb Alti,
Howie Doohan,
Hugh Jass,
Hugh Jorgan,
Ivor Nereckschun,
Jack Gough,
Jack Haas,
Jack Hammer,
Jack Knoff,
Jed Dye,
Jerry Atrick,
Jim Shorts,
Joe Kerr,
Justin Case,
Justin Casey-Howells,
Kerry Siehn,
Kent C. Strait,
Lance Boyle,
Lee King,
Les Hassall,
Lou Pole,
Luke Warm,
Mark de Cards,
Manny Kinn,
Marshall Law,
Matt Tress,
Mike Hunt,
Mike Raffone,
Mike Rotch,
Nat Sass,
Neil Down,
Nick O’Time,
Noah Lott,
Oliver Suddon,
Otto Graf,
Owen Bigg,
Owen Cash,
Page Turner,
Parker Carr,
Pat Hiscock,
Pete Moss,
Phil Bowles,
Phil Graves,
Phil Updegrave,
Pierce Deere,
Piers Dorgan,
Ray Gunn,
Rayner Schein,
Rich Feller,
Rick O'Shea,
Rick Shaw,
Robin Banks,
Rocky Rhodes,
Rocky Shaw,
Russell Paper,
Rusty Steele,
Sawyer B. Hind,
Sandy Beech,
Seymour Bush,
Sonny Day,
Stan Still,
Tad Pohl,
Tim Burr,
Tommy Gunn,
Tommy Hawk,
Warren Peace,
Willie Stroker,
Ziggy Retpaper.

[[User:4th Cuirassier|4th Cuirassier]] 10:15, 11 January 2011 (EST)
: Why should I replace one impractical set of names with another. My recruits get their names erased and replaced by one letter coding the base, a serial number(three digits should do) followed by a string of letters coding their expertise in critical stats. When the time comes I add a number at the end showing their MC strength. Sometimes I add plus and minus signs to note good recruits and candidates for sacking/sacrifice, MC weaklings also get a note in their name. A typical name would be ''A 003 TbRfH 85+'' or ''C 096 C --'' or ''F 001 TBRFH -MC''. For the coding letters a use a system similar to that in the FAQ/walkthrough.--[[User:Tauon|Tauon]] 14:58, 11 January 2011 (EST)

== Setting the difficulty level ==

I've added the above section at the top as I have now finally acquired a patched version of the game in which the higher difficulty levels are playable.

I think I have summarised the implications of high / low difficulty but if not please correct, anybody. [[User:4th Cuirassier|4th Cuirassier]] 09:47, 17 January 2011 (EST)

:I think not the effectiveness of the weapons is changed but the aliens simply have more health on higher settings. That results in the observed results.
--[[User:Tauon|Tauon]] 13:31, 17 January 2011 (EST)

:: That may very well be correct, as it would also result in the buggers being harder to kill. Over to you if you wish to correct it.[[User:4th Cuirassier|4th Cuirassier]] 13:52, 17 January 2011 (EST)

:::I seem to recall that the revert-to-beginner bug was only a UFO bug? TFTD never had this, though some players used to complain that it felt like it always reverted to superhuman. I don't think that was that case, but I can't blame them for thinking that way!

:::UFO's [[Difficulty Levels]] page might of some assistance, as TFTD shares a number of its predecessor's traits. Just be mindful that the TFTD Superhuman level multiplier is 6 instead of a 4. The bit about how difficulty alters the severity of what counts as a 'bad' monthly rating backs up the point about it being much harder to keep the countries pleased on higher levels.

::: [[Alien Stats (TFTD)]] shows how difficulty affects the stats. One difference from UFO is how the armour scales up with difficulty. In UFO it just got halved on beginner and was normal the rest of the time. So in addition to more health, they get a bit more damage reduction.

::: There was one other change that difficulty might have, but I can't back it up with anything to prove it is or isn't. Frequency of smaller enemy subs breaking off from combat feels higher on the harder levels. -[[User:NKF|NKF]] 06:26, 18 January 2011 (EST)

:::: Great info which I hadn't found. Maybe we should just link to that. In summary it seems that enemy troops shoot more accurately, as well as being harder to kill. I've noticed smaller subs being harder to intercept too.[[User:4th Cuirassier|4th Cuirassier]] 09:49, 18 January 2011 (EST)

== Battlescape collateral damage ==

Discussing UFO with a mate back in '94, he reckoned that when fighting battles it was inadvisable to blow the bejasus out of the landscape because this made you unpopular with the country you did it in.

Having played the game a lot since then I don't think this is true. The mission score says nothing about points deductions for shooting up the neighborhood. When defending your bases, although it's never happened, I gather that if you do excessive damage to a module it gets deleted from the base map. Are points also deducted in the end of mission summary when this happens? Or is losing a base module its own penalty?[[User:4th Cuirassier|4th Cuirassier]] 13:57, 26 January 2011 (EST)

: Collateral damage is only a problem in X-COM Apocalypse, in UFO and TFTD you can destroy terrain as much as you want.

: For bases, the only loss is the use of the facility - and every other facility that was dependent on that facility to connect them to the access lift/airlock. There are no monetary penalties or loss in area activity points for it.

: Oddly enough, the contents of any of the destroyed facilities will remain intact. So you could get into situations where you have a couple dozen staff with no beds, three ships sharing one hangar or pen, no stores but still having tons of equipment on hand, etc. Aliens in containment will also remain. Research or manufacture projects that were live at the time will have their progress halted. -[[User:NKF|NKF]] 00:36, 27 January 2011 (EST)

== Downing USOs over land ==

Is there any advantage to doing this, assuming you don't need any techs or kit? ISTR that you lose points if you down a submarine and don't retrieve it, but is that "lose" in the sense of "don't gain", or is there an actual game penalty? - meaning it would then be worth ensuring those's no USO wreck you could have retrieved but didn't? [[User:4th Cuirassier|4th Cuirassier]] 15:53, 26 January 2011 (EST)

: Wrecks have no penalty for letting them vanish over time. You have the initial shoot-down score (doubled if the ship was vapourised). Abandoning the wreck just means you forgo whatever you can can normally earn - or lose - from the mission.

: Also TFTD won't let you shoot down enemy subs over land. However I think are a few tricky joins in the map polygons where you can shoot down ships over land. -[[User:NKF|NKF]] 00:46, 27 January 2011 (EST)

:: Thanks for info, you're right - I am probably thinking of U:EU, where you could shoot UFOs down into the sea, including when you didn't want to. [[User:4th Cuirassier|4th Cuirassier]] 08:18, 28 January 2011 (EST)

File:Kill.xls

2012-03-29T23:02:01Z

Jewcifer:

User talk:Jewcifer

2012-03-29T23:00:46Z

Jewcifer: Created page with "== TFTD Weapon-Alien Damage Chart == Attached is an excel spreadsheet that charts the damage each weapon does against each type of alien. It is saved in an older (97-2003) .xls..."

== TFTD Weapon-Alien Damage Chart ==

Attached is an excel spreadsheet that charts the damage each weapon does against each type of alien. It is saved in an older (97-2003) .xls format for better compatibility, but should display conditional color formatting if opened with a recent enough version of excel. There aren't any macros.

There is a separate sheet for each difficulty level. Each sheet has 3 charts. The top chart shows the chance of killing the alien in a single hit (having done no other prior damage). The middle shows the average number of hits it takes to kill the alien with that weapon. The bottom chart just shows the average damage (with a cap to keep numbers reasonable) per hit. The weapons are sectioned into the following groups: HTH (melee weapons), 1H (1-handed pistols), 2H (standard 2-handed weapons), GRN (grenades), and SWS (attacks for Submersible Weapons Systems). Aliens have multiple columns for each direction of attack for which their armor is different. F = Front, S = Left/Right, R = Rear, U = Under. Cells that involve an area-of-effect weapon and a column that does not include under-armor are always left blank, as are those for single-hit weapons and columns for under-armor only. The four ranked alien types (Aquatoid, Gillman, Lobster Man, Tasoth) each have 2 sets of columns, the first set being for the weakest rank, the second for the strongest.

[[File:kill.xls]]

This is simply intended as a quick-reference lookup for judging battle situations and as a guide to facilitate weapon analysis. I make no claims that it is completely accurate, and even if it were, Murphy's Law and the whims of the RNG God mean it shouldn't be relied heavily on. In fact, I am aware of the following issues:
* Some sources have claimed that weapon damage in TFTD throws 2 rolls over the damage range and averages them, instead of just throwing 1 and using that as in EU. I have been unable to determine if this is actually the case or not. Some have argued that this is highly unlikely since the TFTD team made very few changes to the actual game engine, which I am inclined to agree with. So, the well-known EU method is the one I've used to calculate this chart. If anyone knows for sure one way or the other, please let me know as that could substantially affect everything.
* Only direct hits with AOE weapons are considered. There is no effort to provide information for near-hits or blast radius. This is why values are only present for columns including under-armor.
* For AOE weapons against large-size units, damage is only calculated for a single square and the result just multiplied by 4. I believe however that the game does actually calculate damage independently for each square, as I think I have seen a single adjacent grenade cause a reduction to both the under-armor and directional-armor of a tank. Again, if anyone knows for sure, please let me know. However, the difference is pretty much negligible for this purpose (since only direct-hits are considered).
* None of these values take into account the additional stun damage that is also inflicted on a damaging hit by a lethal weapon. I believe it is well-known and documented how this works, so perhaps at some point I will update the chart to reflect it. For now, this means is that dropping (but not necessarily killing) an alien is about ~12% easier than all data shows.
* The hits-to-kill chart does not take into account armor reduction from successful hits. This will slightly overestimate the larger values.
* I have checked and rechecked most of the data entry and calculations multiple times, but there still may be errors, mistakes, or typos. If anyone actually looks at this and finds any, please point them out.
* There may very well be other things I haven't thought of at all. Please, mention anything you can think of!

Yes, I know, if I spent half as much time playing this game as I do analyzing it, I might actually be decent at it...

Talk:Base Defence Systems

2012-03-29T15:36:41Z

Jewcifer: /* Penetration Math */

I added some info about TFTD to the article since it talks about TFTD too. I noticed though that some of the info conflicts with [[Base_Defense (TFTD)]] article. e.g. here it says the item limit has been raised to 110, there it says the limit is still 80. Anyhow, I can verify there's a sorting algorithm from my experience, but not much further. I wonder if it may end up preferring unresearched guns for example.. [[User:Cesium|Cesium]] 20:02, 30 December 2009 (EST)
:Hadn't realized that there was a page for TFTD. I just corrected it to 110 (this number is actually from the Unofficial Strategy Guide but from what I recall it is correct). About the sorting algorithm I can't confirm it. [[User:Hobbes|Hobbes]] 20:40, 30 December 2009 (EST)
::I just ordered a lot of Jet Harpoons, Dart Guns and Chemical Flares to a base and let the aliens find it. The equipment available in the load screen was mainly Sonic Rifles and Sonic Cannons. The Darts, Jets and Flares were not available. Something has to account for the quartermaster being sane, and we do know some attention was given to base defense (since the item limit was raised). I guess only way to be sure is for someone to disassemble the executable and examine the code.... [[User:Cesium|Cesium]] 09:35, 31 December 2009 (EST)
:::Well the quartermaster is mostly sane. However it does not check if you have researched the clip before it packs the shiny new Sonics. So be sure to move them out if you have not or you might end up with lots of guns without ammo. If you want Medikits be sure to reduce the number of spare weapons--[[User:Tauon|Tauon]] 19:32, 16 October 2010 (EDT)
Not sure the 110 number for TFTD is technically correct. When I try to load more than 80 items on a craft I still get a warning. --[[User:Zombie|Zombie]] 22:31, 30 December 2009 (EST)
:The limit for weapons being carried in craft is still 80 but for the base defense missions the game allows for 110 items. [[User:Hobbes|Hobbes]] 22:56, 30 December 2009 (EST)

== Penetration Math ==

"...Missile/Torpedo Defences are the most cost-effective of the defensive base facilities. The odds of penetrating 12 such modules and a Grav/Bombardment Shield are 30 to 1. On average, 30 attack ships will be destroyed before one gets through. Such a system costs $3.7 million. For the same price, 3 Fusion Ball/P.W.T. Defences with a Grav/Bombardment Shield will offer only 9 to 1 protection..."

Huh? Where is this math coming from? From the way I understand it, it's a simple binomial distribution (at least for exclusively one type of base defense module).

In order to bring down a battleship (3200 hits) you need to connect 7 rounds from a missile defense (500 damage). With 12 missile defenses and a grav shield, you have 24 bernoulli trials with a 50% probability of success. The probability of 6 successes or fewer out of 24 trials at 50% I believe is ~0.01133, or 1 out of about 88 ships getting through your defenses. I calculated this in excel via =BINOM.DIST(6,24,0.5,TRUE) so I am confident it is correct.

In the fusion ball case, I believe it is 2 or fewer successes out of 6 trials with 80% probability, =BINOM.DIST(2,6,0.8,TRUE), 0.01696, or 1 out of about 59 ships getting through.

While the original point still stands with my math (missile is more cost effective than fusion), the odds of penetrating either setup are greatly reduced, as is the difference between the performance of the two. Perhaps I do not properly understand the mechanics of base defense modules, or screwed up my thinking or math somewhere along the way.

--[[User:Jewcifer|Jewcifer]] 12:57, 16 March 2012 (EDT)

:I'm not sure if the page mentions it (I've only got time for a quick skim right now), but to further complicate matters the amount of damage the defences do per-shot is randomised. I think it goes from about 50% to 150% of their rated power, can't remember if I was ever able to confirm an exact range. Seven shots from a missile defence may not be enough to down a battleship. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 17:39, 16 March 2012 (EDT)

::Hmmm, I have seen no mention of variable damage either in-game or anywhere on this wiki (I've been reading through it quite extensively for months before finally getting around to signing up a couple days ago). I think that information should be determined and put somewhere (this article is probably as good a place as any for it). I'm not likely to do that myself (would probably require either extensive simulation or disassembling and hunting through the executable code to determine the range?), but if anyone else does I will run the different calculations appropriately. If the range is 50%-150% it should be only slightly more likely for ships to penetrate in these cases (but not nearly enough to account for the discrepancy), but perhaps if the range is more like 50%-100% (like craft weapons) they would match up with what's in the article. --[[User:Jewcifer|Jewcifer]] 12:24, 21 March 2012 (EDT)
:::I am 100% sure that damage to UFOs from base defences is variable. I have seen Battleships both die and not die from 2 hits with a Fusion Ball Defence while I was using the Battleship Farming exploit. [[User:Magic9mushroom|Magic9mushroom]] 18:19, 21 March 2012 (EDT)

:::Indeed, a defense module may deal more then 100% of its rated damage. I've seen two fusion ball shots take out a battleship, and I've seen some require four - the vast majority drop after three. This "proves" a minimum range of 66%-133% (the damage averages required to achieve 2-4 hit take-downs), which strongly suggests the actual range is 50%-150%.

:::Much of the information on this wiki is written off the top of someone's head, especially articles like this one that deal less in hard statistics and more on handing out strategies and tactics (it doesn't even mention how much damage needs to be done to shoot down a battleship!). Many such errors are only corrected when newcomers come along and spot them. There are plenty there, though, so don't be afraid to question anything you see or correct anything you are certain to be wrong. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 04:42, 22 March 2012 (EDT)

::::Thanks guys. Initially I tried to work out a mathematical approach using the probability density function of an irwin–hall distribution, but dealing with variable n due to the accuracy aspect made it way too complicated and confusing for me to handle. Yikes.
::::So I did what any sensible programmer would do and wrote a quick script to run monte carlo simulations of x-com base defense. I ran 1,500,000 simulations of both of the above scenarios for damage ranges of 100%-100%, 50%-100%, 50%-150%, and 0%-200% (using a discrete uniform distribution within the range). The output is the damage range formula used, the base defense setup (i.e. number of shots, damage, and accuracy), and the average number of attacking ships needed for one to get through:
100%-100%
24 shots, 500 damage, 50% accuracy:
89.46 ships
6 shots, 1200 damage, 80% accuracy:
59.12 ships

50%-100%
24 shots, 500 damage, 50% accuracy:
11.63 ships
6 shots, 1200 damage, 80% accuracy:
07.88 ships

50%-150%
24 shots, 500 damage, 50% accuracy:
67.75 ships
6 shots, 1200 damage, 80% accuracy:
25.19 ships

0%-200%
24 shots, 500 damage, 50% accuracy:
31.32 ships
6 shots, 1200 damage, 80% accuracy:
10.86 ships
::::Nicely enough, the 100%-100% numbers (fixed damage) match my earlier calculations reasonably well, and it seems the 0%-200% numbers are very close to what is in the article! So I think unless someone verifies or is already quite confident the damage range is something other than 0 to double, or maybe has some non-uniform distribution, I'll leave it alone.
::::I do think this article should mention somewhere that the damage is a variable range. Perhaps go ahead and say 0%-200%, with a note that this maybe should be verified?
::::Thanks again for the replies!
::::--[[User:Jewcifer|Jewcifer]] 11:36, 29 March 2012 (EDT)

Talk:Base Defence Systems

2012-03-21T16:24:42Z

Jewcifer: /* Penetration Math */

Talk:Known Bugs

2012-03-21T16:08:50Z

Jewcifer: /* Paying for Dirt in TFTD */

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

= Specific Bug Discussions =

== Misc Technical Bug ? ==

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

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

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

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

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

- [[User:NKF|NKF]]

-----

== "Invisible Muton" bug ==

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

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

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

-----

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

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

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

- [[User:Bomb_Bloke|Bomb Bloke]]

----

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

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

----

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

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

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

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

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

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

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

- [[User:NKF|NKF]]

----

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

----

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

- by tequilachef (April 4th 2007)

== Vanishing snakemen ==

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

---

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

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

- By tequilachef (April 4th, 2007)

== Blaster Bomb Bug ==

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

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

== Disappearing Ammunition ==

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

------

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

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

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

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

==MC at end = MIA?==

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

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

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

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

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

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

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

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

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

----

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

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

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

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

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

- By tequilachef (April 4th, 2007)

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

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

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

: -[[User:NKF|NKF]]

== Crash Site in the atlantic ocean ==

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

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

- UFO: battleship, floater, alien harvest

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

- Date: January 2000

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

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

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

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

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

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

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

== Inconsistencies in MCing Cyberdiscs and Sectopods ==

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

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

:- [[User:NKF|NKF]]

== Facility Dismantle Bug ==

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

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

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

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

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

== Manufacturing Limit Bug ==

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

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

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

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

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

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

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

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

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

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

----

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

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

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

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

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

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

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

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

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

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

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

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

== Unconscious Enemy in Equipment Screen ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--------

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

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

== Soldiers moved to outside of combat screen ==

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

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

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

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

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

==Great Circle Route==

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

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

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

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

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

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

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

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

-----

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

-----

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

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

-----

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

----

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

-----

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

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

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

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

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

== Soldier Recruiting Bugs Tested ==

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

==Floater Medic Bug==

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

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

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

==Strength Overflow==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Sources for a DOS4GW transplant ==

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

== Phantom Carried Casualty ==

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

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

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

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

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

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

==Elerium Base Bug==

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

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

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

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

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

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

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

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

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

See Also [[Talk:Displacer/PWT]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Wish List (TFTD)

2012-03-21T16:04:50Z

Jewcifer: /* New Features */

Suggestions for fixes or improvements that would be nice to have for X-COM: Terror From The Deep (TFTD). ''Since TFTD shares its game engine with X-COM: Enemy Unknown (EU), there are many problems that are common to both games. Please make any shared/common wishes under the EU Wish List (link at the bottom of this page).''

= Fixes =

== Geoscape ==

* Research Tree bugs
* The really annoying "Cannot intercept over land" message that pops up continually (more than once a second) during some pursuits along coastlines.
* Coelacanth\Gauss reload issues. [[User:Tifi|Tifi]] 16:31, 16 December 2009 (EST)
* The interception routes seem really broken in TFTD, usually taking a longer path than I can do by manually creating waypoints. (This might exist in EU, too, but not be as noticeable because of the geography.)

== Battlescape ==

* Underwater-only weapons reaction-firing on land
* Bio-Drone melee attack has no effect. This is a serious flaw in the Bio-Drone, as it always uses this attack when Aquanauts are adjacent.
* Bugs with MC at the end of one stage of a multi-stage mission. (Does this also affect EU, e.g. the 2-stage Cydonia mission?)
* Permit aliens to use carried melee weapons. (This is a game engine bug that applies to EU as well, but is moot since EU aliens don't have carried melee weapons.) This fix could inadvertently make the game easier, as aliens would use Sonic Pulsers (their default option since they can't use melee weapons) less often. So it is essential to ensure the AI chooses sensibly between drills and Pulsers.
* Make ship terror missions less annoying, especially the passenger ship. Aliens hide in labyrinthine structures and every single spot needs to be revisited if a single alien is left out, otherwise the mission is failed. Often over 100 turns are needed to win, as aquanauts quickly run out of energy and finding the last cowardly tasoth is a pain.
* The above also applies to other missions, namely the 2nd stages of alien colony assaults and artifact sites, but both can, fortunately, be won without killing all the aliens.
: Specific suggestion as to how to do this please? For example, reveal last 1-2 alien positions after XX turns, or (EU style), force all aliens to go on the offensive after XX turns (probably not as this is too easy). [[User:Spike|Spike]]
:: Easiest method would be to edit the map modules ("lock" some doors) and route node tables to remove the hidey holes. Heck, just messing with the nodes might be enough to do it - for example, at least one actually allows for large units to spawn in a tiny cabin where they can't move ''at all''. Assuming you find it, you've then got to deal with reaction fire from a critter that will always have maximum TUs on your turn... Stupid Xarquids... [[User:Bomb_Bloke|Bomb Bloke]]
::: In my view, the problems lies in the fact that the last terrified alien simply picks a hiding spot and remains there until you find it. Aliens should be more active, more aggressive. It's not a matter of game balance or difficulty, but playability. [[User:mingos|mingos]]
:::: Good point, there are at least 2 cases: aliens with failed morale, and aliens stuck in the map. For aliens with failed morale, the game should just end with them as prisoners (if they have no built in weapons and no chance of regaining morale). But for aliens stuck in the map by walls or waypoints or whatever, as Bomb Bloke said above, more measures are called for. [[User:Spike|Spike]] 20:42, 12 December 2009 (EST)
::::: I'm not sure it has anything to do with morale. After a few turns they'd've recovered from any "frights" they had (assuming they didn't drop their guns, but seeing as it's often [[Tentaculat]]s which go "missing" I doubt that has much affect on matters). I think the route nodes just send them on one way trips into certain out-of-the-way areas. The aggression stat ([[UNITREF.DAT|unitref(44 / 2C)]]) might actually be the way to go - the theory is that pumping this higher makes a creature more likely to leave cover and attack your agents head on. [[Alien Stats (TFTD)|By default]] most aliens already have it "maxed out", but for all I know the value can be cranked higher then the observed cap of 2. - [[User:Bomb Bloke|Bomb Bloke]] 00:59, 13 December 2009 (EST)
:::::: Same happens to me with other races too. Bio Drones and Tasoths seem to do the same quite often. While Tasoths are probably shaken up and disarmed, entaculats and Bio Drones have their weapons inbuilt, plus, they rarely panic. Not long ago I saw a Bio Drone fire from cover each turn, then hide again, and after I started looking for it, it simply picked a hiding spot and stayed there for ~20 turns until I found it and zapped it. The funny thing was that it was the beginning of the mission and there were only 2 or 3 aliens killed so far. [[User:mingos|mingos]]
::::::: OK the aggression stat sounds a good option for all this hidey behaviour. A 100 turns to finish a game is incredibly frustrating. In EU, you could Seb76's UFO Extender to make the remaining aliens visible. With TFTD, you have the option of using the '''xcomutil dis''' command to get the coordinates of the remaining aliens. There might also be an xcomutil command to make all units visible. And if all else fails you can use the '''xcomutil win''' command to kill the last aliens off. [[User:Spike|Spike]] 09:31, 13 December 2009 (EST)
* Aquanaut strength overflow often prevents highly skilled soldiers from throwing items, as they become strong enough to arc an object above the highest battlescape level (and 'out of bounds') thus generating a 'Cannot Throw Here' message. [[User:Tifi|Tifi]] 16:29, 16 December 2009 (EST)
:I think there might be 2 issues here involved: first one is the fact that when the stats overcome their limit they are reset to 0 by the game; second is that due to height limits the game will not allow for objects to be thrown at some distances because the throwing arc would go over the height limit. [[User:Hobbes|Hobbes]] 12:01, 17 December 2009 (EST)
* Synchronized attacks. Like the waypoint setting for launchers, several aquanauts could target different enemies, and all of them would shoot at the same time. It would not be possible to follow all the trajectories on screen simultaneously, so it should probably focus on one target at a time, or show each shot individually. This would give beginners a chance against e.g. [[Bio-Drone]].

= New Features =

* Airborne Interception - what's the point of flying subs without air to-air weapons anyway?(Avalanches anyone?) Surely it's better to 'splash' the USO ''before'' it makes it to the safety of water?
*Alternatively, get rid of the pretense that subs can fly. How does sonar track a USO over land, anyway?
:Both sonar and radar use the same principle (radio or sound waves being emitted and reflected back to a receiver) so it isn't unconceivable to have equipment that can use both detection methods. [[User:Hobbes|Hobbes]] 22:35, 12 December 2009 (EST)
::Hmm. Steam engines and internal combustion engines are pretty similar too but you rarely see both on the same vehicle! The sensors in TFTD are called sonars, not sonar/radar combinations. I would be quite happy if the names were just changed from Sonar to Sonar/Radar or to Sensor, that would be fine. It is possible to use something very similar to passive sonar to track bearings to aircraft, similar things were used in WWII before the development of radar. Without triangulation, it would be very difficult to get the actual range to the target, and almost impossible to get the target's heading and speed. It is very normal for modern subs and surface ships to have both sonar and radar, but they are totally separate systems aboard the vessel, with different capabilities. I would be fine if the name was changed to Sensor or Sonar/Radar, and the UFOPaedia description changed to say that it used both technologies. Mainly I just object to the flying subs not being able to intercept over land. You can see why though, since it would pose the question of why there were no land USO recovery missions. But you could just take the same approach as EU. Just as UFOs disintegrate if shot down over water, USOs could disintegrate if shot down over land. Or even better, the land/sea game below, allowing land recovery vs USOs and underwater recovery vs UFOs. [[User:Spike|Spike]] 09:22, 13 December 2009 (EST)
::: UFOs didn't disintegrate in water - it was just the Elerium (and presumably the crew!). After the aliens were beaten, X-COM's new job essentially boiled down to finding those drowned ships and scavenging whatever was left. - [[User:Bomb Bloke|Bomb Bloke]] 21:09, 13 December 2009 (EST)
:::: Game-wise, they did disintegrate. The whole story about SORESO and elerium recovery was made up later in order to give a meaning to the subsequent games. [[User:mingos|mingos]]
* Bind equipment set to Aquanaut, so not to pick it every single time.
:This can already be done using XcomUtil.
* Add mortar (acting both on land and underwater).
: A mortar would be very advantageous to X-Com, since a lot of the tactical difficulty in the map is aliens hiding behind obstacles to direct fire. This is what grenades and Pulsers are for of course. An indirect fire weapon seems kind of 'realistic' but I'm not sure helping X-Com kill aliens is good for the game balance. [[User:Spike|Spike]] 09:22, 13 December 2009 (EST)
* Add Ion weapons (They have Ion Beam Accelerators, right?). So why not make them smaller, more compact, and fire faster (if not weaker) shots?
: From the description of Gauss weapons, they sound similar to an Ion weapon of some kind. But yes in general maybe the discovery of IBAs could help the humans develop some weapon and not just armour/mobility technology. But then, the aliens don't seem to have a weapon based on Ions. Though some of the creatures (BioDrone, Xarquid) do have particle-type weapons. Maybe X-COM could design a new weapon based on these principles. Does the game really need new weapons though? [[User:Spike|Spike]] 09:22, 13 December 2009 (EST)
*Allow aquanauts to see through the view ports of their subs (at least the Triton has several black openings which I presume to be view ports). Don't know if this is possible, engine-wise, but would be highly useful as you would be able to take in your surroundings without having to expose your troops to enemy fire by opening the door. --[[User:Safe-Keeper|Safe-Keeper]] 12:02, 30 May 2010 (EDT)
:Possibly this can already be done using [[XcomUtil]], check it out. [[User:Spike|Spike]] 13:59, 6 June 2010 (EDT)
* 3D water movement: allow Aquanauts in ''any'' armour type (including "none") to move up or down in water. Almost as if they were suspended in some kind of buoyant fluid... This would probably also need to be applied to SWS units and to all aliens. The flags exist in the game files. One question would be whether alien AI would properly take advantage of the vertical movement. If not, it could be unbalancing. Unarmoured Aquanauts would still probably want to keep low to avoid being easy targets. But at least the option would exist. Mag-Ion Armour would then need some compensating factor, such as an increased movement rate under water. Or it could just be left as is, a slightly more powerful type of armour that opens up Sub Construction.
* Combined land/sea game, with subs and aircraft, USOs and UFOs, Aquanauts and Soldiers, land and sea bases. Now that would be cool!
**A slightly less dramatic change: on any land mission, automatically swap Dart Guns, Jet Harpoons, HydroJet Cannons and Torpedo Launchers for (respectively) Pistols, Rifles, AutoCannon and Rocket Launchers "from stores" (including their ammo of course). Purchase price of the weapons would be doubled (or just add the cost of the XCOM-EU equivalent) to reflect this versatility.
:Essentially the game would switch icons and elements of OBJECT.DAT for a land mission. Could also switch Grenade types perhaps? But it's best to keep some underwater weapons (eg Gas Cannon), especially for land missions where there is some water present. Conceivably, in recognition of the progress made by X-COM, and the increasing threat, the authorities might even make available some of the scarce (?) stocks of laser weapons, to exchange for Gauss weapons during land missions. (But this is not really necessary, as Gauss weapons are quite adequate on land.) Working plasma weapons of course have long since vanished due to lack of Elerium. (Although by the same argument, 1st Alien War-era Personal Armour should be issued to any unarmoured troops on land missions. Maybe it takes 200% damage from Sonic weapons.)
*Variant on this - allow 1st Alien War equipment to be purchased or leased by X-COM, for a quite high price, to be used on land missions only. Mainly laser weapons and armour. [[User:Spike|Spike]] 09:22, 13 December 2009 (EST)
:The direction that this suggestion is heading seems to point to merge the systems of both games. One idea to do so could be that both types of modules (Sonar and Radar) could be built at X-COM bases. Each of them would only detect USOs/UFOs either underwater or airborne. That would represent a strain on X-COM resources since the player would have to choose which ones to build at each base. Just having one type of system at a base would limit detection and tracking, which would also add another challenge.
:Concerning Subs intercepting USOs over land another interesting change could be that the subs' armaments could also be of limited use while on air, just like the ground battles. Torpedo weapons would be impossible to use on the air (Ajax, DUP and PWT) which would limit the weapons to Gas and Gauss Cannons. Based on the criteria of the ground weapons the Sonic Oscillator could also be used but I'd drop the power of it to 50 so that the TFTD Battleships (equivalent to Terror Ships) could have also a change to strike back at X-COM craft. Another possibility would be prevent the Oscillator from being used on air (the logic would that the sound waves dissipate as the range goes higher) which would present another challenge to the player since he/she would have to make choices concerning how to equip the subs, since it would only be possible to hit airborne USOs with Gas and Gauss Cannons. [[User:Hobbes|Hobbes]] 13:09, 13 December 2009 (EST)
::I like these ideas. I wonder if we should split off a different section or page on combined land/sea EU/TFTD? It would make an awesome game. If a game company was working on a remake of X-COM, it would be great to make an EU/TFTD hybrid from the start. It would be reminiscent of the UFO TV series that was probably one of the inspirations for X-COM.
::In the realm of possibility for player mods might be a game that combines sea and land bases on the same geoscape map, with USOs and UFOs flying around, crash sites on land or underwater depending on the location of the crash, and land (EU) or sea (TFTD) loadouts depending on the crash location. Terror sites and other land sites would probably use EU loadouts? MC and Psi would need to be merged into the same phenomenon, probably. That wouldn't be too hard since under the skin it's the same thing. This could be as simple as calling the EU battlescape for land missions and the TFTD battlescape for undersea missions. Of course the Geoscape changes would be trickier. Only one political map could be used at one time. But possibly you could play first with an EU geoscape, EU political map, and EU victory conditions, and then play again with TFTD geoscape/map/victory conditions. The only difference in the geoscape .exe would be to permit bases and interceptions over sea (in EU) and land (in TFTD). Opening the base screen of a land base in TFTD might requiring calling a patched module from EU, and vice versa. Tech research would need to follow the geoscape (EU or TFTD), unless a way was found to combine the research trees of both games. But I doubt that is possible in a player mod because there is only room for one set of technologies in things like the object table. So basically researching lasers would give you gauss, and vice versa, across the board. Researching each EU technology would give its TFTD equivalent and vice versa. This would be OK I think. [[User:Spike|Spike]] 18:22, 13 December 2009 (EST)
:::I was thinking more of the TFTD plotline rather than EU's when making this suggestion. USO's don't appear on EU nor could their appearance be explained by the plotline. But the opposite would fit TFTD rather nicely. TFTD's political map could be expanded to land and additional cities would have to be placed. Terror attacks on inland cities would be different than the Port attacks on costal cities. Alien land colonies could also be a possibility but plot like they wouldn't make much sense (unless the aliens were preparing to flood the colonies areas. [[User:Hobbes|Hobbes]] 18:53, 13 December 2009 (EST)
::::I did actually [http://www.strategycore.co.uk/forums/UFO-TFTD-Combo-Mod-t7367.html make a start] towards such a game, but sorta lost interest due to the usual lack of testers and the limitations the TFTD engine enforces. If/when I get around to resuming work on it I'll probably be restarting under the UFO engine instead. - [[User:Bomb Bloke|Bomb Bloke]] 21:09, 13 December 2009 (EST)
:::::IIRC the UFO engine has even more limitations than the TFTD one. I've read the post and although a full merger of both games sounds better, why not stick to making TFTD the way I described above? [[User:Hobbes|Hobbes]] 10:39, 14 December 2009 (EST)
::::::Granted, TFTD allows for larger maps, has native support for things like underwater palettes, lets you open doors without going through them, plus a few other minor features. But other then that? Certain weapons/HWPs don't work in certain missions, nor do your flying suits. USOs have a habit of going "airbourne" (even when over a valid geoscape polygon!), preventing you from intercepting them, and seldom fly over "land" even if you have bases there. The tech tree has more constraints slapped on it then I care to count, and running the CE version of the game with a split executable makes it crash all the time.

::::::Sure, most - if not all - of this stuff could be dealt with by messing with the executable, but with my current skills ("basic understanding of how machine code is read with no practical knowledge of opcodes at all") it's easier for me to just do it in UFO using external code (executable hacks can only realistically be applied to one version of the game anyway). Ditto for the concepts you described. Heck, even porting TFTD's plot to UFO's engine wouldn't be much of a challenge in comparison; other then the drills, cruise ships and artifact sites it'd be fairly straightforward to do, because everything else is the same thing under a different name!

::::::On the other hand, if anyone ever comes out with a suitably hacked TFTD executable, I'd be happy to help provide whatever else was needed to make a playable game out of it. - [[User:Bomb Bloke|Bomb Bloke]] 19:39, 14 December 2009 (EST)

:::::::Fair enough :) [[User:Hobbes|Hobbes]] 20:17, 14 December 2009 (EST)
* Make Gauss useful?
: Explain? Gauss weapons are pretty useful. A big improvement on the starting weapons. Make them "more" useful? The XComUtil variant of Heavy Gauss is more useful, it packs quite a punch. Specific proposals please? [[User:Spike|Spike]] 09:22, 13 December 2009 (EST)
:: I agree. Gauss weapons are useful against most aliens, at least on an easy difficulty level. My aquanauts all use Gauss Rifles and the shots needed to down aliens are:
Alien Gauss Rifle hits
Aquatoid 1
Gill Man 1-2
Tasoth 3-5
Lobster Man ~10
Deep One 1
Calcinite 2
Xarquid 4-6
Hallucinoid 2-4
Tentaculat 2-3
Bio-Drone 2-4
Triscene immune
::As you can see, Gauss Rifles are useful and quite powerful. Plus, they offer autofire. The only pain in the butt are Lobster Men, which are near immune, and Triscenes which appear to be totally immune. But these are resistant to pretty much anything anyway, save for grenades in case of Triscenes, and drills in case of Lobster Men. So, uh... what's wrong with Gauss? [[User:mingos|mingos]]
:::Agreed - well demonstrated. Hmm, maybe the point is to make Craft Gauss weapons (Gauss Cannons) more useful? [[User:Spike|Spike]] 18:22, 13 December 2009 (EST)
::::I certainly would not disagree in any particular way that gauss weapons are, in fact, pretty useful early on. Research is very quick up to the rifle, and they are a massive improvement over any starting weapons (well, other than the ultra bad-assery that is the gas cannon). But there's not really much reason to continue carrying them once you have all the sonic weapons researched. On Superhuman the numbers are more like:
Alien Gauss Rifle hits
Aquatoid 1
Gill Man 1-2
Tasoth 5-8
Lobster Man 20-100
Deep One 1
Calcinite 2-3
Xarquid 30-40
Hallucinoid 7-9
Tentaculat 3-8
Bio-Drone 5-9
Triscene immune
::::Making it quite impractical for killing anything beyond Gillmen. (I took the liberty to fill in your Xarquid number for completeness, using Beginner level armor, hope you don't mind!)
::::I don't think there is any doubt that the Heavy Gauss and Craft Gauss Cannon are completely useless. I think the Heavy Gauss would be practical just with a damage boost up to say 120. What does XComUtil do? I wouldn't even know what to recommend for the craft weapon. I'd say all the craft weapons are extremely poorly balanced and would need to be completely reworked to make anything other than DUP and Oscillator worthwhile (I like the very good information/thoughts on this same issue for EU on [[User:Spike#Balancing_Aircraft_Weapons|Spike's Page]]).
::::Now, every single alien takes equal or greater damage from sonic than from gauss. Not only is this sort of unnecessary, since sonic weapons do more damage already, it's kind of flavorless. I would like to see one or two of the terror units have their sonic damage bumped way down and gauss up. Like the Hallucinoid (currently 80 GA / 100 SO) or Bio-Drone (70 GA / 90 SO) to, say, 120 GA / 60 SO. That would just be my personal solution to the original generic 'Make Gauss useful?' --[[User:Jewcifer|Jewcifer]] 12:04, 21 March 2012 (EDT)

= See Also =

[[Wish List (EU)|Wish List (Enemy Unknown)]]

[[Category:Oddities and bugs]]
[[Category:TFTD]]

Talk:Alien Submarines

2012-03-16T19:45:45Z

Jewcifer: /* Crashed/Destroyed Columns */

==Survey Ship and Escort==

From what I can tell, everything in the game, the UFOpaedia entries, the Transmission Resolver data, everything indicates that the one with the two IBAs and the two interior rooms IS the Survey Ship. That USO is more easily shot down/destroyed, comes with only one alien, and the UFOpaedia entry for the Survey Ship matches its design (the two windows being separated over a wider flat portion). The Escort is the one with only one IBA and no internal rooms. These aren't so easily destroyed, come with 4+ aliens and have the windows close together and sloping sides, like in the Escort UFOpaedia entry.

I intend to fix this in the wiki entries unless someone objects. [[User:Magic9mushroom|Magic9mushroom]] 06:19, 20 August 2009 (EDT)

: I object! :) This is believed to be a [[Known Bugs (TFTD)|bug]], the Escort and Survey Ship have been swapped around in the game. [[XcomUtil]] fixes this. The UFOPaedia entries are correct. Maybe make a note of the bug on both wiki pages? [[User:Spike|Spike]] 11:21, 20 August 2009 (EDT)

:: The UFOpaedia entry for Escort matches the picture seen in the interception window when intercepting an "Escort", which matches the smaller design (adjacent portholes, which is listed on here under Survey Ship). The UFOpaedia entry for Survey Ship matches the picture seen in the interception window when intercepting a "Survey Ship", which matches the larger design (separated portholes, which is listed on here under Escort). It's a huge stretch to call it a bug when absolutely everything agrees. The fact of the matter is, a "Survey Ship" within the (unmodified) game for all intents and purposes is the design with the separated portholes and the interior rooms. The entries in this wiki should reflect that. Xcomutil is a separate issue, and while that should be noted on the pages, and the oddity of the situation (Survey Ship bigger than Escort) should also be noted, it hardly makes sense to confuse people coming to the wiki for the first time based on us thinking that a particular feature of the game is unintended. [[User:Magic9mushroom|Magic9mushroom]] 04:13, 21 August 2009 (EDT)

:The interception screen pics might also be swapped. Inteck (from StrategyCore) caught one issue where the Fleet Supply Cruiser and the Battleship pics were swapped in the interception screen. But it should be noted that both interception screens have 2 portals while the real Escort ship map design doesn't even have a single one. Then again, the real Survey Ship's pic is indeed smaller than the real Escort.

:: Actually, you're wrong. The larger ship, which you term the "real" Escort, has 2 portals on the battlescape. They're on either side of the door. This pattern matches the UFOpaedia entry and interception pic for Survey Ship, both of which have two separated portals. The smaller ship, which you term the "real" Survey Ship, has 2 portals right next to each other, which matches the UFOpaedia entry and interception pic of the Escort.

::I actually noticed the Fleet Supply Cruiser/Battleship issue myself. THAT should be noted as a swapping, because the interception and UFOpaedia pic do not match the Battlescape (which is obviously right, because it matches the UFOpaedia text). However, in this case, every in-game source agrees. [[User:Magic9mushroom|Magic9mushroom]] 05:10, 22 August 2009 (EDT)

In my defense, the portals on the larger ship don't look anything like the portals on the smaller ship.--[[User:Zombie|Zombie]] 11:34, 22 August 2009 (EDT)

You're right there. It's because of the different angle. I wasn't faulting you for it. :) [[User:Magic9mushroom|Magic9mushroom]] 04:55, 23 August 2009 (EDT)

:All information points to the fact that the two ship designs were accidentally swapped when they were added to the game. The real survey ship only has 3 spawn points whereas the Escort has 6, not to mention that the real survey ship doesn't have any internal doors while the Escort has 2. Is this intended? I highly doubt it. The designers/programmers had to whack this game out in a short amount of time and a lot of mistakes were made. They were trying to base the USOs off the UFOs from the first game but messed it up. --[[User:Zombie|Zombie]] 09:04, 21 August 2009 (EDT)

:: This is possible. However, the fact that they're swapped everywhere you can possibly look in the (unmodified) game means that we really should discuss the larger, 3-room vessel as the Survey Ship and the smaller, 1-room vessel as the Escort, with probably a note on both pages saying that this is anomalous and could be unintended. [[User:Magic9mushroom|Magic9mushroom]] 05:10, 22 August 2009 (EDT)

:One theory which I came up with a while back is that the map programmers confused the two ships because they look so similar (well, small). It's not that big of a stretch to assume that the person who was responsible for designing the ship layout was not the same person who implemented them in-game, who confused and swapped the two maps, but correctly based the map in the Battlescape against the interception pic in the Geoscape/USOPedia.

:However, just because somethings technically "agree" in-game, there are other glaring inconsistencies which don't agree. The spawn points is one of them and the sheer complexity of the real Escort craft forces a person to really sit down and think about it for a while. Also, look at what happens in the Geoscape: the smaller ship has the correct size class (very small) and the correct sonar blob (which is based off of the class I'd imagine), same goes for the larger ship. In fact, all the stats you would associate with each craft are correct in every respect (weapons, weapon range, speed, etc). But when you go on a mission, the map (and more importantly the size) doesn't reflect the stats in the Geoscape. That's the deciding factor.

:I agree that it should be made more apparent on the two craft pages that there are major discrepancies, but wouldn't go so far as to swap the two articles here just to match some observances in-game. When you boil this all down, it is nothing more than an unfortunate mixup with the maps. It's pretty obvious to me, but I guess to those who do not study the game files or the executable, it's easier to accept the craft are that way intentionally. --[[User:Zombie|Zombie]] 11:34, 22 August 2009 (EDT)

::You have a point. But on the other hand...

::No matter how unintentional it is, the map which comes up when you attack a Survey Ship has the bigger hull. Therefore, it is terribly misleading to put the smaller hull's floor plans in our page about the Survey Ship and the bigger hull's floor plans in our page on Escort. Same for the UFOpaedia/interception pic. Noting that it's screwed up is one thing, but listing things which are not true in-game in a wiki dedicated to it is extremely dodgy. [[User:Magic9mushroom|Magic9mushroom]] 04:55, 23 August 2009 (EDT)

I also have a fix for this up in StrategyCore's [http://www.strategycore.co.uk/files/index.php?dlid=620 files section]. It includes a route fix as well. --[[User:Zombie|Zombie]] 20:16, 20 August 2009 (EDT)

==Terminology==
In-game, these are always referred to as "Alien Submarines" or "Alien Subs", not ever as USOs. We should correct this. Also, the in-game reference is called the UFOpedia, not the USOpaedia. [[User:Magic9mushroom|Magic9mushroom]] 00:54, 15 September 2009 (EDT)

:As I recall, the reason such nomenculture is used is that "USO" is very similar to "UFO", and a fair bit faster and easier to type out than "Alien subs". And while you are correct that the game lists it as a UFOpaedia, remember that TFTD is basically a commercial total-conversion mod of EU. USOpaedia is used to allow a reader to quickly establish that this article or portion thereof refers to TFTD, and '''NOT''' EU.

:It also adjusts to established reading habits; an EU player who starts on TFTD will be easily able to read the TFTD pages without any difficulty due to the use of terms. You'd be surprised how much trouble some people have reinterpreting the same sentence written in a different way. So by using a clear and consistent set of terms, we can avoid those issues...even if it is very slightly inaccurate. [[User:Arrow Quivershaft|Arrow Quivershaft]] 01:30, 15 September 2009 (EDT)

:: It's not official, but many adopted it simply as a spin off "UFO" for convenience. I believe there are also some terminologies we use a lot in UFO that don't necessarily appear in-game.

:: I don't mind either way as long as there is no confusion amongst the readers - the actual sub names are more probably important terminology to keep intact. Actually, that's reminded me of something. Microprose released a set of short stories as teasers for TFTD's release. Not sure if they will have any insight into any of this, but I think they need to be mentioned (or even added) to the Wiki at some stage.

:: To be pedantic, I thought I'd point out that TFTD Americanizes the Ufopaedia into Ufopedia. Most seem to prefer the ae. -[[User:NKF|NKF]] 01:58, 15 September 2009 (EDT)

- I can replace every single instance myself, and would be happy to, so the length is not an issue.

- I had noted that TFTD Americanised the spelling, that is why is it listed as such in my paragraph above.

- The term USO itself is confusing. It confused me. [[User:Magic9mushroom|Magic9mushroom]] 02:47, 15 September 2009 (EDT)

: Well volunteered M9M! I am surprised to discover that USO is not a canonical term. I don't think we should be inventing terms that don't appear in the game. Also, the term USO doesn't occur outside the game (apart from on this website). That is more likely to be confusing to any new people. And they are the ones we should worry about - anyone already reading the site knows what USO means but is not going to be confused by a more specific term like Alien Submarines. It looks like USO is a short-hand and I don't think we should be lazy. My vote is to replace both USO and USOPaedia/USOPedia throughout, as being non-canonical, unhelpful, and confusing to new readers. As an extra question, is SWP canonical or not? [[User:Spike|Spike]] 13:52, 15 September 2009 (EDT)

:: Just had a quick glance at where USO is used, like the navbar, and I don't see it causing any confusion - so go for it. A note on what it means for those who encounter it may be helpful though as it has been in use for so long that many long time players have adopted it even if it's not a canon term. SWP isn't in the game, but SWS is. That's actually encountered in the game text. -[[User:NKF|NKF]] 15:40, 15 September 2009 (EDT)

However, within this wiki SWS is used wrongly a lot of times. It's the equivalent to HWP, not to Tank. Coelacanth is the equivalent to Tank. Hence SWS/Displacer is tautological. [[User:Magic9mushroom|Magic9mushroom]] 22:08, 15 September 2009 (EDT)

So shall I go ahead? [[User:Magic9mushroom|Magic9mushroom]] 11:11, 19 September 2009 (EDT)

:With over two years of lack of response, I decided to just go ahead and do it. The term USO has been excised from this wiki, replaced with Alien Sub. [[User:Magic9mushroom|Magic9mushroom]] 01:31, 5 February 2012 (EST)

== Alien Sub section TO-DO's ==

The sub pages are rich in information about the subs, but we're missing the crew equipment loadouts.

We've got the crews, just not the various possible equipment combinations. An executable dig might reveal this information - just have to recall where this is stored. -[[User:NKF|NKF]] 06:44, 25 February 2011 (EST)

== Crashed/Destroyed Columns ==
These columns were very confusing to me at first, as I thought (due to their position and titles) that they were some measure of the amount of damage you had to inflict to either down or kill the sub. I did not figure it out until I went to [[UFOs]] and saw the different column names. I think the column names should be changed here, or have a clarifying comment below the table. --[[User:Jewcifer|Jewcifer]] 15:40, 16 March 2012 (EDT)

Talk:Alien Submarines

2012-03-16T19:45:23Z

Jewcifer: /* Crashed/Destroyed Columns */

==Survey Ship and Escort==

From what I can tell, everything in the game, the UFOpaedia entries, the Transmission Resolver data, everything indicates that the one with the two IBAs and the two interior rooms IS the Survey Ship. That USO is more easily shot down/destroyed, comes with only one alien, and the UFOpaedia entry for the Survey Ship matches its design (the two windows being separated over a wider flat portion). The Escort is the one with only one IBA and no internal rooms. These aren't so easily destroyed, come with 4+ aliens and have the windows close together and sloping sides, like in the Escort UFOpaedia entry.

I intend to fix this in the wiki entries unless someone objects. [[User:Magic9mushroom|Magic9mushroom]] 06:19, 20 August 2009 (EDT)

: I object! :) This is believed to be a [[Known Bugs (TFTD)|bug]], the Escort and Survey Ship have been swapped around in the game. [[XcomUtil]] fixes this. The UFOPaedia entries are correct. Maybe make a note of the bug on both wiki pages? [[User:Spike|Spike]] 11:21, 20 August 2009 (EDT)

:: The UFOpaedia entry for Escort matches the picture seen in the interception window when intercepting an "Escort", which matches the smaller design (adjacent portholes, which is listed on here under Survey Ship). The UFOpaedia entry for Survey Ship matches the picture seen in the interception window when intercepting a "Survey Ship", which matches the larger design (separated portholes, which is listed on here under Escort). It's a huge stretch to call it a bug when absolutely everything agrees. The fact of the matter is, a "Survey Ship" within the (unmodified) game for all intents and purposes is the design with the separated portholes and the interior rooms. The entries in this wiki should reflect that. Xcomutil is a separate issue, and while that should be noted on the pages, and the oddity of the situation (Survey Ship bigger than Escort) should also be noted, it hardly makes sense to confuse people coming to the wiki for the first time based on us thinking that a particular feature of the game is unintended. [[User:Magic9mushroom|Magic9mushroom]] 04:13, 21 August 2009 (EDT)

:The interception screen pics might also be swapped. Inteck (from StrategyCore) caught one issue where the Fleet Supply Cruiser and the Battleship pics were swapped in the interception screen. But it should be noted that both interception screens have 2 portals while the real Escort ship map design doesn't even have a single one. Then again, the real Survey Ship's pic is indeed smaller than the real Escort.

:: Actually, you're wrong. The larger ship, which you term the "real" Escort, has 2 portals on the battlescape. They're on either side of the door. This pattern matches the UFOpaedia entry and interception pic for Survey Ship, both of which have two separated portals. The smaller ship, which you term the "real" Survey Ship, has 2 portals right next to each other, which matches the UFOpaedia entry and interception pic of the Escort.

::I actually noticed the Fleet Supply Cruiser/Battleship issue myself. THAT should be noted as a swapping, because the interception and UFOpaedia pic do not match the Battlescape (which is obviously right, because it matches the UFOpaedia text). However, in this case, every in-game source agrees. [[User:Magic9mushroom|Magic9mushroom]] 05:10, 22 August 2009 (EDT)

In my defense, the portals on the larger ship don't look anything like the portals on the smaller ship.--[[User:Zombie|Zombie]] 11:34, 22 August 2009 (EDT)

You're right there. It's because of the different angle. I wasn't faulting you for it. :) [[User:Magic9mushroom|Magic9mushroom]] 04:55, 23 August 2009 (EDT)

:All information points to the fact that the two ship designs were accidentally swapped when they were added to the game. The real survey ship only has 3 spawn points whereas the Escort has 6, not to mention that the real survey ship doesn't have any internal doors while the Escort has 2. Is this intended? I highly doubt it. The designers/programmers had to whack this game out in a short amount of time and a lot of mistakes were made. They were trying to base the USOs off the UFOs from the first game but messed it up. --[[User:Zombie|Zombie]] 09:04, 21 August 2009 (EDT)

:: This is possible. However, the fact that they're swapped everywhere you can possibly look in the (unmodified) game means that we really should discuss the larger, 3-room vessel as the Survey Ship and the smaller, 1-room vessel as the Escort, with probably a note on both pages saying that this is anomalous and could be unintended. [[User:Magic9mushroom|Magic9mushroom]] 05:10, 22 August 2009 (EDT)

:One theory which I came up with a while back is that the map programmers confused the two ships because they look so similar (well, small). It's not that big of a stretch to assume that the person who was responsible for designing the ship layout was not the same person who implemented them in-game, who confused and swapped the two maps, but correctly based the map in the Battlescape against the interception pic in the Geoscape/USOPedia.

:However, just because somethings technically "agree" in-game, there are other glaring inconsistencies which don't agree. The spawn points is one of them and the sheer complexity of the real Escort craft forces a person to really sit down and think about it for a while. Also, look at what happens in the Geoscape: the smaller ship has the correct size class (very small) and the correct sonar blob (which is based off of the class I'd imagine), same goes for the larger ship. In fact, all the stats you would associate with each craft are correct in every respect (weapons, weapon range, speed, etc). But when you go on a mission, the map (and more importantly the size) doesn't reflect the stats in the Geoscape. That's the deciding factor.

:I agree that it should be made more apparent on the two craft pages that there are major discrepancies, but wouldn't go so far as to swap the two articles here just to match some observances in-game. When you boil this all down, it is nothing more than an unfortunate mixup with the maps. It's pretty obvious to me, but I guess to those who do not study the game files or the executable, it's easier to accept the craft are that way intentionally. --[[User:Zombie|Zombie]] 11:34, 22 August 2009 (EDT)

::You have a point. But on the other hand...

::No matter how unintentional it is, the map which comes up when you attack a Survey Ship has the bigger hull. Therefore, it is terribly misleading to put the smaller hull's floor plans in our page about the Survey Ship and the bigger hull's floor plans in our page on Escort. Same for the UFOpaedia/interception pic. Noting that it's screwed up is one thing, but listing things which are not true in-game in a wiki dedicated to it is extremely dodgy. [[User:Magic9mushroom|Magic9mushroom]] 04:55, 23 August 2009 (EDT)

I also have a fix for this up in StrategyCore's [http://www.strategycore.co.uk/files/index.php?dlid=620 files section]. It includes a route fix as well. --[[User:Zombie|Zombie]] 20:16, 20 August 2009 (EDT)

==Terminology==
In-game, these are always referred to as "Alien Submarines" or "Alien Subs", not ever as USOs. We should correct this. Also, the in-game reference is called the UFOpedia, not the USOpaedia. [[User:Magic9mushroom|Magic9mushroom]] 00:54, 15 September 2009 (EDT)

:As I recall, the reason such nomenculture is used is that "USO" is very similar to "UFO", and a fair bit faster and easier to type out than "Alien subs". And while you are correct that the game lists it as a UFOpaedia, remember that TFTD is basically a commercial total-conversion mod of EU. USOpaedia is used to allow a reader to quickly establish that this article or portion thereof refers to TFTD, and '''NOT''' EU.

:It also adjusts to established reading habits; an EU player who starts on TFTD will be easily able to read the TFTD pages without any difficulty due to the use of terms. You'd be surprised how much trouble some people have reinterpreting the same sentence written in a different way. So by using a clear and consistent set of terms, we can avoid those issues...even if it is very slightly inaccurate. [[User:Arrow Quivershaft|Arrow Quivershaft]] 01:30, 15 September 2009 (EDT)

:: It's not official, but many adopted it simply as a spin off "UFO" for convenience. I believe there are also some terminologies we use a lot in UFO that don't necessarily appear in-game.

:: I don't mind either way as long as there is no confusion amongst the readers - the actual sub names are more probably important terminology to keep intact. Actually, that's reminded me of something. Microprose released a set of short stories as teasers for TFTD's release. Not sure if they will have any insight into any of this, but I think they need to be mentioned (or even added) to the Wiki at some stage.

:: To be pedantic, I thought I'd point out that TFTD Americanizes the Ufopaedia into Ufopedia. Most seem to prefer the ae. -[[User:NKF|NKF]] 01:58, 15 September 2009 (EDT)

- I can replace every single instance myself, and would be happy to, so the length is not an issue.

- I had noted that TFTD Americanised the spelling, that is why is it listed as such in my paragraph above.

- The term USO itself is confusing. It confused me. [[User:Magic9mushroom|Magic9mushroom]] 02:47, 15 September 2009 (EDT)

: Well volunteered M9M! I am surprised to discover that USO is not a canonical term. I don't think we should be inventing terms that don't appear in the game. Also, the term USO doesn't occur outside the game (apart from on this website). That is more likely to be confusing to any new people. And they are the ones we should worry about - anyone already reading the site knows what USO means but is not going to be confused by a more specific term like Alien Submarines. It looks like USO is a short-hand and I don't think we should be lazy. My vote is to replace both USO and USOPaedia/USOPedia throughout, as being non-canonical, unhelpful, and confusing to new readers. As an extra question, is SWP canonical or not? [[User:Spike|Spike]] 13:52, 15 September 2009 (EDT)

:: Just had a quick glance at where USO is used, like the navbar, and I don't see it causing any confusion - so go for it. A note on what it means for those who encounter it may be helpful though as it has been in use for so long that many long time players have adopted it even if it's not a canon term. SWP isn't in the game, but SWS is. That's actually encountered in the game text. -[[User:NKF|NKF]] 15:40, 15 September 2009 (EDT)

However, within this wiki SWS is used wrongly a lot of times. It's the equivalent to HWP, not to Tank. Coelacanth is the equivalent to Tank. Hence SWS/Displacer is tautological. [[User:Magic9mushroom|Magic9mushroom]] 22:08, 15 September 2009 (EDT)

So shall I go ahead? [[User:Magic9mushroom|Magic9mushroom]] 11:11, 19 September 2009 (EDT)

:With over two years of lack of response, I decided to just go ahead and do it. The term USO has been excised from this wiki, replaced with Alien Sub. [[User:Magic9mushroom|Magic9mushroom]] 01:31, 5 February 2012 (EST)

== Alien Sub section TO-DO's ==

The sub pages are rich in information about the subs, but we're missing the crew equipment loadouts.

We've got the crews, just not the various possible equipment combinations. An executable dig might reveal this information - just have to recall where this is stored. -[[User:NKF|NKF]] 06:44, 25 February 2011 (EST)

== Crashed/Destroyed Columns ==
These columns were very confusing to me at first, as I thought (due to their position and titles) that they were some measure of the amount of damage you had to inflict to either down or kill the sub. I did not figure it out until I went to [[UFOs]] and saw the different column names. I think the column names should be changed here, or have a clarifying comment above or below the table itself. --[[User:Jewcifer|Jewcifer]] 15:40, 16 March 2012 (EDT)

Talk:Known Bugs

2012-03-16T19:44:31Z

Jewcifer: /* Paying for Dirt in TFTD */

Talk:Alien Submarines

2012-03-16T19:40:34Z

Jewcifer:

==Survey Ship and Escort==

From what I can tell, everything in the game, the UFOpaedia entries, the Transmission Resolver data, everything indicates that the one with the two IBAs and the two interior rooms IS the Survey Ship. That USO is more easily shot down/destroyed, comes with only one alien, and the UFOpaedia entry for the Survey Ship matches its design (the two windows being separated over a wider flat portion). The Escort is the one with only one IBA and no internal rooms. These aren't so easily destroyed, come with 4+ aliens and have the windows close together and sloping sides, like in the Escort UFOpaedia entry.

I intend to fix this in the wiki entries unless someone objects. [[User:Magic9mushroom|Magic9mushroom]] 06:19, 20 August 2009 (EDT)

: I object! :) This is believed to be a [[Known Bugs (TFTD)|bug]], the Escort and Survey Ship have been swapped around in the game. [[XcomUtil]] fixes this. The UFOPaedia entries are correct. Maybe make a note of the bug on both wiki pages? [[User:Spike|Spike]] 11:21, 20 August 2009 (EDT)

:: The UFOpaedia entry for Escort matches the picture seen in the interception window when intercepting an "Escort", which matches the smaller design (adjacent portholes, which is listed on here under Survey Ship). The UFOpaedia entry for Survey Ship matches the picture seen in the interception window when intercepting a "Survey Ship", which matches the larger design (separated portholes, which is listed on here under Escort). It's a huge stretch to call it a bug when absolutely everything agrees. The fact of the matter is, a "Survey Ship" within the (unmodified) game for all intents and purposes is the design with the separated portholes and the interior rooms. The entries in this wiki should reflect that. Xcomutil is a separate issue, and while that should be noted on the pages, and the oddity of the situation (Survey Ship bigger than Escort) should also be noted, it hardly makes sense to confuse people coming to the wiki for the first time based on us thinking that a particular feature of the game is unintended. [[User:Magic9mushroom|Magic9mushroom]] 04:13, 21 August 2009 (EDT)

:The interception screen pics might also be swapped. Inteck (from StrategyCore) caught one issue where the Fleet Supply Cruiser and the Battleship pics were swapped in the interception screen. But it should be noted that both interception screens have 2 portals while the real Escort ship map design doesn't even have a single one. Then again, the real Survey Ship's pic is indeed smaller than the real Escort.

:: Actually, you're wrong. The larger ship, which you term the "real" Escort, has 2 portals on the battlescape. They're on either side of the door. This pattern matches the UFOpaedia entry and interception pic for Survey Ship, both of which have two separated portals. The smaller ship, which you term the "real" Survey Ship, has 2 portals right next to each other, which matches the UFOpaedia entry and interception pic of the Escort.

::I actually noticed the Fleet Supply Cruiser/Battleship issue myself. THAT should be noted as a swapping, because the interception and UFOpaedia pic do not match the Battlescape (which is obviously right, because it matches the UFOpaedia text). However, in this case, every in-game source agrees. [[User:Magic9mushroom|Magic9mushroom]] 05:10, 22 August 2009 (EDT)

In my defense, the portals on the larger ship don't look anything like the portals on the smaller ship.--[[User:Zombie|Zombie]] 11:34, 22 August 2009 (EDT)

You're right there. It's because of the different angle. I wasn't faulting you for it. :) [[User:Magic9mushroom|Magic9mushroom]] 04:55, 23 August 2009 (EDT)

:All information points to the fact that the two ship designs were accidentally swapped when they were added to the game. The real survey ship only has 3 spawn points whereas the Escort has 6, not to mention that the real survey ship doesn't have any internal doors while the Escort has 2. Is this intended? I highly doubt it. The designers/programmers had to whack this game out in a short amount of time and a lot of mistakes were made. They were trying to base the USOs off the UFOs from the first game but messed it up. --[[User:Zombie|Zombie]] 09:04, 21 August 2009 (EDT)

:: This is possible. However, the fact that they're swapped everywhere you can possibly look in the (unmodified) game means that we really should discuss the larger, 3-room vessel as the Survey Ship and the smaller, 1-room vessel as the Escort, with probably a note on both pages saying that this is anomalous and could be unintended. [[User:Magic9mushroom|Magic9mushroom]] 05:10, 22 August 2009 (EDT)

:One theory which I came up with a while back is that the map programmers confused the two ships because they look so similar (well, small). It's not that big of a stretch to assume that the person who was responsible for designing the ship layout was not the same person who implemented them in-game, who confused and swapped the two maps, but correctly based the map in the Battlescape against the interception pic in the Geoscape/USOPedia.

:However, just because somethings technically "agree" in-game, there are other glaring inconsistencies which don't agree. The spawn points is one of them and the sheer complexity of the real Escort craft forces a person to really sit down and think about it for a while. Also, look at what happens in the Geoscape: the smaller ship has the correct size class (very small) and the correct sonar blob (which is based off of the class I'd imagine), same goes for the larger ship. In fact, all the stats you would associate with each craft are correct in every respect (weapons, weapon range, speed, etc). But when you go on a mission, the map (and more importantly the size) doesn't reflect the stats in the Geoscape. That's the deciding factor.

:I agree that it should be made more apparent on the two craft pages that there are major discrepancies, but wouldn't go so far as to swap the two articles here just to match some observances in-game. When you boil this all down, it is nothing more than an unfortunate mixup with the maps. It's pretty obvious to me, but I guess to those who do not study the game files or the executable, it's easier to accept the craft are that way intentionally. --[[User:Zombie|Zombie]] 11:34, 22 August 2009 (EDT)

::You have a point. But on the other hand...

::No matter how unintentional it is, the map which comes up when you attack a Survey Ship has the bigger hull. Therefore, it is terribly misleading to put the smaller hull's floor plans in our page about the Survey Ship and the bigger hull's floor plans in our page on Escort. Same for the UFOpaedia/interception pic. Noting that it's screwed up is one thing, but listing things which are not true in-game in a wiki dedicated to it is extremely dodgy. [[User:Magic9mushroom|Magic9mushroom]] 04:55, 23 August 2009 (EDT)

I also have a fix for this up in StrategyCore's [http://www.strategycore.co.uk/files/index.php?dlid=620 files section]. It includes a route fix as well. --[[User:Zombie|Zombie]] 20:16, 20 August 2009 (EDT)

==Terminology==
In-game, these are always referred to as "Alien Submarines" or "Alien Subs", not ever as USOs. We should correct this. Also, the in-game reference is called the UFOpedia, not the USOpaedia. [[User:Magic9mushroom|Magic9mushroom]] 00:54, 15 September 2009 (EDT)

:As I recall, the reason such nomenculture is used is that "USO" is very similar to "UFO", and a fair bit faster and easier to type out than "Alien subs". And while you are correct that the game lists it as a UFOpaedia, remember that TFTD is basically a commercial total-conversion mod of EU. USOpaedia is used to allow a reader to quickly establish that this article or portion thereof refers to TFTD, and '''NOT''' EU.

:It also adjusts to established reading habits; an EU player who starts on TFTD will be easily able to read the TFTD pages without any difficulty due to the use of terms. You'd be surprised how much trouble some people have reinterpreting the same sentence written in a different way. So by using a clear and consistent set of terms, we can avoid those issues...even if it is very slightly inaccurate. [[User:Arrow Quivershaft|Arrow Quivershaft]] 01:30, 15 September 2009 (EDT)

:: It's not official, but many adopted it simply as a spin off "UFO" for convenience. I believe there are also some terminologies we use a lot in UFO that don't necessarily appear in-game.

:: I don't mind either way as long as there is no confusion amongst the readers - the actual sub names are more probably important terminology to keep intact. Actually, that's reminded me of something. Microprose released a set of short stories as teasers for TFTD's release. Not sure if they will have any insight into any of this, but I think they need to be mentioned (or even added) to the Wiki at some stage.

:: To be pedantic, I thought I'd point out that TFTD Americanizes the Ufopaedia into Ufopedia. Most seem to prefer the ae. -[[User:NKF|NKF]] 01:58, 15 September 2009 (EDT)

- I can replace every single instance myself, and would be happy to, so the length is not an issue.

- I had noted that TFTD Americanised the spelling, that is why is it listed as such in my paragraph above.

- The term USO itself is confusing. It confused me. [[User:Magic9mushroom|Magic9mushroom]] 02:47, 15 September 2009 (EDT)

: Well volunteered M9M! I am surprised to discover that USO is not a canonical term. I don't think we should be inventing terms that don't appear in the game. Also, the term USO doesn't occur outside the game (apart from on this website). That is more likely to be confusing to any new people. And they are the ones we should worry about - anyone already reading the site knows what USO means but is not going to be confused by a more specific term like Alien Submarines. It looks like USO is a short-hand and I don't think we should be lazy. My vote is to replace both USO and USOPaedia/USOPedia throughout, as being non-canonical, unhelpful, and confusing to new readers. As an extra question, is SWP canonical or not? [[User:Spike|Spike]] 13:52, 15 September 2009 (EDT)

:: Just had a quick glance at where USO is used, like the navbar, and I don't see it causing any confusion - so go for it. A note on what it means for those who encounter it may be helpful though as it has been in use for so long that many long time players have adopted it even if it's not a canon term. SWP isn't in the game, but SWS is. That's actually encountered in the game text. -[[User:NKF|NKF]] 15:40, 15 September 2009 (EDT)

However, within this wiki SWS is used wrongly a lot of times. It's the equivalent to HWP, not to Tank. Coelacanth is the equivalent to Tank. Hence SWS/Displacer is tautological. [[User:Magic9mushroom|Magic9mushroom]] 22:08, 15 September 2009 (EDT)

So shall I go ahead? [[User:Magic9mushroom|Magic9mushroom]] 11:11, 19 September 2009 (EDT)

:With over two years of lack of response, I decided to just go ahead and do it. The term USO has been excised from this wiki, replaced with Alien Sub. [[User:Magic9mushroom|Magic9mushroom]] 01:31, 5 February 2012 (EST)

== Alien Sub section TO-DO's ==

The sub pages are rich in information about the subs, but we're missing the crew equipment loadouts.

We've got the crews, just not the various possible equipment combinations. An executable dig might reveal this information - just have to recall where this is stored. -[[User:NKF|NKF]] 06:44, 25 February 2011 (EST)

== Crashed/Destroyed Columns ==
These columns were very confusing to me at first, as I thought (due to their position/titles) that they were some measure of the amount of damage you had to inflict to either down or kill the sub. I did not figure it out until I went to [[UFOs]] and saw the different column names. I think the column names should be changed here, or have a clarifying comment above or below the table itself. --[[User:Jewcifer|Jewcifer]] 15:40, 16 March 2012 (EDT)

Talk:Base Defence Systems

2012-03-16T16:57:45Z

Jewcifer:

User:Jewcifer

2012-03-16T16:21:40Z

Jewcifer:

I love TFTD. I have never actually played EU. I enjoy playing with no save-reloading and no MC.

User:Jewcifer

2012-03-16T16:21:19Z

Jewcifer: Created page with "I love TFTD. I have never actually played EU. I enjoy paying with no save-reloading and no MC."

I love TFTD. I have never actually played EU. I enjoy paying with no save-reloading and no MC.

Talk:Known Bugs

2012-03-16T16:18:10Z

Jewcifer:

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

= Specific Bug Discussions =

== Misc Technical Bug ? ==

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

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

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

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

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

- [[User:NKF|NKF]]

-----

== "Invisible Muton" bug ==

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

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

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

-----

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

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

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

- [[User:Bomb_Bloke|Bomb Bloke]]

----

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

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

----

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

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

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

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

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

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

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

- [[User:NKF|NKF]]

----

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

----

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

- by tequilachef (April 4th 2007)

== Vanishing snakemen ==

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

---

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

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

- By tequilachef (April 4th, 2007)

== Blaster Bomb Bug ==

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

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

== Disappearing Ammunition ==

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

------

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

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

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

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

==MC at end = MIA?==

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

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

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

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

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

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

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

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

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

----

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

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

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

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

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

- By tequilachef (April 4th, 2007)

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

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

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

: -[[User:NKF|NKF]]

== Crash Site in the atlantic ocean ==

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

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

- UFO: battleship, floater, alien harvest

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

- Date: January 2000

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

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

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

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

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

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

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

== Inconsistencies in MCing Cyberdiscs and Sectopods ==

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

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

:- [[User:NKF|NKF]]

== Facility Dismantle Bug ==

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

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

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

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

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

== Manufacturing Limit Bug ==

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

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

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

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

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

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

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

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

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

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

----

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

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

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

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

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

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

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

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

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

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

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

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

== Unconscious Enemy in Equipment Screen ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--------

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

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

== Soldiers moved to outside of combat screen ==

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

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

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

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

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

==Great Circle Route==

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

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

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

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

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

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

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

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

-----

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

-----

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

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

-----

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

----

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

-----

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

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

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

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

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

== Soldier Recruiting Bugs Tested ==

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

==Floater Medic Bug==

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

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

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

==Strength Overflow==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Sources for a DOS4GW transplant ==

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

== Phantom Carried Casualty ==

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

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

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

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

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

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

==Elerium Base Bug==

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

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

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

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

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

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

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

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

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

See Also [[Talk:Displacer/PWT]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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