Talk:TFTDextender

Questions or Comments

A place to provide feedback or ask questions:

Thanks to Kyrub, Spike, and numerous others who help to troubleshoot problems, provide feedback on releases, and innumerable other activities to help make TFTDextender and the game better! - Tycho

• The zip archive does not seem to include an .ini file. Where do I get the .ini file from?

If the latest release is a patch, meaning there are no new additions to the INI file, only the patcher.dll file will be updated. In this way, those who already have the current release won't have their INI settings overwritten. You will need to download the last full version, extract the files from it, and then extract file from the latest patch. When I first release the Extender and lots of problems were being reported, I was releasing fixes almost on a weekly basis and so I still continue with this idea. Tycho

Bug Reports

Major Bugs

USOs not detected or Alien Missions not appearing

With the Geoscape Clock mod enabled. Few alien subs are being detected. It may be that alien subs on missions are not appearing at all.

Things that TFTDextender does not fix

Just more or less as a note to the reader, TFTDextender does not fix some of the following things that are sometimes thought of as needing fixing (and this is probably deliberate?):

• Does not fix the apparent swap of the ground map for the VERY SMALL Survey Ship (1 occupant) with the SMALL Escort (half-dozen or more occupants). So you get the VERY SMALL sub occupying about 25 squares of usable area on the Battlescape, and the supposedly larger SMALL sub occupying one square of usable area on the Battlescape, begging the question of how all those aliens got inside there in the first place. XcomUtil will fix this, as will the original patches that XcomUtil incorporates.
• Does not fix the incorrect pictures for the large USO in the interception window.

Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.[1]

