Talk:Known Bugs (TFTD)

More Unconscious Bugs

OK maybe TFTD is just plain buggy. This may be related to the Mind Controlled units MIA bug. What I saw was:

• All human units are killed or stunned, but the game does not end, a Coelecanth keeps working (this is a bug right?). I ran the Coelecanth for at least 4 more turns, with all Aquanauts either dead or stunned.
• If I saved and restored this game with the Coelecanth, on the first restored turn I had no units. I could not use the Units menu, the Next Unit button, or the Centre on Unit button. Nothing. After letting the aliens move for one turn, I could see my Coelecanth again.
• If I aborted this mission with the Coelecanth in the ship, as expected it says "Submarine Lost" and the stunned crew - who had been placed aboard the Triton - do not make it back to base.
• However, one of the stunned crew members does make it back to base. The stunned crew were all psi weak but some were stunned whilst under alien mind control, others were not - they were just panicked. I'm not sure if the crew member who teleported back to base was mind controlled or just (morale) panicked. But I would guess he was panicked, since most of them were mind controlled.
• When this crew member gets back to base he is shown as being assigned to craft called "Weapon-1" (since the craft he was assigned to no longer exists). Since this craft doesn't exist, there is no way to unassign him from it. Even if I had a new Triton I doubt I would be able to assign him to it. Shame he wasn't injured!
• Like in a similar incident I saw before, the affected Aquanaut was the first in the list and also the most senior rank. So that might be a factor.
• In this underwater mission I saw that the Hallucinoid's melee attack definitely works, and is lethal against unarmoured Aquanauts. The melee attack is ineffective against a Coelecanth (with XComUtil improved tank armour I think). I saw no evidence of its ranged attack working, ever, despite many opportunities. It may be possible that (like the HJ Cannon on land), the Hallucinoid's ranged attack might be able to reaction-fire underwater. I didn't do enough to test this, I might try that later.

Spike 14:08, 8 August 2009 (EDT)

I got this situation: Was on a ship attack mission (passenger ship). On the 2nd level, at the lift (big room with crates), one of my soldiers got MC'd while still standing on the lift. He shot a thermal shok bomb and became unconscious (while MC'd). He remained unconscious until I eliminated all aliens, waiting patiently on the lift. Now, the game didn't notify me about a dead or MIA agent, but he disappeared from my aquanauts list. Dunno what was the cause of this misbehaviour. mingos

I imagine it's the bug Zombie reported here in reverse - your dude turned into an alien. He didn't count as MC'd (so no MIA message), and he didn't count as dead (so no DIA message either). That bug - and the others on the same page - really should be documented on the "master lists"... - Bomb Bloke 02:45, 4 December 2009 (EST)

So... If I applied stimulant on him, he'd be hostile for one turn and then magically return to my team, I assume. Damn, all this stunned/revived/MC'd/un-MC'd and the mixtures thereof are really weird. Multiple bugs at play... mingos]

Seb76's loader fixes all the mind control / unconscious bugs. These bugs have many different manifestations. Spike 14:05, 8 December 2009 (EST)

Gill-men reported as Snakemen

I get these interesting bugs playing TFTD. A Gill-man corpse is described as a Snakeman corpse. And I get messages saying "Snakeman soldier has panicked", "Snakeman soldier has gone Berserk", when the Gillmen have morale failures. Now the game I'm running using XComUtil, and these Gill-men were created by using XComUtil REPlace command, changing them from Aquatoids and Tasoths. So this may be a fluke. Has anyone else ever noticed this? Spike 17:27, 8 August 2009 (EDT)

It's due to XcomUtil. There isn't a string containing "Snakeman" (or any variant thereof) in ENGLISH.DAT, ENGLISH2.DAT or even the executable. --Zombie 19:45, 8 August 2009 (EDT)

Survey Ship v. Escort

The Survey Ship and Escort are not interchanged on the battlescape. The sub that comes up matches the UFOpaedia entry and the picture that pops up during interception. Magic9mushroom 04:31, 21 August 2009 (EDT)

Not sure what you mean exactly. I would expect that during Interception it would look like an Escort, but when you shoot it down you see a small 1 room craft (Survey Ship) on the Battlescape map but the expected large crew and loadout from an Escort. And vice versa. Is this not what you see? Spike 16:17, 21 August 2009 (EDT)

