https://temp.ufopaedia.org/api.php?action=feedcontributions&feedformat=atom&user=Player701UFOpaedia - User contributions [en]2026-05-01T09:13:36ZUser contributionsMediaWiki 1.43.6https://temp.ufopaedia.org/index.php?title=Talk:Innate_Weapons_(TFTD)&diff=90421Talk:Innate Weapons (TFTD)2020-04-18T07:29:22Z<p>Player701: /* Snap accuracy of the sonic turret */ new section</p>
<hr />
<div>== Snap accuracy of the sonic turret ==<br />
<br />
The sonic turret's snap accuracy is listed here as 86, but the articles [[Displacer /Sonic]], [[Bio-Drone]] and [[Triscene]] all say that the snap accuracy is 85. Does anyone know what the correct value is, 86 or 85? [[User:Player701|Player701]] ([[User talk:Player701|talk]]) 07:29, 18 April 2020 (UTC)</div>Player701https://temp.ufopaedia.org/index.php?title=Talk:TFTDextender&diff=40542Talk:TFTDextender2012-10-29T12:52:03Z<p>Player701: /* Cannot build Leviathan */</p>
<hr />
<div>=Questions or Comments=<br />
'''A place to provide feedback or ask questions:'''<br />
<br />
The zip archive does not seem to include an .ini file. Where do I get the .ini file from? <br />
:: Oh hang on. It looks like the latest version of the zip file does not include the .ini file. When I go back to the previous version of the zip file, I can see the .ini file. [[User:Spike|Spike]] 17:45, 6 September 2012 (EDT)<br />
<br />
:::''The latest release is a patch, which means there are no new additions to the INI. I don't include it in patches usually so that those who already have the prior release don't have to reconfigure their current INI. It may not seem like a big deal now but earlier, I was releasing fixes almost on a weekly basis and so I still continue with that idea.''[[User:Morgan525|Tycho]]<br />
<br />
== Bug Reports ==<br />
<br />
=== Crash when starting a landed/crashed USO battle ===<br />
<br />
:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."<br />
<br />
''Interesting. I had someone report a similar thing when they were starting their first instance of the battlescape on a new install of the game. I looked into it and the game generated some bad data. When he let the UFO take off and land again, the battle started with no problems..''<br />
<br />
:It's [[Known_Bugs_(TFTD)#Geoscape_Bugs|a bug I've reported before]] (before TFTD Extender even existed), so it's not specific to TFTDExtender / UFOExtender. What is happening is the Alien Sub is landing on land, and the Triton is also attempting to land on land. Probably the game crashes when it fails to generate the appropriate terrain type? So the GEOSCAPE map/terrain data must be corrupted. I've seen three examples of this. In a couple of cases the landing site is clearly inland, by hundreds of kilometres. In some cases it's right on the sea/land boundary and hard to tell. I have two save games that reproduce the bug now. From memory, the previous cases all happened around North Africa, like these present cases. [[User:Spike|Spike]] 08:31, 9 September 2012 (EDT)<br />
<br />
:''I think the problem is that there is no database to reference what type of terrain to load. EU would reference this based on map coordinates. Since USO aren't usually engaged over land, the map generator can't get an appropriate tileset for the location in these cases.-[[User:Morgan525|Tycho]]''<br />
<br />
=== Cannot build Leviathan ===<br />
<br />
Hi Tycho. I've just researched Leviathan in my TFDExtender game but cannot manufacture it! I have enough resources (Plastics, IBA, ManNav), 3 workshops, more than 100 technicans and one empty sub pen. But when starting the Leviathan manufacture task I cannot assign any technicans to it. I press the "up" button, and there are no reaction to this. I can build Manta, but not Leviathan. Don't you know what is it? [[User:PavelB|PavelB]] 06:55, 2 October 2012 (EDT)<br />
<br />
:''I was able to replicate Pavel's problem and quickly 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. A simple change and the problem is fixed with patch 3.1 - [[User:Morgan525|Tycho]] 07:29, 28 October 2012 (EDT)''<br />
<br />
::I'm sorry, but I've just downloaded this patch and for me this error has not been fixed (I simply ran into the same problem and went here to check it out). Maybe this doesn't work with saved games? I'm pretty sure I've downloaded the correct file, checked three times... --[[User:Player701|Player701]] 13:50, 28 October 2012 (EDT)<br />
<br />
:''A saved game won't matter as it was a line in the routine for creating a production order. Are you using extender 1.05 and patch3.1? What OS are you running and are you running any other mods?-[[User:Morgan525|Tycho]]''<br />
<br />
:: I've done a "clean" test: deleted all files related to the Extender and redownloaded [http://ufopaedia.org/images/archive/9/9c/20120828095852%21TFTDextender.zip this] (comment says: version 1.05) and [http://ufopaedia.org/images/9/9c/TFTDextender.zip this] (comment says: patch 3.1), extracted them to the game directory, overwriting patcher.dll from the first archive with the new file from the second archive. Still doesn't work. Using Windows 7 64-bit. No, I'm not using any other mods apart from the Extender itself. --[[User:Player701|Player701]] 08:51, 29 October 2012 (EDT)<br />
<br />
== Minor Bugs ==<br />
<br />
=== Weightless Ammo Bug ===<br />
<br />
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)<br />
<br />
''From what I understand right now, I am pretty sure I can arrange it so that weapons are not automatically loaded and soldiers would be given an extra clip. Feedback?''<br />
: By an extra clip, you mean the clip/ammo that would have been loaded into the weapon is instead carried by the soldier? And for carried clips, the encumbrance effects are correct. For me anyway, in order of most benefit, the options would be<br />
:# Fix the root cause of the bug (ensure all relevant object locations and "contains/contained in" pointers are set during automatic clip loading) so that automatically loaded clips correctly affect encumbrance <br />
:# As a workaround, don't load ammo for multi-ammotype weapons (Heavy Cannon/Gas Cannon, Auto-Cannon/Hydrojet Cannon, Rocket Launcher / Torpedo Launcher). These are the weapons for which the bug has the greatest impact, since it imposes a 'cost' of switching away from the automatically-loaded ammo (usually AP or Small Rocket/Torp). With single-ammotype weapons, there's never any need to change the clips before combat. <br />
:# As a workaround, don't load ammo for any weapons. This avoids the 'switching cost' issue but does impose a fairly significant logistics overhead on each combat, to go through and manually load all clips. Plus the risk that you forget to load a weapon and only find out at a critical moment. :) This is for the "purist" who wants to make the game harder.<br />
:If it's tricky to fix the root cause, any of the other two options would be helpful. Suggested text:<br />
:* [Multi Ammo Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. Weapons using multiple ammo types (Heavy Cannon, Auto-Cannon, Rocket Launcher / Gas Cannon, Hydrojet Cannon, Torpedo Launcher) will not be pre-loaded before combat. You will need to load these weapons manually during the pre-combat Equip phase. This will significantly affect the heavy weapons ammunition load your squad can carry into combat without suffering encumbrance penalties, thus making the early game harder.<br />
:* [All Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. This option overrides the previous option. No weapons will be pre-loaded before combat. You will need to load all ammo manually during the pre-combat Equip phase. This will significantly affect the ammunition load your squad can carry into combat without suffering encumbrance penalties, making the early game harder.<br />
:[[User:Spike|Spike]] 05:10, 21 September 2012 (EDT)<br />
::''I found the source of the problem: 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 changed in inventory management.-''[[User:Morgan525|Tycho]] 19:00, 19 October 2012 (EDT)<br />
::: That is just awesome! :D [[User:Spike|Spike]] 22:36, 19 October 2012 (EDT)<br />
<br />
=== MIA Bugs ===<br />
<br />
==== Supernumary MIA on Abort ====<br />
<br />
I Abort a mission with 8 Aquanauts and get the confirmation message "8 Aquanauts inside craft, 2 outside". No one has been stunned or MCd. I did have two aquanauts, only, outside, but they have moved back inside the transport. Very odd. Saved Equipment was enabled. [[User:Spike|Spike]] 11:06, 5 October 2012 (EDT)<br />
<br />
:''How many Aquanauts did you have in total?- -''[[User:Morgan525|Tycho]] 02:54, 11 October 2012 (EDT)<br />
:: I started the mission with only 8 Aquanauts and they all survived. Only two had even been outside the transport (quite an unusual situation). However I can't reproduce this bug, so please ignore it unless/until I can reproduce it. :) [[User:Spike|Spike]] 06:48, 17 October 2012 (EDT)<br />
<br />
==== Crewed Flying Sub Lost on Abort ====<br />
<br />
Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)<br />
<br />
:Presumably the 3 aquanauts in the craft were not stunned or mind controlled on the Abort turn? [[User:Spike|Spike]] 16:37, 21 October 2012 (EDT)<br />
:Right, they are not stunned (or dead) and they are under your control. And they are definitely in the sub. OK this is similar to a minor bug I have seen before - see [[#Supernumary MIA on Abort|preceding item]]. On your pre-abort confirmation screen it says "3 units in craft, 9 units outside". I've had a similar issue before. It's double counting your aquanauts as being both inside and outside the craft on the confirm screen, since you only have 9 units (8 and 1 tank) in total. On actual abort you incorrectly get 9 MIAs (including the tank presumably) and I guess that's why you lose the sub. Interestingly, the 3 affected aquanauts look like they never moved from their original positions, is that true? I believe when I've had similar problems before, it related to aquanauts who had never left the sub / never left their initial positions. We will have to see if Tycho can get to the bottom of this one. [[User:Spike|Spike]] 16:51, 21 October 2012 (EDT)<br />
::Yes, that's true - those 3 haven't moved from their original positions. --[[User:Player701|Player701]] 17:19, 21 October 2012 (EDT)<br />
<br />
:''I found the nature of the issue here: On one hand, all parts of the tank are being counted separately but then the End of Battle routine calculates the correct number of units but when it goes to locate the units on the battlefield, the three other parts of the tank are being tallied and thus the last three aquanauts are not checked since the 4 areas of the tank are first in the UNITPOS.DAT file.-[[User:Morgan525|Tycho]] 09:47, 24 October 2012 (EDT)''<br />
<br />
==== Stunned Carried Aquanauts MIA on Abort ====<br />
<br />
While you are looking the EOB script, I noticed one more anomaly. I'm not sure if this is an original bug or an Extender bug. If you are carrying a stunned Aquanaut in the transport at the time of Abort, the stunned Aquanaut is lost (MIA). You have to drop the stunned Aquanaut on the floor. Probably this is because the position of the Aquanaut has not been updated and is still pointing to where they were stunned, not to the location of the carrying Aquanaut. [[User:Spike|Spike]] 04:49, 27 September 2012 (EDT)<br />
<br />
:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. At least it is manageable: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)<br />
<br />
=== Items on transport floor lost on Abort ===<br />
<br />
I went in to a mission with ten Sonic Cannons and came back with 3, despite retrieving them from the battlefield and dumping them on the transport floor. I only had 3 aquanauts on the transport armed with Sonic Cannon at the time of abort. The rest were stunned or unarmed. I also dumped half a dozen corpses and some alien items on the transport floor and I don't think those made it back to my base either. The transport was operating from base 2 rather than base 1, in case that's a factor. This may be an original bug of course. I just read through the multiplayer TFTD LP on StrategyCore, and they reported missing equipment on a lot of missions. I can go back and check if the missing equipment was on abort missions rather than victory missions. Sorry not to provide more specifics at this time but it was a hard mission and not exactly a controlled experiment. ;) [[User:Spike|Spike]] 21:35, 23 October 2012 (EDT)<br />
: I tried to reproduce this in the unmodified game without success, controlling for aquanauts being stunned/not stunned, inside/outside transport, stunned inside/outside transport. I didn't control for reloading the game, that sometimes causes glitches. I will retry with the Extender next and see if that reproduces anything. [[User:Spike|Spike]] 21:06, 24 October 2012 (EDT)<br />
Here's another thought. The problematic game was a Colony Assault which has a lot of objects in the object table. As the missing objects were created (corpses) or dropped (weapons) after the game started, they could be a long way down the object table. Now, doesn't TFTD have a bigger object table than EU? Maybe the TFTDextender is only recovering items from a sub-section of the TFTD object table? [[User:Spike|Spike]] 17:13, 26 October 2012 (EDT)<br />
<br />
== Save Equipment not working? ==<br />
<br />
With "Save Equipment" option enabled, the soldiers' loadout at first was always like this: grenade in leg slot, clip in backpack - and it didn't change on the next mission, despite the fact that I re-equipped the soldiers correctly (grenades and clips on the belt). When I manufactured Gauss Rifles and issued them to my soldiers, it got even worse - none of the soldiers got clips, and two of the rifles were unloaded. Next I upgraded to Sonic-Blasta Rifles and now nothing, except some grenades (still in leg slots), is issued to the soldiers at all. "Save Equipment" was known to work in UFOExtender, did something get broken? --[[User:Player701|Player701]] 09:18, 21 October 2012 (EDT)<br />
<br />
:''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. See the discussion on problems with the OBDATA mod about the final source of the problem and its solution.-[[User:Morgan525|Tycho]] 20:03, 21 October 2012 (EDT)''<br />
<br />
:: Would you suggest that everyone disables Save Equipment for the time being, in TFTDextender? [[User:Spike|Spike]] 07:44, 24 October 2012 (EDT)<br />
<br />
:''It couldn't hurt. I believe that TFTD has its own form of autoequip and part of the solution will probably require that I disable it. Something similar happened to the "stunned units are KIA" mod from UFOextender: TFTD has its own version that conflicted but, since it worked well, I only needed to add code to update the unit's location so the corpse would appear in the right place.-[[User:Morgan525|Tycho]] 22:38, 24 October 2012 (EDT)''<br />
<br />
:: I just did a few tests in raw TFTD (Steam CE) and the auto equip function is pretty basic: Give everyone a loaded weapon in what is probably reverse OBDATA.DAT order, then dish out any extra clips, grenades etc. Are you thinking that the Save Equipment efforts of TFTDextender are then being overwritten or partly overwritten by the existing TFTD auto equip function? I guess that would make sense. [[User:Spike|Spike]] 11:01, 25 October 2012 (EDT)<br />
<br />
=Resolved Problems=<br />
===<s> Executable directive </s>===<br />
''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)<br />
<br />
=== <s>Extra Artefacts Reported</s> ===<br />
''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)<br />
''This will be fixed in the next release.-''[[User:Morgan525|Tycho]] 03:00, 13 October 2012 (EDT)<br />
: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
===<s>Manufacturing Projects Minimum Production</s> ===<br />
<br />
In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''<br />
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)<br />
<br />
Tested - If I reduce the production quantity of a current production run to less than what as already been produced, the display completion time changes (incorrectly) to 'Indefinite', but production ends after completion of the next unit. So if I start by producing 10 units, wait until I have produced 2, then reduce the quantity to 2 (or probably 1), production stops after 3 units. Thies basically replicates the pre-existing behaviour when using the down arrow on the Quantity, so there has been no loss of functionality with your Mod. Also, Autosell and Autoproduce work normally when applied as changes to an existing production run. The only thing is I can't distinguish them on the Manufacturing display - both say 'unlimited' quantity and 'indefinite' period - is that intended? I suppose it makes sense, but it would be good to be able to tell which kind of production it is, *** Autoproduce or $$$ Autosell. [[User:Spike|Spike]] 08:57, 2 October 2012 (EDT)<br />
<br />
:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''<br />
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)<br />
:::''OK. Changed the output to display "$unlimited$".[[User:Morgan525|Tycho]]<br />
<br />
===<s>Stunned MC'd Aquanauts MIA on Abort </s> ===<br />
<br />
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. <br />
::''I now have the code in place to uncontrol any creature that has been rendered unconscious. - -''[[User:Morgan525|Tycho]] 02:47, 11 October 2012 (EDT)<br />
This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
=== <s>Grenade Resistance in INI file </s> ===<br />
:''I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]<br />
<br />
<br />
===<s> Materials deducted from wrong base </s>===<br />
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''<br />
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)<br />
<br />
===<s> OBDATA / Dye Grenade mod not working? </s>===<br />
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)<br />
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
== <s>Displacer/Sonic damage fix</s> ==<br />
<br />
'' I changed the damage to be 130, same as the UFOpaedia entry.-''[[User:Morgan525|Tycho]] 03:52, 13 October 2012 (EDT)<br />
<br />
==<s> Weight Display in Inventory not Localised </s> ==<br />
<br />
At least when I run the game in German, it comes up as "Weight" and not something like "Gewicht". Reactions comes up ok as "Zeitwerte". [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
<br />
:''Added ability for users to added their own language by copying lines from Extender's page under the equipment section to the same section in their INI, alter the text as specified, and save the INI' [[User:Morgan525|Tycho]]<br />
<br />
<br />
== Things that TFTDextender does not fix ==<br />
<br />
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?):<br />
<br />
* 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.<br />
* Does not fix the incorrect pictures for the large USO in the interception window. <br />
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]<br />
* 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.)<br />
* 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).<br />
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.<br />
* 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.<br />
<br />
= Feature Requests and Suggestions =<br />
<br />
== Useful alien species research ==<br />
<br />
Tycho, I really like this idea you proposed in the StrategyCore forum:<br />
<br />
: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.<br />
<br />
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. <br />
<br />
:''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.'' [[User:Morgan525|Tycho]]<br />
::''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%, 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-100% for that lucky shot. With autopsy done, the game reverts back to the usual 0-200% on any hit.''<br />
<br />
::: 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". [[User:Spike|Spike]] 10:35, 15 September 2012 (EDT)<br />
<br />
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?<br />
<br />
:''I thought about that but the game doesn't record live aliens that have been researched. When you finish research on a live alien, it only follows the routine to unlock the appropriate UFOpaedia articles and then checks to see if the finished research can unlock other topics.'' [[User:Morgan525|Tycho]]<br />
<br />
I had a further thought on this while trying to guess what your new pre-requisites are for the various armours. For now it's really cool to be guessing but once people have figured it out, well, it will be more logical but still will have 'replay fatigue'. Would it be possible to randomise the pre-requisites for a lot of the key research topics, from out of a plausible list of items (or even randomise pre-requisite topics)? That would make every game fresh in terms of the research sequence, and make the research aspect of the game more challenging and less dry & predictable. As ever, just a suggestion. :) Cheers, [[User:Spike|Spike]] 16:01, 19 October 2012 (EDT)<br />
<br />
== All Units Can "Fly" In Water ==<br />
<br />
It's very illogical that most units are stuck on the seabed in underwater missions. Please provide the option to set all units (X-Com and alien) to have "flying" (i.e. swimming) ability when underwater. This is unlikely to cause an outbreak of 3D combat, since there is no cover except at seabed level, so anyone swimming excessively or incautiously is going to get shot. It might disadvantage the aliens if their tactical map waypoints are all set on the surface. But as some of them can "fly", there is hopefully a mechanism to deal with that in the code already. For me it will just solve the frustration of being unable to swim over small obstacles or swim up a level, and being stuck or tactically limited for no sensible reason. Mag-Ion Armour remains useful as an important step in Sub Research and (if using the Everything Works on Land mod) for land use. [[User:Spike|Spike]] 11:36, 9 September 2012 (EDT)<br />
: This requires setting [[UNITREF.DAT]] byte 0x78 bit 2 for the unit (e.g. for all units on both sides). Or the in-memory equivalent of UNITREF.DAT. [[User:Spike|Spike]] 10:19, 5 October 2012 (EDT)<br />
<br />
== Aliens Pick Up Weapons ==<br />
<br />
Related to Improved Alien AI. This makes the game tougher as stunned / panicked bipedal-type aliens are no longer permanently disarmed. This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. A fix for this would be a very helpful rebalancing of both games that eliminates one of the aliens' weak spots. The existing (but unused) routine looks pretty smart and not immediately exploitable to ambush aliens using weapons as traps. <br />
<br />
: I noticed the UFO Extender source code has a 'get' keyword under the OBDATA.DAT directive that populates this field 0x2D. Is that working? [[User:Spike|Spike]] 21:03, 16 October 2012 (EDT)<br />
:''It should be. I haven't tested it out but it should work like any other OBDATA change, in theory. As long as the code in the AI routine handles this byte, it should work. I believe someone mentioned under the Geoscape.exe page that the AI routine ignores any value under 5.-[[User:Morgan525|Tycho]] 00:58, 25 October 2012 (EDT)''<br />
<br />
== General Tank Modding ==<br />
<br />
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?<br />
<br />
Thanks,<br />
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)<br />
<br />
== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==<br />
<br />
Hook the right and left weapon menus on mind controlled aliens to add in actions for their built in melee attacks (if they have them) and built in Psi/MC attacks (if they have Psi/MC Skill). Ideally add these actions to the menu, and pop up a menu, even if the alien isn't holding any weapons.<br />
<br />
This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.<br />
<br />
== Fix Interception and Navigation Course Algorithms ==<br />
<br />
Or just find the algorithms and I volunteer to fix them!<br />
<br />
=== Use Great Circle Routes ===<br />
<br />
Travel toward the target on the shortest Great Circle, rather than always travelling along lines of latitude first (like they are some kind of main bus route!). <br />
<br />
=== Use Predictive Interception ===<br />
<br />
For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.<br />
<br />
=== Show Degree Headings ===<br />
<br />
The game only ever reports alien headings as North, South, East, West, but clearly alien craft move in other directions than just these four, and clearly XCOM detection equipment is capable of resolving these finer-grained headings, since the crafts' tracks are shown correctly in the Geoscope. <br />
As a first step towards predictive interceptions, it would be great to display the alien craft's heading in degrees, eg 135 degrees for South-East. Maybe rounded to the nearest 5 or 10 degrees.<br />
<br />
== Interception Craft vs Touched Down Alien Craft == <br />
<br />
If an alien craft is touched down and an XCOM interception craft (not touched down) is at the same X/Y position, if the alien craft begins to move, immediately open the Interception window at minimum range (8km/nm), presumably with the alien attempting to get away / break off. Currently the Interception window only happens if the XCom craft is faster, which is dumb, ''even if'' the alien craft could accelerate instantly to its maximum speed. <br />
<br />
For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach. <br />
<br />
== Fun, not Funky, Fire ==<br />
<br />
An alternative option for incendiaries/phosphorous damage processing: Do process the so called 'impact' damage of an incendiary on every shot, not just at the end of the turn. But only apply it to those in the area of affect of this specific shell burst, not to all units who are standing in smoke or fire anywhere on the map. This will please fans of incendiaries/phosphorous. It's probably a balancing, rather than unbalancing, change in the relative strengths of the ammo types. Makes incendiaries/phosphorous useful for more than just illumination or desperation. Gives some use to the research topics that advise use of incendiaries/phosphorous, and the damage modifiers aliens have been assigned.<br />
<br />
== Rearming Rates ==<br />
<br />
<br />
From [[Known_Bugs_(TFTD)#Geoscape_Bugs]]:<br />
<br />
=== Craft Gauss Cannon Rearming Rate ===<br />
<br />
This weapon rearms at 10/hr but probably should be 50/hr or at least 25/hr, otherwise it is far slower to rearm than any other cannon weapon in either game. In fact it's the second slowest weapon system to rearm, slower only than AJAX...<br />
<br />
=== AJAX Rearming Rate ===<br />
<br />
An AJAX system takes twice as long to fully reload as a D.U.P. system, as a result AJAX-armed Craft have much worse operational tempo and readiness than D.U.P. armed Craft. Like we needed yet another reason to always use D.U.Ps. This is probably a design error rather than a bug, but it would be good to fix it - anything to give a more balanced set of craft weapon choices. The rearming rate should be raised from 1/hr to 2/hr. The AJAX system will then have the same operational tempo as the D.U.P. system. <br />
<br />
Could also be applied to Stingray missiles in EU 1994, as the same analysis applies to Stingray vs Avalanche.<br />
<br />
== Retaliate for Colony Assault ==<br />
<br />
See this discussion [[Talk:Alien_Retaliation#Retaliation_Triggers]]. Colony raids are a good way for the alien to lose badly, so it would be a good balancing move to create severe consequences for raiding. It is at least as sensible as retaliation for USO Assaults.</div>Player701https://temp.ufopaedia.org/index.php?title=Talk:TFTDextender&diff=40541Talk:TFTDextender2012-10-29T12:51:06Z<p>Player701: /* Cannot build Leviathan */</p>
<hr />
<div>=Questions or Comments=<br />
'''A place to provide feedback or ask questions:'''<br />
<br />
The zip archive does not seem to include an .ini file. Where do I get the .ini file from? <br />
:: Oh hang on. It looks like the latest version of the zip file does not include the .ini file. When I go back to the previous version of the zip file, I can see the .ini file. [[User:Spike|Spike]] 17:45, 6 September 2012 (EDT)<br />
<br />
:::''The latest release is a patch, which means there are no new additions to the INI. I don't include it in patches usually so that those who already have the prior release don't have to reconfigure their current INI. It may not seem like a big deal now but earlier, I was releasing fixes almost on a weekly basis and so I still continue with that idea.''[[User:Morgan525|Tycho]]<br />
<br />
== Bug Reports ==<br />
<br />
=== Crash when starting a landed/crashed USO battle ===<br />
<br />
:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."<br />
<br />
''Interesting. I had someone report a similar thing when they were starting their first instance of the battlescape on a new install of the game. I looked into it and the game generated some bad data. When he let the UFO take off and land again, the battle started with no problems..''<br />
<br />
:It's [[Known_Bugs_(TFTD)#Geoscape_Bugs|a bug I've reported before]] (before TFTD Extender even existed), so it's not specific to TFTDExtender / UFOExtender. What is happening is the Alien Sub is landing on land, and the Triton is also attempting to land on land. Probably the game crashes when it fails to generate the appropriate terrain type? So the GEOSCAPE map/terrain data must be corrupted. I've seen three examples of this. In a couple of cases the landing site is clearly inland, by hundreds of kilometres. In some cases it's right on the sea/land boundary and hard to tell. I have two save games that reproduce the bug now. From memory, the previous cases all happened around North Africa, like these present cases. [[User:Spike|Spike]] 08:31, 9 September 2012 (EDT)<br />
<br />
:''I think the problem is that there is no database to reference what type of terrain to load. EU would reference this based on map coordinates. Since USO aren't usually engaged over land, the map generator can't get an appropriate tileset for the location in these cases.-[[User:Morgan525|Tycho]]''<br />
<br />
=== Cannot build Leviathan ===<br />
<br />
Hi Tycho. I've just researched Leviathan in my TFDExtender game but cannot manufacture it! I have enough resources (Plastics, IBA, ManNav), 3 workshops, more than 100 technicans and one empty sub pen. But when starting the Leviathan manufacture task I cannot assign any technicans to it. I press the "up" button, and there are no reaction to this. I can build Manta, but not Leviathan. Don't you know what is it? [[User:PavelB|PavelB]] 06:55, 2 October 2012 (EDT)<br />
<br />
:''I was able to replicate Pavel's problem and quickly 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. A simple change and the problem is fixed with patch 3.1 - [[User:Morgan525|Tycho]] 07:29, 28 October 2012 (EDT)''<br />
<br />
::I'm sorry, but I've just downloaded this patch and for me this error has not been fixed (I simply ran into the same problem and went here to check it out). Maybe this doesn't work with saved games? I'm pretty sure I've downloaded the correct file, checked three times... --[[User:Player701|Player701]] 13:50, 28 October 2012 (EDT)<br />
<br />
:''A saved game won't matter as it was a line in the routine for creating a production order. Are you using extender 1.05 and patch3.1? What OS are you running and are you running any other mods?-[[User:Morgan525|Tycho]]''<br />
<br />
:: I've done a "clean" test: deleted all files related to the Extender and redownloaded [http://ufopaedia.org/images/archive/9/9c/20120828095852%21TFTDextender.zip this] (comment says: version 1.05) and [http://ufopaedia.org/images/9/9c/TFTDextender.zip this] (comment says: patch 3.1), extracted them to the game directory, overwriting patcher.dll from the first archive with the new file from the second archive. Still doesn't work. Using Windows 7 64-bit. --[[User:Player701|Player701]] 08:51, 29 October 2012 (EDT)<br />
<br />
== Minor Bugs ==<br />
<br />
=== Weightless Ammo Bug ===<br />
<br />
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)<br />
<br />
''From what I understand right now, I am pretty sure I can arrange it so that weapons are not automatically loaded and soldiers would be given an extra clip. Feedback?''<br />
: By an extra clip, you mean the clip/ammo that would have been loaded into the weapon is instead carried by the soldier? And for carried clips, the encumbrance effects are correct. For me anyway, in order of most benefit, the options would be<br />
:# Fix the root cause of the bug (ensure all relevant object locations and "contains/contained in" pointers are set during automatic clip loading) so that automatically loaded clips correctly affect encumbrance <br />
:# As a workaround, don't load ammo for multi-ammotype weapons (Heavy Cannon/Gas Cannon, Auto-Cannon/Hydrojet Cannon, Rocket Launcher / Torpedo Launcher). These are the weapons for which the bug has the greatest impact, since it imposes a 'cost' of switching away from the automatically-loaded ammo (usually AP or Small Rocket/Torp). With single-ammotype weapons, there's never any need to change the clips before combat. <br />
:# As a workaround, don't load ammo for any weapons. This avoids the 'switching cost' issue but does impose a fairly significant logistics overhead on each combat, to go through and manually load all clips. Plus the risk that you forget to load a weapon and only find out at a critical moment. :) This is for the "purist" who wants to make the game harder.<br />
:If it's tricky to fix the root cause, any of the other two options would be helpful. Suggested text:<br />
:* [Multi Ammo Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. Weapons using multiple ammo types (Heavy Cannon, Auto-Cannon, Rocket Launcher / Gas Cannon, Hydrojet Cannon, Torpedo Launcher) will not be pre-loaded before combat. You will need to load these weapons manually during the pre-combat Equip phase. This will significantly affect the heavy weapons ammunition load your squad can carry into combat without suffering encumbrance penalties, thus making the early game harder.<br />
:* [All Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. This option overrides the previous option. No weapons will be pre-loaded before combat. You will need to load all ammo manually during the pre-combat Equip phase. This will significantly affect the ammunition load your squad can carry into combat without suffering encumbrance penalties, making the early game harder.<br />
:[[User:Spike|Spike]] 05:10, 21 September 2012 (EDT)<br />
::''I found the source of the problem: 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 changed in inventory management.-''[[User:Morgan525|Tycho]] 19:00, 19 October 2012 (EDT)<br />
::: That is just awesome! :D [[User:Spike|Spike]] 22:36, 19 October 2012 (EDT)<br />
<br />
=== MIA Bugs ===<br />
<br />
==== Supernumary MIA on Abort ====<br />
<br />
I Abort a mission with 8 Aquanauts and get the confirmation message "8 Aquanauts inside craft, 2 outside". No one has been stunned or MCd. I did have two aquanauts, only, outside, but they have moved back inside the transport. Very odd. Saved Equipment was enabled. [[User:Spike|Spike]] 11:06, 5 October 2012 (EDT)<br />
<br />
:''How many Aquanauts did you have in total?- -''[[User:Morgan525|Tycho]] 02:54, 11 October 2012 (EDT)<br />
:: I started the mission with only 8 Aquanauts and they all survived. Only two had even been outside the transport (quite an unusual situation). However I can't reproduce this bug, so please ignore it unless/until I can reproduce it. :) [[User:Spike|Spike]] 06:48, 17 October 2012 (EDT)<br />
<br />
==== Crewed Flying Sub Lost on Abort ====<br />
<br />
Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)<br />
<br />
:Presumably the 3 aquanauts in the craft were not stunned or mind controlled on the Abort turn? [[User:Spike|Spike]] 16:37, 21 October 2012 (EDT)<br />
:Right, they are not stunned (or dead) and they are under your control. And they are definitely in the sub. OK this is similar to a minor bug I have seen before - see [[#Supernumary MIA on Abort|preceding item]]. On your pre-abort confirmation screen it says "3 units in craft, 9 units outside". I've had a similar issue before. It's double counting your aquanauts as being both inside and outside the craft on the confirm screen, since you only have 9 units (8 and 1 tank) in total. On actual abort you incorrectly get 9 MIAs (including the tank presumably) and I guess that's why you lose the sub. Interestingly, the 3 affected aquanauts look like they never moved from their original positions, is that true? I believe when I've had similar problems before, it related to aquanauts who had never left the sub / never left their initial positions. We will have to see if Tycho can get to the bottom of this one. [[User:Spike|Spike]] 16:51, 21 October 2012 (EDT)<br />
::Yes, that's true - those 3 haven't moved from their original positions. --[[User:Player701|Player701]] 17:19, 21 October 2012 (EDT)<br />
<br />
:''I found the nature of the issue here: On one hand, all parts of the tank are being counted separately but then the End of Battle routine calculates the correct number of units but when it goes to locate the units on the battlefield, the three other parts of the tank are being tallied and thus the last three aquanauts are not checked since the 4 areas of the tank are first in the UNITPOS.DAT file.-[[User:Morgan525|Tycho]] 09:47, 24 October 2012 (EDT)''<br />
<br />
==== Stunned Carried Aquanauts MIA on Abort ====<br />
<br />
While you are looking the EOB script, I noticed one more anomaly. I'm not sure if this is an original bug or an Extender bug. If you are carrying a stunned Aquanaut in the transport at the time of Abort, the stunned Aquanaut is lost (MIA). You have to drop the stunned Aquanaut on the floor. Probably this is because the position of the Aquanaut has not been updated and is still pointing to where they were stunned, not to the location of the carrying Aquanaut. [[User:Spike|Spike]] 04:49, 27 September 2012 (EDT)<br />
<br />
:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. At least it is manageable: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)<br />
<br />
=== Items on transport floor lost on Abort ===<br />
<br />
I went in to a mission with ten Sonic Cannons and came back with 3, despite retrieving them from the battlefield and dumping them on the transport floor. I only had 3 aquanauts on the transport armed with Sonic Cannon at the time of abort. The rest were stunned or unarmed. I also dumped half a dozen corpses and some alien items on the transport floor and I don't think those made it back to my base either. The transport was operating from base 2 rather than base 1, in case that's a factor. This may be an original bug of course. I just read through the multiplayer TFTD LP on StrategyCore, and they reported missing equipment on a lot of missions. I can go back and check if the missing equipment was on abort missions rather than victory missions. Sorry not to provide more specifics at this time but it was a hard mission and not exactly a controlled experiment. ;) [[User:Spike|Spike]] 21:35, 23 October 2012 (EDT)<br />
: I tried to reproduce this in the unmodified game without success, controlling for aquanauts being stunned/not stunned, inside/outside transport, stunned inside/outside transport. I didn't control for reloading the game, that sometimes causes glitches. I will retry with the Extender next and see if that reproduces anything. [[User:Spike|Spike]] 21:06, 24 October 2012 (EDT)<br />
Here's another thought. The problematic game was a Colony Assault which has a lot of objects in the object table. As the missing objects were created (corpses) or dropped (weapons) after the game started, they could be a long way down the object table. Now, doesn't TFTD have a bigger object table than EU? Maybe the TFTDextender is only recovering items from a sub-section of the TFTD object table? [[User:Spike|Spike]] 17:13, 26 October 2012 (EDT)<br />
<br />
== Save Equipment not working? ==<br />
<br />
With "Save Equipment" option enabled, the soldiers' loadout at first was always like this: grenade in leg slot, clip in backpack - and it didn't change on the next mission, despite the fact that I re-equipped the soldiers correctly (grenades and clips on the belt). When I manufactured Gauss Rifles and issued them to my soldiers, it got even worse - none of the soldiers got clips, and two of the rifles were unloaded. Next I upgraded to Sonic-Blasta Rifles and now nothing, except some grenades (still in leg slots), is issued to the soldiers at all. "Save Equipment" was known to work in UFOExtender, did something get broken? --[[User:Player701|Player701]] 09:18, 21 October 2012 (EDT)<br />
<br />
:''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. See the discussion on problems with the OBDATA mod about the final source of the problem and its solution.-[[User:Morgan525|Tycho]] 20:03, 21 October 2012 (EDT)''<br />
<br />
:: Would you suggest that everyone disables Save Equipment for the time being, in TFTDextender? [[User:Spike|Spike]] 07:44, 24 October 2012 (EDT)<br />
<br />
:''It couldn't hurt. I believe that TFTD has its own form of autoequip and part of the solution will probably require that I disable it. Something similar happened to the "stunned units are KIA" mod from UFOextender: TFTD has its own version that conflicted but, since it worked well, I only needed to add code to update the unit's location so the corpse would appear in the right place.-[[User:Morgan525|Tycho]] 22:38, 24 October 2012 (EDT)''<br />
<br />
:: I just did a few tests in raw TFTD (Steam CE) and the auto equip function is pretty basic: Give everyone a loaded weapon in what is probably reverse OBDATA.DAT order, then dish out any extra clips, grenades etc. Are you thinking that the Save Equipment efforts of TFTDextender are then being overwritten or partly overwritten by the existing TFTD auto equip function? I guess that would make sense. [[User:Spike|Spike]] 11:01, 25 October 2012 (EDT)<br />
<br />
=Resolved Problems=<br />
===<s> Executable directive </s>===<br />
''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)<br />
<br />
=== <s>Extra Artefacts Reported</s> ===<br />
''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)<br />
''This will be fixed in the next release.-''[[User:Morgan525|Tycho]] 03:00, 13 October 2012 (EDT)<br />
: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
===<s>Manufacturing Projects Minimum Production</s> ===<br />
<br />
In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''<br />
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)<br />
<br />
Tested - If I reduce the production quantity of a current production run to less than what as already been produced, the display completion time changes (incorrectly) to 'Indefinite', but production ends after completion of the next unit. So if I start by producing 10 units, wait until I have produced 2, then reduce the quantity to 2 (or probably 1), production stops after 3 units. Thies basically replicates the pre-existing behaviour when using the down arrow on the Quantity, so there has been no loss of functionality with your Mod. Also, Autosell and Autoproduce work normally when applied as changes to an existing production run. The only thing is I can't distinguish them on the Manufacturing display - both say 'unlimited' quantity and 'indefinite' period - is that intended? I suppose it makes sense, but it would be good to be able to tell which kind of production it is, *** Autoproduce or $$$ Autosell. [[User:Spike|Spike]] 08:57, 2 October 2012 (EDT)<br />
<br />
:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''<br />
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)<br />
:::''OK. Changed the output to display "$unlimited$".[[User:Morgan525|Tycho]]<br />
<br />
===<s>Stunned MC'd Aquanauts MIA on Abort </s> ===<br />
<br />
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. <br />
::''I now have the code in place to uncontrol any creature that has been rendered unconscious. - -''[[User:Morgan525|Tycho]] 02:47, 11 October 2012 (EDT)<br />
This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
=== <s>Grenade Resistance in INI file </s> ===<br />
:''I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]<br />
<br />
<br />
===<s> Materials deducted from wrong base </s>===<br />
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''<br />
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)<br />
<br />
===<s> OBDATA / Dye Grenade mod not working? </s>===<br />
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)<br />
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
== <s>Displacer/Sonic damage fix</s> ==<br />
<br />
'' I changed the damage to be 130, same as the UFOpaedia entry.-''[[User:Morgan525|Tycho]] 03:52, 13 October 2012 (EDT)<br />
<br />
==<s> Weight Display in Inventory not Localised </s> ==<br />
<br />
At least when I run the game in German, it comes up as "Weight" and not something like "Gewicht". Reactions comes up ok as "Zeitwerte". [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
<br />
:''Added ability for users to added their own language by copying lines from Extender's page under the equipment section to the same section in their INI, alter the text as specified, and save the INI' [[User:Morgan525|Tycho]]<br />
<br />
<br />
== Things that TFTDextender does not fix ==<br />
<br />
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?):<br />
<br />
* 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.<br />
* Does not fix the incorrect pictures for the large USO in the interception window. <br />
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]<br />
* 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.)<br />
* 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).<br />
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.<br />
* 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.<br />
<br />
= Feature Requests and Suggestions =<br />
<br />
== Useful alien species research ==<br />
<br />
Tycho, I really like this idea you proposed in the StrategyCore forum:<br />
<br />
: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.<br />
<br />
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. <br />
<br />
:''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.'' [[User:Morgan525|Tycho]]<br />
::''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%, 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-100% for that lucky shot. With autopsy done, the game reverts back to the usual 0-200% on any hit.''<br />
<br />
::: 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". [[User:Spike|Spike]] 10:35, 15 September 2012 (EDT)<br />
<br />
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?<br />
<br />
:''I thought about that but the game doesn't record live aliens that have been researched. When you finish research on a live alien, it only follows the routine to unlock the appropriate UFOpaedia articles and then checks to see if the finished research can unlock other topics.'' [[User:Morgan525|Tycho]]<br />
<br />
I had a further thought on this while trying to guess what your new pre-requisites are for the various armours. For now it's really cool to be guessing but once people have figured it out, well, it will be more logical but still will have 'replay fatigue'. Would it be possible to randomise the pre-requisites for a lot of the key research topics, from out of a plausible list of items (or even randomise pre-requisite topics)? That would make every game fresh in terms of the research sequence, and make the research aspect of the game more challenging and less dry & predictable. As ever, just a suggestion. :) Cheers, [[User:Spike|Spike]] 16:01, 19 October 2012 (EDT)<br />
<br />
== All Units Can "Fly" In Water ==<br />
<br />
It's very illogical that most units are stuck on the seabed in underwater missions. Please provide the option to set all units (X-Com and alien) to have "flying" (i.e. swimming) ability when underwater. This is unlikely to cause an outbreak of 3D combat, since there is no cover except at seabed level, so anyone swimming excessively or incautiously is going to get shot. It might disadvantage the aliens if their tactical map waypoints are all set on the surface. But as some of them can "fly", there is hopefully a mechanism to deal with that in the code already. For me it will just solve the frustration of being unable to swim over small obstacles or swim up a level, and being stuck or tactically limited for no sensible reason. Mag-Ion Armour remains useful as an important step in Sub Research and (if using the Everything Works on Land mod) for land use. [[User:Spike|Spike]] 11:36, 9 September 2012 (EDT)<br />
: This requires setting [[UNITREF.DAT]] byte 0x78 bit 2 for the unit (e.g. for all units on both sides). Or the in-memory equivalent of UNITREF.DAT. [[User:Spike|Spike]] 10:19, 5 October 2012 (EDT)<br />
<br />
== Aliens Pick Up Weapons ==<br />
<br />
Related to Improved Alien AI. This makes the game tougher as stunned / panicked bipedal-type aliens are no longer permanently disarmed. This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. A fix for this would be a very helpful rebalancing of both games that eliminates one of the aliens' weak spots. The existing (but unused) routine looks pretty smart and not immediately exploitable to ambush aliens using weapons as traps. <br />
<br />
: I noticed the UFO Extender source code has a 'get' keyword under the OBDATA.DAT directive that populates this field 0x2D. Is that working? [[User:Spike|Spike]] 21:03, 16 October 2012 (EDT)<br />
:''It should be. I haven't tested it out but it should work like any other OBDATA change, in theory. As long as the code in the AI routine handles this byte, it should work. I believe someone mentioned under the Geoscape.exe page that the AI routine ignores any value under 5.-[[User:Morgan525|Tycho]] 00:58, 25 October 2012 (EDT)''<br />
<br />
== General Tank Modding ==<br />
<br />
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?<br />
<br />
Thanks,<br />
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)<br />
<br />
== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==<br />
<br />
Hook the right and left weapon menus on mind controlled aliens to add in actions for their built in melee attacks (if they have them) and built in Psi/MC attacks (if they have Psi/MC Skill). Ideally add these actions to the menu, and pop up a menu, even if the alien isn't holding any weapons.<br />
<br />
This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.<br />
<br />
== Fix Interception and Navigation Course Algorithms ==<br />
<br />
Or just find the algorithms and I volunteer to fix them!<br />
<br />
=== Use Great Circle Routes ===<br />
<br />
Travel toward the target on the shortest Great Circle, rather than always travelling along lines of latitude first (like they are some kind of main bus route!). <br />
<br />
=== Use Predictive Interception ===<br />
<br />
For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.<br />
<br />
=== Show Degree Headings ===<br />
<br />
The game only ever reports alien headings as North, South, East, West, but clearly alien craft move in other directions than just these four, and clearly XCOM detection equipment is capable of resolving these finer-grained headings, since the crafts' tracks are shown correctly in the Geoscope. <br />
As a first step towards predictive interceptions, it would be great to display the alien craft's heading in degrees, eg 135 degrees for South-East. Maybe rounded to the nearest 5 or 10 degrees.<br />
<br />
== Interception Craft vs Touched Down Alien Craft == <br />
<br />
If an alien craft is touched down and an XCOM interception craft (not touched down) is at the same X/Y position, if the alien craft begins to move, immediately open the Interception window at minimum range (8km/nm), presumably with the alien attempting to get away / break off. Currently the Interception window only happens if the XCom craft is faster, which is dumb, ''even if'' the alien craft could accelerate instantly to its maximum speed. <br />
<br />
For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach. <br />
<br />
== Fun, not Funky, Fire ==<br />
<br />
An alternative option for incendiaries/phosphorous damage processing: Do process the so called 'impact' damage of an incendiary on every shot, not just at the end of the turn. But only apply it to those in the area of affect of this specific shell burst, not to all units who are standing in smoke or fire anywhere on the map. This will please fans of incendiaries/phosphorous. It's probably a balancing, rather than unbalancing, change in the relative strengths of the ammo types. Makes incendiaries/phosphorous useful for more than just illumination or desperation. Gives some use to the research topics that advise use of incendiaries/phosphorous, and the damage modifiers aliens have been assigned.<br />
<br />
== Rearming Rates ==<br />
<br />
<br />
From [[Known_Bugs_(TFTD)#Geoscape_Bugs]]:<br />
<br />
=== Craft Gauss Cannon Rearming Rate ===<br />
<br />
This weapon rearms at 10/hr but probably should be 50/hr or at least 25/hr, otherwise it is far slower to rearm than any other cannon weapon in either game. In fact it's the second slowest weapon system to rearm, slower only than AJAX...<br />
<br />
=== AJAX Rearming Rate ===<br />
<br />
An AJAX system takes twice as long to fully reload as a D.U.P. system, as a result AJAX-armed Craft have much worse operational tempo and readiness than D.U.P. armed Craft. Like we needed yet another reason to always use D.U.Ps. This is probably a design error rather than a bug, but it would be good to fix it - anything to give a more balanced set of craft weapon choices. The rearming rate should be raised from 1/hr to 2/hr. The AJAX system will then have the same operational tempo as the D.U.P. system. <br />
<br />
Could also be applied to Stingray missiles in EU 1994, as the same analysis applies to Stingray vs Avalanche.<br />
<br />
== Retaliate for Colony Assault ==<br />
<br />
See this discussion [[Talk:Alien_Retaliation#Retaliation_Triggers]]. Colony raids are a good way for the alien to lose badly, so it would be a good balancing move to create severe consequences for raiding. It is at least as sensible as retaliation for USO Assaults.</div>Player701https://temp.ufopaedia.org/index.php?title=Talk:TFTDextender&diff=40540Talk:TFTDextender2012-10-29T12:50:56Z<p>Player701: /* Cannot build Leviathan */</p>
<hr />
<div>=Questions or Comments=<br />
'''A place to provide feedback or ask questions:'''<br />
<br />
The zip archive does not seem to include an .ini file. Where do I get the .ini file from? <br />
:: Oh hang on. It looks like the latest version of the zip file does not include the .ini file. When I go back to the previous version of the zip file, I can see the .ini file. [[User:Spike|Spike]] 17:45, 6 September 2012 (EDT)<br />
<br />
:::''The latest release is a patch, which means there are no new additions to the INI. I don't include it in patches usually so that those who already have the prior release don't have to reconfigure their current INI. It may not seem like a big deal now but earlier, I was releasing fixes almost on a weekly basis and so I still continue with that idea.''[[User:Morgan525|Tycho]]<br />
<br />
== Bug Reports ==<br />
<br />
=== Crash when starting a landed/crashed USO battle ===<br />
<br />
:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."<br />
<br />
''Interesting. I had someone report a similar thing when they were starting their first instance of the battlescape on a new install of the game. I looked into it and the game generated some bad data. When he let the UFO take off and land again, the battle started with no problems..''<br />
<br />
:It's [[Known_Bugs_(TFTD)#Geoscape_Bugs|a bug I've reported before]] (before TFTD Extender even existed), so it's not specific to TFTDExtender / UFOExtender. What is happening is the Alien Sub is landing on land, and the Triton is also attempting to land on land. Probably the game crashes when it fails to generate the appropriate terrain type? So the GEOSCAPE map/terrain data must be corrupted. I've seen three examples of this. In a couple of cases the landing site is clearly inland, by hundreds of kilometres. In some cases it's right on the sea/land boundary and hard to tell. I have two save games that reproduce the bug now. From memory, the previous cases all happened around North Africa, like these present cases. [[User:Spike|Spike]] 08:31, 9 September 2012 (EDT)<br />
<br />
:''I think the problem is that there is no database to reference what type of terrain to load. EU would reference this based on map coordinates. Since USO aren't usually engaged over land, the map generator can't get an appropriate tileset for the location in these cases.-[[User:Morgan525|Tycho]]''<br />
<br />
=== Cannot build Leviathan ===<br />
<br />
Hi Tycho. I've just researched Leviathan in my TFDExtender game but cannot manufacture it! I have enough resources (Plastics, IBA, ManNav), 3 workshops, more than 100 technicans and one empty sub pen. But when starting the Leviathan manufacture task I cannot assign any technicans to it. I press the "up" button, and there are no reaction to this. I can build Manta, but not Leviathan. Don't you know what is it? [[User:PavelB|PavelB]] 06:55, 2 October 2012 (EDT)<br />
<br />
:''I was able to replicate Pavel's problem and quickly 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. A simple change and the problem is fixed with patch 3.1 - [[User:Morgan525|Tycho]] 07:29, 28 October 2012 (EDT)''<br />
<br />
::I'm sorry, but I've just downloaded this patch and for me this error has not been fixed (I simply ran into the same problem and went here to check it out). Maybe this doesn't work with saved games? I'm pretty sure I've downloaded the correct file, checked three times... --[[User:Player701|Player701]] 13:50, 28 October 2012 (EDT)<br />
<br />
:''A saved game won't matter as it was a line in the routine for creating a production order. Are you using extender 1.05 and patch3.1? What OS are you running and are you running any other mods?-[[User:Morgan525|Tycho]]''<br />
<br />
:: I've done a "clean" test: deleted all files related to the Extender and redownloaded [http://ufopaedia.org/images/archive/9/9c/20120828095852%21TFTDextender.zip this] (comment says: version 1.05) and [http://ufopaedia.org/images/9/9c/TFTDextender.zip this] (comment says: patch 3.1), extracted them to the game directory, overwriting patcher.dll from the first archive with the new file from the second archive. Still doesn't work. Using Windows 7 64-bit.<br />
<br />
== Minor Bugs ==<br />
<br />
=== Weightless Ammo Bug ===<br />
<br />
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)<br />
<br />
''From what I understand right now, I am pretty sure I can arrange it so that weapons are not automatically loaded and soldiers would be given an extra clip. Feedback?''<br />
: By an extra clip, you mean the clip/ammo that would have been loaded into the weapon is instead carried by the soldier? And for carried clips, the encumbrance effects are correct. For me anyway, in order of most benefit, the options would be<br />
:# Fix the root cause of the bug (ensure all relevant object locations and "contains/contained in" pointers are set during automatic clip loading) so that automatically loaded clips correctly affect encumbrance <br />
:# As a workaround, don't load ammo for multi-ammotype weapons (Heavy Cannon/Gas Cannon, Auto-Cannon/Hydrojet Cannon, Rocket Launcher / Torpedo Launcher). These are the weapons for which the bug has the greatest impact, since it imposes a 'cost' of switching away from the automatically-loaded ammo (usually AP or Small Rocket/Torp). With single-ammotype weapons, there's never any need to change the clips before combat. <br />
:# As a workaround, don't load ammo for any weapons. This avoids the 'switching cost' issue but does impose a fairly significant logistics overhead on each combat, to go through and manually load all clips. Plus the risk that you forget to load a weapon and only find out at a critical moment. :) This is for the "purist" who wants to make the game harder.<br />
:If it's tricky to fix the root cause, any of the other two options would be helpful. Suggested text:<br />
:* [Multi Ammo Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. Weapons using multiple ammo types (Heavy Cannon, Auto-Cannon, Rocket Launcher / Gas Cannon, Hydrojet Cannon, Torpedo Launcher) will not be pre-loaded before combat. You will need to load these weapons manually during the pre-combat Equip phase. This will significantly affect the heavy weapons ammunition load your squad can carry into combat without suffering encumbrance penalties, thus making the early game harder.<br />
:* [All Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. This option overrides the previous option. No weapons will be pre-loaded before combat. You will need to load all ammo manually during the pre-combat Equip phase. This will significantly affect the ammunition load your squad can carry into combat without suffering encumbrance penalties, making the early game harder.<br />
:[[User:Spike|Spike]] 05:10, 21 September 2012 (EDT)<br />
::''I found the source of the problem: 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 changed in inventory management.-''[[User:Morgan525|Tycho]] 19:00, 19 October 2012 (EDT)<br />
::: That is just awesome! :D [[User:Spike|Spike]] 22:36, 19 October 2012 (EDT)<br />
<br />
=== MIA Bugs ===<br />
<br />
==== Supernumary MIA on Abort ====<br />
<br />
I Abort a mission with 8 Aquanauts and get the confirmation message "8 Aquanauts inside craft, 2 outside". No one has been stunned or MCd. I did have two aquanauts, only, outside, but they have moved back inside the transport. Very odd. Saved Equipment was enabled. [[User:Spike|Spike]] 11:06, 5 October 2012 (EDT)<br />
<br />
:''How many Aquanauts did you have in total?- -''[[User:Morgan525|Tycho]] 02:54, 11 October 2012 (EDT)<br />
:: I started the mission with only 8 Aquanauts and they all survived. Only two had even been outside the transport (quite an unusual situation). However I can't reproduce this bug, so please ignore it unless/until I can reproduce it. :) [[User:Spike|Spike]] 06:48, 17 October 2012 (EDT)<br />
<br />
==== Crewed Flying Sub Lost on Abort ====<br />
<br />
Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)<br />
<br />
:Presumably the 3 aquanauts in the craft were not stunned or mind controlled on the Abort turn? [[User:Spike|Spike]] 16:37, 21 October 2012 (EDT)<br />
:Right, they are not stunned (or dead) and they are under your control. And they are definitely in the sub. OK this is similar to a minor bug I have seen before - see [[#Supernumary MIA on Abort|preceding item]]. On your pre-abort confirmation screen it says "3 units in craft, 9 units outside". I've had a similar issue before. It's double counting your aquanauts as being both inside and outside the craft on the confirm screen, since you only have 9 units (8 and 1 tank) in total. On actual abort you incorrectly get 9 MIAs (including the tank presumably) and I guess that's why you lose the sub. Interestingly, the 3 affected aquanauts look like they never moved from their original positions, is that true? I believe when I've had similar problems before, it related to aquanauts who had never left the sub / never left their initial positions. We will have to see if Tycho can get to the bottom of this one. [[User:Spike|Spike]] 16:51, 21 October 2012 (EDT)<br />
::Yes, that's true - those 3 haven't moved from their original positions. --[[User:Player701|Player701]] 17:19, 21 October 2012 (EDT)<br />
<br />
:''I found the nature of the issue here: On one hand, all parts of the tank are being counted separately but then the End of Battle routine calculates the correct number of units but when it goes to locate the units on the battlefield, the three other parts of the tank are being tallied and thus the last three aquanauts are not checked since the 4 areas of the tank are first in the UNITPOS.DAT file.-[[User:Morgan525|Tycho]] 09:47, 24 October 2012 (EDT)''<br />
<br />
==== Stunned Carried Aquanauts MIA on Abort ====<br />
<br />
While you are looking the EOB script, I noticed one more anomaly. I'm not sure if this is an original bug or an Extender bug. If you are carrying a stunned Aquanaut in the transport at the time of Abort, the stunned Aquanaut is lost (MIA). You have to drop the stunned Aquanaut on the floor. Probably this is because the position of the Aquanaut has not been updated and is still pointing to where they were stunned, not to the location of the carrying Aquanaut. [[User:Spike|Spike]] 04:49, 27 September 2012 (EDT)<br />
<br />
:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. At least it is manageable: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)<br />
<br />
=== Items on transport floor lost on Abort ===<br />
<br />
I went in to a mission with ten Sonic Cannons and came back with 3, despite retrieving them from the battlefield and dumping them on the transport floor. I only had 3 aquanauts on the transport armed with Sonic Cannon at the time of abort. The rest were stunned or unarmed. I also dumped half a dozen corpses and some alien items on the transport floor and I don't think those made it back to my base either. The transport was operating from base 2 rather than base 1, in case that's a factor. This may be an original bug of course. I just read through the multiplayer TFTD LP on StrategyCore, and they reported missing equipment on a lot of missions. I can go back and check if the missing equipment was on abort missions rather than victory missions. Sorry not to provide more specifics at this time but it was a hard mission and not exactly a controlled experiment. ;) [[User:Spike|Spike]] 21:35, 23 October 2012 (EDT)<br />
: I tried to reproduce this in the unmodified game without success, controlling for aquanauts being stunned/not stunned, inside/outside transport, stunned inside/outside transport. I didn't control for reloading the game, that sometimes causes glitches. I will retry with the Extender next and see if that reproduces anything. [[User:Spike|Spike]] 21:06, 24 October 2012 (EDT)<br />
Here's another thought. The problematic game was a Colony Assault which has a lot of objects in the object table. As the missing objects were created (corpses) or dropped (weapons) after the game started, they could be a long way down the object table. Now, doesn't TFTD have a bigger object table than EU? Maybe the TFTDextender is only recovering items from a sub-section of the TFTD object table? [[User:Spike|Spike]] 17:13, 26 October 2012 (EDT)<br />
<br />
== Save Equipment not working? ==<br />
<br />
With "Save Equipment" option enabled, the soldiers' loadout at first was always like this: grenade in leg slot, clip in backpack - and it didn't change on the next mission, despite the fact that I re-equipped the soldiers correctly (grenades and clips on the belt). When I manufactured Gauss Rifles and issued them to my soldiers, it got even worse - none of the soldiers got clips, and two of the rifles were unloaded. Next I upgraded to Sonic-Blasta Rifles and now nothing, except some grenades (still in leg slots), is issued to the soldiers at all. "Save Equipment" was known to work in UFOExtender, did something get broken? --[[User:Player701|Player701]] 09:18, 21 October 2012 (EDT)<br />
<br />
:''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. See the discussion on problems with the OBDATA mod about the final source of the problem and its solution.-[[User:Morgan525|Tycho]] 20:03, 21 October 2012 (EDT)''<br />
<br />
:: Would you suggest that everyone disables Save Equipment for the time being, in TFTDextender? [[User:Spike|Spike]] 07:44, 24 October 2012 (EDT)<br />
<br />
:''It couldn't hurt. I believe that TFTD has its own form of autoequip and part of the solution will probably require that I disable it. Something similar happened to the "stunned units are KIA" mod from UFOextender: TFTD has its own version that conflicted but, since it worked well, I only needed to add code to update the unit's location so the corpse would appear in the right place.-[[User:Morgan525|Tycho]] 22:38, 24 October 2012 (EDT)''<br />
<br />
:: I just did a few tests in raw TFTD (Steam CE) and the auto equip function is pretty basic: Give everyone a loaded weapon in what is probably reverse OBDATA.DAT order, then dish out any extra clips, grenades etc. Are you thinking that the Save Equipment efforts of TFTDextender are then being overwritten or partly overwritten by the existing TFTD auto equip function? I guess that would make sense. [[User:Spike|Spike]] 11:01, 25 October 2012 (EDT)<br />
<br />
=Resolved Problems=<br />
===<s> Executable directive </s>===<br />
''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)<br />
<br />
=== <s>Extra Artefacts Reported</s> ===<br />
''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)<br />
''This will be fixed in the next release.-''[[User:Morgan525|Tycho]] 03:00, 13 October 2012 (EDT)<br />
: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
===<s>Manufacturing Projects Minimum Production</s> ===<br />
<br />
In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''<br />
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)<br />
<br />
Tested - If I reduce the production quantity of a current production run to less than what as already been produced, the display completion time changes (incorrectly) to 'Indefinite', but production ends after completion of the next unit. So if I start by producing 10 units, wait until I have produced 2, then reduce the quantity to 2 (or probably 1), production stops after 3 units. Thies basically replicates the pre-existing behaviour when using the down arrow on the Quantity, so there has been no loss of functionality with your Mod. Also, Autosell and Autoproduce work normally when applied as changes to an existing production run. The only thing is I can't distinguish them on the Manufacturing display - both say 'unlimited' quantity and 'indefinite' period - is that intended? I suppose it makes sense, but it would be good to be able to tell which kind of production it is, *** Autoproduce or $$$ Autosell. [[User:Spike|Spike]] 08:57, 2 October 2012 (EDT)<br />
<br />
:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''<br />
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)<br />
:::''OK. Changed the output to display "$unlimited$".[[User:Morgan525|Tycho]]<br />
<br />
===<s>Stunned MC'd Aquanauts MIA on Abort </s> ===<br />
<br />
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. <br />
::''I now have the code in place to uncontrol any creature that has been rendered unconscious. - -''[[User:Morgan525|Tycho]] 02:47, 11 October 2012 (EDT)<br />
This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
=== <s>Grenade Resistance in INI file </s> ===<br />
:''I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]<br />
<br />
<br />
===<s> Materials deducted from wrong base </s>===<br />
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''<br />
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)<br />
<br />
===<s> OBDATA / Dye Grenade mod not working? </s>===<br />
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)<br />
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
== <s>Displacer/Sonic damage fix</s> ==<br />
<br />
'' I changed the damage to be 130, same as the UFOpaedia entry.-''[[User:Morgan525|Tycho]] 03:52, 13 October 2012 (EDT)<br />
<br />
==<s> Weight Display in Inventory not Localised </s> ==<br />
<br />
At least when I run the game in German, it comes up as "Weight" and not something like "Gewicht". Reactions comes up ok as "Zeitwerte". [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
<br />
:''Added ability for users to added their own language by copying lines from Extender's page under the equipment section to the same section in their INI, alter the text as specified, and save the INI' [[User:Morgan525|Tycho]]<br />
<br />
<br />
== Things that TFTDextender does not fix ==<br />
<br />
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?):<br />
<br />
* 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.<br />
* Does not fix the incorrect pictures for the large USO in the interception window. <br />
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]<br />
* 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.)<br />
* 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).<br />
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.<br />
* 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.<br />
<br />
= Feature Requests and Suggestions =<br />
<br />
== Useful alien species research ==<br />
<br />
Tycho, I really like this idea you proposed in the StrategyCore forum:<br />
<br />
: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.<br />
<br />
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. <br />
<br />
:''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.'' [[User:Morgan525|Tycho]]<br />
::''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%, 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-100% for that lucky shot. With autopsy done, the game reverts back to the usual 0-200% on any hit.''<br />
<br />
::: 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". [[User:Spike|Spike]] 10:35, 15 September 2012 (EDT)<br />
<br />
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?<br />
<br />
:''I thought about that but the game doesn't record live aliens that have been researched. When you finish research on a live alien, it only follows the routine to unlock the appropriate UFOpaedia articles and then checks to see if the finished research can unlock other topics.'' [[User:Morgan525|Tycho]]<br />
<br />
I had a further thought on this while trying to guess what your new pre-requisites are for the various armours. For now it's really cool to be guessing but once people have figured it out, well, it will be more logical but still will have 'replay fatigue'. Would it be possible to randomise the pre-requisites for a lot of the key research topics, from out of a plausible list of items (or even randomise pre-requisite topics)? That would make every game fresh in terms of the research sequence, and make the research aspect of the game more challenging and less dry & predictable. As ever, just a suggestion. :) Cheers, [[User:Spike|Spike]] 16:01, 19 October 2012 (EDT)<br />
<br />
== All Units Can "Fly" In Water ==<br />
<br />
It's very illogical that most units are stuck on the seabed in underwater missions. Please provide the option to set all units (X-Com and alien) to have "flying" (i.e. swimming) ability when underwater. This is unlikely to cause an outbreak of 3D combat, since there is no cover except at seabed level, so anyone swimming excessively or incautiously is going to get shot. It might disadvantage the aliens if their tactical map waypoints are all set on the surface. But as some of them can "fly", there is hopefully a mechanism to deal with that in the code already. For me it will just solve the frustration of being unable to swim over small obstacles or swim up a level, and being stuck or tactically limited for no sensible reason. Mag-Ion Armour remains useful as an important step in Sub Research and (if using the Everything Works on Land mod) for land use. [[User:Spike|Spike]] 11:36, 9 September 2012 (EDT)<br />
: This requires setting [[UNITREF.DAT]] byte 0x78 bit 2 for the unit (e.g. for all units on both sides). Or the in-memory equivalent of UNITREF.DAT. [[User:Spike|Spike]] 10:19, 5 October 2012 (EDT)<br />
<br />
== Aliens Pick Up Weapons ==<br />
<br />
Related to Improved Alien AI. This makes the game tougher as stunned / panicked bipedal-type aliens are no longer permanently disarmed. This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. A fix for this would be a very helpful rebalancing of both games that eliminates one of the aliens' weak spots. The existing (but unused) routine looks pretty smart and not immediately exploitable to ambush aliens using weapons as traps. <br />
<br />
: I noticed the UFO Extender source code has a 'get' keyword under the OBDATA.DAT directive that populates this field 0x2D. Is that working? [[User:Spike|Spike]] 21:03, 16 October 2012 (EDT)<br />
:''It should be. I haven't tested it out but it should work like any other OBDATA change, in theory. As long as the code in the AI routine handles this byte, it should work. I believe someone mentioned under the Geoscape.exe page that the AI routine ignores any value under 5.-[[User:Morgan525|Tycho]] 00:58, 25 October 2012 (EDT)''<br />
<br />
== General Tank Modding ==<br />
<br />
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?<br />
<br />
Thanks,<br />
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)<br />
<br />
== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==<br />
<br />
Hook the right and left weapon menus on mind controlled aliens to add in actions for their built in melee attacks (if they have them) and built in Psi/MC attacks (if they have Psi/MC Skill). Ideally add these actions to the menu, and pop up a menu, even if the alien isn't holding any weapons.<br />
<br />
This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.<br />
<br />
== Fix Interception and Navigation Course Algorithms ==<br />
<br />
Or just find the algorithms and I volunteer to fix them!<br />
<br />
=== Use Great Circle Routes ===<br />
<br />
Travel toward the target on the shortest Great Circle, rather than always travelling along lines of latitude first (like they are some kind of main bus route!). <br />
<br />
=== Use Predictive Interception ===<br />
<br />
For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.<br />
<br />
=== Show Degree Headings ===<br />
<br />
The game only ever reports alien headings as North, South, East, West, but clearly alien craft move in other directions than just these four, and clearly XCOM detection equipment is capable of resolving these finer-grained headings, since the crafts' tracks are shown correctly in the Geoscope. <br />
As a first step towards predictive interceptions, it would be great to display the alien craft's heading in degrees, eg 135 degrees for South-East. Maybe rounded to the nearest 5 or 10 degrees.<br />
<br />
== Interception Craft vs Touched Down Alien Craft == <br />
<br />
If an alien craft is touched down and an XCOM interception craft (not touched down) is at the same X/Y position, if the alien craft begins to move, immediately open the Interception window at minimum range (8km/nm), presumably with the alien attempting to get away / break off. Currently the Interception window only happens if the XCom craft is faster, which is dumb, ''even if'' the alien craft could accelerate instantly to its maximum speed. <br />
<br />
For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach. <br />
<br />
== Fun, not Funky, Fire ==<br />
<br />
An alternative option for incendiaries/phosphorous damage processing: Do process the so called 'impact' damage of an incendiary on every shot, not just at the end of the turn. But only apply it to those in the area of affect of this specific shell burst, not to all units who are standing in smoke or fire anywhere on the map. This will please fans of incendiaries/phosphorous. It's probably a balancing, rather than unbalancing, change in the relative strengths of the ammo types. Makes incendiaries/phosphorous useful for more than just illumination or desperation. Gives some use to the research topics that advise use of incendiaries/phosphorous, and the damage modifiers aliens have been assigned.<br />
<br />
== Rearming Rates ==<br />
<br />
<br />
From [[Known_Bugs_(TFTD)#Geoscape_Bugs]]:<br />
<br />
=== Craft Gauss Cannon Rearming Rate ===<br />
<br />
This weapon rearms at 10/hr but probably should be 50/hr or at least 25/hr, otherwise it is far slower to rearm than any other cannon weapon in either game. In fact it's the second slowest weapon system to rearm, slower only than AJAX...<br />
<br />
=== AJAX Rearming Rate ===<br />
<br />
An AJAX system takes twice as long to fully reload as a D.U.P. system, as a result AJAX-armed Craft have much worse operational tempo and readiness than D.U.P. armed Craft. Like we needed yet another reason to always use D.U.Ps. This is probably a design error rather than a bug, but it would be good to fix it - anything to give a more balanced set of craft weapon choices. The rearming rate should be raised from 1/hr to 2/hr. The AJAX system will then have the same operational tempo as the D.U.P. system. <br />
<br />
Could also be applied to Stingray missiles in EU 1994, as the same analysis applies to Stingray vs Avalanche.<br />
<br />
== Retaliate for Colony Assault ==<br />
<br />
See this discussion [[Talk:Alien_Retaliation#Retaliation_Triggers]]. Colony raids are a good way for the alien to lose badly, so it would be a good balancing move to create severe consequences for raiding. It is at least as sensible as retaliation for USO Assaults.</div>Player701https://temp.ufopaedia.org/index.php?title=Talk:TFTDextender&diff=40502Talk:TFTDextender2012-10-28T17:52:22Z<p>Player701: /* Cannot build Leviathan */</p>
<hr />
<div>=Questions or Comments=<br />
'''A place to provide feedback or ask questions:'''<br />
<br />
The zip archive does not seem to include an .ini file. Where do I get the .ini file from? <br />
:: Oh hang on. It looks like the latest version of the zip file does not include the .ini file. When I go back to the previous version of the zip file, I can see the .ini file. [[User:Spike|Spike]] 17:45, 6 September 2012 (EDT)<br />
<br />
:::''The latest release is a patch, which means there are no new additions to the INI. I don't include it in patches usually so that those who already have the prior release don't have to reconfigure their current INI. It may not seem like a big deal now but earlier, I was releasing fixes almost on a weekly basis and so I still continue with that idea.''[[User:Morgan525|Tycho]]<br />
<br />
== Bug Reports ==<br />
<br />
=== Crash when starting a landed/crashed USO battle ===<br />
<br />
:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."<br />
<br />
''Interesting. I had someone report a similar thing when they were starting their first instance of the battlescape on a new install of the game. I looked into it and the game generated some bad data. When he let the UFO take off and land again, the battle started with no problems..''<br />
<br />
:It's [[Known_Bugs_(TFTD)#Geoscape_Bugs|a bug I've reported before]] (before TFTD Extender even existed), so it's not specific to TFTDExtender / UFOExtender. What is happening is the Alien Sub is landing on land, and the Triton is also attempting to land on land. Probably the game crashes when it fails to generate the appropriate terrain type? So the GEOSCAPE map/terrain data must be corrupted. I've seen three examples of this. In a couple of cases the landing site is clearly inland, by hundreds of kilometres. In some cases it's right on the sea/land boundary and hard to tell. I have two save games that reproduce the bug now. From memory, the previous cases all happened around North Africa, like these present cases. [[User:Spike|Spike]] 08:31, 9 September 2012 (EDT)<br />
<br />
:''I think the problem is that there is no database to reference what type of terrain to load. EU would reference this based on map coordinates. Since USO aren't usually engaged over land, the map generator can't get an appropriate tileset for the location in these cases.-[[User:Morgan525|Tycho]]''<br />
<br />
== Minor Bugs ==<br />
<br />
=== Weightless Ammo Bug ===<br />
<br />
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)<br />
<br />
''From what I understand right now, I am pretty sure I can arrange it so that weapons are not automatically loaded and soldiers would be given an extra clip. Feedback?''<br />
: By an extra clip, you mean the clip/ammo that would have been loaded into the weapon is instead carried by the soldier? And for carried clips, the encumbrance effects are correct. For me anyway, in order of most benefit, the options would be<br />
:# Fix the root cause of the bug (ensure all relevant object locations and "contains/contained in" pointers are set during automatic clip loading) so that automatically loaded clips correctly affect encumbrance <br />
:# As a workaround, don't load ammo for multi-ammotype weapons (Heavy Cannon/Gas Cannon, Auto-Cannon/Hydrojet Cannon, Rocket Launcher / Torpedo Launcher). These are the weapons for which the bug has the greatest impact, since it imposes a 'cost' of switching away from the automatically-loaded ammo (usually AP or Small Rocket/Torp). With single-ammotype weapons, there's never any need to change the clips before combat. <br />
:# As a workaround, don't load ammo for any weapons. This avoids the 'switching cost' issue but does impose a fairly significant logistics overhead on each combat, to go through and manually load all clips. Plus the risk that you forget to load a weapon and only find out at a critical moment. :) This is for the "purist" who wants to make the game harder.<br />
:If it's tricky to fix the root cause, any of the other two options would be helpful. Suggested text:<br />
:* [Multi Ammo Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. Weapons using multiple ammo types (Heavy Cannon, Auto-Cannon, Rocket Launcher / Gas Cannon, Hydrojet Cannon, Torpedo Launcher) will not be pre-loaded before combat. You will need to load these weapons manually during the pre-combat Equip phase. This will significantly affect the heavy weapons ammunition load your squad can carry into combat without suffering encumbrance penalties, thus making the early game harder.<br />
:* [All Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. This option overrides the previous option. No weapons will be pre-loaded before combat. You will need to load all ammo manually during the pre-combat Equip phase. This will significantly affect the ammunition load your squad can carry into combat without suffering encumbrance penalties, making the early game harder.<br />
:[[User:Spike|Spike]] 05:10, 21 September 2012 (EDT)<br />
::''I found the source of the problem: 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 changed in inventory management.-''[[User:Morgan525|Tycho]] 19:00, 19 October 2012 (EDT)<br />
::: That is just awesome! :D [[User:Spike|Spike]] 22:36, 19 October 2012 (EDT)<br />
<br />
=== MIA Bugs ===<br />
<br />
==== Supernumary MIA on Abort ====<br />
<br />
I Abort a mission with 8 Aquanauts and get the confirmation message "8 Aquanauts inside craft, 2 outside". No one has been stunned or MCd. I did have two aquanauts, only, outside, but they have moved back inside the transport. Very odd. Saved Equipment was enabled. [[User:Spike|Spike]] 11:06, 5 October 2012 (EDT)<br />
<br />
:''How many Aquanauts did you have in total?- -''[[User:Morgan525|Tycho]] 02:54, 11 October 2012 (EDT)<br />
:: I started the mission with only 8 Aquanauts and they all survived. Only two had even been outside the transport (quite an unusual situation). However I can't reproduce this bug, so please ignore it unless/until I can reproduce it. :) [[User:Spike|Spike]] 06:48, 17 October 2012 (EDT)<br />
<br />
==== Crewed Flying Sub Lost on Abort ====<br />
<br />
Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)<br />
<br />
:Presumably the 3 aquanauts in the craft were not stunned or mind controlled on the Abort turn? [[User:Spike|Spike]] 16:37, 21 October 2012 (EDT)<br />
:Right, they are not stunned (or dead) and they are under your control. And they are definitely in the sub. OK this is similar to a minor bug I have seen before - see [[#Supernumary MIA on Abort|preceding item]]. On your pre-abort confirmation screen it says "3 units in craft, 9 units outside". I've had a similar issue before. It's double counting your aquanauts as being both inside and outside the craft on the confirm screen, since you only have 9 units (8 and 1 tank) in total. On actual abort you incorrectly get 9 MIAs (including the tank presumably) and I guess that's why you lose the sub. Interestingly, the 3 affected aquanauts look like they never moved from their original positions, is that true? I believe when I've had similar problems before, it related to aquanauts who had never left the sub / never left their initial positions. We will have to see if Tycho can get to the bottom of this one. [[User:Spike|Spike]] 16:51, 21 October 2012 (EDT)<br />
::Yes, that's true - those 3 haven't moved from their original positions. --[[User:Player701|Player701]] 17:19, 21 October 2012 (EDT)<br />
<br />
:''I found the nature of the issue here: On one hand, all parts of the tank are being counted separately but then the End of Battle routine calculates the correct number of units but when it goes to locate the units on the battlefield, the three other parts of the tank are being tallied and thus the last three aquanauts are not checked since the 4 areas of the tank are first in the UNITPOS.DAT file.-[[User:Morgan525|Tycho]] 09:47, 24 October 2012 (EDT)''<br />
<br />
==== Stunned Carried Aquanauts MIA on Abort ====<br />
<br />
While you are looking the EOB script, I noticed one more anomaly. I'm not sure if this is an original bug or an Extender bug. If you are carrying a stunned Aquanaut in the transport at the time of Abort, the stunned Aquanaut is lost (MIA). You have to drop the stunned Aquanaut on the floor. Probably this is because the position of the Aquanaut has not been updated and is still pointing to where they were stunned, not to the location of the carrying Aquanaut. [[User:Spike|Spike]] 04:49, 27 September 2012 (EDT)<br />
<br />
:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. At least it is manageable: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)<br />
<br />
=== Items on transport floor lost on Abort ===<br />
<br />
I went in to a mission with ten Sonic Cannons and came back with 3, despite retrieving them from the battlefield and dumping them on the transport floor. I only had 3 aquanauts on the transport armed with Sonic Cannon at the time of abort. The rest were stunned or unarmed. I also dumped half a dozen corpses and some alien items on the transport floor and I don't think those made it back to my base either. The transport was operating from base 2 rather than base 1, in case that's a factor. This may be an original bug of course. I just read through the multiplayer TFTD LP on StrategyCore, and they reported missing equipment on a lot of missions. I can go back and check if the missing equipment was on abort missions rather than victory missions. Sorry not to provide more specifics at this time but it was a hard mission and not exactly a controlled experiment. ;) [[User:Spike|Spike]] 21:35, 23 October 2012 (EDT)<br />
: I tried to reproduce this in the unmodified game without success, controlling for aquanauts being stunned/not stunned, inside/outside transport, stunned inside/outside transport. I didn't control for reloading the game, that sometimes causes glitches. I will retry with the Extender next and see if that reproduces anything. [[User:Spike|Spike]] 21:06, 24 October 2012 (EDT)<br />
Here's another thought. The problematic game was a Colony Assault which has a lot of objects in the object table. As the missing objects were created (corpses) or dropped (weapons) after the game started, they could be a long way down the object table. Now, doesn't TFTD have a bigger object table than EU? Maybe the TFTDextender is only recovering items from a sub-section of the TFTD object table? [[User:Spike|Spike]] 17:13, 26 October 2012 (EDT)<br />
<br />
== Save Equipment not working? ==<br />
<br />
With "Save Equipment" option enabled, the soldiers' loadout at first was always like this: grenade in leg slot, clip in backpack - and it didn't change on the next mission, despite the fact that I re-equipped the soldiers correctly (grenades and clips on the belt). When I manufactured Gauss Rifles and issued them to my soldiers, it got even worse - none of the soldiers got clips, and two of the rifles were unloaded. Next I upgraded to Sonic-Blasta Rifles and now nothing, except some grenades (still in leg slots), is issued to the soldiers at all. "Save Equipment" was known to work in UFOExtender, did something get broken? --[[User:Player701|Player701]] 09:18, 21 October 2012 (EDT)<br />
<br />
:''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. See the discussion on problems with the OBDATA mod about the final source of the problem and its solution.-[[User:Morgan525|Tycho]] 20:03, 21 October 2012 (EDT)''<br />
<br />
:: Would you suggest that everyone disables Save Equipment for the time being, in TFTDextender? [[User:Spike|Spike]] 07:44, 24 October 2012 (EDT)<br />
<br />
:''It couldn't hurt. I believe that TFTD has its own form of autoequip and part of the solution will probably require that I disable it. Something similar happened to the "stunned units are KIA" mod from UFOextender: TFTD has its own version that conflicted but, since it worked well, I only needed to add code to update the unit's location so the corpse would appear in the right place.-[[User:Morgan525|Tycho]] 22:38, 24 October 2012 (EDT)''<br />
<br />
:: I just did a few tests in raw TFTD (Steam CE) and the auto equip function is pretty basic: Give everyone a loaded weapon in what is probably reverse OBDATA.DAT order, then dish out any extra clips, grenades etc. Are you thinking that the Save Equipment efforts of TFTDextender are then being overwritten or partly overwritten by the existing TFTD auto equip function? I guess that would make sense. [[User:Spike|Spike]] 11:01, 25 October 2012 (EDT)<br />
<br />
=Resolved Problems=<br />
<br />
===<s> Cannot build Leviathan </s>===<br />
<br />
Hi Tycho. I've just researched Leviathan in my TFDExtender game but cannot manufacture it! I have enough resources (Plastics, IBA, ManNav), 3 workshops, more than 100 technicans and one empty sub pen. But when starting the Leviathan manufacture task I cannot assign any technicans to it. I press the "up" button, and there are no reaction to this. I can build Manta, but not Leviathan. Don't you know what is it? [[User:PavelB|PavelB]] 06:55, 2 October 2012 (EDT)<br />
<br />
:''I was able to replicate Pavel's problem and quickly 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. A simple change and the problem is fixed with patch 3.1 - [[User:Morgan525|Tycho]] 07:29, 28 October 2012 (EDT)''<br />
<br />
::I'm sorry, but I've just downloaded this patch and for me this error has not been fixed (I simply ran into the same problem and went here to check it out). Maybe this doesn't work with saved games? I'm pretty sure I've downloaded the correct file, checked three times... --[[User:Player701|Player701]] 13:50, 28 October 2012 (EDT)<br />
<br />
===<s> Executable directive </s>===<br />
''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)<br />
<br />
=== <s>Extra Artefacts Reported</s> ===<br />
''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)<br />
''This will be fixed in the next release.-''[[User:Morgan525|Tycho]] 03:00, 13 October 2012 (EDT)<br />
: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
===<s>Manufacturing Projects Minimum Production</s> ===<br />
<br />
In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''<br />
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)<br />
<br />
Tested - If I reduce the production quantity of a current production run to less than what as already been produced, the display completion time changes (incorrectly) to 'Indefinite', but production ends after completion of the next unit. So if I start by producing 10 units, wait until I have produced 2, then reduce the quantity to 2 (or probably 1), production stops after 3 units. Thies basically replicates the pre-existing behaviour when using the down arrow on the Quantity, so there has been no loss of functionality with your Mod. Also, Autosell and Autoproduce work normally when applied as changes to an existing production run. The only thing is I can't distinguish them on the Manufacturing display - both say 'unlimited' quantity and 'indefinite' period - is that intended? I suppose it makes sense, but it would be good to be able to tell which kind of production it is, *** Autoproduce or $$$ Autosell. [[User:Spike|Spike]] 08:57, 2 October 2012 (EDT)<br />
<br />
:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''<br />
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)<br />
:::''OK. Changed the output to display "$unlimited$".[[User:Morgan525|Tycho]]<br />
<br />
===<s>Stunned MC'd Aquanauts MIA on Abort </s> ===<br />
<br />
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. <br />
::''I now have the code in place to uncontrol any creature that has been rendered unconscious. - -''[[User:Morgan525|Tycho]] 02:47, 11 October 2012 (EDT)<br />
This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
=== <s>Grenade Resistance in INI file </s> ===<br />
:''I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]<br />
<br />
<br />
===<s> Materials deducted from wrong base </s>===<br />
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''<br />
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)<br />
<br />
===<s> OBDATA / Dye Grenade mod not working? </s>===<br />
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)<br />
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
== <s>Displacer/Sonic damage fix</s> ==<br />
<br />
'' I changed the damage to be 130, same as the UFOpaedia entry.-''[[User:Morgan525|Tycho]] 03:52, 13 October 2012 (EDT)<br />
<br />
==<s> Weight Display in Inventory not Localised </s> ==<br />
<br />
At least when I run the game in German, it comes up as "Weight" and not something like "Gewicht". Reactions comes up ok as "Zeitwerte". [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
<br />
:''Added ability for users to added their own language by copying lines from Extender's page under the equipment section to the same section in their INI, alter the text as specified, and save the INI' [[User:Morgan525|Tycho]]<br />
<br />
<br />
== Things that TFTDextender does not fix ==<br />
<br />
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?):<br />
<br />
* 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.<br />
* Does not fix the incorrect pictures for the large USO in the interception window. <br />
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]<br />
* 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.)<br />
* 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).<br />
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.<br />
* 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.<br />
<br />
= Feature Requests and Suggestions =<br />
<br />
== Useful alien species research ==<br />
<br />
Tycho, I really like this idea you proposed in the StrategyCore forum:<br />
<br />
: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.<br />
<br />
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. <br />
<br />
:''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.'' [[User:Morgan525|Tycho]]<br />
::''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%, 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-100% for that lucky shot. With autopsy done, the game reverts back to the usual 0-200% on any hit.''<br />
<br />
::: 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". [[User:Spike|Spike]] 10:35, 15 September 2012 (EDT)<br />
<br />
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?<br />
<br />
:''I thought about that but the game doesn't record live aliens that have been researched. When you finish research on a live alien, it only follows the routine to unlock the appropriate UFOpaedia articles and then checks to see if the finished research can unlock other topics.'' [[User:Morgan525|Tycho]]<br />
<br />
I had a further thought on this while trying to guess what your new pre-requisites are for the various armours. For now it's really cool to be guessing but once people have figured it out, well, it will be more logical but still will have 'replay fatigue'. Would it be possible to randomise the pre-requisites for a lot of the key research topics, from out of a plausible list of items (or even randomise pre-requisite topics)? That would make every game fresh in terms of the research sequence, and make the research aspect of the game more challenging and less dry & predictable. As ever, just a suggestion. :) Cheers, [[User:Spike|Spike]] 16:01, 19 October 2012 (EDT)<br />
<br />
== All Units Can "Fly" In Water ==<br />
<br />
It's very illogical that most units are stuck on the seabed in underwater missions. Please provide the option to set all units (X-Com and alien) to have "flying" (i.e. swimming) ability when underwater. This is unlikely to cause an outbreak of 3D combat, since there is no cover except at seabed level, so anyone swimming excessively or incautiously is going to get shot. It might disadvantage the aliens if their tactical map waypoints are all set on the surface. But as some of them can "fly", there is hopefully a mechanism to deal with that in the code already. For me it will just solve the frustration of being unable to swim over small obstacles or swim up a level, and being stuck or tactically limited for no sensible reason. Mag-Ion Armour remains useful as an important step in Sub Research and (if using the Everything Works on Land mod) for land use. [[User:Spike|Spike]] 11:36, 9 September 2012 (EDT)<br />
: This requires setting [[UNITREF.DAT]] byte 0x78 bit 2 for the unit (e.g. for all units on both sides). Or the in-memory equivalent of UNITREF.DAT. [[User:Spike|Spike]] 10:19, 5 October 2012 (EDT)<br />
<br />
== Aliens Pick Up Weapons ==<br />
<br />
Related to Improved Alien AI. This makes the game tougher as stunned / panicked bipedal-type aliens are no longer permanently disarmed. This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. A fix for this would be a very helpful rebalancing of both games that eliminates one of the aliens' weak spots. The existing (but unused) routine looks pretty smart and not immediately exploitable to ambush aliens using weapons as traps. <br />
<br />
: I noticed the UFO Extender source code has a 'get' keyword under the OBDATA.DAT directive that populates this field 0x2D. Is that working? [[User:Spike|Spike]] 21:03, 16 October 2012 (EDT)<br />
:''It should be. I haven't tested it out but it should work like any other OBDATA change, in theory. As long as the code in the AI routine handles this byte, it should work. I believe someone mentioned under the Geoscape.exe page that the AI routine ignores any value under 5.-[[User:Morgan525|Tycho]] 00:58, 25 October 2012 (EDT)''<br />
<br />
== General Tank Modding ==<br />
<br />
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?<br />
<br />
Thanks,<br />
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)<br />
<br />
== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==<br />
<br />
Hook the right and left weapon menus on mind controlled aliens to add in actions for their built in melee attacks (if they have them) and built in Psi/MC attacks (if they have Psi/MC Skill). Ideally add these actions to the menu, and pop up a menu, even if the alien isn't holding any weapons.<br />
<br />
This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.<br />
<br />
== Fix Interception and Navigation Course Algorithms ==<br />
<br />
Or just find the algorithms and I volunteer to fix them!<br />
<br />
=== Use Great Circle Routes ===<br />
<br />
Travel toward the target on the shortest Great Circle, rather than always travelling along lines of latitude first (like they are some kind of main bus route!). <br />
<br />
=== Use Predictive Interception ===<br />
<br />
For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.<br />
<br />
=== Show Degree Headings ===<br />
<br />
The game only ever reports alien headings as North, South, East, West, but clearly alien craft move in other directions than just these four, and clearly XCOM detection equipment is capable of resolving these finer-grained headings, since the crafts' tracks are shown correctly in the Geoscope. <br />
As a first step towards predictive interceptions, it would be great to display the alien craft's heading in degrees, eg 135 degrees for South-East. Maybe rounded to the nearest 5 or 10 degrees.<br />
<br />
== Interception Craft vs Touched Down Alien Craft == <br />
<br />
If an alien craft is touched down and an XCOM interception craft (not touched down) is at the same X/Y position, if the alien craft begins to move, immediately open the Interception window at minimum range (8km/nm), presumably with the alien attempting to get away / break off. Currently the Interception window only happens if the XCom craft is faster, which is dumb, ''even if'' the alien craft could accelerate instantly to its maximum speed. <br />
<br />
For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach. <br />
<br />
== Fun, not Funky, Fire ==<br />
<br />
An alternative option for incendiaries/phosphorous damage processing: Do process the so called 'impact' damage of an incendiary on every shot, not just at the end of the turn. But only apply it to those in the area of affect of this specific shell burst, not to all units who are standing in smoke or fire anywhere on the map. This will please fans of incendiaries/phosphorous. It's probably a balancing, rather than unbalancing, change in the relative strengths of the ammo types. Makes incendiaries/phosphorous useful for more than just illumination or desperation. Gives some use to the research topics that advise use of incendiaries/phosphorous, and the damage modifiers aliens have been assigned.<br />
<br />
== Rearming Rates ==<br />
<br />
<br />
From [[Known_Bugs_(TFTD)#Geoscape_Bugs]]:<br />
<br />
=== Craft Gauss Cannon Rearming Rate ===<br />
<br />
This weapon rearms at 10/hr but probably should be 50/hr or at least 25/hr, otherwise it is far slower to rearm than any other cannon weapon in either game. In fact it's the second slowest weapon system to rearm, slower only than AJAX...<br />
<br />
=== AJAX Rearming Rate ===<br />
<br />
An AJAX system takes twice as long to fully reload as a D.U.P. system, as a result AJAX-armed Craft have much worse operational tempo and readiness than D.U.P. armed Craft. Like we needed yet another reason to always use D.U.Ps. This is probably a design error rather than a bug, but it would be good to fix it - anything to give a more balanced set of craft weapon choices. The rearming rate should be raised from 1/hr to 2/hr. The AJAX system will then have the same operational tempo as the D.U.P. system. <br />
<br />
Could also be applied to Stingray missiles in EU 1994, as the same analysis applies to Stingray vs Avalanche.<br />
<br />
== Retaliate for Colony Assault ==<br />
<br />
See this discussion [[Talk:Alien_Retaliation#Retaliation_Triggers]]. Colony raids are a good way for the alien to lose badly, so it would be a good balancing move to create severe consequences for raiding. It is at least as sensible as retaliation for USO Assaults.</div>Player701https://temp.ufopaedia.org/index.php?title=Talk:TFTDextender&diff=40501Talk:TFTDextender2012-10-28T17:50:50Z<p>Player701: /* Cannot build Leviathan */</p>
<hr />
<div>=Questions or Comments=<br />
'''A place to provide feedback or ask questions:'''<br />
<br />
The zip archive does not seem to include an .ini file. Where do I get the .ini file from? <br />
:: Oh hang on. It looks like the latest version of the zip file does not include the .ini file. When I go back to the previous version of the zip file, I can see the .ini file. [[User:Spike|Spike]] 17:45, 6 September 2012 (EDT)<br />
<br />
:::''The latest release is a patch, which means there are no new additions to the INI. I don't include it in patches usually so that those who already have the prior release don't have to reconfigure their current INI. It may not seem like a big deal now but earlier, I was releasing fixes almost on a weekly basis and so I still continue with that idea.''[[User:Morgan525|Tycho]]<br />
<br />
== Bug Reports ==<br />
<br />
=== Crash when starting a landed/crashed USO battle ===<br />
<br />
:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."<br />
<br />
''Interesting. I had someone report a similar thing when they were starting their first instance of the battlescape on a new install of the game. I looked into it and the game generated some bad data. When he let the UFO take off and land again, the battle started with no problems..''<br />
<br />
:It's [[Known_Bugs_(TFTD)#Geoscape_Bugs|a bug I've reported before]] (before TFTD Extender even existed), so it's not specific to TFTDExtender / UFOExtender. What is happening is the Alien Sub is landing on land, and the Triton is also attempting to land on land. Probably the game crashes when it fails to generate the appropriate terrain type? So the GEOSCAPE map/terrain data must be corrupted. I've seen three examples of this. In a couple of cases the landing site is clearly inland, by hundreds of kilometres. In some cases it's right on the sea/land boundary and hard to tell. I have two save games that reproduce the bug now. From memory, the previous cases all happened around North Africa, like these present cases. [[User:Spike|Spike]] 08:31, 9 September 2012 (EDT)<br />
<br />
:''I think the problem is that there is no database to reference what type of terrain to load. EU would reference this based on map coordinates. Since USO aren't usually engaged over land, the map generator can't get an appropriate tileset for the location in these cases.-[[User:Morgan525|Tycho]]''<br />
<br />
== Minor Bugs ==<br />
<br />
=== Weightless Ammo Bug ===<br />
<br />
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)<br />
<br />
''From what I understand right now, I am pretty sure I can arrange it so that weapons are not automatically loaded and soldiers would be given an extra clip. Feedback?''<br />
: By an extra clip, you mean the clip/ammo that would have been loaded into the weapon is instead carried by the soldier? And for carried clips, the encumbrance effects are correct. For me anyway, in order of most benefit, the options would be<br />
:# Fix the root cause of the bug (ensure all relevant object locations and "contains/contained in" pointers are set during automatic clip loading) so that automatically loaded clips correctly affect encumbrance <br />
:# As a workaround, don't load ammo for multi-ammotype weapons (Heavy Cannon/Gas Cannon, Auto-Cannon/Hydrojet Cannon, Rocket Launcher / Torpedo Launcher). These are the weapons for which the bug has the greatest impact, since it imposes a 'cost' of switching away from the automatically-loaded ammo (usually AP or Small Rocket/Torp). With single-ammotype weapons, there's never any need to change the clips before combat. <br />
:# As a workaround, don't load ammo for any weapons. This avoids the 'switching cost' issue but does impose a fairly significant logistics overhead on each combat, to go through and manually load all clips. Plus the risk that you forget to load a weapon and only find out at a critical moment. :) This is for the "purist" who wants to make the game harder.<br />
:If it's tricky to fix the root cause, any of the other two options would be helpful. Suggested text:<br />
:* [Multi Ammo Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. Weapons using multiple ammo types (Heavy Cannon, Auto-Cannon, Rocket Launcher / Gas Cannon, Hydrojet Cannon, Torpedo Launcher) will not be pre-loaded before combat. You will need to load these weapons manually during the pre-combat Equip phase. This will significantly affect the heavy weapons ammunition load your squad can carry into combat without suffering encumbrance penalties, thus making the early game harder.<br />
:* [All Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. This option overrides the previous option. No weapons will be pre-loaded before combat. You will need to load all ammo manually during the pre-combat Equip phase. This will significantly affect the ammunition load your squad can carry into combat without suffering encumbrance penalties, making the early game harder.<br />
:[[User:Spike|Spike]] 05:10, 21 September 2012 (EDT)<br />
::''I found the source of the problem: 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 changed in inventory management.-''[[User:Morgan525|Tycho]] 19:00, 19 October 2012 (EDT)<br />
::: That is just awesome! :D [[User:Spike|Spike]] 22:36, 19 October 2012 (EDT)<br />
<br />
=== MIA Bugs ===<br />
<br />
==== Supernumary MIA on Abort ====<br />
<br />
I Abort a mission with 8 Aquanauts and get the confirmation message "8 Aquanauts inside craft, 2 outside". No one has been stunned or MCd. I did have two aquanauts, only, outside, but they have moved back inside the transport. Very odd. Saved Equipment was enabled. [[User:Spike|Spike]] 11:06, 5 October 2012 (EDT)<br />
<br />
:''How many Aquanauts did you have in total?- -''[[User:Morgan525|Tycho]] 02:54, 11 October 2012 (EDT)<br />
:: I started the mission with only 8 Aquanauts and they all survived. Only two had even been outside the transport (quite an unusual situation). However I can't reproduce this bug, so please ignore it unless/until I can reproduce it. :) [[User:Spike|Spike]] 06:48, 17 October 2012 (EDT)<br />
<br />
==== Crewed Flying Sub Lost on Abort ====<br />
<br />
Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)<br />
<br />
:Presumably the 3 aquanauts in the craft were not stunned or mind controlled on the Abort turn? [[User:Spike|Spike]] 16:37, 21 October 2012 (EDT)<br />
:Right, they are not stunned (or dead) and they are under your control. And they are definitely in the sub. OK this is similar to a minor bug I have seen before - see [[#Supernumary MIA on Abort|preceding item]]. On your pre-abort confirmation screen it says "3 units in craft, 9 units outside". I've had a similar issue before. It's double counting your aquanauts as being both inside and outside the craft on the confirm screen, since you only have 9 units (8 and 1 tank) in total. On actual abort you incorrectly get 9 MIAs (including the tank presumably) and I guess that's why you lose the sub. Interestingly, the 3 affected aquanauts look like they never moved from their original positions, is that true? I believe when I've had similar problems before, it related to aquanauts who had never left the sub / never left their initial positions. We will have to see if Tycho can get to the bottom of this one. [[User:Spike|Spike]] 16:51, 21 October 2012 (EDT)<br />
::Yes, that's true - those 3 haven't moved from their original positions. --[[User:Player701|Player701]] 17:19, 21 October 2012 (EDT)<br />
<br />
:''I found the nature of the issue here: On one hand, all parts of the tank are being counted separately but then the End of Battle routine calculates the correct number of units but when it goes to locate the units on the battlefield, the three other parts of the tank are being tallied and thus the last three aquanauts are not checked since the 4 areas of the tank are first in the UNITPOS.DAT file.-[[User:Morgan525|Tycho]] 09:47, 24 October 2012 (EDT)''<br />
<br />
==== Stunned Carried Aquanauts MIA on Abort ====<br />
<br />
While you are looking the EOB script, I noticed one more anomaly. I'm not sure if this is an original bug or an Extender bug. If you are carrying a stunned Aquanaut in the transport at the time of Abort, the stunned Aquanaut is lost (MIA). You have to drop the stunned Aquanaut on the floor. Probably this is because the position of the Aquanaut has not been updated and is still pointing to where they were stunned, not to the location of the carrying Aquanaut. [[User:Spike|Spike]] 04:49, 27 September 2012 (EDT)<br />
<br />
:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. At least it is manageable: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)<br />
<br />
=== Items on transport floor lost on Abort ===<br />
<br />
I went in to a mission with ten Sonic Cannons and came back with 3, despite retrieving them from the battlefield and dumping them on the transport floor. I only had 3 aquanauts on the transport armed with Sonic Cannon at the time of abort. The rest were stunned or unarmed. I also dumped half a dozen corpses and some alien items on the transport floor and I don't think those made it back to my base either. The transport was operating from base 2 rather than base 1, in case that's a factor. This may be an original bug of course. I just read through the multiplayer TFTD LP on StrategyCore, and they reported missing equipment on a lot of missions. I can go back and check if the missing equipment was on abort missions rather than victory missions. Sorry not to provide more specifics at this time but it was a hard mission and not exactly a controlled experiment. ;) [[User:Spike|Spike]] 21:35, 23 October 2012 (EDT)<br />
: I tried to reproduce this in the unmodified game without success, controlling for aquanauts being stunned/not stunned, inside/outside transport, stunned inside/outside transport. I didn't control for reloading the game, that sometimes causes glitches. I will retry with the Extender next and see if that reproduces anything. [[User:Spike|Spike]] 21:06, 24 October 2012 (EDT)<br />
Here's another thought. The problematic game was a Colony Assault which has a lot of objects in the object table. As the missing objects were created (corpses) or dropped (weapons) after the game started, they could be a long way down the object table. Now, doesn't TFTD have a bigger object table than EU? Maybe the TFTDextender is only recovering items from a sub-section of the TFTD object table? [[User:Spike|Spike]] 17:13, 26 October 2012 (EDT)<br />
<br />
== Save Equipment not working? ==<br />
<br />
With "Save Equipment" option enabled, the soldiers' loadout at first was always like this: grenade in leg slot, clip in backpack - and it didn't change on the next mission, despite the fact that I re-equipped the soldiers correctly (grenades and clips on the belt). When I manufactured Gauss Rifles and issued them to my soldiers, it got even worse - none of the soldiers got clips, and two of the rifles were unloaded. Next I upgraded to Sonic-Blasta Rifles and now nothing, except some grenades (still in leg slots), is issued to the soldiers at all. "Save Equipment" was known to work in UFOExtender, did something get broken? --[[User:Player701|Player701]] 09:18, 21 October 2012 (EDT)<br />
<br />
:''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. See the discussion on problems with the OBDATA mod about the final source of the problem and its solution.-[[User:Morgan525|Tycho]] 20:03, 21 October 2012 (EDT)''<br />
<br />
:: Would you suggest that everyone disables Save Equipment for the time being, in TFTDextender? [[User:Spike|Spike]] 07:44, 24 October 2012 (EDT)<br />
<br />
:''It couldn't hurt. I believe that TFTD has its own form of autoequip and part of the solution will probably require that I disable it. Something similar happened to the "stunned units are KIA" mod from UFOextender: TFTD has its own version that conflicted but, since it worked well, I only needed to add code to update the unit's location so the corpse would appear in the right place.-[[User:Morgan525|Tycho]] 22:38, 24 October 2012 (EDT)''<br />
<br />
:: I just did a few tests in raw TFTD (Steam CE) and the auto equip function is pretty basic: Give everyone a loaded weapon in what is probably reverse OBDATA.DAT order, then dish out any extra clips, grenades etc. Are you thinking that the Save Equipment efforts of TFTDextender are then being overwritten or partly overwritten by the existing TFTD auto equip function? I guess that would make sense. [[User:Spike|Spike]] 11:01, 25 October 2012 (EDT)<br />
<br />
=Resolved Problems=<br />
<br />
===<s> Cannot build Leviathan </s>===<br />
<br />
Hi Tycho. I've just researched Leviathan in my TFDExtender game but cannot manufacture it! I have enough resources (Plastics, IBA, ManNav), 3 workshops, more than 100 technicans and one empty sub pen. But when starting the Leviathan manufacture task I cannot assign any technicans to it. I press the "up" button, and there are no reaction to this. I can build Manta, but not Leviathan. Don't you know what is it? [[User:PavelB|PavelB]] 06:55, 2 October 2012 (EDT)<br />
<br />
:''I was able to replicate Pavel's problem and quickly 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. A simple change and the problem is fixed with patch 3.1 - [[User:Morgan525|Tycho]] 07:29, 28 October 2012 (EDT)''<br />
<br />
::I'm sorry, but I've just downloaded this patch and for me this error has not been fixed. (I simply ran into the same problem and went here to check it out). Maybe this doesn't work with saved games? I'm pretty sure I've downloaded the correct file, checked three times... --[[User:Player701|Player701]] 13:50, 28 October 2012 (EDT)<br />
<br />
===<s> Executable directive </s>===<br />
''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)<br />
<br />
=== <s>Extra Artefacts Reported</s> ===<br />
''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)<br />
''This will be fixed in the next release.-''[[User:Morgan525|Tycho]] 03:00, 13 October 2012 (EDT)<br />
: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
===<s>Manufacturing Projects Minimum Production</s> ===<br />
<br />
In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''<br />
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)<br />
<br />
Tested - If I reduce the production quantity of a current production run to less than what as already been produced, the display completion time changes (incorrectly) to 'Indefinite', but production ends after completion of the next unit. So if I start by producing 10 units, wait until I have produced 2, then reduce the quantity to 2 (or probably 1), production stops after 3 units. Thies basically replicates the pre-existing behaviour when using the down arrow on the Quantity, so there has been no loss of functionality with your Mod. Also, Autosell and Autoproduce work normally when applied as changes to an existing production run. The only thing is I can't distinguish them on the Manufacturing display - both say 'unlimited' quantity and 'indefinite' period - is that intended? I suppose it makes sense, but it would be good to be able to tell which kind of production it is, *** Autoproduce or $$$ Autosell. [[User:Spike|Spike]] 08:57, 2 October 2012 (EDT)<br />
<br />
:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''<br />
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)<br />
:::''OK. Changed the output to display "$unlimited$".[[User:Morgan525|Tycho]]<br />
<br />
===<s>Stunned MC'd Aquanauts MIA on Abort </s> ===<br />
<br />
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. <br />
::''I now have the code in place to uncontrol any creature that has been rendered unconscious. - -''[[User:Morgan525|Tycho]] 02:47, 11 October 2012 (EDT)<br />
This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
=== <s>Grenade Resistance in INI file </s> ===<br />
:''I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]<br />
<br />
<br />
===<s> Materials deducted from wrong base </s>===<br />
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''<br />
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)<br />
<br />
===<s> OBDATA / Dye Grenade mod not working? </s>===<br />
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)<br />
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
== <s>Displacer/Sonic damage fix</s> ==<br />
<br />
'' I changed the damage to be 130, same as the UFOpaedia entry.-''[[User:Morgan525|Tycho]] 03:52, 13 October 2012 (EDT)<br />
<br />
==<s> Weight Display in Inventory not Localised </s> ==<br />
<br />
At least when I run the game in German, it comes up as "Weight" and not something like "Gewicht". Reactions comes up ok as "Zeitwerte". [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
<br />
:''Added ability for users to added their own language by copying lines from Extender's page under the equipment section to the same section in their INI, alter the text as specified, and save the INI' [[User:Morgan525|Tycho]]<br />
<br />
<br />
== Things that TFTDextender does not fix ==<br />
<br />
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?):<br />
<br />
* 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.<br />
* Does not fix the incorrect pictures for the large USO in the interception window. <br />
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]<br />
* 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.)<br />
* 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).<br />
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.<br />
* 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.<br />
<br />
= Feature Requests and Suggestions =<br />
<br />
== Useful alien species research ==<br />
<br />
Tycho, I really like this idea you proposed in the StrategyCore forum:<br />
<br />
: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.<br />
<br />
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. <br />
<br />
:''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.'' [[User:Morgan525|Tycho]]<br />
::''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%, 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-100% for that lucky shot. With autopsy done, the game reverts back to the usual 0-200% on any hit.''<br />
<br />
::: 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". [[User:Spike|Spike]] 10:35, 15 September 2012 (EDT)<br />
<br />
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?<br />
<br />
:''I thought about that but the game doesn't record live aliens that have been researched. When you finish research on a live alien, it only follows the routine to unlock the appropriate UFOpaedia articles and then checks to see if the finished research can unlock other topics.'' [[User:Morgan525|Tycho]]<br />
<br />
I had a further thought on this while trying to guess what your new pre-requisites are for the various armours. For now it's really cool to be guessing but once people have figured it out, well, it will be more logical but still will have 'replay fatigue'. Would it be possible to randomise the pre-requisites for a lot of the key research topics, from out of a plausible list of items (or even randomise pre-requisite topics)? That would make every game fresh in terms of the research sequence, and make the research aspect of the game more challenging and less dry & predictable. As ever, just a suggestion. :) Cheers, [[User:Spike|Spike]] 16:01, 19 October 2012 (EDT)<br />
<br />
== All Units Can "Fly" In Water ==<br />
<br />
It's very illogical that most units are stuck on the seabed in underwater missions. Please provide the option to set all units (X-Com and alien) to have "flying" (i.e. swimming) ability when underwater. This is unlikely to cause an outbreak of 3D combat, since there is no cover except at seabed level, so anyone swimming excessively or incautiously is going to get shot. It might disadvantage the aliens if their tactical map waypoints are all set on the surface. But as some of them can "fly", there is hopefully a mechanism to deal with that in the code already. For me it will just solve the frustration of being unable to swim over small obstacles or swim up a level, and being stuck or tactically limited for no sensible reason. Mag-Ion Armour remains useful as an important step in Sub Research and (if using the Everything Works on Land mod) for land use. [[User:Spike|Spike]] 11:36, 9 September 2012 (EDT)<br />
: This requires setting [[UNITREF.DAT]] byte 0x78 bit 2 for the unit (e.g. for all units on both sides). Or the in-memory equivalent of UNITREF.DAT. [[User:Spike|Spike]] 10:19, 5 October 2012 (EDT)<br />
<br />
== Aliens Pick Up Weapons ==<br />
<br />
Related to Improved Alien AI. This makes the game tougher as stunned / panicked bipedal-type aliens are no longer permanently disarmed. This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. A fix for this would be a very helpful rebalancing of both games that eliminates one of the aliens' weak spots. The existing (but unused) routine looks pretty smart and not immediately exploitable to ambush aliens using weapons as traps. <br />
<br />
: I noticed the UFO Extender source code has a 'get' keyword under the OBDATA.DAT directive that populates this field 0x2D. Is that working? [[User:Spike|Spike]] 21:03, 16 October 2012 (EDT)<br />
:''It should be. I haven't tested it out but it should work like any other OBDATA change, in theory. As long as the code in the AI routine handles this byte, it should work. I believe someone mentioned under the Geoscape.exe page that the AI routine ignores any value under 5.-[[User:Morgan525|Tycho]] 00:58, 25 October 2012 (EDT)''<br />
<br />
== General Tank Modding ==<br />
<br />
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?<br />
<br />
Thanks,<br />
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)<br />
<br />
== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==<br />
<br />
Hook the right and left weapon menus on mind controlled aliens to add in actions for their built in melee attacks (if they have them) and built in Psi/MC attacks (if they have Psi/MC Skill). Ideally add these actions to the menu, and pop up a menu, even if the alien isn't holding any weapons.<br />
<br />
This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.<br />
<br />
== Fix Interception and Navigation Course Algorithms ==<br />
<br />
Or just find the algorithms and I volunteer to fix them!<br />
<br />
=== Use Great Circle Routes ===<br />
<br />
Travel toward the target on the shortest Great Circle, rather than always travelling along lines of latitude first (like they are some kind of main bus route!). <br />
<br />
=== Use Predictive Interception ===<br />
<br />
For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.<br />
<br />
=== Show Degree Headings ===<br />
<br />
The game only ever reports alien headings as North, South, East, West, but clearly alien craft move in other directions than just these four, and clearly XCOM detection equipment is capable of resolving these finer-grained headings, since the crafts' tracks are shown correctly in the Geoscope. <br />
As a first step towards predictive interceptions, it would be great to display the alien craft's heading in degrees, eg 135 degrees for South-East. Maybe rounded to the nearest 5 or 10 degrees.<br />
<br />
== Interception Craft vs Touched Down Alien Craft == <br />
<br />
If an alien craft is touched down and an XCOM interception craft (not touched down) is at the same X/Y position, if the alien craft begins to move, immediately open the Interception window at minimum range (8km/nm), presumably with the alien attempting to get away / break off. Currently the Interception window only happens if the XCom craft is faster, which is dumb, ''even if'' the alien craft could accelerate instantly to its maximum speed. <br />
<br />
For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach. <br />
<br />
== Fun, not Funky, Fire ==<br />
<br />
An alternative option for incendiaries/phosphorous damage processing: Do process the so called 'impact' damage of an incendiary on every shot, not just at the end of the turn. But only apply it to those in the area of affect of this specific shell burst, not to all units who are standing in smoke or fire anywhere on the map. This will please fans of incendiaries/phosphorous. It's probably a balancing, rather than unbalancing, change in the relative strengths of the ammo types. Makes incendiaries/phosphorous useful for more than just illumination or desperation. Gives some use to the research topics that advise use of incendiaries/phosphorous, and the damage modifiers aliens have been assigned.<br />
<br />
== Rearming Rates ==<br />
<br />
<br />
From [[Known_Bugs_(TFTD)#Geoscape_Bugs]]:<br />
<br />
=== Craft Gauss Cannon Rearming Rate ===<br />
<br />
This weapon rearms at 10/hr but probably should be 50/hr or at least 25/hr, otherwise it is far slower to rearm than any other cannon weapon in either game. In fact it's the second slowest weapon system to rearm, slower only than AJAX...<br />
<br />
=== AJAX Rearming Rate ===<br />
<br />
An AJAX system takes twice as long to fully reload as a D.U.P. system, as a result AJAX-armed Craft have much worse operational tempo and readiness than D.U.P. armed Craft. Like we needed yet another reason to always use D.U.Ps. This is probably a design error rather than a bug, but it would be good to fix it - anything to give a more balanced set of craft weapon choices. The rearming rate should be raised from 1/hr to 2/hr. The AJAX system will then have the same operational tempo as the D.U.P. system. <br />
<br />
Could also be applied to Stingray missiles in EU 1994, as the same analysis applies to Stingray vs Avalanche.<br />
<br />
== Retaliate for Colony Assault ==<br />
<br />
See this discussion [[Talk:Alien_Retaliation#Retaliation_Triggers]]. Colony raids are a good way for the alien to lose badly, so it would be a good balancing move to create severe consequences for raiding. It is at least as sensible as retaliation for USO Assaults.</div>Player701https://temp.ufopaedia.org/index.php?title=Talk:TFTDextender&diff=40007Talk:TFTDextender2012-10-21T21:19:58Z<p>Player701: </p>
<hr />
<div>=Questions or Comments=<br />
'''A place to provide feedback or ask questions:'''<br />
<br />
The zip archive does not seem to include an .ini file. Where do I get the .ini file from? [[User:Spike|Spike]] 12:37, 6 September 2012 (EDT)<br />
:: Oh hang on. It looks like the latest version of the zip file does not include the .ini file. When I go back to the previous version of the zip file, I can see the .ini file. [[User:Spike|Spike]] 17:45, 6 September 2012 (EDT)<br />
<br />
:::''The latest release is a patch, which means there are no new additions to the INI. I don't include it in patches usually so that those who already have the prior release don't have to reconfigure their current INI. It may not seem like a big deal now but earlier, I was releasing fixes almost on a weekly basis and so I still continue with that idea.''[[User:Morgan525|Tycho]]<br />
:::: Ah I guessed that might be the reason. Makes a lot of sense. It really sucks to have a customised INI file overwritten. [[User:Spike|Spike]] 07:25, 7 September 2012 (EDT)<br />
<br />
== Bug Reports ==<br />
<br />
=== Crash 0xFFE00B30 ===<br />
<br />
:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."<br />
<br />
''Interesting. I had someone report a similar thing when they were starting their first instance of the battlescape on a new install of the game. I looked into it and the game generated some bad data. When he let the UFO take off and land again, the battle started with no problems..''<br />
<br />
:It's [[Known_Bugs_(TFTD)#Geoscape_Bugs|a bug I've reported before]] (before TFTD Extender even existed), so it's not specific to TFTDExtender / UFOExtender. What is happening is the Alien Sub is landing on land, and the Triton is also attempting to land on land. Probably the game crashes when it fails to generate the appropriate terrain type? So the GEOSCAPE map/terrain data must be corrupted. I've seen three examples of this. In a couple of cases the landing site is clearly inland, by hundreds of kilometres. In some cases it's right on the sea/land boundary and hard to tell. I have two save games that reproduce the bug now. From memory, the previous cases all happened around North Africa, like these present cases. [[User:Spike|Spike]] 08:31, 9 September 2012 (EDT)<br />
<br />
=== Cannot build Leviathan ===<br />
<br />
Hi Tycho. I've just researched Leviathan in my TFDExtender game but cannot manufacture it! I have enough resources (Plastics, IBA, ManNav), 3 workshops, more than 100 technicans and one empty sub pen. But when starting the Leviathan manufacture task I cannot assign any technicans to it. I press the "up" button, and there are no reaction to this. I can build Manta, but not Leviathan. Don't you know what is it? [[User:PavelB|PavelB]] 06:55, 2 October 2012 (EDT)<br />
<br />
: Double check that you have sufficient cash to start the project, iirc $600K or so. That matches this symptom. Also that you have enough workshop space available (Leviathan needs a lot of space). Failing that, cancel all existing manufacturing projects, then retry. Failing that you could try reducing Technicians below 100 but that's taking us into Bug territory. [[User:Spike|Spike]] 07:17, 2 October 2012 (EDT)<br />
<br />
:: Resources are 100% enough. I've launched "Terror from the Deep.exe", loaded this saved game and started manufacturing Lev without any problems. I've saved this variant with Lev being manufactured and then loaded it from "TFTDextender.exe". As a result the process was okey, but I could only decrease the number of technicans working on it, not increase (even after decreasing!). That is: with 64 technicans had been assigned, I've pressed the "down" button, and the number changed to 63. But then I was unable to revert it to 64 by pressing "up" button: it didn't work! [[User:PavelB|PavelB]] 07:57, 2 October 2012 (EDT)<br />
:''I'll check into it. Although, I can't understand how changes to the research tree would affect production. Unless it has something to do with the autoproduce feature?''<br />
:'''This problem may be fixed with the same patch that fixed the production materials being deducted from the wrong base. Can anyone confirm?'''- - [[User:Morgan525|Tycho]] 23:12, 17 October 2012 (EDT)<br />
:: If I try to replicate PavelB's situation, I am able to build a Leviathan with no problems using the latest build. However I am also able to build a Leviathan using the 1.05p1.1 build. So I'm not able to replicate his original problem unfortunately. [[User:Spike|Spike]] 19:18, 19 October 2012 (EDT)<br />
<br />
===<s> Materials deducted from wrong base </s>===<br />
<br />
My second base has -20 Aqua Plastics. Might be XComUtil's fault rather than TFTD Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
I don't use any mods/editor except TFDExtender, bus still have -98 Zrbite, -4 Lobster Man Corpses, -5 I-B Accs, -3 MagNavs and -358 Aqua Plastics on my second base! (and nothing extraordinary at other bases).<br />
:: Interesting. In the game where I found - 20 Aqua Plastics at my second base, I was manufacturing Plastic Aqua Armour at the first base. So it could be that a change to the manufacturing routine in TFTDextender is deducting manufacturing resources from the wrong base. It might also explain PavelB's Leviathan problem. [[User:Spike|Spike]] 09:32, 3 October 2012 (EDT)<br />
<br />
As an update on this, it does render the affected base if not unusable, hard to use, because the negative value is interpreted as a very large unsigned integer (60000+) and this has the effect of eliminating all Stores capacity at the base. The consequence is you can't buy anything at the base, nor transfer to it. [[User:Spike|Spike]] 22:41, 14 October 2012 (EDT)<br />
<br />
Steps to reproduce: <br />
# Start a new game under TFTDExtender<br />
# Create a second base. <br />
# Start construction of General Stores at second base (probably this is irrelevant)<br />
# Enable Aqua Plastics technology and Plastic Aqua Armour technology (eg XComUtil TEC:ALL) <br />
# Produce 4 Aqua Plastics at first base, without using autoproduce/autosell<br />
# Check Base Information - Stores at both bases. <br />
## = as expected, 4 at base 1 and zero at base 2<br />
# Then produce 1 Plastic Aqua Armour at first base, without using autoproduce/autosell<br />
# As soon as production starts, check Buy/Sell and Base Info - Stores at both bases<br />
## = At first base, 4 Aqua Plastics are still present and have not been deducted. <br />
## = At second base, -4 Aqua Plastics shown in Buy/Sell, equivalent unsigned two byte number shown in Stores<br />
<br />
Weirdly, this seems to happen even if Auto sell = 0 in the TFTDExtender.ini file. But it seems like a fairly ordinary off-by-one index type of error I guess? I confirmed it does not recur in the base game, the CE executable from Steam. It does not occur when running the game under XComUtil. Only when running under TFTD Extender. Since it does not seem sensitive to Auto sell = 0/1, I would guess it is due one of the bug fixes? Maybe some of the manufacturing exploit fixes? [[User:Spike|Spike]] 22:00, 16 October 2012 (EDT)<br />
<br />
: I think I may have localised this bug to the "Manufacture Rate Limit Fix". If I disable that particular bug fix, I get normal behaviour, i.e. manufacturing materials are deducted from the base where the manufacturing happens, not the next base. Also I'm going to go out on a limb and guess this is the same cause as Cannot Build Leviathan, above. [[User:Spike|Spike]] 22:14, 16 October 2012 (EDT)<br />
<br />
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''<br />
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)<br />
<br />
== Minor Bugs ==<br />
<br />
===<s> OBDATA / Dye Grenade mod not working? </s>===<br />
<br />
I can't seem to get this to work. Regardless of what I do, the Dye Grenade radius is the same as in the unpatched game. It starts on one square, slowly spreads out to about a 4 by 4 diamond, then contracts and fades out. Am I doing something wrong? Is it using the right OBDATA.DAT file? [[User:Spike|Spike]] 09:41, 7 September 2012 (EDT)<br />
: I'm not sure this feature is working for me at all. I tried changing the stats of a Dart Gun like this, also with no apparent effect. <br />
<br />
[OBDATA.DAT]<br />
Apply=01<br />
;Dye grenade will have similar initial effect as smoke grenade in EU.<br />
Dye Grenade Damage=60<br />
;Mega Dart Gun<br />
Dart Pistol Auto TUs=50<br />
Dart Pistol Auto accuracy=20<br />
Dart Pistol Snap accuracy=50<br />
Dart Pistol Aimed accuracy=100<br />
;Mega Dart Pistol ammo<br />
Dart Pod Damage=250<br />
Dart Pod Size=100<br />
;Turn HJC-AP into mega-phosphorous shell<br />
AP-Shell Damage Type=1<br />
AP-Shell Damage=250<br />
;Turn HJC-P into mega-phosphorous shell<br />
Phosphorous-Shell Damage=250<br />
;mega-pack<br />
Magna-Pack Damage=250<br />
;mini-pack<br />
;Magna-Pack Damage=20<br />
<br />
[[User:Spike|Spike]] 16:39, 8 September 2012 (EDT)<br />
I've checked that OBDATA modding works ok in UFOExtender. I can't get it to work in TFDExtender though. I have tried modding one-word items like Magna-pack. I have tried using the [[Talk:OBDATA.DAT (TFTD)|exact literal names from OBDATA.DAT (TFTD)]]. I have tried using the literal names from UFO. All no good. The record structure looks to be the same in TFTD as in UFO. I am a bit stumped. [[User:Spike|Spike]] 22:32, 8 September 2012 (EDT)<br />
<br />
:''OK. I'll look into it. My work has restarted so I am a little busy right now. Once I get readjusted to the work schedule, I'll be able to investigate more.''[[User:Morgan525|Tycho]] 04:23, 9 September 2012 (EDT) <br />
I completely understand. Thank you so much for this amazing contribution. [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
: update - ''I think I located the problem, the LoadFile command had been referencing the wrong LoadFile subroutine.''<br />
Excellent. I will be happy test as soon as you have time to upload an update. [[User:Spike|Spike]] 09:45, 20 September 2012 (EDT)<br />
: ''check this with the latest patch. [[User:Morgan525|Tycho]]''<br />
<br />
With 1.05p1.1, the Dye Grenade fix is working regardless of whether I do Apply=1 in the OBDATA.DAT section. I can't get anything else to work still. [[User:Spike|Spike]] 10:05, 2 October 2012 (EDT)<br />
<br />
Hang on, looks like it only works with a New Game? I got some things working but it's still not working 100% for me, but I will continue to investigate, I could be using the wrong names or settings etc. See updates to config file above. [[User:Spike|Spike]] 11:17, 2 October 2012 (EDT)<br />
:''It could be that I'll need to add multiple hooks into the executable to ensure that the mod is loaded at all times. - [[User:Morgan525|Tycho]] 22:35, 2 October 2012 (EDT)''<br />
<br />
OK it does seem to work on loaded saved games as well as in new games. The OBDATA.DAT changes are reflected in the in-game UFOPedia. But, the names of the objects to modify must be the exact literal strings that I posted in [[Talk:OBDATA.DAT_(TFTD)#Exact literal item name strings]]. The strings on the main page of the OBDATA.DAT article have been "corrected" and don't always exactly match what's in OBDATA.DAT. And I'm still not convinced all attributes are being copied over correctly into TACTICAL, even when they appear correctly in the in-game UFOPedia. I can change the damage of ammo types and see updates in the in game UFOPedia, but no change in damage or area of effect on the battlefield. [[User:Spike|Spike]] 10:34, 3 October 2012 (EDT)<br />
:''maybe the best test would be to zero damage on items and shoot an unarmed aquanaut?''<br />
<br />
I went back and checked UFO Extender. In UFO Extender I am able to make a full set of changes to a Pistol using basically the same config settings as above. In TFTD Extender, I am only able to affect what is reported in the in game UFOPedia, and the actual clip size. I even went so far as to double check the structure of OBDATA.DAT in both games, by inspection, but it does appear to be the same, at least for Damage which is the thing I'm unable to change in TFTD. Could this possibly be that LoadFile issue again? [[User:Spike|Spike]] 18:24, 3 October 2012 (EDT)<br />
<br />
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)<br />
<br />
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
=== Weightless Ammo Bug ===<br />
<br />
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)<br />
<br />
''From what I understand right now, I am pretty sure I can arrange it so that weapons are not automatically loaded and soldiers would be given an extra clip. Feedback?''<br />
: By an extra clip, you mean the clip/ammo that would have been loaded into the weapon is instead carried by the soldier? And for carried clips, the encumbrance effects are correct. For me anyway, in order of most benefit, the options would be<br />
:# Fix the root cause of the bug (ensure all relevant object locations and "contains/contained in" pointers are set during automatic clip loading) so that automatically loaded clips correctly affect encumbrance <br />
:# As a workaround, don't load ammo for multi-ammotype weapons (Heavy Cannon/Gas Cannon, Auto-Cannon/Hydrojet Cannon, Rocket Launcher / Torpedo Launcher). These are the weapons for which the bug has the greatest impact, since it imposes a 'cost' of switching away from the automatically-loaded ammo (usually AP or Small Rocket/Torp). With single-ammotype weapons, there's never any need to change the clips before combat. <br />
:# As a workaround, don't load ammo for any weapons. This avoids the 'switching cost' issue but does impose a fairly significant logistics overhead on each combat, to go through and manually load all clips. Plus the risk that you forget to load a weapon and only find out at a critical moment. :) This is for the "purist" who wants to make the game harder.<br />
:If it's tricky to fix the root cause, any of the other two options would be helpful. Suggested text:<br />
:* [Multi Ammo Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. Weapons using multiple ammo types (Heavy Cannon, Auto-Cannon, Rocket Launcher / Gas Cannon, Hydrojet Cannon, Torpedo Launcher) will not be pre-loaded before combat. You will need to load these weapons manually during the pre-combat Equip phase. This will significantly affect the heavy weapons ammunition load your squad can carry into combat without suffering encumbrance penalties, thus making the early game harder.<br />
:* [All Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. This option overrides the previous option. No weapons will be pre-loaded before combat. You will need to load all ammo manually during the pre-combat Equip phase. This will significantly affect the ammunition load your squad can carry into combat without suffering encumbrance penalties, making the early game harder.<br />
:[[User:Spike|Spike]] 05:10, 21 September 2012 (EDT)<br />
::''I found the source of the problem: 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 changed in inventory management.-''[[User:Morgan525|Tycho]] 19:00, 19 October 2012 (EDT)<br />
::: That is just awesome! :D [[User:Spike|Spike]] 22:36, 19 October 2012 (EDT)<br />
<br />
=== <s>Grenade Resistance in INI file </s> ===<br />
<br />
I think this is a holdover from UFOExtender, because 'Grenade' is not a TFTD object, and in TFTD I think all forms of grenades already have high damage resistance, and so are already "stackable". [[User:Spike|Spike]] 09:14, 7 September 2012 (EDT)<br />
:''Your correct. I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]<br />
<br />
=== MIA Bugs ===<br />
<br />
==== <s>Stunned MC'd Aquanauts MIA on Abort </s> ====<br />
<br />
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. <br />
:''This is one of those exceptional cases where my End of Battle (Abort?) routine doesn't cover. If the aquanaut is MCed or unconscious the EOB routine will correct these states and end the battle but it doesn't check for both on the same unit, so an aquanaut who was MCed and then made unconscious, may fall through the hole that was originally in the game. [[User:Morgan525|Tycho]]'' <br />
<br />
::''I now have the code in place to uncontrol any creature that has been rendered unconscious. - -''[[User:Morgan525|Tycho]] 02:47, 11 October 2012 (EDT)<br />
<br />
This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
==== Stunned Carried Aquanauts MIA on Abort ====<br />
<br />
While you are looking the EOB script, I noticed one more anomaly. I'm not sure if this is an original bug or an Extender bug. If you are carrying a stunned Aquanaut in the transport at the time of Abort, the stunned Aquanaut is lost (MIA). You have to drop the stunned Aquanaut on the floor. Probably this is because the position of the Aquanaut has not been updated and is still pointing to where they were stunned, not to the location of the carrying Aquanaut. [[User:Spike|Spike]] 04:49, 27 September 2012 (EDT)<br />
<br />
:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. At least it is manageable: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)<br />
<br />
==== Supernumary MIA on Abort ====<br />
<br />
I Abort a mission with 8 Aquanauts and get the confirmation message "8 Aquanauts inside craft, 2 outside". No one has been stunned or MCd. I did have two aquanauts, only, outside, but they have moved back inside the transport. Very odd. Saved Equipment was enabled. [[User:Spike|Spike]] 11:06, 5 October 2012 (EDT)<br />
<br />
:''How many Aquanauts did you have in total: 10?- -''[[User:Morgan525|Tycho]] 02:54, 11 October 2012 (EDT)<br />
:: I started the mission with only 8 Aquanauts and they all survived. Only two had even been outside the transport (quite an unusual situation). However I can't reproduce this bug, so please ignore it unless/until I can reproduce it. :) [[User:Spike|Spike]] 06:48, 17 October 2012 (EDT)<br />
<br />
==== Crewed Flying Sub Lost on Abort ====<br />
<br />
Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)<br />
<br />
:Presumably the 3 aquanauts in the craft were not stunned or mind controlled on the Abort turn? [[User:Spike|Spike]] 16:37, 21 October 2012 (EDT)<br />
:Right, they are not stunned (or dead) and they are under your control. And they are definitely in the sub. OK this is similar to a minor bug I have seen before - see [[#Supernumary MIA on Abort|preceding item]]. On your pre-abort confirmation screen it says "3 units in craft, 9 units outside". I've had a similar issue before. It's double counting your aquanauts as being both inside and outside the craft on the confirm screen, since you only have 9 units (8 and 1 tank) in total. On actual abort you incorrectly get 9 MIAs (including the tank presumably) and I guess that's why you lose the sub. Interestingly, the 3 affected aquanauts look like they never moved from their original positions, is that true? I believe when I've had similar problems before, it related to aquanauts who had never left the sub / never left their initial positions. We will have to see if Tycho can get to the bottom of this one. [[User:Spike|Spike]] 16:51, 21 October 2012 (EDT)<br />
::Yes, that's true - those 3 haven't moved from their original positions. --[[User:Player701|Player701]] 17:19, 21 October 2012 (EDT)<br />
<br />
=== <s>Extra Artefacts Reported</s> ===<br />
<br />
I quite often recover 1 or 2 alien artefacts according to the Results screen, even though I am Aborting the mission and have definitely not brought anything back to the transport. I don't think I'm actually bringing back any artefacts - I think the Results screen is reporting incorrectly for some reason. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''I've seen this too. You are correct that no artifacts are actually found and it's a minor problem with the EOB calculations. Since it only gives players a minor boost (a few points at most) to their score, it's low on my to-do list at the moment.''<br />
:: Hmm I just came back from a mission (first mission of a new game) and I had two alien sonic clips available as new Research topics (Pistol and Blasta), even though I aborted the mission with no loot. I did use XComHack to edit other equipment on the Triton so it may be related to that. I'll let you know if it recurs. [[User:Spike|Spike]] 08:47, 2 October 2012 (EDT)<br />
:::''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)<br />
:::''This will be fixed in the next release.-''[[User:Morgan525|Tycho]] 03:00, 13 October 2012 (EDT)<br />
<br />
:::: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
===<s>Manufacturing Projects Minimum Production</s> ===<br />
<br />
In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''<br />
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)<br />
<br />
Tested - If I reduce the production quantity of a current production run to less than what as already been produced, the display completion time changes (incorrectly) to 'Indefinite', but production ends after completion of the next unit. So if I start by producing 10 units, wait until I have produced 2, then reduce the quantity to 2 (or probably 1), production stops after 3 units. Thies basically replicates the pre-existing behaviour when using the down arrow on the Quantity, so there has been no loss of functionality with your Mod. Also, Autosell and Autoproduce work normally when applied as changes to an existing production run. The only thing is I can't distinguish them on the Manufacturing display - both say 'unlimited' quantity and 'indefinite' period - is that intended? I suppose it makes sense, but it would be good to be able to tell which kind of production it is, *** Autoproduce or $$$ Autosell. [[User:Spike|Spike]] 08:57, 2 October 2012 (EDT)<br />
<br />
:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''<br />
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)<br />
:::''OK. Changed the output to display "$unlimited$".[[User:Morgan525|Tycho]]<br />
<br />
=== Weight Display in Inventory not Localised ===<br />
<br />
At least when I run the game in German, it comes up as "Weight" and not something like "Gewicht". Reactions comes up ok as "Zeitwerte". [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
<br />
:''There is no entry in the text DAT files for "weight". Seb had to add the text string for it into his subroutine. Thanks for pointing it out.'' [[User:Morgan525|Tycho]]<br />
<br />
===<s> Executable directive </s>===<br />
<br />
It looks to me that the Executable directive is being ignored and the loader always loads Terror from the Deep.exe. Is that correct? [[User:Spike|Spike]] 15:35, 24 September 2012 (EDT)<br />
<br />
:''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.-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)<br />
<br />
== Displacer/Sonic damage fix ==<br />
<br />
If I understand this fix correctly, the Displacer/Sonic weapon damage has been increased to 150 from the previous in-code value of 110, and vs the previous UFOPedia entry of 130? SWS Sonic weapon damage has been increased to 150 because this matches the craft-mounted Sonic Oscillator?<br />
<br />
I don't think this is the right idea. Increasing damage to 150 gives Displacer/Sonic a higher damage level than Displacer/PWT. That removes some of the distinctiveness of Displacer/PWT, and more importantly it is inconsistent with the general principle in the game that PWT weapons (of a given class) do more damage than Sonic (which in turn do more than Gauss). That is true for infantry weapons, SWS weapons (unless you create this exception), and Craft weapons. <br />
<br />
Also, there is no reason why SWS weapon damage should be equated to Craft weapon damage. I'm pretty sure that Battlescape damage values and Craft combat (Geoscape Interception) damage values are completely different, they are not meant to be compared to each other in any way. There is only one SWS weapon that has the same damage as its equivalent Craft weapon, and that is the Coelacanth/Gauss = Gauss Cannon. I think this is a coincidence, as the other equivalent weapons are all different between the SWS version and the Craft version (this applies to Gas Cannon, PWT, Sonic, and also Aqua Jet vs torpedos). <br />
<br />
Clearly there ''is'' an inconsistency between the code and the UFOPedia, and that should be fixed. It's hard to say if the "right" value is 110 or 130. Is the code wrong or is the UFOPedia wrong? It could be either way. But I would correct this inconsistency either to 110 or to 130, not increase it to 150. <br />
<br />
[[User:Spike|Spike]] 08:02, 7 September 2012 (EDT)<br />
<br />
: Or make it an option: Displacer Sonic Fix={0|110|130|150} [[User:Spike|Spike]] 09:50, 9 September 2012 (EDT)<br />
'' I changed the damage to be 125, similar to the ratio for the hovertank turrent to plasma cannon.-''[[User:Morgan525|Tycho]] 03:52, 13 October 2012 (EDT)<br />
<br />
== Things that TFTDextender does not fix ==<br />
<br />
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?):<br />
<br />
* 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.<br />
* Does not fix the incorrect pictures for the large USO in the interception window. <br />
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]<br />
* 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.)<br />
* 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).<br />
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.<br />
* 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.<br />
<br />
== Save Equipment not working? ==<br />
<br />
With "Save Equipment" option enabled, the soldiers' loadout at first was always like this: grenade in leg slot, clip in backpack - and it didn't change on the next mission, despite the fact that I re-equipped the soldiers correctly (grenades and clips on the belt). When I manufactured Gauss Rifles and issued them to my soldiers, it got even worse - none of the soldiers got clips, and two of the rifles were unloaded. Next I upgraded to Sonic-Blasta Rifles and now nothing, except some grenades (still in leg slots), is issued to the soldiers at all. "Save Equipment" was known to work in UFOExtender, did something get broken? --[[User:Player701|Player701]] 09:18, 21 October 2012 (EDT)<br />
<br />
= Feature Requests and Suggestions =<br />
<br />
== Useful alien species research ==<br />
<br />
Tycho, I really like this idea you proposed in the StrategyCore forum:<br />
<br />
: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.<br />
<br />
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. <br />
<br />
:''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.'' [[User:Morgan525|Tycho]]<br />
::''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%, 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-100% for that lucky shot. With autopsy done, the game reverts back to the usual 0-200% on any hit.''<br />
<br />
::: 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". [[User:Spike|Spike]] 10:35, 15 September 2012 (EDT)<br />
<br />
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?<br />
<br />
:''I thought about that but the game doesn't record live aliens that have been researched. When you finish research on a live alien, it only follows the routine to unlock the appropriate UFOpaedia articles and then checks to see if the finished research can unlock other topics.'' [[User:Morgan525|Tycho]]<br />
<br />
I had a further thought on this while trying to guess what your new pre-requisites are for the various armours. For now it's really cool to be guessing but once people have figured it out, well, it will be more logical but still will have 'replay fatigue'. Would it be possible to randomise the pre-requisites for a lot of the key research topics, from out of a plausible list of items (or even randomise pre-requisite topics)? That would make every game fresh in terms of the research sequence, and make the research aspect of the game more challenging and less dry & predictable. As ever, just a suggestion. :) Cheers, [[User:Spike|Spike]] 16:01, 19 October 2012 (EDT)<br />
<br />
== All Units Can "Fly" In Water ==<br />
<br />
It's very illogical that most units are stuck on the seabed in underwater missions. Please provide the option to set all units (X-Com and alien) to have "flying" (i.e. swimming) ability when underwater. This is unlikely to cause an outbreak of 3D combat, since there is no cover except at seabed level, so anyone swimming excessively or incautiously is going to get shot. It might disadvantage the aliens if their tactical map waypoints are all set on the surface. But as some of them can "fly", there is hopefully a mechanism to deal with that in the code already. For me it will just solve the frustration of being unable to swim over small obstacles or swim up a level, and being stuck or tactically limited for no sensible reason. Mag-Ion Armour remains useful as an important step in Sub Research and (if using the Everything Works on Land mod) for land use. [[User:Spike|Spike]] 11:36, 9 September 2012 (EDT)<br />
: This requires setting [[UNITREF.DAT]] byte 0x78 bit 2 for the unit (e.g. for all units on both sides). Or the in-memory equivalent of UNITREF.DAT. [[User:Spike|Spike]] 10:19, 5 October 2012 (EDT)<br />
<br />
== Aliens Pick Up Weapons ==<br />
<br />
Related to Improved Alien AI. This makes the game tougher as stunned / panicked bipedal-type aliens are no longer permanently disarmed. This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. A fix for this would be a very helpful rebalancing of both games that eliminates one of the aliens' weak spots. The existing (but unused) routine looks pretty smart and not immediately exploitable to ambush aliens using weapons as traps. <br />
<br />
: I noticed the UFO Extender source code has a 'get' keyword under the OBDATA.DAT directive that populates this field 0x2D. Is that working? [[User:Spike|Spike]] 21:03, 16 October 2012 (EDT)<br />
<br />
== General Tank Modding ==<br />
<br />
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?<br />
<br />
Thanks,<br />
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)<br />
<br />
== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==<br />
<br />
Hook the right and left weapon menus on mind controlled aliens to add in actions for their built in melee attacks (if they have them) and built in Psi/MC attacks (if they have Psi/MC Skill). Ideally add these actions to the menu, and pop up a menu, even if the alien isn't holding any weapons.<br />
<br />
This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.<br />
<br />
== Fix Interception and Navigation Course Algorithms ==<br />
<br />
Or just find the algorithms and I volunteer to fix them!<br />
<br />
=== Use Great Circle Routes ===<br />
<br />
Travel toward the target on the shortest Great Circle, rather than always travelling along lines of latitude first (like they are some kind of main bus route!). <br />
<br />
=== Use Predictive Interception ===<br />
<br />
For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.<br />
<br />
=== Show Degree Headings ===<br />
<br />
The game only ever reports alien headings as North, South, East, West, but clearly alien craft move in other directions than just these four, and clearly XCOM detection equipment is capable of resolving these finer-grained headings, since the crafts' tracks are shown correctly in the Geoscope. <br />
As a first step towards predictive interceptions, it would be great to display the alien craft's heading in degrees, eg 135 degrees for South-East. Maybe rounded to the nearest 5 or 10 degrees.<br />
<br />
== Interception Craft vs Touched Down Alien Craft == <br />
<br />
If an alien craft is touched down and an XCOM interception craft (not touched down) is at the same X/Y position, if the alien craft begins to move, immediately open the Interception window at minimum range (8km/nm), presumably with the alien attempting to get away / break off. Currently the Interception window only happens if the XCom craft is faster, which is dumb, ''even if'' the alien craft could accelerate instantly to its maximum speed. <br />
<br />
For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach. <br />
<br />
== Fun, not Funky, Fire ==<br />
<br />
An alternative option for incendiaries/phosphorous damage processing: Do process the so called 'impact' damage of an incendiary on every shot, not just at the end of the turn. But only apply it to those in the area of affect of this specific shell burst, not to all units who are standing in smoke or fire anywhere on the map. This will please fans of incendiaries/phosphorous. It's probably a balancing, rather than unbalancing, change in the relative strengths of the ammo types. Makes incendiaries/phosphorous useful for more than just illumination or desperation. Gives some use to the research topics that advise use of incendiaries/phosphorous, and the damage modifiers aliens have been assigned.<br />
<br />
== Rearming Rates ==<br />
<br />
<br />
From [[Known_Bugs_(TFTD)#Geoscape_Bugs]]:<br />
<br />
=== Craft Gauss Cannon Rearming Rate ===<br />
<br />
This weapon rearms at 10/hr but probably should be 50/hr or at least 25/hr, otherwise it is far slower to rearm than any other cannon weapon in either game. In fact it's the second slowest weapon system to rearm, slower only than AJAX...<br />
<br />
=== AJAX Rearming Rate ===<br />
<br />
An AJAX system takes twice as long to fully reload as a D.U.P. system, as a result AJAX-armed Craft have much worse operational tempo and readiness than D.U.P. armed Craft. Like we needed yet another reason to always use D.U.Ps. This is probably a design error rather than a bug, but it would be good to fix it - anything to give a more balanced set of craft weapon choices. The rearming rate should be raised from 1/hr to 2/hr. The AJAX system will then have the same operational tempo as the D.U.P. system. <br />
<br />
Could also be applied to Stingray missiles in EU 1994, as the same analysis applies to Stingray vs Avalanche.</div>Player701https://temp.ufopaedia.org/index.php?title=Talk:TFTDextender&diff=39965Talk:TFTDextender2012-10-21T14:39:12Z<p>Player701: </p>
<hr />
<div>=Questions or Comments=<br />
'''A place to provide feedback or ask questions:'''<br />
<br />
The zip archive does not seem to include an .ini file. Where do I get the .ini file from? [[User:Spike|Spike]] 12:37, 6 September 2012 (EDT)<br />
:: Oh hang on. It looks like the latest version of the zip file does not include the .ini file. When I go back to the previous version of the zip file, I can see the .ini file. [[User:Spike|Spike]] 17:45, 6 September 2012 (EDT)<br />
<br />
:::''The latest release is a patch, which means there are no new additions to the INI. I don't include it in patches usually so that those who already have the prior release don't have to reconfigure their current INI. It may not seem like a big deal now but earlier, I was releasing fixes almost on a weekly basis and so I still continue with that idea.''[[User:Morgan525|Tycho]]<br />
:::: Ah I guessed that might be the reason. Makes a lot of sense. It really sucks to have a customised INI file overwritten. [[User:Spike|Spike]] 07:25, 7 September 2012 (EDT)<br />
<br />
== Bug Reports ==<br />
<br />
=== Crash 0xFFE00B30 ===<br />
<br />
:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."<br />
<br />
''Interesting. I had someone report a similar thing when they were starting their first instance of the battlescape on a new install of the game. I looked into it and the game generated some bad data. When he let the UFO take off and land again, the battle started with no problems..''<br />
<br />
:It's [[Known_Bugs_(TFTD)#Geoscape_Bugs|a bug I've reported before]] (before TFTD Extender even existed), so it's not specific to TFTDExtender / UFOExtender. What is happening is the Alien Sub is landing on land, and the Triton is also attempting to land on land. Probably the game crashes when it fails to generate the appropriate terrain type? So the GEOSCAPE map/terrain data must be corrupted. I've seen three examples of this. In a couple of cases the landing site is clearly inland, by hundreds of kilometres. In some cases it's right on the sea/land boundary and hard to tell. I have two save games that reproduce the bug now. From memory, the previous cases all happened around North Africa, like these present cases. [[User:Spike|Spike]] 08:31, 9 September 2012 (EDT)<br />
<br />
=== Cannot build Leviathan ===<br />
<br />
Hi Tycho. I've just researched Leviathan in my TFDExtender game but cannot manufacture it! I have enough resources (Plastics, IBA, ManNav), 3 workshops, more than 100 technicans and one empty sub pen. But when starting the Leviathan manufacture task I cannot assign any technicans to it. I press the "up" button, and there are no reaction to this. I can build Manta, but not Leviathan. Don't you know what is it? [[User:PavelB|PavelB]] 06:55, 2 October 2012 (EDT)<br />
<br />
: Double check that you have sufficient cash to start the project, iirc $600K or so. That matches this symptom. Also that you have enough workshop space available (Leviathan needs a lot of space). Failing that, cancel all existing manufacturing projects, then retry. Failing that you could try reducing Technicians below 100 but that's taking us into Bug territory. [[User:Spike|Spike]] 07:17, 2 October 2012 (EDT)<br />
<br />
:: Resources are 100% enough. I've launched "Terror from the Deep.exe", loaded this saved game and started manufacturing Lev without any problems. I've saved this variant with Lev being manufactured and then loaded it from "TFTDextender.exe". As a result the process was okey, but I could only decrease the number of technicans working on it, not increase (even after decreasing!). That is: with 64 technicans had been assigned, I've pressed the "down" button, and the number changed to 63. But then I was unable to revert it to 64 by pressing "up" button: it didn't work! [[User:PavelB|PavelB]] 07:57, 2 October 2012 (EDT)<br />
:''I'll check into it. Although, I can't understand how changes to the research tree would affect production. Unless it has something to do with the autoproduce feature?''<br />
:'''This problem may be fixed with the same patch that fixed the production materials being deducted from the wrong base. Can anyone confirm?'''- - [[User:Morgan525|Tycho]] 23:12, 17 October 2012 (EDT)<br />
:: If I try to replicate PavelB's situation, I am able to build a Leviathan with no problems using the latest build. However I am also able to build a Leviathan using the 1.05p1.1 build. So I'm not able to replicate his original problem unfortunately. [[User:Spike|Spike]] 19:18, 19 October 2012 (EDT)<br />
<br />
===<s> Materials deducted from wrong base </s>===<br />
<br />
My second base has -20 Aqua Plastics. Might be XComUtil's fault rather than TFTD Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
I don't use any mods/editor except TFDExtender, bus still have -98 Zrbite, -4 Lobster Man Corpses, -5 I-B Accs, -3 MagNavs and -358 Aqua Plastics on my second base! (and nothing extraordinary at other bases).<br />
:: Interesting. In the game where I found - 20 Aqua Plastics at my second base, I was manufacturing Plastic Aqua Armour at the first base. So it could be that a change to the manufacturing routine in TFTDextender is deducting manufacturing resources from the wrong base. It might also explain PavelB's Leviathan problem. [[User:Spike|Spike]] 09:32, 3 October 2012 (EDT)<br />
<br />
As an update on this, it does render the affected base if not unusable, hard to use, because the negative value is interpreted as a very large unsigned integer (60000+) and this has the effect of eliminating all Stores capacity at the base. The consequence is you can't buy anything at the base, nor transfer to it. [[User:Spike|Spike]] 22:41, 14 October 2012 (EDT)<br />
<br />
Steps to reproduce: <br />
# Start a new game under TFTDExtender<br />
# Create a second base. <br />
# Start construction of General Stores at second base (probably this is irrelevant)<br />
# Enable Aqua Plastics technology and Plastic Aqua Armour technology (eg XComUtil TEC:ALL) <br />
# Produce 4 Aqua Plastics at first base, without using autoproduce/autosell<br />
# Check Base Information - Stores at both bases. <br />
## = as expected, 4 at base 1 and zero at base 2<br />
# Then produce 1 Plastic Aqua Armour at first base, without using autoproduce/autosell<br />
# As soon as production starts, check Buy/Sell and Base Info - Stores at both bases<br />
## = At first base, 4 Aqua Plastics are still present and have not been deducted. <br />
## = At second base, -4 Aqua Plastics shown in Buy/Sell, equivalent unsigned two byte number shown in Stores<br />
<br />
Weirdly, this seems to happen even if Auto sell = 0 in the TFTDExtender.ini file. But it seems like a fairly ordinary off-by-one index type of error I guess? I confirmed it does not recur in the base game, the CE executable from Steam. It does not occur when running the game under XComUtil. Only when running under TFTD Extender. Since it does not seem sensitive to Auto sell = 0/1, I would guess it is due one of the bug fixes? Maybe some of the manufacturing exploit fixes? [[User:Spike|Spike]] 22:00, 16 October 2012 (EDT)<br />
<br />
: I think I may have localised this bug to the "Manufacture Rate Limit Fix". If I disable that particular bug fix, I get normal behaviour, i.e. manufacturing materials are deducted from the base where the manufacturing happens, not the next base. Also I'm going to go out on a limb and guess this is the same cause as Cannot Build Leviathan, above. [[User:Spike|Spike]] 22:14, 16 October 2012 (EDT)<br />
<br />
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''<br />
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)<br />
<br />
== Minor Bugs ==<br />
<br />
===<s> OBDATA / Dye Grenade mod not working? </s>===<br />
<br />
I can't seem to get this to work. Regardless of what I do, the Dye Grenade radius is the same as in the unpatched game. It starts on one square, slowly spreads out to about a 4 by 4 diamond, then contracts and fades out. Am I doing something wrong? Is it using the right OBDATA.DAT file? [[User:Spike|Spike]] 09:41, 7 September 2012 (EDT)<br />
: I'm not sure this feature is working for me at all. I tried changing the stats of a Dart Gun like this, also with no apparent effect. <br />
<br />
[OBDATA.DAT]<br />
Apply=01<br />
;Dye grenade will have similar initial effect as smoke grenade in EU.<br />
Dye Grenade Damage=60<br />
;Mega Dart Gun<br />
Dart Pistol Auto TUs=50<br />
Dart Pistol Auto accuracy=20<br />
Dart Pistol Snap accuracy=50<br />
Dart Pistol Aimed accuracy=100<br />
;Mega Dart Pistol ammo<br />
Dart Pod Damage=250<br />
Dart Pod Size=100<br />
;Turn HJC-AP into mega-phosphorous shell<br />
AP-Shell Damage Type=1<br />
AP-Shell Damage=250<br />
;Turn HJC-P into mega-phosphorous shell<br />
Phosphorous-Shell Damage=250<br />
;mega-pack<br />
Magna-Pack Damage=250<br />
;mini-pack<br />
;Magna-Pack Damage=20<br />
<br />
[[User:Spike|Spike]] 16:39, 8 September 2012 (EDT)<br />
I've checked that OBDATA modding works ok in UFOExtender. I can't get it to work in TFDExtender though. I have tried modding one-word items like Magna-pack. I have tried using the [[Talk:OBDATA.DAT (TFTD)|exact literal names from OBDATA.DAT (TFTD)]]. I have tried using the literal names from UFO. All no good. The record structure looks to be the same in TFTD as in UFO. I am a bit stumped. [[User:Spike|Spike]] 22:32, 8 September 2012 (EDT)<br />
<br />
:''OK. I'll look into it. My work has restarted so I am a little busy right now. Once I get readjusted to the work schedule, I'll be able to investigate more.''[[User:Morgan525|Tycho]] 04:23, 9 September 2012 (EDT) <br />
I completely understand. Thank you so much for this amazing contribution. [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
: update - ''I think I located the problem, the LoadFile command had been referencing the wrong LoadFile subroutine.''<br />
Excellent. I will be happy test as soon as you have time to upload an update. [[User:Spike|Spike]] 09:45, 20 September 2012 (EDT)<br />
: ''check this with the latest patch. [[User:Morgan525|Tycho]]''<br />
<br />
With 1.05p1.1, the Dye Grenade fix is working regardless of whether I do Apply=1 in the OBDATA.DAT section. I can't get anything else to work still. [[User:Spike|Spike]] 10:05, 2 October 2012 (EDT)<br />
<br />
Hang on, looks like it only works with a New Game? I got some things working but it's still not working 100% for me, but I will continue to investigate, I could be using the wrong names or settings etc. See updates to config file above. [[User:Spike|Spike]] 11:17, 2 October 2012 (EDT)<br />
:''It could be that I'll need to add multiple hooks into the executable to ensure that the mod is loaded at all times. - [[User:Morgan525|Tycho]] 22:35, 2 October 2012 (EDT)''<br />
<br />
OK it does seem to work on loaded saved games as well as in new games. The OBDATA.DAT changes are reflected in the in-game UFOPedia. But, the names of the objects to modify must be the exact literal strings that I posted in [[Talk:OBDATA.DAT_(TFTD)#Exact literal item name strings]]. The strings on the main page of the OBDATA.DAT article have been "corrected" and don't always exactly match what's in OBDATA.DAT. And I'm still not convinced all attributes are being copied over correctly into TACTICAL, even when they appear correctly in the in-game UFOPedia. I can change the damage of ammo types and see updates in the in game UFOPedia, but no change in damage or area of effect on the battlefield. [[User:Spike|Spike]] 10:34, 3 October 2012 (EDT)<br />
:''maybe the best test would be to zero damage on items and shoot an unarmed aquanaut?''<br />
<br />
I went back and checked UFO Extender. In UFO Extender I am able to make a full set of changes to a Pistol using basically the same config settings as above. In TFTD Extender, I am only able to affect what is reported in the in game UFOPedia, and the actual clip size. I even went so far as to double check the structure of OBDATA.DAT in both games, by inspection, but it does appear to be the same, at least for Damage which is the thing I'm unable to change in TFTD. Could this possibly be that LoadFile issue again? [[User:Spike|Spike]] 18:24, 3 October 2012 (EDT)<br />
<br />
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)<br />
<br />
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
=== Weightless Ammo Bug ===<br />
<br />
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)<br />
<br />
''From what I understand right now, I am pretty sure I can arrange it so that weapons are not automatically loaded and soldiers would be given an extra clip. Feedback?''<br />
: By an extra clip, you mean the clip/ammo that would have been loaded into the weapon is instead carried by the soldier? And for carried clips, the encumbrance effects are correct. For me anyway, in order of most benefit, the options would be<br />
:# Fix the root cause of the bug (ensure all relevant object locations and "contains/contained in" pointers are set during automatic clip loading) so that automatically loaded clips correctly affect encumbrance <br />
:# As a workaround, don't load ammo for multi-ammotype weapons (Heavy Cannon/Gas Cannon, Auto-Cannon/Hydrojet Cannon, Rocket Launcher / Torpedo Launcher). These are the weapons for which the bug has the greatest impact, since it imposes a 'cost' of switching away from the automatically-loaded ammo (usually AP or Small Rocket/Torp). With single-ammotype weapons, there's never any need to change the clips before combat. <br />
:# As a workaround, don't load ammo for any weapons. This avoids the 'switching cost' issue but does impose a fairly significant logistics overhead on each combat, to go through and manually load all clips. Plus the risk that you forget to load a weapon and only find out at a critical moment. :) This is for the "purist" who wants to make the game harder.<br />
:If it's tricky to fix the root cause, any of the other two options would be helpful. Suggested text:<br />
:* [Multi Ammo Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. Weapons using multiple ammo types (Heavy Cannon, Auto-Cannon, Rocket Launcher / Gas Cannon, Hydrojet Cannon, Torpedo Launcher) will not be pre-loaded before combat. You will need to load these weapons manually during the pre-combat Equip phase. This will significantly affect the heavy weapons ammunition load your squad can carry into combat without suffering encumbrance penalties, thus making the early game harder.<br />
:* [All Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. This option overrides the previous option. No weapons will be pre-loaded before combat. You will need to load all ammo manually during the pre-combat Equip phase. This will significantly affect the ammunition load your squad can carry into combat without suffering encumbrance penalties, making the early game harder.<br />
:[[User:Spike|Spike]] 05:10, 21 September 2012 (EDT)<br />
::''I found the source of the problem: 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 changed in inventory management.-''[[User:Morgan525|Tycho]] 19:00, 19 October 2012 (EDT)<br />
::: That is just awesome! :D [[User:Spike|Spike]] 22:36, 19 October 2012 (EDT)<br />
<br />
=== <s>Grenade Resistance in INI file </s> ===<br />
<br />
I think this is a holdover from UFOExtender, because 'Grenade' is not a TFTD object, and in TFTD I think all forms of grenades already have high damage resistance, and so are already "stackable". [[User:Spike|Spike]] 09:14, 7 September 2012 (EDT)<br />
:''Your correct. I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]<br />
<br />
=== MIA Bugs ===<br />
<br />
==== Supernumary MIA on Abort ====<br />
<br />
I Abort a mission with 8 Aquanauts and get the confirmation message "8 Aquanauts inside craft, 2 outside". No one has been stunned or MCd. I did have two aquanauts, only, outside, but they have moved back inside the transport. Very odd. Saved Equipment was enabled. [[User:Spike|Spike]] 11:06, 5 October 2012 (EDT)<br />
<br />
:''How many Aquanauts did you have in total: 10?- -''[[User:Morgan525|Tycho]] 02:54, 11 October 2012 (EDT)<br />
:: I started the mission with only 8 Aquanauts and they all survived. Only two had even been outside the transport (quite an unusual situation). However I can't reproduce this bug, so please ignore it unless/until I can reproduce it. :) [[User:Spike|Spike]] 06:48, 17 October 2012 (EDT)<br />
<br />
==== <s>Stunned MC'd Aquanauts MIA on Abort </s> ====<br />
<br />
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. <br />
:''This is one of those exceptional cases where my End of Battle (Abort?) routine doesn't cover. If the aquanaut is MCed or unconscious the EOB routine will correct these states and end the battle but it doesn't check for both on the same unit, so an aquanaut who was MCed and then made unconscious, may fall through the hole that was originally in the game. [[User:Morgan525|Tycho]]'' <br />
<br />
::''I now have the code in place to uncontrol any creature that has been rendered unconscious. - -''[[User:Morgan525|Tycho]] 02:47, 11 October 2012 (EDT)<br />
<br />
This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
==== Stunned Carried Aquanauts MIA on Abort ====<br />
<br />
While you are looking the EOB script, I noticed one more anomaly. I'm not sure if this is an original bug or an Extender bug. If you are carrying a stunned Aquanaut in the transport at the time of Abort, the stunned Aquanaut is lost (MIA). You have to drop the stunned Aquanaut on the floor. Probably this is because the position of the Aquanaut has not been updated and is still pointing to where they were stunned, not to the location of the carrying Aquanaut. [[User:Spike|Spike]] 04:49, 27 September 2012 (EDT)<br />
<br />
:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. At least it is manageable: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)<br />
<br />
<br />
=== <s>Extra Artefacts Reported</s> ===<br />
<br />
I quite often recover 1 or 2 alien artefacts according to the Results screen, even though I am Aborting the mission and have definitely not brought anything back to the transport. I don't think I'm actually bringing back any artefacts - I think the Results screen is reporting incorrectly for some reason. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''I've seen this too. You are correct that no artifacts are actually found and it's a minor problem with the EOB calculations. Since it only gives players a minor boost (a few points at most) to their score, it's low on my to-do list at the moment.''<br />
:: Hmm I just came back from a mission (first mission of a new game) and I had two alien sonic clips available as new Research topics (Pistol and Blasta), even though I aborted the mission with no loot. I did use XComHack to edit other equipment on the Triton so it may be related to that. I'll let you know if it recurs. [[User:Spike|Spike]] 08:47, 2 October 2012 (EDT)<br />
:::''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)<br />
:::''This will be fixed in the next release.-''[[User:Morgan525|Tycho]] 03:00, 13 October 2012 (EDT)<br />
<br />
:::: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
===<s>Manufacturing Projects Minimum Production</s> ===<br />
<br />
In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''<br />
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)<br />
<br />
Tested - If I reduce the production quantity of a current production run to less than what as already been produced, the display completion time changes (incorrectly) to 'Indefinite', but production ends after completion of the next unit. So if I start by producing 10 units, wait until I have produced 2, then reduce the quantity to 2 (or probably 1), production stops after 3 units. Thies basically replicates the pre-existing behaviour when using the down arrow on the Quantity, so there has been no loss of functionality with your Mod. Also, Autosell and Autoproduce work normally when applied as changes to an existing production run. The only thing is I can't distinguish them on the Manufacturing display - both say 'unlimited' quantity and 'indefinite' period - is that intended? I suppose it makes sense, but it would be good to be able to tell which kind of production it is, *** Autoproduce or $$$ Autosell. [[User:Spike|Spike]] 08:57, 2 October 2012 (EDT)<br />
<br />
:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''<br />
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)<br />
:::''OK. Changed the output to display "$unlimited$".[[User:Morgan525|Tycho]]<br />
<br />
=== Weight Display in Inventory not Localised ===<br />
<br />
At least when I run the game in German, it comes up as "Weight" and not something like "Gewicht". Reactions comes up ok as "Zeitwerte". [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
<br />
:''There is no entry in the text DAT files for "weight". Seb had to add the text string for it into his subroutine. Thanks for pointing it out.'' [[User:Morgan525|Tycho]]<br />
<br />
===<s> Executable directive </s>===<br />
<br />
It looks to me that the Executable directive is being ignored and the loader always loads Terror from the Deep.exe. Is that correct? [[User:Spike|Spike]] 15:35, 24 September 2012 (EDT)<br />
<br />
:''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.-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)<br />
<br />
== Displacer/Sonic damage fix ==<br />
<br />
If I understand this fix correctly, the Displacer/Sonic weapon damage has been increased to 150 from the previous in-code value of 110, and vs the previous UFOPedia entry of 130? SWS Sonic weapon damage has been increased to 150 because this matches the craft-mounted Sonic Oscillator?<br />
<br />
I don't think this is the right idea. Increasing damage to 150 gives Displacer/Sonic a higher damage level than Displacer/PWT. That removes some of the distinctiveness of Displacer/PWT, and more importantly it is inconsistent with the general principle in the game that PWT weapons (of a given class) do more damage than Sonic (which in turn do more than Gauss). That is true for infantry weapons, SWS weapons (unless you create this exception), and Craft weapons. <br />
<br />
Also, there is no reason why SWS weapon damage should be equated to Craft weapon damage. I'm pretty sure that Battlescape damage values and Craft combat (Geoscape Interception) damage values are completely different, they are not meant to be compared to each other in any way. There is only one SWS weapon that has the same damage as its equivalent Craft weapon, and that is the Coelacanth/Gauss = Gauss Cannon. I think this is a coincidence, as the other equivalent weapons are all different between the SWS version and the Craft version (this applies to Gas Cannon, PWT, Sonic, and also Aqua Jet vs torpedos). <br />
<br />
Clearly there ''is'' an inconsistency between the code and the UFOPedia, and that should be fixed. It's hard to say if the "right" value is 110 or 130. Is the code wrong or is the UFOPedia wrong? It could be either way. But I would correct this inconsistency either to 110 or to 130, not increase it to 150. <br />
<br />
[[User:Spike|Spike]] 08:02, 7 September 2012 (EDT)<br />
<br />
: Or make it an option: Displacer Sonic Fix={0|110|130|150} [[User:Spike|Spike]] 09:50, 9 September 2012 (EDT)<br />
'' I changed the damage to be 125, similar to the ratio for the hovertank turrent to plasma cannon.-''[[User:Morgan525|Tycho]] 03:52, 13 October 2012 (EDT)<br />
<br />
== Things that TFTDextender does not fix ==<br />
<br />
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?):<br />
<br />
* 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.<br />
* Does not fix the incorrect pictures for the large USO in the interception window. <br />
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]<br />
* 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.)<br />
* 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).<br />
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.<br />
* 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.<br />
<br />
== Save Equipment not working? ==<br />
<br />
With "Save Equipment" option enabled, the soldiers' loadout at first was always like this: grenade in leg slot, clip in backpack - and it didn't change on the next mission, despite the fact that I re-equipped the soldiers correctly (grenades and clips on the belt). When I manufactured Gauss Rifles and issued them to my soldiers, it got even worse - none of the soldiers got clips, and two of the rifles were unloaded. Next I upgraded to Sonic-Blasta Rifles and now nothing, except some grenades (still in leg slots), is issued to the soldiers at all. "Save Equipment" was known to work in UFOExtender, did something get broken? --[[User:Player701|Player701]] 09:18, 21 October 2012 (EDT)<br />
<br />
== Flying Sub Lost ==<br />
<br />
Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)<br />
<br />
= Feature Requests and Suggestions =<br />
<br />
== Useful alien species research ==<br />
<br />
Tycho, I really like this idea you proposed in the StrategyCore forum:<br />
<br />
: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.<br />
<br />
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. <br />
<br />
:''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.'' [[User:Morgan525|Tycho]]<br />
::''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%, 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-100% for that lucky shot. With autopsy done, the game reverts back to the usual 0-200% on any hit.''<br />
<br />
::: 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". [[User:Spike|Spike]] 10:35, 15 September 2012 (EDT)<br />
<br />
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?<br />
<br />
:''I thought about that but the game doesn't record live aliens that have been researched. When you finish research on a live alien, it only follows the routine to unlock the appropriate UFOpaedia articles and then checks to see if the finished research can unlock other topics.'' [[User:Morgan525|Tycho]]<br />
<br />
I had a further thought on this while trying to guess what your new pre-requisites are for the various armours. For now it's really cool to be guessing but once people have figured it out, well, it will be more logical but still will have 'replay fatigue'. Would it be possible to randomise the pre-requisites for a lot of the key research topics, from out of a plausible list of items (or even randomise pre-requisite topics)? That would make every game fresh in terms of the research sequence, and make the research aspect of the game more challenging and less dry & predictable. As ever, just a suggestion. :) Cheers, [[User:Spike|Spike]] 16:01, 19 October 2012 (EDT)<br />
<br />
== All Units Can "Fly" In Water ==<br />
<br />
It's very illogical that most units are stuck on the seabed in underwater missions. Please provide the option to set all units (X-Com and alien) to have "flying" (i.e. swimming) ability when underwater. This is unlikely to cause an outbreak of 3D combat, since there is no cover except at seabed level, so anyone swimming excessively or incautiously is going to get shot. It might disadvantage the aliens if their tactical map waypoints are all set on the surface. But as some of them can "fly", there is hopefully a mechanism to deal with that in the code already. For me it will just solve the frustration of being unable to swim over small obstacles or swim up a level, and being stuck or tactically limited for no sensible reason. Mag-Ion Armour remains useful as an important step in Sub Research and (if using the Everything Works on Land mod) for land use. [[User:Spike|Spike]] 11:36, 9 September 2012 (EDT)<br />
: This requires setting [[UNITREF.DAT]] byte 0x78 bit 2 for the unit (e.g. for all units on both sides). Or the in-memory equivalent of UNITREF.DAT. [[User:Spike|Spike]] 10:19, 5 October 2012 (EDT)<br />
<br />
== Aliens Pick Up Weapons ==<br />
<br />
Related to Improved Alien AI. This makes the game tougher as stunned / panicked bipedal-type aliens are no longer permanently disarmed. This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. A fix for this would be a very helpful rebalancing of both games that eliminates one of the aliens' weak spots. The existing (but unused) routine looks pretty smart and not immediately exploitable to ambush aliens using weapons as traps. <br />
<br />
: I noticed the UFO Extender source code has a 'get' keyword under the OBDATA.DAT directive that populates this field 0x2D. Is that working? [[User:Spike|Spike]] 21:03, 16 October 2012 (EDT)<br />
<br />
== General Tank Modding ==<br />
<br />
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?<br />
<br />
Thanks,<br />
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)<br />
<br />
== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==<br />
<br />
Hook the right and left weapon menus on mind controlled aliens to add in actions for their built in melee attacks (if they have them) and built in Psi/MC attacks (if they have Psi/MC Skill). Ideally add these actions to the menu, and pop up a menu, even if the alien isn't holding any weapons.<br />
<br />
This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.<br />
<br />
== Fix Interception and Navigation Course Algorithms ==<br />
<br />
Or just find the algorithms and I volunteer to fix them!<br />
<br />
=== Use Great Circle Routes ===<br />
<br />
Travel toward the target on the shortest Great Circle, rather than always travelling along lines of latitude first (like they are some kind of main bus route!). <br />
<br />
=== Use Predictive Interception ===<br />
<br />
For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.<br />
<br />
=== Show Degree Headings ===<br />
<br />
The game only ever reports alien headings as North, South, East, West, but clearly alien craft move in other directions than just these four, and clearly XCOM detection equipment is capable of resolving these finer-grained headings, since the crafts' tracks are shown correctly in the Geoscope. <br />
As a first step towards predictive interceptions, it would be great to display the alien craft's heading in degrees, eg 135 degrees for South-East. Maybe rounded to the nearest 5 or 10 degrees.<br />
<br />
== Interception Craft vs Touched Down Alien Craft == <br />
<br />
If an alien craft is touched down and an XCOM interception craft (not touched down) is at the same X/Y position, if the alien craft begins to move, immediately open the Interception window at minimum range (8km/nm), presumably with the alien attempting to get away / break off. Currently the Interception window only happens if the XCom craft is faster, which is dumb, ''even if'' the alien craft could accelerate instantly to its maximum speed. <br />
<br />
For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach. <br />
<br />
== Fun, not Funky, Fire ==<br />
<br />
An alternative option for incendiaries/phosphorous damage processing: Do process the so called 'impact' damage of an incendiary on every shot, not just at the end of the turn. But only apply it to those in the area of affect of this specific shell burst, not to all units who are standing in smoke or fire anywhere on the map. This will please fans of incendiaries/phosphorous. It's probably a balancing, rather than unbalancing, change in the relative strengths of the ammo types. Makes incendiaries/phosphorous useful for more than just illumination or desperation. Gives some use to the research topics that advise use of incendiaries/phosphorous, and the damage modifiers aliens have been assigned.<br />
<br />
== Rearming Rates ==<br />
<br />
<br />
From [[Known_Bugs_(TFTD)#Geoscape_Bugs]]:<br />
<br />
=== Craft Gauss Cannon Rearming Rate ===<br />
<br />
This weapon rearms at 10/hr but probably should be 50/hr or at least 25/hr, otherwise it is far slower to rearm than any other cannon weapon in either game. In fact it's the second slowest weapon system to rearm, slower only than AJAX...<br />
<br />
=== AJAX Rearming Rate ===<br />
<br />
An AJAX system takes twice as long to fully reload as a D.U.P. system, as a result AJAX-armed Craft have much worse operational tempo and readiness than D.U.P. armed Craft. Like we needed yet another reason to always use D.U.Ps. This is probably a design error rather than a bug, but it would be good to fix it - anything to give a more balanced set of craft weapon choices. The rearming rate should be raised from 1/hr to 2/hr. The AJAX system will then have the same operational tempo as the D.U.P. system. <br />
<br />
Could also be applied to Stingray missiles in EU 1994, as the same analysis applies to Stingray vs Avalanche.</div>Player701https://temp.ufopaedia.org/index.php?title=Talk:TFTDextender&diff=39963Talk:TFTDextender2012-10-21T13:18:53Z<p>Player701: </p>
<hr />
<div>=Questions or Comments=<br />
'''A place to provide feedback or ask questions:'''<br />
<br />
The zip archive does not seem to include an .ini file. Where do I get the .ini file from? [[User:Spike|Spike]] 12:37, 6 September 2012 (EDT)<br />
:: Oh hang on. It looks like the latest version of the zip file does not include the .ini file. When I go back to the previous version of the zip file, I can see the .ini file. [[User:Spike|Spike]] 17:45, 6 September 2012 (EDT)<br />
<br />
:::''The latest release is a patch, which means there are no new additions to the INI. I don't include it in patches usually so that those who already have the prior release don't have to reconfigure their current INI. It may not seem like a big deal now but earlier, I was releasing fixes almost on a weekly basis and so I still continue with that idea.''[[User:Morgan525|Tycho]]<br />
:::: Ah I guessed that might be the reason. Makes a lot of sense. It really sucks to have a customised INI file overwritten. [[User:Spike|Spike]] 07:25, 7 September 2012 (EDT)<br />
<br />
== Bug Reports ==<br />
<br />
=== Crash 0xFFE00B30 ===<br />
<br />
:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."<br />
<br />
''Interesting. I had someone report a similar thing when they were starting their first instance of the battlescape on a new install of the game. I looked into it and the game generated some bad data. When he let the UFO take off and land again, the battle started with no problems..''<br />
<br />
:It's [[Known_Bugs_(TFTD)#Geoscape_Bugs|a bug I've reported before]] (before TFTD Extender even existed), so it's not specific to TFTDExtender / UFOExtender. What is happening is the Alien Sub is landing on land, and the Triton is also attempting to land on land. Probably the game crashes when it fails to generate the appropriate terrain type? So the GEOSCAPE map/terrain data must be corrupted. I've seen three examples of this. In a couple of cases the landing site is clearly inland, by hundreds of kilometres. In some cases it's right on the sea/land boundary and hard to tell. I have two save games that reproduce the bug now. From memory, the previous cases all happened around North Africa, like these present cases. [[User:Spike|Spike]] 08:31, 9 September 2012 (EDT)<br />
<br />
=== Cannot build Leviathan ===<br />
<br />
Hi Tycho. I've just researched Leviathan in my TFDExtender game but cannot manufacture it! I have enough resources (Plastics, IBA, ManNav), 3 workshops, more than 100 technicans and one empty sub pen. But when starting the Leviathan manufacture task I cannot assign any technicans to it. I press the "up" button, and there are no reaction to this. I can build Manta, but not Leviathan. Don't you know what is it? [[User:PavelB|PavelB]] 06:55, 2 October 2012 (EDT)<br />
<br />
: Double check that you have sufficient cash to start the project, iirc $600K or so. That matches this symptom. Also that you have enough workshop space available (Leviathan needs a lot of space). Failing that, cancel all existing manufacturing projects, then retry. Failing that you could try reducing Technicians below 100 but that's taking us into Bug territory. [[User:Spike|Spike]] 07:17, 2 October 2012 (EDT)<br />
<br />
:: Resources are 100% enough. I've launched "Terror from the Deep.exe", loaded this saved game and started manufacturing Lev without any problems. I've saved this variant with Lev being manufactured and then loaded it from "TFTDextender.exe". As a result the process was okey, but I could only decrease the number of technicans working on it, not increase (even after decreasing!). That is: with 64 technicans had been assigned, I've pressed the "down" button, and the number changed to 63. But then I was unable to revert it to 64 by pressing "up" button: it didn't work! [[User:PavelB|PavelB]] 07:57, 2 October 2012 (EDT)<br />
:''I'll check into it. Although, I can't understand how changes to the research tree would affect production. Unless it has something to do with the autoproduce feature?''<br />
:'''This problem may be fixed with the same patch that fixed the production materials being deducted from the wrong base. Can anyone confirm?'''- - [[User:Morgan525|Tycho]] 23:12, 17 October 2012 (EDT)<br />
:: If I try to replicate PavelB's situation, I am able to build a Leviathan with no problems using the latest build. However I am also able to build a Leviathan using the 1.05p1.1 build. So I'm not able to replicate his original problem unfortunately. [[User:Spike|Spike]] 19:18, 19 October 2012 (EDT)<br />
<br />
===<s> Materials deducted from wrong base </s>===<br />
<br />
My second base has -20 Aqua Plastics. Might be XComUtil's fault rather than TFTD Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
I don't use any mods/editor except TFDExtender, bus still have -98 Zrbite, -4 Lobster Man Corpses, -5 I-B Accs, -3 MagNavs and -358 Aqua Plastics on my second base! (and nothing extraordinary at other bases).<br />
:: Interesting. In the game where I found - 20 Aqua Plastics at my second base, I was manufacturing Plastic Aqua Armour at the first base. So it could be that a change to the manufacturing routine in TFTDextender is deducting manufacturing resources from the wrong base. It might also explain PavelB's Leviathan problem. [[User:Spike|Spike]] 09:32, 3 October 2012 (EDT)<br />
<br />
As an update on this, it does render the affected base if not unusable, hard to use, because the negative value is interpreted as a very large unsigned integer (60000+) and this has the effect of eliminating all Stores capacity at the base. The consequence is you can't buy anything at the base, nor transfer to it. [[User:Spike|Spike]] 22:41, 14 October 2012 (EDT)<br />
<br />
Steps to reproduce: <br />
# Start a new game under TFTDExtender<br />
# Create a second base. <br />
# Start construction of General Stores at second base (probably this is irrelevant)<br />
# Enable Aqua Plastics technology and Plastic Aqua Armour technology (eg XComUtil TEC:ALL) <br />
# Produce 4 Aqua Plastics at first base, without using autoproduce/autosell<br />
# Check Base Information - Stores at both bases. <br />
## = as expected, 4 at base 1 and zero at base 2<br />
# Then produce 1 Plastic Aqua Armour at first base, without using autoproduce/autosell<br />
# As soon as production starts, check Buy/Sell and Base Info - Stores at both bases<br />
## = At first base, 4 Aqua Plastics are still present and have not been deducted. <br />
## = At second base, -4 Aqua Plastics shown in Buy/Sell, equivalent unsigned two byte number shown in Stores<br />
<br />
Weirdly, this seems to happen even if Auto sell = 0 in the TFTDExtender.ini file. But it seems like a fairly ordinary off-by-one index type of error I guess? I confirmed it does not recur in the base game, the CE executable from Steam. It does not occur when running the game under XComUtil. Only when running under TFTD Extender. Since it does not seem sensitive to Auto sell = 0/1, I would guess it is due one of the bug fixes? Maybe some of the manufacturing exploit fixes? [[User:Spike|Spike]] 22:00, 16 October 2012 (EDT)<br />
<br />
: I think I may have localised this bug to the "Manufacture Rate Limit Fix". If I disable that particular bug fix, I get normal behaviour, i.e. manufacturing materials are deducted from the base where the manufacturing happens, not the next base. Also I'm going to go out on a limb and guess this is the same cause as Cannot Build Leviathan, above. [[User:Spike|Spike]] 22:14, 16 October 2012 (EDT)<br />
<br />
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''<br />
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)<br />
<br />
== Minor Bugs ==<br />
<br />
===<s> OBDATA / Dye Grenade mod not working? </s>===<br />
<br />
I can't seem to get this to work. Regardless of what I do, the Dye Grenade radius is the same as in the unpatched game. It starts on one square, slowly spreads out to about a 4 by 4 diamond, then contracts and fades out. Am I doing something wrong? Is it using the right OBDATA.DAT file? [[User:Spike|Spike]] 09:41, 7 September 2012 (EDT)<br />
: I'm not sure this feature is working for me at all. I tried changing the stats of a Dart Gun like this, also with no apparent effect. <br />
<br />
[OBDATA.DAT]<br />
Apply=01<br />
;Dye grenade will have similar initial effect as smoke grenade in EU.<br />
Dye Grenade Damage=60<br />
;Mega Dart Gun<br />
Dart Pistol Auto TUs=50<br />
Dart Pistol Auto accuracy=20<br />
Dart Pistol Snap accuracy=50<br />
Dart Pistol Aimed accuracy=100<br />
;Mega Dart Pistol ammo<br />
Dart Pod Damage=250<br />
Dart Pod Size=100<br />
;Turn HJC-AP into mega-phosphorous shell<br />
AP-Shell Damage Type=1<br />
AP-Shell Damage=250<br />
;Turn HJC-P into mega-phosphorous shell<br />
Phosphorous-Shell Damage=250<br />
;mega-pack<br />
Magna-Pack Damage=250<br />
;mini-pack<br />
;Magna-Pack Damage=20<br />
<br />
[[User:Spike|Spike]] 16:39, 8 September 2012 (EDT)<br />
I've checked that OBDATA modding works ok in UFOExtender. I can't get it to work in TFDExtender though. I have tried modding one-word items like Magna-pack. I have tried using the [[Talk:OBDATA.DAT (TFTD)|exact literal names from OBDATA.DAT (TFTD)]]. I have tried using the literal names from UFO. All no good. The record structure looks to be the same in TFTD as in UFO. I am a bit stumped. [[User:Spike|Spike]] 22:32, 8 September 2012 (EDT)<br />
<br />
:''OK. I'll look into it. My work has restarted so I am a little busy right now. Once I get readjusted to the work schedule, I'll be able to investigate more.''[[User:Morgan525|Tycho]] 04:23, 9 September 2012 (EDT) <br />
I completely understand. Thank you so much for this amazing contribution. [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
: update - ''I think I located the problem, the LoadFile command had been referencing the wrong LoadFile subroutine.''<br />
Excellent. I will be happy test as soon as you have time to upload an update. [[User:Spike|Spike]] 09:45, 20 September 2012 (EDT)<br />
: ''check this with the latest patch. [[User:Morgan525|Tycho]]''<br />
<br />
With 1.05p1.1, the Dye Grenade fix is working regardless of whether I do Apply=1 in the OBDATA.DAT section. I can't get anything else to work still. [[User:Spike|Spike]] 10:05, 2 October 2012 (EDT)<br />
<br />
Hang on, looks like it only works with a New Game? I got some things working but it's still not working 100% for me, but I will continue to investigate, I could be using the wrong names or settings etc. See updates to config file above. [[User:Spike|Spike]] 11:17, 2 October 2012 (EDT)<br />
:''It could be that I'll need to add multiple hooks into the executable to ensure that the mod is loaded at all times. - [[User:Morgan525|Tycho]] 22:35, 2 October 2012 (EDT)''<br />
<br />
OK it does seem to work on loaded saved games as well as in new games. The OBDATA.DAT changes are reflected in the in-game UFOPedia. But, the names of the objects to modify must be the exact literal strings that I posted in [[Talk:OBDATA.DAT_(TFTD)#Exact literal item name strings]]. The strings on the main page of the OBDATA.DAT article have been "corrected" and don't always exactly match what's in OBDATA.DAT. And I'm still not convinced all attributes are being copied over correctly into TACTICAL, even when they appear correctly in the in-game UFOPedia. I can change the damage of ammo types and see updates in the in game UFOPedia, but no change in damage or area of effect on the battlefield. [[User:Spike|Spike]] 10:34, 3 October 2012 (EDT)<br />
:''maybe the best test would be to zero damage on items and shoot an unarmed aquanaut?''<br />
<br />
I went back and checked UFO Extender. In UFO Extender I am able to make a full set of changes to a Pistol using basically the same config settings as above. In TFTD Extender, I am only able to affect what is reported in the in game UFOPedia, and the actual clip size. I even went so far as to double check the structure of OBDATA.DAT in both games, by inspection, but it does appear to be the same, at least for Damage which is the thing I'm unable to change in TFTD. Could this possibly be that LoadFile issue again? [[User:Spike|Spike]] 18:24, 3 October 2012 (EDT)<br />
<br />
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)<br />
<br />
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
=== Weightless Ammo Bug ===<br />
<br />
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)<br />
<br />
''From what I understand right now, I am pretty sure I can arrange it so that weapons are not automatically loaded and soldiers would be given an extra clip. Feedback?''<br />
: By an extra clip, you mean the clip/ammo that would have been loaded into the weapon is instead carried by the soldier? And for carried clips, the encumbrance effects are correct. For me anyway, in order of most benefit, the options would be<br />
:# Fix the root cause of the bug (ensure all relevant object locations and "contains/contained in" pointers are set during automatic clip loading) so that automatically loaded clips correctly affect encumbrance <br />
:# As a workaround, don't load ammo for multi-ammotype weapons (Heavy Cannon/Gas Cannon, Auto-Cannon/Hydrojet Cannon, Rocket Launcher / Torpedo Launcher). These are the weapons for which the bug has the greatest impact, since it imposes a 'cost' of switching away from the automatically-loaded ammo (usually AP or Small Rocket/Torp). With single-ammotype weapons, there's never any need to change the clips before combat. <br />
:# As a workaround, don't load ammo for any weapons. This avoids the 'switching cost' issue but does impose a fairly significant logistics overhead on each combat, to go through and manually load all clips. Plus the risk that you forget to load a weapon and only find out at a critical moment. :) This is for the "purist" who wants to make the game harder.<br />
:If it's tricky to fix the root cause, any of the other two options would be helpful. Suggested text:<br />
:* [Multi Ammo Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. Weapons using multiple ammo types (Heavy Cannon, Auto-Cannon, Rocket Launcher / Gas Cannon, Hydrojet Cannon, Torpedo Launcher) will not be pre-loaded before combat. You will need to load these weapons manually during the pre-combat Equip phase. This will significantly affect the heavy weapons ammunition load your squad can carry into combat without suffering encumbrance penalties, thus making the early game harder.<br />
:* [All Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. This option overrides the previous option. No weapons will be pre-loaded before combat. You will need to load all ammo manually during the pre-combat Equip phase. This will significantly affect the ammunition load your squad can carry into combat without suffering encumbrance penalties, making the early game harder.<br />
:[[User:Spike|Spike]] 05:10, 21 September 2012 (EDT)<br />
::''I found the source of the problem: 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 changed in inventory management.-''[[User:Morgan525|Tycho]] 19:00, 19 October 2012 (EDT)<br />
::: That is just awesome! :D [[User:Spike|Spike]] 22:36, 19 October 2012 (EDT)<br />
<br />
=== <s>Grenade Resistance in INI file </s> ===<br />
<br />
I think this is a holdover from UFOExtender, because 'Grenade' is not a TFTD object, and in TFTD I think all forms of grenades already have high damage resistance, and so are already "stackable". [[User:Spike|Spike]] 09:14, 7 September 2012 (EDT)<br />
:''Your correct. I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]<br />
<br />
=== MIA Bugs ===<br />
<br />
==== Supernumary MIA on Abort ====<br />
<br />
I Abort a mission with 8 Aquanauts and get the confirmation message "8 Aquanauts inside craft, 2 outside". No one has been stunned or MCd. I did have two aquanauts, only, outside, but they have moved back inside the transport. Very odd. Saved Equipment was enabled. [[User:Spike|Spike]] 11:06, 5 October 2012 (EDT)<br />
<br />
:''How many Aquanauts did you have in total: 10?- -''[[User:Morgan525|Tycho]] 02:54, 11 October 2012 (EDT)<br />
:: I started the mission with only 8 Aquanauts and they all survived. Only two had even been outside the transport (quite an unusual situation). However I can't reproduce this bug, so please ignore it unless/until I can reproduce it. :) [[User:Spike|Spike]] 06:48, 17 October 2012 (EDT)<br />
<br />
==== <s>Stunned MC'd Aquanauts MIA on Abort </s> ====<br />
<br />
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. <br />
:''This is one of those exceptional cases where my End of Battle (Abort?) routine doesn't cover. If the aquanaut is MCed or unconscious the EOB routine will correct these states and end the battle but it doesn't check for both on the same unit, so an aquanaut who was MCed and then made unconscious, may fall through the hole that was originally in the game. [[User:Morgan525|Tycho]]'' <br />
<br />
::''I now have the code in place to uncontrol any creature that has been rendered unconscious. - -''[[User:Morgan525|Tycho]] 02:47, 11 October 2012 (EDT)<br />
<br />
This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
==== Stunned Carried Aquanauts MIA on Abort ====<br />
<br />
While you are looking the EOB script, I noticed one more anomaly. I'm not sure if this is an original bug or an Extender bug. If you are carrying a stunned Aquanaut in the transport at the time of Abort, the stunned Aquanaut is lost (MIA). You have to drop the stunned Aquanaut on the floor. Probably this is because the position of the Aquanaut has not been updated and is still pointing to where they were stunned, not to the location of the carrying Aquanaut. [[User:Spike|Spike]] 04:49, 27 September 2012 (EDT)<br />
<br />
:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. At least it is manageable: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)<br />
<br />
<br />
=== <s>Extra Artefacts Reported</s> ===<br />
<br />
I quite often recover 1 or 2 alien artefacts according to the Results screen, even though I am Aborting the mission and have definitely not brought anything back to the transport. I don't think I'm actually bringing back any artefacts - I think the Results screen is reporting incorrectly for some reason. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''I've seen this too. You are correct that no artifacts are actually found and it's a minor problem with the EOB calculations. Since it only gives players a minor boost (a few points at most) to their score, it's low on my to-do list at the moment.''<br />
:: Hmm I just came back from a mission (first mission of a new game) and I had two alien sonic clips available as new Research topics (Pistol and Blasta), even though I aborted the mission with no loot. I did use XComHack to edit other equipment on the Triton so it may be related to that. I'll let you know if it recurs. [[User:Spike|Spike]] 08:47, 2 October 2012 (EDT)<br />
:::''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)<br />
:::''This will be fixed in the next release.-''[[User:Morgan525|Tycho]] 03:00, 13 October 2012 (EDT)<br />
<br />
:::: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
===<s>Manufacturing Projects Minimum Production</s> ===<br />
<br />
In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''<br />
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)<br />
<br />
Tested - If I reduce the production quantity of a current production run to less than what as already been produced, the display completion time changes (incorrectly) to 'Indefinite', but production ends after completion of the next unit. So if I start by producing 10 units, wait until I have produced 2, then reduce the quantity to 2 (or probably 1), production stops after 3 units. Thies basically replicates the pre-existing behaviour when using the down arrow on the Quantity, so there has been no loss of functionality with your Mod. Also, Autosell and Autoproduce work normally when applied as changes to an existing production run. The only thing is I can't distinguish them on the Manufacturing display - both say 'unlimited' quantity and 'indefinite' period - is that intended? I suppose it makes sense, but it would be good to be able to tell which kind of production it is, *** Autoproduce or $$$ Autosell. [[User:Spike|Spike]] 08:57, 2 October 2012 (EDT)<br />
<br />
:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''<br />
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)<br />
:::''OK. Changed the output to display "$unlimited$".[[User:Morgan525|Tycho]]<br />
<br />
=== Weight Display in Inventory not Localised ===<br />
<br />
At least when I run the game in German, it comes up as "Weight" and not something like "Gewicht". Reactions comes up ok as "Zeitwerte". [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
<br />
:''There is no entry in the text DAT files for "weight". Seb had to add the text string for it into his subroutine. Thanks for pointing it out.'' [[User:Morgan525|Tycho]]<br />
<br />
===<s> Executable directive </s>===<br />
<br />
It looks to me that the Executable directive is being ignored and the loader always loads Terror from the Deep.exe. Is that correct? [[User:Spike|Spike]] 15:35, 24 September 2012 (EDT)<br />
<br />
:''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.-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)<br />
<br />
== Displacer/Sonic damage fix ==<br />
<br />
If I understand this fix correctly, the Displacer/Sonic weapon damage has been increased to 150 from the previous in-code value of 110, and vs the previous UFOPedia entry of 130? SWS Sonic weapon damage has been increased to 150 because this matches the craft-mounted Sonic Oscillator?<br />
<br />
I don't think this is the right idea. Increasing damage to 150 gives Displacer/Sonic a higher damage level than Displacer/PWT. That removes some of the distinctiveness of Displacer/PWT, and more importantly it is inconsistent with the general principle in the game that PWT weapons (of a given class) do more damage than Sonic (which in turn do more than Gauss). That is true for infantry weapons, SWS weapons (unless you create this exception), and Craft weapons. <br />
<br />
Also, there is no reason why SWS weapon damage should be equated to Craft weapon damage. I'm pretty sure that Battlescape damage values and Craft combat (Geoscape Interception) damage values are completely different, they are not meant to be compared to each other in any way. There is only one SWS weapon that has the same damage as its equivalent Craft weapon, and that is the Coelacanth/Gauss = Gauss Cannon. I think this is a coincidence, as the other equivalent weapons are all different between the SWS version and the Craft version (this applies to Gas Cannon, PWT, Sonic, and also Aqua Jet vs torpedos). <br />
<br />
Clearly there ''is'' an inconsistency between the code and the UFOPedia, and that should be fixed. It's hard to say if the "right" value is 110 or 130. Is the code wrong or is the UFOPedia wrong? It could be either way. But I would correct this inconsistency either to 110 or to 130, not increase it to 150. <br />
<br />
[[User:Spike|Spike]] 08:02, 7 September 2012 (EDT)<br />
<br />
: Or make it an option: Displacer Sonic Fix={0|110|130|150} [[User:Spike|Spike]] 09:50, 9 September 2012 (EDT)<br />
'' I changed the damage to be 125, similar to the ratio for the hovertank turrent to plasma cannon.-''[[User:Morgan525|Tycho]] 03:52, 13 October 2012 (EDT)<br />
<br />
== Things that TFTDextender does not fix ==<br />
<br />
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?):<br />
<br />
* 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.<br />
* Does not fix the incorrect pictures for the large USO in the interception window. <br />
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]<br />
* 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.)<br />
* 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).<br />
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.<br />
* 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.<br />
<br />
== Save Equipment not working? ==<br />
<br />
With "Save Equipment" option enabled, the soldiers' loadout at first was always like this: grenade in leg slot, clip in backpack - and it didn't change on the next mission, despite the fact that I re-equipped the soldiers correctly (grenades and clips on the belt). When I manufactured Gauss Rifles and issued them to my soldiers, it got even worse - none of the soldiers got clips, and two of the rifles were unloaded. Next I upgraded to Sonic-Blasta Rifles and now nothing, except some grenades (still in leg slots), is issued to the soldiers at all. "Save Equipment" was known to work in UFOExtender, did something get broken? --[[User:Player701|Player701]] 09:18, 21 October 2012 (EDT)<br />
<br />
= Feature Requests and Suggestions =<br />
<br />
== Useful alien species research ==<br />
<br />
Tycho, I really like this idea you proposed in the StrategyCore forum:<br />
<br />
: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.<br />
<br />
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. <br />
<br />
:''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.'' [[User:Morgan525|Tycho]]<br />
::''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%, 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-100% for that lucky shot. With autopsy done, the game reverts back to the usual 0-200% on any hit.''<br />
<br />
::: 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". [[User:Spike|Spike]] 10:35, 15 September 2012 (EDT)<br />
<br />
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?<br />
<br />
:''I thought about that but the game doesn't record live aliens that have been researched. When you finish research on a live alien, it only follows the routine to unlock the appropriate UFOpaedia articles and then checks to see if the finished research can unlock other topics.'' [[User:Morgan525|Tycho]]<br />
<br />
I had a further thought on this while trying to guess what your new pre-requisites are for the various armours. For now it's really cool to be guessing but once people have figured it out, well, it will be more logical but still will have 'replay fatigue'. Would it be possible to randomise the pre-requisites for a lot of the key research topics, from out of a plausible list of items (or even randomise pre-requisite topics)? That would make every game fresh in terms of the research sequence, and make the research aspect of the game more challenging and less dry & predictable. As ever, just a suggestion. :) Cheers, [[User:Spike|Spike]] 16:01, 19 October 2012 (EDT)<br />
<br />
== All Units Can "Fly" In Water ==<br />
<br />
It's very illogical that most units are stuck on the seabed in underwater missions. Please provide the option to set all units (X-Com and alien) to have "flying" (i.e. swimming) ability when underwater. This is unlikely to cause an outbreak of 3D combat, since there is no cover except at seabed level, so anyone swimming excessively or incautiously is going to get shot. It might disadvantage the aliens if their tactical map waypoints are all set on the surface. But as some of them can "fly", there is hopefully a mechanism to deal with that in the code already. For me it will just solve the frustration of being unable to swim over small obstacles or swim up a level, and being stuck or tactically limited for no sensible reason. Mag-Ion Armour remains useful as an important step in Sub Research and (if using the Everything Works on Land mod) for land use. [[User:Spike|Spike]] 11:36, 9 September 2012 (EDT)<br />
: This requires setting [[UNITREF.DAT]] byte 0x78 bit 2 for the unit (e.g. for all units on both sides). Or the in-memory equivalent of UNITREF.DAT. [[User:Spike|Spike]] 10:19, 5 October 2012 (EDT)<br />
<br />
== Aliens Pick Up Weapons ==<br />
<br />
Related to Improved Alien AI. This makes the game tougher as stunned / panicked bipedal-type aliens are no longer permanently disarmed. This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. A fix for this would be a very helpful rebalancing of both games that eliminates one of the aliens' weak spots. The existing (but unused) routine looks pretty smart and not immediately exploitable to ambush aliens using weapons as traps. <br />
<br />
: I noticed the UFO Extender source code has a 'get' keyword under the OBDATA.DAT directive that populates this field 0x2D. Is that working? [[User:Spike|Spike]] 21:03, 16 October 2012 (EDT)<br />
<br />
== General Tank Modding ==<br />
<br />
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?<br />
<br />
Thanks,<br />
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)<br />
<br />
== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==<br />
<br />
Hook the right and left weapon menus on mind controlled aliens to add in actions for their built in melee attacks (if they have them) and built in Psi/MC attacks (if they have Psi/MC Skill). Ideally add these actions to the menu, and pop up a menu, even if the alien isn't holding any weapons.<br />
<br />
This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.<br />
<br />
== Fix Interception and Navigation Course Algorithms ==<br />
<br />
Or just find the algorithms and I volunteer to fix them!<br />
<br />
=== Use Great Circle Routes ===<br />
<br />
Travel toward the target on the shortest Great Circle, rather than always travelling along lines of latitude first (like they are some kind of main bus route!). <br />
<br />
=== Use Predictive Interception ===<br />
<br />
For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.<br />
<br />
=== Show Degree Headings ===<br />
<br />
The game only ever reports alien headings as North, South, East, West, but clearly alien craft move in other directions than just these four, and clearly XCOM detection equipment is capable of resolving these finer-grained headings, since the crafts' tracks are shown correctly in the Geoscope. <br />
As a first step towards predictive interceptions, it would be great to display the alien craft's heading in degrees, eg 135 degrees for South-East. Maybe rounded to the nearest 5 or 10 degrees.<br />
<br />
== Interception Craft vs Touched Down Alien Craft == <br />
<br />
If an alien craft is touched down and an XCOM interception craft (not touched down) is at the same X/Y position, if the alien craft begins to move, immediately open the Interception window at minimum range (8km/nm), presumably with the alien attempting to get away / break off. Currently the Interception window only happens if the XCom craft is faster, which is dumb, ''even if'' the alien craft could accelerate instantly to its maximum speed. <br />
<br />
For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach. <br />
<br />
== Fun, not Funky, Fire ==<br />
<br />
An alternative option for incendiaries/phosphorous damage processing: Do process the so called 'impact' damage of an incendiary on every shot, not just at the end of the turn. But only apply it to those in the area of affect of this specific shell burst, not to all units who are standing in smoke or fire anywhere on the map. This will please fans of incendiaries/phosphorous. It's probably a balancing, rather than unbalancing, change in the relative strengths of the ammo types. Makes incendiaries/phosphorous useful for more than just illumination or desperation. Gives some use to the research topics that advise use of incendiaries/phosphorous, and the damage modifiers aliens have been assigned.<br />
<br />
== Rearming Rates ==<br />
<br />
<br />
From [[Known_Bugs_(TFTD)#Geoscape_Bugs]]:<br />
<br />
=== Craft Gauss Cannon Rearming Rate ===<br />
<br />
This weapon rearms at 10/hr but probably should be 50/hr or at least 25/hr, otherwise it is far slower to rearm than any other cannon weapon in either game. In fact it's the second slowest weapon system to rearm, slower only than AJAX...<br />
<br />
=== AJAX Rearming Rate ===<br />
<br />
An AJAX system takes twice as long to fully reload as a D.U.P. system, as a result AJAX-armed Craft have much worse operational tempo and readiness than D.U.P. armed Craft. Like we needed yet another reason to always use D.U.Ps. This is probably a design error rather than a bug, but it would be good to fix it - anything to give a more balanced set of craft weapon choices. The rearming rate should be raised from 1/hr to 2/hr. The AJAX system will then have the same operational tempo as the D.U.P. system. <br />
<br />
Could also be applied to Stingray missiles in EU 1994, as the same analysis applies to Stingray vs Avalanche.</div>Player701https://temp.ufopaedia.org/index.php?title=Sonic_Cannon&diff=28391Sonic Cannon2010-07-02T16:43:30Z<p>Player701: </p>
<hr />
<div>==General Information==<br />
<br />
{{Ref Open}}<br />
'''Sonic Cannon Official Entry'''<br />
<p style="text-indent:1em;">''"The Sonic Cannon is the most potent of the Sonic weapons family. Featuring a higher range audio oscillator and a larger reverberation chamber than the [[Sonic-Blasta Rifle|Blasta]]. The Cannon also has a pulse detonation system that alters the ultra-sonic wave by modulation to produce a more effective Sonic Shock."''</p><br />
<br />
<br />
'''Cannon Power Clip Official Entry'''<br />
<p style="text-indent:1em;">''"This compact device is used as ammunition for a Heavy Sonic Gun. It contains a small quantity of [[Zrbite]]."''</p><br />
{{Ref Close | Source: Terror From The Deep Ufopaedia}} <br />
<br />
<br />
[[Image:SonicCannon.gif|right|64px]]<br />
[[Image:SonicCannonClip.gif|right|64px]]<br />
The Sonic Cannon is the last of the hand-held sonic weapons. It is the workhorse of the aquatic alien invaders and is capable of dealing a superfluous amounts of damage. <br />
<br />
In general function, the Sonic Cannon is a very high powered sniping weapon. <br />
<br />
The Sonic Cannon benefits mainly from its very high snap and aimed accuracy as well as its ability to deal very high damage per round fired. On the other hand it carries the least ammunition amongst the Sonic Weapons and is slow, heavy and cumbersome to handle. With these extreme positive and negative attributes, this weapon can be classified as a 'heavy weapon'. <br />
<br />
A common trait shared amongst the Sonic weapons is a lack of autofire. <br />
<br />
Unlike its predecessors, the Sonic Cannon eventually becomes the standard issue weapon that is carried by the bulk of the alien forces. Due to its prolific nature, the cannon and its ammunition can easily be obtained from fallen aliens during many battles. There will rarely be an ammunition shortage of Cannon Power Clips throughout the campaign. This greatly assists with the Cannon Power Clip's otherwise low ammunition capacity and high [[Zrbite]] production cost. In effect, the cannon and its ammunition almost never need to be manufactured. <br />
<br />
Overall the Sonic Cannon is a very powerful weapon, but its various limitations do not make it a particularly suitable weapon to arm the entire squad on its own. The Sonic Cannon greatly hampers the shooter's mobility with its high [[Time Unit]] expenditure, and the shooter is often heavily exhausted after firing just one shot. This is a disastrous situation to be put into if caught in close quarter combat. On the other hand, from a sniping perspective, there are few weapons bar the [[Thermal Shok Launcher]] that can equal the Sonic Cannon's ability to snipe in a straight line. <br />
<br />
Very strong aquanauts with good accuracy can take a more extreme approach to the use of the Sonic Cannon. It can, in effect, be used like an over sized Sonic Pistol and used with other weapons or tools held out at the same time to provide that extra little bit of oomph at crucial moments. This works because the naturally high accuracy of the Sonic Cannon mitigates much of the accuracy penalty. The drills in particular are an excellent accompaniment for the Sonic Cannon, filling in the Sonic Cannon's close quarter combat limitations. <br />
<br />
This weapon appears in ''[[TFTD|Terror from the Deep]]''. For the ''[[X-COM|UFO: Enemy Unknown]]'' equivalent, refer to the [[Heavy Plasma]].<br />
<br />
<br />
{| {{StdCenterTable}} align = "center" width = "40%" <br />
|-<br />
|colspan = "2" {{StdDescTable_Heading}}|'''Key Features'''<br />
|- <br />
|colspan = "2" align="left" valign = "top"| <br />
* Sonic Damage <br />
|-<br />
|{{StdDescTable_Heading}} width = "50%" |'''Pros''' <br />
|{{StdDescTable_Heading}} width = "50%" |'''Cons'''<br />
|-<br />
| align = "left" valign = "top"|<br />
* Very High Power <br />
* Very High Accuracy <br />
* Recoverable <br />
* Very common<br />
| align = "left" valign = "top"|<br />
* Very Slow<br />
* Heavy<br />
* Cumbersome<br />
* Low Ammunition<br />
* Zrbite for ammo manufacture<br />
|}<br />
<br />
==Weapon Statistics==<br />
<br />
'''Sonic Cannon'''<br />
* Size: 3 high x 2 wide<br />
* Firing Accuracy:<br />
** 80% Snapshot<br />
** 115% Aimed<br />
<br />
* Firing Cost:<br />
** 50% Snapshot<br />
** 70% Aimed<br />
<br />
* Selling Cost: $171,600<br />
* Build Cost: $122,000 plus:<br />
** Technician Hrs: 1000<br />
** Workshop Space: 4<br />
** Aqua Plastics: 1<br />
** Zrbite: 0<br />
<br />
==Ammo Statistics==<br />
<br />
<br />
'''Sonic Cannon Clip'''<br />
* Size: 1 high x 1 wide<br />
* Damage: 130 Sonic<br />
* Ammo Capacity: 10<br />
* Selling Cost: $9,590<br />
* Build Cost: $6,000 plus:<br />
** Technician Hrs: 80<br />
** Workshop Space: 4<br />
** Aqua Plastics: 0<br />
** Zrbite: 3<br />
<br />
==See Also==<br />
* [[Cannon Power Clip]]<br />
* [[Weapons (TFTD)|Weapons]]<br />
* [[Sonic Pistol]]<br />
* [[Sonic-Blasta Rifle]]<br />
* [[Heavy Plasma vs Sonic Cannon]]<br />
<br />
<br />
{{Equipment (TFTD) Navbar}}<br />
<br />
[[Category:Equipment (TFTD)]][[Category:Research (TFTD)]]</div>Player701https://temp.ufopaedia.org/index.php?title=Talk:Artefact_Site&diff=28387Talk:Artefact Site2010-07-01T09:58:00Z<p>Player701: </p>
<hr />
<div>==Locked Hallucinoid?==<br />
Hi everybody, I'm new here - and here's my new question.<br />
I have recently completed two Artefact Site missions on Superhuman difficulty. In both of these missions (in second part) there was a Hallucinoid located far outside the map. I was able to find it by using XComUtil (SWP flag).<br />
<br />
The question is as follows: can this Hallucinoid present there knowingly (by developers) to ensure that you will manually destroy the Synomium Device instead of just kill all the aliens? Or maybe this is just a bug of the Windows version of the game, or something like alien overflow on higher difficulties?<br />
<br />
Thanks.<br />
<br />
[[User:Player701|Player701]] 08:05, 29 June 2010 (EDT)<br />
<br />
:XComUtil sometimes generated X-COM units outside the boundaries of the map (I'm not sure if this has been corrected on the latest version), so it is possible that it is simply an XComUtil generated bug. [[User:Hobbes|Hobbes]] 08:25, 29 June 2010 (EDT)<br />
<br />
::I know that, but I haven't used XComUtil before. I have installed it just to find that last alien, so this bug can't be related to XComUtil. And I have installed it in another game directory, so it couldn't corrupt my save files. [[User:Player701|Player701]] 10:05, 29 June 2010 (EDT)<br />
<br />
::: If you upload the save file (here for eg: [[Image:Out_of_bounds_Hallucinoid.zip]]), I could take a look at it. I would guess the map ran out of spawn nodes (higher difficulty = more aliens to place on the map). - [[User:Bomb Bloke|Bomb Bloke]] 23:24, 29 June 2010 (EDT)<br />
<br />
:::: There are a few maps in TFTD where large units may end up spawned in odd locations, probably due to what Bomb Bloke mentioned. Actually, in one odd example I helped troubleshoot a while back was a Xarquid that was stuck in the cargo hold shaft at the front of the boat in a shipping lane mission. Since it cannot be breached even by alien weapons, it made the first map impossible to complete without aborting. As for the aliens getting stuck in walls in the colonies, I don't know if that was deliberate or accidental on the part of the mappers. <br />
<br />
:::: I had a feeling Zombie had a series of map pack sets that corrected the placement problems, but currently I can only find the ones for the two small subs and the ones for UFO. -[[User:NKF|NKF]] 01:56, 30 June 2010 (EDT)<br />
<br />
:::: Uploaded the save game: [[Image:Out of bounds Hallucinoid.zip]], you can take a look. That's my fourth Artefact Site mission in this campaign, and the third case of a Hallucinoid outside of the map (There is only one alien remaining, and the SWP flag was applied using XComUtil). [[User:Player701|Player701]] 05:53, 1 July 2010 (EDT)</div>Player701https://temp.ufopaedia.org/index.php?title=Talk:Artefact_Site&diff=28386Talk:Artefact Site2010-07-01T09:57:20Z<p>Player701: </p>
<hr />
<div>==Locked Hallucinoid?==<br />
Hi everybody, I'm new here - and here's my new question.<br />
I have recently completed two Artefact Site missions on Superhuman difficulty. In both of these missions (in second part) there was a Hallucinoid located far outside the map. I was able to find it by using XComUtil (SWP flag).<br />
<br />
The question is as follows: can this Hallucinoid present there knowingly (by developers) to ensure that you will manually destroy the Synomium Device instead of just kill all the aliens? Or maybe this is just a bug of the Windows version of the game, or something like alien overflow on higher difficulties?<br />
<br />
Thanks.<br />
<br />
[[User:Player701|Player701]] 08:05, 29 June 2010 (EDT)<br />
<br />
:XComUtil sometimes generated X-COM units outside the boundaries of the map (I'm not sure if this has been corrected on the latest version), so it is possible that it is simply an XComUtil generated bug. [[User:Hobbes|Hobbes]] 08:25, 29 June 2010 (EDT)<br />
<br />
::I know that, but I haven't used XComUtil before. I have installed it just to find that last alien, so this bug can't be related to XComUtil. And I have installed it in another game directory, so it couldn't corrupt my save files. [[User:Player701|Player701]] 10:05, 29 June 2010 (EDT)<br />
<br />
::: If you upload the save file (here for eg: [[Image:Out_of_bounds_Hallucinoid.zip]]), I could take a look at it. I would guess the map ran out of spawn nodes (higher difficulty = more aliens to place on the map). - [[User:Bomb Bloke|Bomb Bloke]] 23:24, 29 June 2010 (EDT)<br />
<br />
:::: There are a few maps in TFTD where large units may end up spawned in odd locations, probably due to what Bomb Bloke mentioned. Actually, in one odd example I helped troubleshoot a while back was a Xarquid that was stuck in the cargo hold shaft at the front of the boat in a shipping lane mission. Since it cannot be breached even by alien weapons, it made the first map impossible to complete without aborting. As for the aliens getting stuck in walls in the colonies, I don't know if that was deliberate or accidental on the part of the mappers. <br />
<br />
:::: I had a feeling Zombie had a series of map pack sets that corrected the placement problems, but currently I can only find the ones for the two small subs and the ones for UFO. -[[User:NKF|NKF]] 01:56, 30 June 2010 (EDT)<br />
<br />
:::: Uploaded the save game: [[Image:Out of bounds Hallucinoid.zip]], you can take a look. That's my fourth Artefact Site mission in this campaign, and the third case with a Hallucinoid outside of the map (There is only one alien remaining, and the SWP flag was applied using XComUtil). [[User:Player701|Player701]] 05:53, 1 July 2010 (EDT)</div>Player701https://temp.ufopaedia.org/index.php?title=Talk:Artefact_Site&diff=28385Talk:Artefact Site2010-07-01T09:55:18Z<p>Player701: </p>
<hr />
<div>==Locked Hallucinoid?==<br />
Hi everybody, I'm new here - and here's my new question.<br />
I have recently completed two Artefact Site missions on Superhuman difficulty. In both of these missions (in second part) there was a Hallucinoid located far outside the map. I was able to find it by using XComUtil (SWP flag).<br />
<br />
The question is as follows: can this Hallucinoid present there knowingly (by developers) to ensure that you will manually destroy the Synomium Device instead of just kill all the aliens? Or maybe this is just a bug of the Windows version of the game, or something like alien overflow on higher difficulties?<br />
<br />
Thanks.<br />
<br />
[[User:Player701|Player701]] 08:05, 29 June 2010 (EDT)<br />
<br />
:XComUtil sometimes generated X-COM units outside the boundaries of the map (I'm not sure if this has been corrected on the latest version), so it is possible that it is simply an XComUtil generated bug. [[User:Hobbes|Hobbes]] 08:25, 29 June 2010 (EDT)<br />
<br />
::I know that, but I haven't used XComUtil before. I have installed it just to find that last alien, so this bug can't be related to XComUtil. And I have installed it in another game directory, so it couldn't corrupt my save files. [[User:Player701|Player701]] 10:05, 29 June 2010 (EDT)<br />
<br />
::: If you upload the save file (here for eg: [[Image:Out_of_bounds_Hallucinoid.zip]]), I could take a look at it. I would guess the map ran out of spawn nodes (higher difficulty = more aliens to place on the map). - [[User:Bomb Bloke|Bomb Bloke]] 23:24, 29 June 2010 (EDT)<br />
<br />
:::: There are a few maps in TFTD where large units may end up spawned in odd locations, probably due to what Bomb Bloke mentioned. Actually, in one odd example I helped troubleshoot a while back was a Xarquid that was stuck in the cargo hold shaft at the front of the boat in a shipping lane mission. Since it cannot be breached even by alien weapons, it made the first map impossible to complete without aborting. As for the aliens getting stuck in walls in the colonies, I don't know if that was deliberate or accidental on the part of the mappers. <br />
<br />
:::: I had a feeling Zombie had a series of map pack sets that corrected the placement problems, but currently I can only find the ones for the two small subs and the ones for UFO. -[[User:NKF|NKF]] 01:56, 30 June 2010 (EDT)<br />
<br />
:::: Uploaded the save game: [[Image:Out of bounds Hallucinoid.zip]], you can take a look. That's my fourth Artefact Site mission in this campaign, and the third case with such issue. [[User:Player701|Player701]] 05:53, 1 July 2010 (EDT)</div>Player701https://temp.ufopaedia.org/index.php?title=Talk:Artefact_Site&diff=28384Talk:Artefact Site2010-07-01T09:54:20Z<p>Player701: </p>
<hr />
<div>==Locked Hallucinoid?==<br />
Hi everybody, I'm new here - and here's my new question.<br />
I have recently completed two Artefact Site missions on Superhuman difficulty. In both of these missions (in second part) there was a Hallucinoid located far outside the map. I was able to find it by using XComUtil (SWP flag).<br />
<br />
The question is as follows: can this Hallucinoid present there knowingly (by developers) to ensure that you will manually destroy the Synomium Device instead of just kill all the aliens? Or maybe this is just a bug of the Windows version of the game, or something like alien overflow on higher difficulties?<br />
<br />
Thanks.<br />
<br />
[[User:Player701|Player701]] 08:05, 29 June 2010 (EDT)<br />
<br />
:XComUtil sometimes generated X-COM units outside the boundaries of the map (I'm not sure if this has been corrected on the latest version), so it is possible that it is simply an XComUtil generated bug. [[User:Hobbes|Hobbes]] 08:25, 29 June 2010 (EDT)<br />
<br />
::I know that, but I haven't used XComUtil before. I have installed it just to find that last alien, so this bug can't be related to XComUtil. And I have installed it in another game directory, so it couldn't corrupt my save files. [[User:Player701|Player701]] 10:05, 29 June 2010 (EDT)<br />
<br />
::: If you upload the save file (here for eg: [[Image:Out_of_bounds_Hallucinoid.zip]]), I could take a look at it. I would guess the map ran out of spawn nodes (higher difficulty = more aliens to place on the map). - [[User:Bomb Bloke|Bomb Bloke]] 23:24, 29 June 2010 (EDT)<br />
<br />
:::: There are a few maps in TFTD where large units may end up spawned in odd locations, probably due to what Bomb Bloke mentioned. Actually, in one odd example I helped troubleshoot a while back was a Xarquid that was stuck in the cargo hold shaft at the front of the boat in a shipping lane mission. Since it cannot be breached even by alien weapons, it made the first map impossible to complete without aborting. As for the aliens getting stuck in walls in the colonies, I don't know if that was deliberate or accidental on the part of the mappers. <br />
<br />
:::: I had a feeling Zombie had a series of map pack sets that corrected the placement problems, but currently I can only find the ones for the two small subs and the ones for UFO. -[[User:NKF|NKF]] 01:56, 30 June 2010 (EDT)<br />
<br />
:::: Uploaded the save game: [[Image:Out of bounds Hallucinoid.zip]], you can take a look. [[User:Player701|Player701]] 05:53, 1 July 2010 (EDT)</div>Player701https://temp.ufopaedia.org/index.php?title=Talk:Artefact_Site&diff=28383Talk:Artefact Site2010-07-01T09:53:50Z<p>Player701: </p>
<hr />
<div>==Locked Hallucinoid?==<br />
Hi everybody, I'm new here - and here's my new question.<br />
I have recently completed two Artefact Site missions on Superhuman difficulty. In both of these missions (in second part) there was a Hallucinoid located far outside the map. I was able to find it by using XComUtil (SWP flag).<br />
<br />
The question is as follows: can this Hallucinoid present there knowingly (by developers) to ensure that you will manually destroy the Synomium Device instead of just kill all the aliens? Or maybe this is just a bug of the Windows version of the game, or something like alien overflow on higher difficulties?<br />
<br />
Thanks.<br />
<br />
[[User:Player701|Player701]] 08:05, 29 June 2010 (EDT)<br />
<br />
:XComUtil sometimes generated X-COM units outside the boundaries of the map (I'm not sure if this has been corrected on the latest version), so it is possible that it is simply an XComUtil generated bug. [[User:Hobbes|Hobbes]] 08:25, 29 June 2010 (EDT)<br />
<br />
::I know that, but I haven't used XComUtil before. I have installed it just to find that last alien, so this bug can't be related to XComUtil. And I have installed it in another game directory, so it couldn't corrupt my save files. [[User:Player701|Player701]] 10:05, 29 June 2010 (EDT)<br />
<br />
::: If you upload the save file (here for eg: [[Image:Out_of_bounds_Hallucinoid.zip]]), I could take a look at it. I would guess the map ran out of spawn nodes (higher difficulty = more aliens to place on the map). - [[User:Bomb Bloke|Bomb Bloke]] 23:24, 29 June 2010 (EDT)<br />
<br />
:::: There are a few maps in TFTD where large units may end up spawned in odd locations, probably due to what Bomb Bloke mentioned. Actually, in one odd example I helped troubleshoot a while back was a Xarquid that was stuck in the cargo hold shaft at the front of the boat in a shipping lane mission. Since it cannot be breached even by alien weapons, it made the first map impossible to complete without aborting. As for the aliens getting stuck in walls in the colonies, I don't know if that was deliberate or accidental on the part of the mappers. <br />
<br />
:::: I had a feeling Zombie had a series of map pack sets that corrected the placement problems, but currently I can only find the ones for the two small subs and the ones for UFO. -[[User:NKF|NKF]] 01:56, 30 June 2010 (EDT)<br />
<br />
:::: Uploaded the save game, you can take a look. [[User:Player701|Player701]] 05:53, 1 July 2010 (EDT)</div>Player701https://temp.ufopaedia.org/index.php?title=File:Out_of_bounds_Hallucinoid.zip&diff=28382File:Out of bounds Hallucinoid.zip2010-07-01T09:53:05Z<p>Player701: Superhuman-diffuculty saved game on 2nd part of an Artefact Site misssion.</p>
<hr />
<div>Superhuman-diffuculty saved game on 2nd part of an Artefact Site misssion.</div>Player701https://temp.ufopaedia.org/index.php?title=Talk:Artefact_Site&diff=28378Talk:Artefact Site2010-06-29T14:05:26Z<p>Player701: </p>
<hr />
<div>==Locked Hallucinoid?==<br />
Hi everybody, I'm new here - and here's my new question.<br />
I have recently completed two Artefact Site missions on Superhuman difficulty. In both of these missions (in second part) there was a Hallucinoid located far outside the map. I was able to find it by using XComUtil (SWP flag).<br />
<br />
The question is as follows: can this Hallucinoid present there knowingly (by developers) to ensure that you will manually destroy the Synomium Device instead of just kill all the aliens? Or maybe this is just a bug of the Windows version of the game, or something like alien overflow on higher difficulties?<br />
<br />
Thanks.<br />
<br />
[[User:Player701|Player701]] 08:05, 29 June 2010 (EDT)<br />
<br />
:XComUtil sometimes generated X-COM units outside the boundaries of the map (I'm not sure if this has been corrected on the latest version), so it is possible that it is simply an XComUtil generated bug. [[User:Hobbes|Hobbes]] 08:25, 29 June 2010 (EDT)<br />
<br />
::I know that, but I haven't used XComUtil before. I have installed it just to find that last alien, so this bug can't be related to XComUtil. And I have installed it in another game directory, so it couldn't corrupt my save files. [[User:Player701|Player701]] 10:05, 29 June 2010 (EDT)</div>Player701https://temp.ufopaedia.org/index.php?title=Talk:Artefact_Site&diff=28376Talk:Artefact Site2010-06-29T12:05:58Z<p>Player701: New page: ==Locked Hallucinoid?== Hi everybody, I'm new here - and here's my new question. I have recently completed two Artefact Site missions on Superhuman difficulty. In both of these missions (i...</p>
<hr />
<div>==Locked Hallucinoid?==<br />
Hi everybody, I'm new here - and here's my new question.<br />
I have recently completed two Artefact Site missions on Superhuman difficulty. In both of these missions (in second part) there was a Hallucinoid located far outside the map. I was able to find it by using XComUtil (SWP flag).<br />
<br />
The question is as follows: can this Hallucinoid present there knowingly (by developers) to ensure that you will manually destroy the Synomium Device instead of just kill all the aliens? Or maybe this is just a bug of the Windows version of the game, or something like alien overflow on higher difficulties?<br />
<br />
Thanks.<br />
<br />
[[User:Player701|Player701]] 08:05, 29 June 2010 (EDT)</div>Player701