• Does not fix the Dart Gun to make it any less utterly useless. Though you can do this yourself via the OBDATA.DAT section of TFTDextender. (Suggestion: don't fix it. The useless Dart Gun is all part of the "oh no we're all gonna die" experience of the beginning of TFTD.)
• Does not improve the armour and effectiveness of the basic Aqua-Jet and Gas Cannon Coelecanths (it does upgrade the Coelecanth/Gauss). (Again, suggestion: this is a good thing - XCOM should start the game hopelessly outclassed, and scramble to catch up).
• Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.
• Does not allow you to have 360 degree vision out of your sub before exiting it. (What kind of coward would want that?). XComUtil does this.

FYI

• When I try to send any Leviathan to T'Leth, I get an immediate crash: "XCOM crashed at 0x458822 with error 0xC0000005 trying to access 0xFA6C8304.".

It happens when the CE version doesn't find the RISE animation: Specifically, it needs ANIMS\RISE.IDX and ANIMS\RISE.VID - If RISE.IDX is missing, it crashes with the error code above, if RISE.VID is missing, it crashes with another error. Some experimenting suggests that RISE.VID can be any valid .VID file, while RISE.IDX can either be empty (producing a black screen that can be skipped by clicking) or the "appropriate" .IDX for the used .VID...AMX 13 November 2012 (EST)

• The game crashes when I start mission against a sub: "XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."

It's an already reported bug. What is happening is the Alien Sub is landing on land, and the Triton is also attempting to land on land. Probably the game crashes when it fails to generate the appropriate terrain type? So the GEOSCAPE map/terrain data must be corrupted. I've seen three examples of this. In a couple of cases the landing site is clearly inland, by hundreds of kilometres. In some cases it's right on the sea/land boundary and hard to tell. I have two save games that reproduce the bug now. From memory, the previous cases all happened around North Africa, like these present cases. Spike 08:31, 9 September 2012 (EDT)

• Trojan Horse? AVG Anti-Virus reports that TFTDExtender.exe contains a Trojan Horse (Generic30.MKG).

AVG has been known to produce false positives before. I use AV software on my machine and have checked this by uploading/downloading from a site with its own AV check. In some sense Extender acts like a trojan, in that, it overwrites code in memory, just not in a malicious way. -Tycho

Resolved Reported Problems

• Save Equipment not working

With "Save Equipment" option enabled, the soldiers' loadout at first was always like this: grenade in leg slot, clip in backpack - and it didn't change on the next mission, despite the fact that I re-equipped the soldiers correctly (grenades and clips on the belt). When I manufactured Gauss Rifles and issued them to my soldiers, it got even worse - none of the soldiers got clips, and two of the rifles were unloaded. Next I upgraded to Sonic-Blasta Rifles and now nothing, except some grenades (still in leg slots), is issued to the soldiers at all. "Save Equipment" was known to work in UFOExtender, did something get broken? --Player701 09:18, 21 October 2012 (EDT)

Yes. Something is broken but not by the Extender. I haven't modified anything in the save equipment code, except datapoints and offsets that were necessary to match it to the executable and changes in the DAT files. Many subroutines, their order of execution, or the variables were modified in the TFTD game code. Problems resulting from this are difficult to resolve since it requires finding what changed in the game code and then determining what changes are needed to get the UFOextender code to work. I believe that TFTD has its own form of autoequip and part of the solution will probably require that I disable it. Something similar happened to the "stunned units are KIA" mod from UFOextender: TFTD has its own version that conflicted but, since it worked well, I only needed to add code to update the unit's location so the corpse would appear in the right place.-Tycho 22:38, 24 October 2012 (EDT)

I just did a few tests in raw TFTD (Steam CE) and the auto equip function is pretty basic: Give everyone a loaded weapon in what is probably reverse OBDATA.DAT order, then dish out any extra clips, grenades etc. Are you thinking that the Save Equipment efforts of TFTDextender are then being overwritten or partly overwritten by the existing TFTD auto equip function? I guess that would make sense. Spike 11:01, 25 October 2012 (EDT)

Fixed in 1.05p4 - Tycho

• Weight Issues or "Weightless" Ammo Bug

while playing TFD with TFD extender (v. 1.05 patch 1.1) I've noticed a stange thing: some soldiers have their weight > 0 (2-5) even when their inventory is empty! Bug?... PavelB 05:17, 27 September 2012 (EDT)

If you drop a loaded weapon, even if you loaded it manually, the weight of the ammo still stays with the Aquanaut. Workaround: unload each weapon manually before dropping it. If you forget (and if you notice) it's possible to pick the weapon up again, unload it, and correctly lose the weight by dropping the weapon and clip separately. It's possible to build up huge amounts of phantom weight on a Soldier by repeatedly loading, and then dropping, different weapons. It's also possible to move lots of weapons with weightless clips to one Soldier, increasing the amount of 'free' weight that one Soldier gets. Both of these effects are probably aspects of the original bug, not anything that UFOExtender has done. Spike 11:15, 27 September 2012 (EDT)

This Weight error is a side effect of an original game error that Seb never quite fixed. Removing clips from a Soldier or Aquanaut does not remove the clips' weight. This is because the clips are not correctly assigned to the Soldier or Aquanaut in the first place. See Talk:TFTDextender#Weightless Ammo Bug.

Do you think you could fix this bug? Known_Bugs#Equip_Phase_Ammo_Load_Error. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). Spike 22:55, 6 September 2012 (EDT)

I found the source of the problems: None of the subroutines for inventory consider the clips in weapons so their entries in OBPOS.DAT are never updated. So when clips are autoloaded at the beginning of each battle, they have no owner. I've got the code to sync the ownership of clips with the weapon they are loaded into at the beginning of each battle and to update the clips when weapons are changed in inventory management.-Tycho 19:00, 19 October 2012 (EDT)

All fixed in 1.05p4 - Tycho

• Items on transport floor lost on Abort

I went in to a mission with ten Sonic Cannons and came back with 3, despite retrieving them from the battlefield and dumping them on the transport floor. I only had 3 aquanauts on the transport armed with Sonic Cannon at the time of abort. The rest were stunned or unarmed. I also dumped half a dozen corpses and some alien items on the transport floor and I don't think those made it back to my base either. The transport was operating from base 2 rather than base 1, in case that's a factor. This may be an original bug of course. I just read through the multiplayer TFTD LP on StrategyCore, and they reported missing equipment on a lot of missions. I can go back and check if the missing equipment was on abort missions rather than victory missions. Sorry not to provide more specifics at this time but it was a hard mission and not exactly a controlled experiment. ;) Spike 21:35, 23 October 2012 (EDT)

Fixed in 1.05p4 - Tycho

• Coelacanth/Gauss mutates into Coelacanth/G.C.

In my current game (using the Steam version) I observed it twice that, when a Coelacanth/Gauss is removed from a sub due to lack of ammo, it turns into a Coelacanth/Gas Cannon.