No. When you shoot an Escort down the picture (although not the size of the blob) matches the design of what you term a Survey Ship, the 1 room craft. When you shoot down a Survey Ship the picture (though again, not the size of the blob) matches the larger, 3 room craft. Which is also confirmed by the UFOpaedia entries. The UFOpaedia entry for the Survey Ship looks like the larger craft and the UFOpaedia entry for the Escort looks like the smaller craft.

So the sub seen on the battlescape matches the sub picture seen during interception and the sub picture in the UFOpaedia. There's no switching in the Battlescape relative to the stuff seen in the interception window and UFOpaedia. It may be that the Survey Ship was intended to be the one-room craft (and indeed, this seems logical) but if that's the case, it's switched in all three. I checked and double-checked this. Magic9mushroom 05:03, 22 August 2009 (EDT)

Ok this is interesting, you may have uncovered a general misunderstanding. It's been suggested before that maybe it's just the names that are switched.

I know you have double checked that you have never run XcomUtil or a map pack? Definitely a virgin install?

Do you still see a large crew on a small craft and a 1 man crew on the larger craft?

That the sonar blob size is wrong does suggest maybe a problem in the .exe rather than the map files.

Spike 05:47, 22 August 2009 (EDT)

I don't even know how to use Xcomutil and have never downloaded it, so I can guarantee it's not been run on my Collector's Edition version.

I see multiple aliens on the 1-room craft and 1 alien on the 3-room craft.

I don't think the names are switched, since IIRC the Survey Ship still appears first and the Escort second in a mission. Besides, it'd have to be names and crew switched to make sense.

The sonar blob size isn't wrong, it coincides with the reported size of the craft. Escorts are reported as Small while Survey Ships are reported as Very Small. The problem, however, is that that reported size doesn't agree with the actual size of the ships, although it does agree with their loadouts. Magic9mushroom 05:57, 22 August 2009 (EDT)