Note that I'm using only the Gauss Tank Ammo Fix, but not the Gauss Tank Turret Stats Fix, nor the Improved Gauss Tank mod AMX 09:09, 1 November 2012 (EDT)

Fixed in 1.05p4 - Tycho

• Cannot build Leviathan

Hi Tycho. I've just researched Leviathan in my TFDExtender game but cannot manufacture it! I have enough resources (Plastics, IBA, ManNav), 3 workshops, more than 100 technicans and one empty sub pen. But when starting the Leviathan manufacture task I cannot assign any technicans to it. I press the "up" button, and there are no reaction to this. I can build Manta, but not Leviathan. Don't you know what is it? PavelB 06:55, 2 October 2012 (EDT)

I was able to replicate Pavel's problem and found the problem: the Leviathan is the only item that its tech hours exceed 0x8000. If you use the wrong command to pass the value between registers, the program handles the value as though it were negative. - Tycho

The problem is fixed with patch 3.2. Confirmed by an independent source.

• Executable directive

I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-Tycho 10:24, 4 October 2012 (EDT)

• Extra Artefacts Reported

After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-Tycho 20:27, 5 October 2012 (EDT)

Fixed in the patch 3.1-Tycho

Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. Spike 15:36, 19 October 2012 (EDT)

• Manufacturing Projects Minimum Production

In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. Spike 22:06, 21 September 2012 (EDT)

It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? Tycho

OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. Spike 04:45, 25 September 2012 (EDT)

Tested - If I reduce the production quantity of a current production run to less than what as already been produced, the display completion time changes (incorrectly) to 'Indefinite', but production ends after completion of the next unit. So if I start by producing 10 units, wait until I have produced 2, then reduce the quantity to 2 (or probably 1), production stops after 3 units. Thies basically replicates the pre-existing behaviour when using the down arrow on the Quantity, so there has been no loss of functionality with your Mod. Also, Autosell and Autoproduce work normally when applied as changes to an existing production run. The only thing is I can't distinguish them on the Manufacturing display - both say 'unlimited' quantity and 'indefinite' period - is that intended? I suppose it makes sense, but it would be good to be able to tell which kind of production it is, *** Autoproduce or $$$ Autosell. Spike 08:57, 2 October 2012 (EDT)

Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - Tycho

I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? Spike 09:46, 5 October 2012 (EDT)

Changed the output to display "$unlimited$".Tycho

• Stunned MC'd Aquanauts MIA on Abort

This is a subset of MC'd Aquanauts go MIA Known_Bugs#Mind_Controlled_Soldiers_go_MIA. In this case Aquanauts are MC'd by the aliens, then stunned (by friendlies), then the mission is Aborted with the stunned X-Com Aquanauts aboard the transport. The Aquanauts then disappear from the roster forever. I'm not sure if it's due to Abort rather than Victory, or due to them being stunned first. This would also apply to UFO Extender. Spike 22:06, 21 September 2012 (EDT)

I now have the code in place to uncontrol any creature that has been rendered unconscious. Available in patch 3.1- -Tycho

• • Crewed Flying Sub Lost on Abort

Aborting this mission will lead to loss of the craft, despite 3 soldiers still being in the Triton. --Player701 10:39, 21 October 2012 (EDT)

I found the nature of the issue here: This only will happen with a tank present. On one hand, all parts of the tank are being counted separately but then the End of Battle routine calculates the number of units correctly (ignores three of the sections of a tank) but when it goes to locate the units on the battlefield, the three other parts of the tank are being counted and thus the last three aquanauts are not checked since the 4 areas of the tank are first in the UNITPOS.DAT file.-Tycho 09:47, 24 October 2012 (EDT)

Fixed in 105 patch 4.-Tycho

• Grenade Resistance in INI file

I removed the reference in the INI since it's unnecessary.-Tycho

• Materials deducted from wrong base

I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - Tycho 08:33, 17 October 2012 (EDT)

I can confirm this is fixed and all is working correctly - great job, thanks Tycho. Spike 15:22, 19 October 2012 (EDT)

• OBDATA / Dye Grenade mod not working?

OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -Tycho 20:24, 5 October 2012 (EDT)

Confirmed fixed. Thanks again. Spike 15:36, 19 October 2012 (EDT)

• Displacer/Sonic damage fix

I changed the damage to be 125, similar to the ratio of tank/plasma to heavy plasma in EU.-Tycho 03:52, 13 October 2012 (EDT)

• Weight Display in Inventory not Localised

At least when I run the game in German, it comes up as "Weight" and not something like "Gewicht". Reactions comes up ok as "Zeitwerte". Spike 09:47, 9 September 2012 (EDT)

Added ability for users to added their own language by copying lines from Extender's page under the equipment section to the same section in their INI, alter the text as specified, and save the INI.' Tycho

Feature Requests and Suggestions

Please check the TFTD Known Bugs or EU Known Bugs(for bugs common to both games) and post bugs which are part of the original game in the appropriate section. Please post any general suggestions for the game here: Wish_List_(TFTD).

• Any errors that are a result of the Extender should be posted here.
• Use this section for suggestions and feedback on options currently available in the Extender or to discuss projects in Extender that are under development.

Useful alien species research

Tycho, I really like this idea you proposed in the StrategyCore forum:

I'm thinking about giving a hp bonus to all aliens until Xcom performs an autopsy on the species to learn the location of their vital organs (like in the movie "Battle of LA"). This would give more importance to performing autopsies rather than just as a stepping stone to new tech.

Definite +1. It would be equally valid to add to UFO Extender. I suppose it could also be implemented using Vulnerabilities (no Vulnerabilities are in effect until the Autopsy is completed), or Resistances (across-the-board increased Resistances until Autopsy is completed). If that's easier.

The bonus to hp was an initial thought. Later, I decided against it since it would make aliens more resistant to HE and stun, which don't rely on hitting the right locations. Increasing resistances would be the most appropriate but the damage routine code is very tight and adding anything new that won't break the existing variable stack pointers is tough. Tycho

A new idea for this that I recently have been toying with, would be on the damage generation routine: Most direct fire damage is 0-200 50-150%, with anything over 100% considered a "critical hit". If autopsy hasn't been preformed, then the base damage would be 0-100% and a small chance (maybe 25%) of another 0-50% for that lucky shot. With autopsy done, the game reverts back to the usual 0-200% on any hit.

That works. And it makes doing Alien Autopsies a no-brainer, as it should be. It is pretty much inconceivable that XCom wouldn't prioritise the autopsy of any newly encountered alien. And any player playing the game for the first time would do autopsies too. This mod will help experienced players to stop playing as if they've "seen it all before". Spike 10:35, 15 September 2012 (EDT)

Would it also be worth adding some kind of bonus for Live Alien research? Maybe the negation of some kind of Morale penalty and/or Psi penalty? Fear of the unknown, know your enemy, that kind of thing?

I thought about that but the game doesn't record live aliens that have been researched. When you finish research on a live alien, it only follows the routine to unlock the appropriate UFOpaedia articles and then checks to see if the finished research can unlock other topics. Tycho

I had a further thought on this while trying to guess what your new pre-requisites are for the various armours. For now it's really cool to be guessing but once people have figured it out, well, it will be more logical but still will have 'replay fatigue'. Would it be possible to randomise the pre-requisites for a lot of the key research topics, from out of a plausible list of items (or even randomise pre-requisite topics)? That would make every game fresh in terms of the research sequence, and make the research aspect of the game more challenging and less dry & predictable. As ever, just a suggestion. :) Cheers, Spike 16:01, 19 October 2012 (EDT)

I am going to do some major changes to how this is implemented and it will go hand-in-hand with changes to the interaction with armor. Currently I am doing this for EU since I've got a lot of help recently with music and video from members of the community.

1)For AP the armor works as it does currently: The armor value is applied as is and damage that is lower than the value is ignored but a hit that penetrates does very little damage to the armor itself.

2)Laser(Gauss) and Plasma(Sonic) attacks will eat away at the armor: The current armor value in the location hit is doubled and then damage is subtracted from this value. The remaining armor value (if any) is halved and saved for the next hit. For these attack types, armor is stronger but quickly is gone. A soldier in power(ion) armor can take at least one seriously good hit from a heavy plasma(sonic) from the front without damage to the soldier. In testing, I've had a lot of occasions were a soldier in coveralls was able to take a hit from a plasma pistol, although be seriously wounded in the process.

3)HE works just like laser and plasma.

4)Stun damage depends on the weapons used: the stun rod works like an AP attack vs armor (just like it does now: normal), but a stun bomb is applied against the modified armor value.

5)IN still works the same. Fire damage is unchanged.