Ok you have been very thorough on this. Let me try to summarise. The battlescape map, UFOpaedia picture and Interception window picture all agree in showing the Survey Ship as the larger of the two. The reported detection size, crew loadouts, spawn points, order of appearance, combat power, & sonar blob size all agree in showing the Escort as the larger. (We haven't looked at Mission types, a further clue.)

I think the most likely explanation is your earlier suggestion that all 3 "pictures" (map, intercept, UFOPaedia) were switched. Probably the last 2 are configured in the same place in the exe. As Zombie said, a miscommunication between different parts of the development team. Good investigative work! Spike 12:57, 22 August 2009 (EDT)

You two have convinced me that it is probably unintentional. I don't think it should be listed under bugs though, as it always happens and doesn't actually screw up the game or anything. It's a very odd state of affairs and one that should be listed on the pages for the ships though. I still think the Survey Ship and Escort pages should reflect what actually happens in-game, ie that we should have the bigger floor plans under Survey Ship and the smaller ones under Escort, along with listing the UFOpaedia pics as they're actually noted in-game. Magic9mushroom 05:00, 23 August 2009 (EDT)

Magic9mushroom, your investigation has improved the understanding of this issue. It should definitely be flagged up on the wiki pages of both craft. And the other picture-swapping case, the supply ship, should also be flagged on the relevant wiki pages. I think both should be considered Bugs, as they are illogical / inconsistent and don't behave as a player would reasonably expect. It's not necessary that an issue is unpredictable, nor that it damage game play, to be called a bug. Most listed bugs are always repeatable, and quite a few arguably aid gameplay. So I think we should list these as bugs, add your additional findings, and update the craft wiki pages. I'm not sure if we should swap the pictures and descriptions on the wiki pages back to the unmodified state or not. I'm thinking it over. You're right that it's confusing to players who use the unmodified game. Spike 09:57, 23 August 2009 (EDT)

I'll put my support for the motion that Wiki should present this information as per what players will find in an unmodified game. So if they see pictures of an apple in the Ufopaedia but find an Orange in the Battlescape instead, while the Ufopaedia Orange entry comes up with a Battlescape Apple, then let it be so, but also note that the objects have been unintentionally swapped either in one place or the other. There are plenty more inconsistencies in TFTD anyhow. -NKF

So then, if there are no further objections, I plan to do the following:

- Swap the listed UFOpaedia pics for the Escort and Survey Ship to match the ones found in the in-game UFOpaedia.

- Swap the listed floorplans to agree with what is actually found on the Battlescape

- Add a note to both articles that there's likely some sort of mixup.

Any objections? Magic9mushroom 19:47, 25 August 2009 (EDT)

Generally agreed but you could consider putting both images on each page, listing the unmodified one first, and saying "it looks like THIS but should probably look like THIS". Spike 07:45, 26 August 2009 (EDT)

I'll link each page to the other of course, so that seems a bit redundant. It's been over a day by my count so I'll do the switch. Magic9mushroom 07:54, 26 August 2009 (EDT)

...and done! Magic9mushroom 08:32, 26 August 2009 (EDT)

disappearing corpses

I thought this one is quite well known but could not find it on the list(Remove this if I missed it somehow). This annoying bug is regularly encountered in settings with large maps containing lots of aliens (ship lane terror missions, XCOM base assault, Alien base assault, Artefact sites). Since the item table gets too full at some point and alien corpses and I think stunned aliens as well are items they are simply disappearing when any more killed/stunned. Too bad if this happens to be your hard earned lobsterman commander... The easiest way to reproduce it is to take leviathan load of aquanauts including a squad of strong MC troopers, bring a taser, drills and a medikit and assault an Alien base. At sea level use MC chains to put every alien under molecular control and and march them to your transport. ASAP stun one aquatoid soldier,revive it with the medikit and wall it in. Then cull the rest of the Alien garrison and stuff your pockets and backpacks with DPLs and ammo, Sonic pulsers, corpses and other weapons and ammo(unload ammo from weapons) until you can carry no more. Once you are done finish the off the last aquatoid and proceed to the second stage. There drop the stuff and play hunt the last alien(in order to get all the loot from the base) and soon you will encounter the bug.--Tauon 15:13, 11 October 2010 (EDT)

Multi-part map ammo loss

I believe this is XComutil related. It was intended to solve the problem of not recovering any loot on the first part of the mission.

It's actually worse than that. Plain vanilla TFTD loses everything on the first map that is not being carried by aquanauts. Including everything in the Triton floor area. So if you had a few spare Gas Cannons on standby at the sub for example, but left them when you proceeded to the second part, you'll lose them for good.

Partly to avoid this bug, and to allow you to collect any loot in the first map, XComutil returns this stuff back to base. Although, it seems that XComutil sometimes gets carried and removes all your carried ammo as well.

This is just a guess, but it might be related to ammo that the game placed in inventory at the start of the mission. If you haven't moved them or unloaded/reloaded the weapons, XComutil may be seeing them as not being owned by anyone. -NKF 04:02, 31 October 2010 (UTC)

Thanks NKF I will investigate further. Spike 19:04, 31 October 2010 (UTC)

Well this just gets weirder. In one test, I left everything as loaded by the equip phase. In that case, when I get to stage 2, every clip that was originally loaded, is in the equipment pile. I can live with that. Everything that was left in the stage 1 equipment pile is gone - I can live with that, too. Not clear if the stage 1 equipment pile has been teleported back to my base-of-origin. It's hard to tell, because automatic re-equip of guns and ammo after the mission is instant (hence the "Not enough equipment to fully re-equip troops" message).

In the 2nd test, instead I manually reloaded every item. Every ammo unit that I had manually loaded into a gun during stage 1, was gone at the stage 2 equip phase. Even all the ammo that Aquanauts had been carrying as spares, was gone. The only ammo I had was one gauss pistol clip which I suspect I forgot to manually reload - so it was only there because of the behaviour observed in the preceding test (previous paragraph). And, the ammo had definitely not teleported back to base, because after I aborted the mission (at the stage 2 start area), my ammo stores back at base were depleted by pretty much the same amount as the missing ammo. So I think something's going badly wrong here.

(Tests were done using XcomUtil 9.60, not XcomUtil 9.7 Beta.) Spike 20:41, 1 November 2010 (UTC)

I tried installing XcomUtil 9.7 Beta, to test that version, but had some issues with my Steam TFTD installation. I'll try again tomorrow. Spike 21:54, 1 November 2010 (UTC)

Perhaps the older version of XComutil was just too eager with sending the loose items back home? Either way, don't forget to do a test in the plain vanilla copy of the game if you get a chance. My tests were based on a vanilla copy of the v2.0 dos version in Dosbox. Of course, your mileage certainly may vary.

OK I checked plain vanilla - full reinstall of Steam version (Dosbox, though reported by XcomUtil 9.7 as TFTDWin 1.0 version). Plain vanilla install, using the savegame from the XCU9.6 game, and a Turn 1 state (so XCU9.6 may have messed with things during the equip phase). The results are as expected - all carried equipment and loaded ammunition, including ammo counts, are preserved between stage 1 and stage 2. Equipment pile or other dropped items from stage 1 are not carried over to stage 2. Alien kills, corpses and artefacts from stage 1 are credited upon abort from stage 2. All civilians from both stages die upon abort. Mission was a cargo ship mission. Spike 20:38, 3 November 2010 (UTC)

I also checked XCU 9.7 Build 422, clean install on a clean install of TFTD (Steam). Good news, the bug is fixed. I can't reproduce any of the bad behaviour - no missing ammo, no missing equipment. Cool! Spike 20:45, 3 November 2010 (UTC)

One thing that has come from this is that I'm never going to leave any excess items in the Triton on two-parters ever again. Well, unless it's every-day easy-to-get stuff like the Sonic Cannons. Just have to be mindful of the spare tazers and chem. flares. -NKF 07:11, 2 November 2010 (UTC)

And just a minor update note for this discussion since I noted it in the article on the two-parters: The losing-everything in the first part bug is a TFTD v1.0 issue. Not a problem for 2.0 or CE. -NKF 23:18, 26 April 2011 (EDT)

Actually, 2.0 only resolves this issue in the case that you KILL everything in part 1. If you placed your guys in the exit zone and hit abort, you might still lose stuff. You definitely don't get the loot in this case. Jasonred 14

34, 27 April 2011 (EDT)

Land missions reaction fire bug

This is an expansion of a bug known as "X-COM underwater-only weapons fire on land missions". The bug may actually be more serious than that and it may extend to all present units.

The game tries to check for land availability of a weapon in hand, but it wrongly tests the first OBPOS.dat item instead. If the first item stored in OBPOS is not allowed on land, no reaction fire is possible, during the whole mission, both for X-Com and for Alien side! If, however, the first item is allowed, all reaction fire is always possible, for both normal and underwater-only weapons. Note: This has not been tested in game. I don't know how the first OBPOS.dat is selected. Maybe this effect occures very rarely, or never. The code leaves the possibility open. --kyrub 07:19, 26 April 2011 (EDT)

Very interesting research. Also very scary! Spike 16:34, 26 April 2011 (EDT)

They probably failed to point to the right index. Either hardcoding a 0 in as the obpos index (or offset if using memory pointers). That actually makes me wonder if this is what influences the aliens' reluctance to react against the cannon or aquajet Coelacanths? If it is then my theory that Coelacanths are (nearly) immune to reaction fire may stem from this. -NKF 23:18, 26 April 2011 (EDT)

Deep One "shooting" is suspect

The Deep One seems to miss most of the time, and it hits VERY rarely. This is strange, since his internal (turret) accuracy is not bad at all (75% for Snap shot, 110% for aimed shot, but the latter is less used due to the closer distance of engagement). Deep one has FA = 50 which on normal difficulty gives: 50*75% = 37,5% for a snapshot. This does not seem to match the reality. What could go wrong? The "shot" seems to follow the grenade trajectory. Grenades, however, are always targeted at the ground. As it seems, there is no adjustment for the Deep One targetting in the code. My guess is, the Deep One shoots on the ground under the soldier and it hits him only by accident. Same should be true for Celatid in UFO. Can anybody confirm the experience? --kyrub 19:23, 23 February 2012 (EST)

I wonder if it's like the Launch command for the Blaster/Disrupter Torpedo launcher, it may use its own routine that bypasses the normal snap attack? -NKF 13:59, 24 February 2012 (EST)