Know thy Enemy: It affects the damage that is applied against the unit's health:

• Headshot: full damage
• Other: If autopsy on this unit type has been done: full damage. Otherwise half damage.

General Tank Modding

I see you are interested in modding tanks (HWPs/SWPs) and that's partly what got you into updating UFO Extender. I made some suggestions for Tank Modding myself, including some of the mechanics required to make it work via a config file such as the UFO / TFD Extender config file. For example you could have cargo carrier / ambulance / casevac tanks, you could have demolition tanks, mine thrower tanks, and of course tanks with custom weapons including dual weapons. Could you have a look here: User:Spike#Tank_mods and see if any of that makes you feel like getting creative?

Thanks, Spike 10:46, 3 September 2012 (EDT)

TFTDextender and XComUtil

I suggest adding a section on co-operating with XComUtil. And why it should be so complicated? Is it possible to make needed changes in XComUtil? But it has support for UFOextender - why not for TFTDextender?

All good questions. I suggest you contact BladeFirelight, who is developing XComUtil (still?). - Tycho

A couple of notes;

Getting TFTDextender to work with XcomUtil does indeed have to be handled by XcomUtil. The steps described above are not sufficient, as XcomUtil needs to know the filename for TFTDextender.

I put together a patch for XcomUtil that adds the support, but this was close-ish to the time when TFTDextender was still named TFTDLoader. Which means you still have to rename the extender executable, but it's buried away here if anyone wants to take a look. I may update it shortly and send it off to Blade again.

For whatever reason, kryub's fix for the splitter code STILL doesn't prevent an error on exiting the geoscape to the battlescape, but only if using TFTDextender, and not if you're quitting the game completely. I've been right through the ini and disabled everything I could find (cross checking against the ini ref file - by the way, that doesn't mention the "Enhanced Tactical AI" flags), but couldn't find a way to prevent this. Oddly enough it only seems to happen on my XP machine, not my Windows 7 laptop. The error is:

TFTD crashed at 0x7C9102F6 with error 0xC0000005 trying to access 0x00000002

-  Bomb Bloke (Talk/Contribs) 20:04, 24 January 2013 (EST)

After using your patch, I managed to get XComUtil to run with TFTD Extender. I'm using Windows XP Home. I get the above error when the program swaps from Geoscape to Battlescape and I get another error upon 'Quit to DOS' [TFTD crashed at 0x1 with error 0xC0000005 trying to access 0x00000001] with any version of TFTD Extender or even Xusalik's TFTDloader. --Tycho 20:26, 26 January 2013 (EST). The only thing I can think to do from this end would be add an option that would disable the debug portion of the Loader. - Tycho 08:57, 29 January 2013 (EST)

I was thinking of suggesting that myself, but there are pros and cons... You'd want to leave the message prompts enabled, by default.

Note that disabling the code entirely is even worse, because then the default Windows debugger takes over and that takes ages to load if it's not already in RAM (and of course that still gives you an error pop-up window)... You'd want it to still catch crashes, but then just exit cleanly if it detects one. -  Bomb Bloke (Talk/Contribs) 16:58, 29 January 2013 (EST)

One could always disable the Windows Debugger, since it's of no use to anyone because XP is a "dead" OS: System Properties>Advanced Settings>Error Reporting>Select 'Disable Error Reporting' and uncheck the option to report only if there is a serious error. - I do this with every version of Windows I'm using, since I never had patience for the delay as the debugger loads. - Tycho 22:16, 29 January 2013 (EST)

Good point - I also used to do that in the past, but it seems I somehow forgot about that with my current unit.

So assuming you go with this, it'd be worth mentioning that OS setting in the Extender FAQ, not because it's anything to do with the Extender as such, but because people will look for it there. -  Bomb Bloke (Talk/Contribs) 04:15, 30 January 2013 (EST)

I need to ensure that it would only be disabled in the case of Windows XP and a split executable. All other combinations seem to work correctly. BTW, thanks for the heads up about the missing entries in the INI ref file. An oversight because I'm juggling between two similar programs and I'm getting easily confused.-Tycho 00:41, 31 January 2013 (EST)

Reckon it'd be better off to make it a user-setting rather then trying to detect the environment and whatnot. Having it automatically disabled might make it tricky to diagnose other crashes later down the track. -  Bomb Bloke (Talk/Contribs) 02:14, 31 January 2013 (EST)