UFOpaedia - User contributions [en]

Talk:Alien Appearance Ratios (TFTD)

2014-09-14T11:40:56Z

Sherlock: /* Alien Missions and Attacks */

In these tables there is only one column for "Mixed Crew", but there are two different sorts of Mixed Crew. What's going on here? [[User:Magic9mushroom|Magic9mushroom]] 07:34, 7 February 2012 (EST)

: That's because there's only one column of probabilities available in the table that is taken directly from the game executable. I think where the mixed crew types 1 and 2 come from is the equipment and rank makeup tables. [[User:NKF|NKF]] 01:08, 8 February 2012 (EST)

So a single Alien Surface Attacks mission with a Mixed Crew (according to this table, the only Mixed Crew mission that should ever occur) could have different (ie Tasoth-based vs. Lobsterman-based) crews on different subs? This sounds like it needs to be checked. [[User:Magic9mushroom|Magic9mushroom]] 02:35, 8 February 2012 (EST)

: I had a re-read of the relevant articles, and I see the game specifically marks them as a type 4 and type 5, yet the probability table only has one column for both. If this is the case, then the game must do a toss between the two main races at the time it decides on creating the surface attack scouting wave or instant surface attack mission. [[User:NKF|NKF]] 02:52, 8 February 2012 (EST)

The choice between the two types of Mixed Crew appears to be not the only one the game makes. Tasoths on land missions can be accompanied by either Bio-Drones or Triscenes (not by both). I have saved a game just before a Shipping Lane Attack mission, and tried to start playing from it several times. And I have always got Tasoths + Bio-Drones on a Cargo Ship Terror mission. So, the "racial" contents of the alien crew as well as the type of the attacked ship must be fixed before the start of the mission. The only thing that changes is the number of the aliens.

As a result, in the observed alien appearance ratios some sub-types are distinguished:

1. Tasoths on land missions
(a) Tasoths + Bio-Drones
(b) Tasoths + Triscenes

2. Mixed Crew on land missions
2.1.
(a) Tasoths + Bio-drones + Aquatoids + Xarquids (or Calcinites?)
(b) Tasoths + Triscenes + Aquatoids + Calcinites (or Xarquids?)
2.2.
(c) Lobster Men + Bio-Drones (or Calcinites???) + Aquatoids + Deep Ones

(Details on Mixed Crew are quite a mystery for me; here I am relying on the contents of [[Mixed Crew]] article rather than on my own observations from the game.)

Do you know how and where the sub-types are coded in the game exe or/and data files?

[[User:Sherlock|Sherlock]] 09:12, 19 January 2013 (EST)

Addition: if to believe what has been said in [[Talk:Mixed_Crew]], Bio-drones and Triscenes are possible in one mission side by side - only with the mixed crew of Tasoths and Aquatoids? Telling the truth, I have not spot one yet (even if played TFTD many times). Any way,

Tasoths + Triscenes + Bio-Drones + Aquatoids + Calcinites on the 1st stage

Tasoths + Triscenes + Bio-Drones + Aquatoids + Xarquids on the 2nd stage

of a ship terror mission have been reported.

Perhaps yet more types of Mixed Crew are possible then. It is hard for me to check it: mixed crew may not happen is some campaigns at all.

[[User:Sherlock|Sherlock]] 09:49, 19 January 2013 (EST)

== a) Sonic research encouraging tougher aliens b) Tasoth appearance time error? ==

I've seen this referred to elsewhere, but I can't find it now: someone wanting to "bust the myth" that lobstermen appear later if you delay research on sonics.
I'm just playing a superhuman game, and have researched all sonics pretty much as late as possible, and lobsters haven't appeared until June. It definitely feels like a very late showing, and it came just after I got my first few sonics.

I had the same occur in UFO with late appearing snakemen (& mutons and ethereals) when I delayed plasma research.

If the new appearance percentages come in on the 1st of every other month, and don't ramp up gradually, then this data supports the tentative theory for me: it has been quite marked. How well understood is the code about this?

As a second, related point, something appears to be wrong somewhere with these charts: Playing TFTD on steam, with Xcomutil being used to catch bugs and having an otherwise "classic" game, I had a Tasoth and Bio-drone cargo ship terror mission on May 1st, which should be flat-out impossible according to these tables. It's now June 16th and I still haven't seen them since.

:Even though the aliens start to get the probability of appearing, that doesn't always guarantee that they'll appear. I had one game in UFO where I never even met the Mutons. Once they get a probability of appearing, missions for these races will start to get scheduled from the 1st and will not necessarily show up right away. What you'll get initially will be the leftovers from the last month.

:I'm not sure about the slightly earlier Tasoth mission, unless these probabilities only affect the normal sub waves that go out searching for a terror site and the monthly instant terror missions follow slightly different rules (Or suffer a fencepost error). XComutil doesn't touch the probabilities, and I doubt the probabilities will have changed when the Dos version was ported to the CE version. -[[User:NKF|NKF]] 03:55, 19 June 2012 (EDT)

Tasoths + Bio-Drone shipping route attacks in May may be a rule in the game, or an result of a bug. I have just got one as well. And I have checked missions.dat - there is no trace of any Tasoth activity there, only 0 (Aquatoids) and 1 (Gill Men) missions. Which is more, there is not a single Alien Surface Attack active mission recorded in there as well. I have checked saved games before the attack (of April 2040) and after the mission, and still no trace of any Tasoth alien mission at all.

In addition: the place of the attack is not very far from a base of mine. There is a Wide Array Sonar in the base, so the chance of detecting a battleship heading for the attack was not very low - but I did not detect anything, and such an event is not the first time. It looks like the aliens emerged from beneath the waves just to the attacked ship.

Some interesting questions arise then:

(1) Shouldn't any alien active mission be recorded in missions.dat?

(2) Is there a possibility that some kind of alien activities are hard recorded (in the exe) and are thus basic events of the game timeline (or its milestones)?

(3) Or perhaps the-first-day-of-the-month alien surface attacks are not scheduled in the same way like other alien missions?

And, as a consequence, tasoths may appear on them even if they should not have appeared yet, as it is too early for it according to the game alien appearance ratios?

[[User:Sherlock|Sherlock]] 09:35, 19 January 2013 (EST)

I'll just chip in and say I've seen a Tasoth shipping route terror mission as early as 1st April (it wasn't an April fools, sadly). In fact, in that game they showed up before the Lobster Men. I was playing on Superhuman.
--[[User:Darkpast|Darkpast]] 10:32, 30 July 2013 (EDT)
:Update: I think I may have found the answer to the Tasoth mission in April. According to the tables here, it seems that a Lobsterman terror mission has a 50% chance of spawning in April. However, I remember that every single time I played the game, there was a Shipping Route mission with either Lobster Men or (rarely) Tasoths in the first few days of April. Therefore, Sherlock's point #3 seems correct: the missions at the beginning of the month are recorded somewhere else... And I have a hunch it's the same place that Artifact Site missions are recorded, because Artifact Sites aren't "normal" missions either; they simply pop out of nowhere. Furthermore, later in the game there will (almost?) always be either an Artifact Site or Shipping Route mission at the beginning of the month - if you try re-loading the game you'll see they're interchangeable; you can get either one (seems the chance is 50-50). --[[User:Darkpast|Darkpast]] ([[User talk:Darkpast|talk]]) 17:22, 3 July 2014 (EDT)

== Alien Missions and Attacks ==

Perhaps I have found a solution of the April Tasoth problem, and by the way, of the problem of alien appearance ratios for Floating Base Attack, said to be superfluous and not used by the game.

It seems that the aliens take a part in both missions and attacks which are not part of any mission (and thus are not recorded). Single attacks (not being part of a mission) mean shipping route, port and island terror attacks, not scheduled before, not preceded by an appearance of any USO (the aliens attack immediately) and not in agreement with the tables presented in the current article. Hence Tasoths may appear in April, and hence aliens may terrorize land as early as in the first days of the campaign.

Note that an Alien Surface Attacks mission, unlike a single attack, contains of several phases. It begins from smaller USOs, and only in the last phase a Battleship appears and attacks a ship, a port or an island. It is in total agreement with the appearence charts discussed here. Unlike this, single attacks are not preceded by smaller USO's, and are not in agreement with the charts.

Single terror attacks are frequent in first months, then they seem to cease. Aliens can still terrorize ships, ports and islands but during their Alien Surface Attacks missions rather than single attacks.

As it seems to me, a similar mechanism lies behind attacks on XCom bases. Some of the attacks are a result of an alien response to downing a USO (with a chance which depends on the game difficulty level). Contrary to single terror attacks, a Dreadnought always appears then. The aliens know exactly where the XCom base is located. Appearance ratios are of no use then - it is the same race which responds, as the race whose USO was downed by XCom.

These single attacks in response to USO downing seem to have nothing to do with Floating Base Attack missions. Like other of the 7 mission types altogether, Floating Base Attacks are scheduled and consist of several phases. Alien Appearence Ratios are applied. It is only a chance that the aliens will find the XCom base location.

[[User:Sherlock|Sherlock]] ([[User talk:Sherlock|talk]]) 07:40, 14 September 2014 (EDT)

User:Sherlock

2013-02-03T19:48:41Z

Sherlock: /* TFTD Routes Fixes */

Hi, my real name is Grzegorz Jagodziński. I am a Pole and I live in a small town in Poland called Libiąż. Here is my webpage: http://grzegorj.orangespace.pl/, with a set of pages on X-Com games (mainly in Polish): http://grzegorj.orangespace.pl/xc/index.html

= UFO:EU and TFTD Research Trees =

As for now, I have made UFO Enemy Unknown and Terror from the Deep research trees. Use them freely if you like them!

<center>[[file:tree1.png|800px|thumb|center|UFO:EU Research Tree]]</center>
<center>[[file:tree1_ob_en.png|400px|thumb|center|Explanations]]</center>

[http://grzegorj.orangespace.pl/xc/obrazki/tree1.png UFO Enemy Unknown research tree]
[http://grzegorj.orangespace.pl/xc/obrazki/tree1_ob_en.png Key to the tree in English] (and [http://grzegorj.orangespace.pl/xc/obrazki/tree1_ob_pl.png in Polish])

<center>[[file:tree2.png|800px|thumb|center|TFTD Research Tree]]</center>
<center>[[file:tree2_ob_en.png|400px|thumb|center|Explanations]]</center>

[http://grzegorj.orangespace.pl/xc/obrazki/tree2.png Terror from the Deep research tree]
[http://grzegorj.orangespace.pl/xc/obrazki/tree2_ob_en.png Key to the tree in English] (and [http://grzegorj.orangespace.pl/xc/obrazki/tree2_ob_pl.png in Polish])

= Spawn points =

Lists of spawn points on various maps. The list includes the original and the patched versions. Only alien spawn points, and only levels with alien spawn points are listed.

== UFO: EU ==

=== Alien Ships ===

<pre>
Original Game

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
UFO1a 1 | 3 2 0 0 5 | 5
| |
UFO_110 1 | 2 4 1 0 7 | 7
| |
UFO_120 2 | 0 0 0 1 1 |
1 | 13 6 1 0 20 | 21
| |
UFO_130 3 | 8 0 0 0 8 |
2 | 10 1 0 0 11 |
1 | 10 6 0 0 16 | 35
| |
UFO_140 2 | 4 0 0 0 4 |
1 | 15 8 0 0 23 | 27
| |
UFO_150 2 | 11 6 0 2 19 |
1 | 2 10 0 0 12 | 31
| |
UFO_160 3 | 31 0 0 0 31 |
2 | 10 9 0 0 19 |
1 | 11 9 0 0 20 | 70
| |
UFO_170 3 | 7 0 0 0 7 |
2 | 26 0 0 0 26 |
1 | 14 9 0 0 23 | 56
----------------------------------------------------------------------------------------

Combo Patch

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
UFO1a 1 | 1 4 0 0 5 | 5
| |
UFO_110 1 | 8 2 0 0 10 | 10
| |
UFO_120 2 | 0 0 0 1 1 |
1 | 14 6 0 0 20 | 21
| |
UFO_130 3 | 8 0 0 0 8 |
2 | 11 0 0 0 11 |
1 | 10 6 0 0 16 | 35
| |
UFO_140 2 | 4 0 0 0 4 |
1 | 14 9 0 0 23 | 27
| |
UFO_150 2 | 13 4 0 2 19 |
1 | 6 14 0 0 20 | 39
| |
UFO_160 3 | 31 0 0 0 31 |
2 | 11 8 0 0 19 |
1 | 10 10 0 0 20 | 70
| |
UFO_170 3 | 7 0 0 0 7 |
2 | 26 0 0 0 26 |
1 | 14 10 0 0 24 | 57
----------------------------------------------------------------------------------------

</pre>

=== Alien Base ===

<pre>

Original Game

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
UBASE_00 2 | 0 4 0 0 4 |
1 | 1 8 0 0 9 | 13
| |
UBASE_01 2 | 2 0 0 0 2 |
1 | 0 4 0 0 4 | 6
| |
UBASE_02 2 | 1 0 0 0 1 |
1 | 1 8 0 0 9 | 10
| |
UBASE_03 2 | 4 0 0 0 4 |
1 | 0 9 0 0 9 | 13
| |
UBASE_05 2 | 1 0 0 0 1 |
1 | 0 4 0 0 4 | 5
| |
UBASE_06 2 | 1 0 0 0 1 |
1 | 4 0 0 0 4 | 5
| |
UBASE_07 1 | 0 1 0 0 1 | 1
| |
UBASE_08 2 | 1 0 0 0 1 |
1 | 1 4 0 0 5 | 6
| |
UBASE_10 1 | 0 1 0 0 1 | 1
| |
UBASE_11 2 | 0 1 0 0 1 |
1 | 0 1 0 0 1 | 2
| |
UBASE_12 2 | 0 0 0 1 1 | 1
| |
UBASE_14 2 | 0 0 0 1 1 | 1
| |
UBASE_15 2 | 5 0 0 0 5 |
1 | 0 5 0 0 5 | 10
----------------------------------------------------------------------------------------

Combo Patch

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
UBASE_00 2 | 0 5 0 0 5 |
1 | 1 8 0 0 9 | 14
| |
UBASE_01 2 | 2 0 0 0 2 |
1 | 0 4 0 0 4 | 6
| |
UBASE_02 2 | 1 0 0 0 1 |
1 | 1 8 0 0 9 | 10
| |
UBASE_03 2 | 4 0 0 0 4 |
1 | 0 9 0 0 9 | 13
| |
UBASE_05 2 | 1 0 0 0 1 |
1 | 0 4 0 0 4 | 5
| |
UBASE_06 2 | 1 0 0 0 1 |
1 | 4 0 0 0 4 | 5
| |
UBASE_07 1 | 0 1 0 0 1 | 1
| |
UBASE_08 2 | 1 0 0 0 1 |
1 | 1 4 0 0 5 | 6
| |
UBASE_10 1 | 0 1 0 0 1 | 1
| |
UBASE_11 2 | 0 0 0 1 1 |
1 | 0 1 0 0 1 | 2
| |
UBASE_12 2 | 0 0 0 1 1 | 1
| |
UBASE_14 2 | 0 0 0 1 1 | 1
| |
UBASE_15 2 | 5 0 0 0 5 |
1 | 0 5 0 0 5 | 10
----------------------------------------------------------------------------------------

</pre>

=== Cydonia ===

<pre>

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
MARS02 1 | 1 0 0 0 1 | 1
| |
MARS03 1 | 0 1 0 0 1 | 1
| |
MARS04 1 | 3 0 0 0 3 | 3
| |
MARS05 1 | 0 1 0 0 1 | 1
| |
MARS06 1 | 0 2 0 0 2 | 2
| |
MARS07 1 | 2 0 0 0 2 | 2
| |
MARS08 1 | 2 0 0 0 2 | 2
| |
MARS09 2 | 4 0 0 0 4 | 4
| |
MARS10 1 | 2 0 0 0 2 | 2
----------------------------------------------------------------------------------------

</pre>

=== City Terror ===

<pre>

Original Game

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
URBAN_05 2 | 2 0 0 0 2 |
1 | 1 6 0 0 7 | 9
| |
URBAN_06 2 | 4 0 0 0 4 |
1 | 2 4 0 0 6 | 10
| |
URBAN_07 1 | 0 2 0 0 2 | 2
| |
URBAN_08 3 | 2 0 0 0 2 |
2 | 2 0 0 0 2 |
1 | 1 3 0 0 4 | 8
| |
URBAN_09 1 | 4 4 0 0 8 | 8
| |
URBAN_14 1 | 6 0 0 0 6 | 6
| |
URBAN_15 2 | 2 0 0 0 2 |
1 | 3 0 0 0 3 | 5
| |
URBAN_16 1 | 1 0 0 0 1 | 1
| |
URBAN_17 1 | 6 0 0 0 6 | 6
| |
URBAN_18 2 | 1 0 0 0 1 |
1 | 1 3 0 0 4 | 5
----------------------------------------------------------------------------------------

Fixed Game

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
URBAN_05 2 | 2 0 0 0 2 |
1 | 1 6 0 0 7 | 9
| |
URBAN_06 2 | 4 0 0 0 4 |
1 | 2 4 0 0 6 | 10
| |
URBAN_07 1 | 0 2 0 0 2 | 2
| |
URBAN_08 3 | 2 0 0 0 2 |
2 | 2 0 0 0 2 |
1 | 1 3 0 0 4 | 8
| |
URBAN_09 1 | 4 4 0 0 8 | 8
| |
URBAN_14 1 | 6 0 0 0 6 | 6
| |
URBAN_15 2 | 2 0 0 0 2 |
1 | 3 0 0 0 3 | 5
| |
URBAN_16 1 | 0 0 0 1 1 | 1
| |
URBAN_17 1 | 6 0 0 0 6 | 6
| |
URBAN_18 2 | 1 0 0 0 1 |
1 | 1 3 0 0 4 | 5
----------------------------------------------------------------------------------------

</pre>

=== Xcom Base ===

<pre>
Original Game

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
XBASE_00 2 | 0 3 0 0 3 |
1 | 0 5 0 0 5 | 8
| |
XBASE_03 1 | 0 3 0 0 3 | 3
| |
XBASE_04 2 | 2 0 0 0 2 | 2
| |
XBASE_05 1 | 0 4 0 0 4 | 4
| |
XBASE_06 1 | 0 4 0 0 4 | 4
| |
XBASE_07 1 | 0 1 0 0 1 | 1
| |
XBASE_08 2 | 5 0 0 0 5 |
1 | 4 3 0 0 7 | 12
| |
XBASE_09 2 | 1 0 0 0 1 |
1 | 1 4 0 0 5 | 6
| |
XBASE_10 2 | 1 0 0 0 1 |
1 | 1 4 0 0 5 | 6
| |
XBASE_11 2 | 1 0 0 0 1 |
1 | 1 4 0 0 5 | 6
| |
XBASE_12 2 | 1 0 0 0 1 |
1 | 1 4 0 0 5 | 6
| |
XBASE_13 2 | 1 0 0 0 1 |
1 | 1 4 0 0 5 | 6
| |
XBASE_14 2 | 3 0 0 0 3 |
1 | 4 3 0 0 7 | 8
| |
XBASE_15 2 | 1 0 0 0 1 |
1 | 1 4 0 0 5 | 6
| |
XBASE_16 1 | 1 3 0 0 4 | 4
| |
XBASE_17 1 | 0 4 0 0 4 | 4
| |
XBASE_18 1 | 1 3 0 0 4 | 4
| |
XBASE_18 1 | 0 3 0 0 3 | 3
----------------------------------------------------------------------------------------

Combo Patch + Fix

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
XBASE_00 2 | 4 8 0 0 12 |
1 | 0 5 0 0 5 | 17
| |
XBASE_03 1 | 0 3 0 0 3 | 3
| |
XBASE_04 2 | 2 0 0 0 2 | 2
| |
XBASE_05 1 | 0 4 0 0 4 | 4
| |
XBASE_06 1 | 0 4 0 0 4 | 4
| |
XBASE_08 2 | 5 0 0 0 5 |
1 | 4 3 0 0 7 | 12
| |
XBASE_09 2 | 1 0 0 0 1 |
1 | 1 4 0 0 5 | 6
| |
XBASE_10 2 | 1 0 0 0 1 |
1 | 1 4 0 0 5 | 6
| |
XBASE_11 2 | 1 0 0 0 1 |
1 | 1 4 0 0 5 | 6
| |
XBASE_12 2 | 1 0 0 0 1 |
1 | 1 4 0 0 5 | 6
| |
XBASE_13 2 | 1 0 0 0 1 |
1 | 1 4 0 0 5 | 6
| |
XBASE_14 2 | 3 0 0 0 3 |
1 | 4 3 0 0 7 | 8
| |
XBASE_15 2 | 1 0 0 0 1 |
1 | 1 4 0 0 5 | 6
| |
XBASE_16 1 | 1 3 0 0 4 | 4
| |
XBASE_17 1 | 0 4 0 0 4 | 4
| |
XBASE_18 1 | 1 3 0 0 4 | 4
| |
XBASE_18 1 | 0 3 0 0 3 | 3
----------------------------------------------------------------------------------------

</pre>

=== Desert ===

<pre>

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
DESERT03 1 | 0 1 0 0 1 | 1
| |
DESERT05 1 | 0 1 0 0 1 | 1
| |
DESERT06 1 | 0 2 0 0 2 | 2
| |
DESERT07 1 | 0 1 0 0 1 | 1
| |
DESERT08 1 | 0 1 0 0 1 | 1
| |
DESERT09 1 | 0 3 0 0 3 | 3
| |
DESERT10 2 | 0 1 0 0 1 |
1 | 0 3 0 0 3 | 4
| |
DESERT11 1 | 0 2 0 0 2 | 2
----------------------------------------------------------------------------------------

</pre>

=== Farm ===

<pre>

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
CULTA00 1 | 0 1 0 0 1 | 1
| |
CULTA01 1 | 0 1 0 0 1 | 1
| |
CULTA02 1 | 0 1 0 0 1 | 1
| |
CULTA03 1 | 0 1 0 0 1 | 1
| |
CULTA04 1 | 0 1 0 0 1 | 1
| |
CULTA05 1 | 0 2 0 0 2 | 2
| |
CULTA06 1 | 0 2 0 0 2 | 2
| |
CULTA07 1 | 0 1 0 0 1 | 1
| |
CULTA08 1 | 0 1 0 0 1 | 1
| |
CULTA09 1 | 0 1 0 0 1 | 1
| |
CULTA10 1 | 0 1 0 0 1 | 1
| |
CULTA11 1 | 0 1 0 0 1 | 1
| |
CULTA12 1 | 0 1 0 0 1 | 1
| |
CULTA13 1 | 2 0 0 0 2 | 2
| |
CULTA14 1 | 0 1 0 0 1 | 1
| |
CULTA15 1 | 0 1 0 0 1 | 1
| |
CULTA16 2 | 4 0 0 0 4 |
1 | 0 1 0 0 1 | 5
| |
CULTA17 1 | 1 3 0 0 4 | 4
| |
CULTA18 3 | 2 0 0 0 2 |
2 | 4 0 0 0 4 |
1 | 2 0 0 0 2 | 8
----------------------------------------------------------------------------------------

</pre>

=== Forest ===

<pre>

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
FOREST03 1 | 0 1 0 0 1 | 1
| |
FOREST04 1 | 0 1 0 0 1 | 1
| |
FOREST06 1 | 0 1 0 0 1 | 1
| |
FOREST07 1 | 0 1 0 0 1 | 1
| |
FOREST08 1 | 0 1 0 0 1 | 1
| |
FOREST09 1 | 0 1 0 0 1 | 1
| |
FOREST10 1 | 0 3 0 0 3 | 1
| |
FOREST11 2 | 0 1 0 0 1 |
1 | 0 3 0 0 3 | 4
----------------------------------------------------------------------------------------

</pre>

=== Jungle ===

<pre>

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
JUNGLE03 1 | 0 1 0 0 1 | 1
| |
JUNGLE04 1 | 0 1 0 0 1 | 1
| |
JUNGLE05 1 | 0 1 0 0 1 | 1
| |
JUNGLE06 1 | 0 1 0 0 1 | 1
| |
JUNGLE07 1 | 0 2 0 0 2 | 2
| |
JUNGLE08 1 | 0 2 0 0 2 | 2
| |
JUNGLE09 1 | 0 1 0 0 1 | 1
| |
JUNGLE10 1 | 0 1 0 0 1 | 1
| |
JUNGLE11 1 | 0 1 0 0 1 | 1
----------------------------------------------------------------------------------------

</pre>

=== Mountain ===

<pre>

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
MOUNT03 1 | 0 2 0 0 2 | 2
| |
MOUNT04 1 | 1 1 0 0 2 | 2
| |
MOUNT05 1 | 0 2 0 0 2 | 2
| |
MOUNT06 1 | 1 1 0 0 2 | 2
| |
MOUNT07 2 | 0 1 0 0 1 |
1 | 1 0 0 0 1 | 2
| |
MOUNT08 1 | 0 1 0 0 1 | 1
| |
MOUNT09 1 | 0 1 0 0 1 | 1
| |
MOUNT10 3 | 0 0 0 1 1 |
1 | 0 1 0 0 1 | 2
| |
MOUNT11 2 | 0 1 0 0 1 |
1 | 0 2 0 0 2 | 3
| |
MOUNT12 1 | 0 2 0 0 2 | 2
----------------------------------------------------------------------------------------

</pre>

=== Polar ===

<pre>

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
POLAR03 1 | 0 1 0 0 1 | 1
| |
POLAR04 1 | 0 1 0 0 1 | 1
| |
POLAR06 1 | 0 1 0 0 1 | 1
| |
POLAR07 1 | 0 1 0 0 1 | 1
| |
POLAR08 1 | 0 1 0 0 1 | 1
| |
POLAR10 1 | 0 1 0 0 1 | 1
----------------------------------------------------------------------------------------

</pre>

== TFTD ==

=== Alien Subs ===

<pre>

Original Game

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
UFO01 1 | 5 1 0 0 6 | 6
| |
UFO02 1 | 2 1 0 0 3 | 3
| |
UFO03 1 | 12 0 0 0 12 | 12
| |
UFO04 2 | 7 0 0 0 7 |
1 | 13 1 0 0 14 | 21
| |
UFO05 3 | 8 0 0 0 8 |
2 | 15 1 0 0 16 |
1 | 7 0 0 0 7 | 31
| |
UFO06 3 | 13 0 0 0 13 |
2 | 22 0 0 0 22 |
1 | 13 1 0 0 14 | 49
| |
UFO07 3 | 44 0 0 0 44 |
2 | 16 0 0 0 16 |
1 | 20 0 0 0 20 | 80
| |
UFO08 4 | 2 0 0 0 2 |
3 | 20 0 0 0 20 |
2 | 22 0 0 0 22 |
1 | 24 0 0 0 24 | 68
----------------------------------------------------------------------------------------

Combo Patch + Fix

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
UFO01 1 | 3 0 0 0 3 | 3
| |
UFO02 1 | 6 0 0 0 6 | 6
| |
UFO03 1 | 12 0 0 0 12 | 12
| |
UFO04 2 | 7 0 0 0 7 |
1 | 14 0 0 0 14 | 21
| |
UFO05 3 | 10 0 0 0 10 |
2 | 16 0 0 0 16 |
1 | 7 0 0 0 7 | 31
| |
UFO06 3 | 13 0 0 0 13 |
2 | 22 0 0 0 22 |
1 | 9 5 0 0 14 | 49
| |
UFO07 3 | 45 0 0 0 45 |
2 | 20 4 0 0 24 |
1 | 21 4 0 0 25 | 94
| |
UFO08 4 | 2 0 0 0 2 |
3 | 20 0 0 0 20 |
2 | 22 0 0 0 22 |
1 | 24 0 0 0 24 | 68
----------------------------------------------------------------------------------------

</pre>

=== Alien Artifact Site 1 ===

<pre>

Original Game

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
ALART01 1 | 0 1 0 0 1 | 1
| |
ALART02 1 | 1 0 0 0 1 | 1
| |
ALART03 1 | 0 1 0 0 1 | 1
| |
ALART04 1 | 0 1 0 0 1 | 1
| |
ALART05 1 | 1 0 0 0 1 | 1
| |
ALART06 1 | 0 1 0 0 1 | 1
| |
ALART08 1 | 1 0 0 0 1 | 1
| |
ALART09 1 | 0 1 0 0 1 | 1
| |
ALART10 1 | 1 0 0 0 1 | 1
| |
ALART11 3 | 1 0 0 0 1 |
2 | 1 0 0 0 1 |
1 | 1 0 0 0 1 | 3
----------------------------------------------------------------------------------------

Combo Patch + Fix

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
ALART01 1 | 0 1 0 0 1 | 1
| |
ALART02 1 | 0 1 0 0 1 | 1
| |
ALART03 2 | 0 0 0 1 1 |
1 | 0 1 0 0 1 | 2
| |
ALART04 1 | 0 1 0 0 1 | 1
| |
ALART05 1 | 0 1 0 0 1 | 1
| |
ALART06 3 | 0 0 0 1 1 |
1 | 0 1 0 0 1 | 2
| |
ALART07 3 | 0 0 0 1 1 |
1 | 0 1 0 0 1 | 2
| |
ALART08 2 | 0 0 0 1 1 |
1 | 0 1 0 0 1 | 2
| |
ALART09 1 | 0 0 0 2 2 |
1 | 2 4 0 0 6 | 8
| |
ALART10 2 | 0 0 0 2 2 |
1 | 2 6 0 0 8 | 10
| |
ALART11 4 | 4 0 0 0 4 |
3 | 4 0 0 0 4 |
2 | 4 0 0 0 4 |
1 | 1 3 0 0 4 | 16
----------------------------------------------------------------------------------------

</pre>

=== Alien Artifact Site 2 ===

<pre>

Original Game

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
GRUNGE00 2 | 0 1 0 0 1 | 1
| |
GRUNGE01 1 | 0 1 0 0 1 | 1
| |
GRUNGE02 2 | 0 1 0 0 1 | 1
| |
GRUNGE05 1 | 1 0 0 0 1 | 1
| |
GRUNGE06 2 | 0 1 0 0 1 |
1 | 0 1 0 0 1 | 2
| |
GRUNGE07 1 | 0 1 0 0 1 | 1
| |
GRUNGE08 2 | 0 1 0 0 1 | 1
| |
GRUNGE09 1 | 0 1 0 0 1 | 1
| |
GRUNGE10 2 | 0 1 0 0 1 | 1
| |
GRUNGE11 2 | 2 5 0 0 7 |
1 | 0 1 0 0 1 | 8
| |
GRUNGE12 2 | 0 4 0 0 4 |
1 | 1 1 0 0 2 | 6
| |
GRUNGE13 2 | 1 0 0 0 1 |
1 | 0 2 0 0 2 | 3
| |
GRUNGE14 2 | 0 2 0 0 2 |
1 | 0 3 0 0 3 | 5
| |
GRUNGE15 3 | 6 0 0 0 6 |
2 | 5 0 0 0 5 |
1 | 0 1 0 0 1 | 12
| |
GRUNGE16 3 | 0 3 0 0 3 |
1 | 6 1 0 0 7 | 10
----------------------------------------------------------------------------------------

Combo Patch + Fix

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
GRUNGE00 2 | 0 1 0 0 1 | 1
| |
GRUNGE01 2 | 0 1 0 0 1 |
1 | 0 1 0 0 1 | 2
| |
GRUNGE02 2 | 0 1 0 0 1 | 1
| |
GRUNGE03 2 | 0 1 0 0 1 | 1
| |
GRUNGE05 1 | 1 0 0 0 1 | 1
| |
GRUNGE06 2 | 2 1 0 0 3 |
1 | 0 1 0 0 1 | 4
| |
GRUNGE07 1 | 0 1 0 0 1 | 1
| |
GRUNGE08 2 | 1 0 0 0 1 | 1
| |
GRUNGE09 2 | 1 0 0 0 1 |
1 | 1 0 0 0 1 | 2
| |
GRUNGE10 2 | 2 0 0 0 2 |
1 | 0 1 0 0 1 | 3
| |
GRUNGE11 2 | 2 5 0 0 7 |
1 | 0 3 0 0 3 | 10
| |
GRUNGE12 2 | 4 1 0 0 5 |
1 | 5 4 0 0 9 | 14
| |
GRUNGE13 2 | 4 0 0 0 4 |
1 | 2 4 0 0 6 | 10
| |
GRUNGE14 2 | 2 1 0 0 3 |
1 | 1 5 0 0 6 | 9
| |
GRUNGE15 4 | 4 0 0 0 4 |
3 | 6 1 0 0 7 |
2 | 5 0 0 0 5 |
1 | 0 6 0 0 6 | 22
| |
GRUNGE16 3 | 1 5 0 0 6 |
1 | 7 0 0 0 7 | 13
----------------------------------------------------------------------------------------

</pre>

=== Alien Base Level 1 ===

<pre>

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
ENTRY00 3 | 0 0 0 1 1 |
1 | 0 1 0 0 1 | 2
| |
ENTRY01 2 | 2 2 0 0 4 |
1 | 0 5 0 0 5 | 9
| |
ENTRY02 3 | 0 0 0 1 1 |
1 | 3 0 0 0 3 | 4
| |
ENTRY03 3 | 0 0 0 2 2 |
2 | 0 0 0 1 1 |
1 | 2 0 0 0 2 | 5
| |
ENTRY04 2 | 8 0 0 0 8 |
1 | 4 4 0 0 8 | 16
| |
ENTRY05 3 | 0 0 0 2 2 |
2 | 0 0 0 1 1 |
1 | 1 1 0 0 2 | 5
| |
ENTRY06 1 | 0 3 0 0 3 | 3
| |
ENTRY07 2 | 0 0 0 1 1 |
1 | 1 0 0 0 1 | 2
| |
ENTRY08 3 | 0 0 0 1 1 |
2 | 0 0 0 1 1 |
1 | 0 1 0 0 1 | 3
----------------------------------------------------------------------------------------

</pre>

=== Alien Base Level 2 ===

<pre>

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
A_BASE00 2 | 3 0 0 0 3 |
1 | 4 0 0 0 4 | 7
| |
A_BASE01 3 | 4 0 0 0 4 |
2 | 4 0 0 0 4 |
1 | 4 0 0 0 4 | 12
| |
A_BASE02 3 | 2 0 0 0 2 |
2 | 1 0 0 0 1 |
1 | 2 0 0 0 2 | 5
| |
A_BASE03 3 | 2 0 0 0 2 |
2 | 4 0 0 0 4 |
1 | 4 0 0 0 4 | 10
| |
A_BASE04 3 | 2 0 0 0 2 |
2 | 3 0 0 0 3 |
1 | 5 0 0 0 5 | 10
| |
A_BASE05 3 | 3 0 0 0 3 |
2 | 3 0 0 0 3 |
1 | 7 0 0 0 7 | 13
| |
A_BASE06 3 | 1 0 0 0 1 |
2 | 2 0 0 0 2 |
1 | 6 0 0 0 6 | 9
| |
A_BASE07 3 | 4 0 0 0 4 |
2 | 2 0 0 0 2 |
1 | 3 0 0 0 3 | 9
| |
A_BASE08 3 | 2 0 0 0 2 |
2 | 3 0 0 0 3 |
1 | 3 0 0 0 3 | 8
| |
A_BASE09 3 | 2 0 0 0 2 |
2 | 2 0 0 0 2 |
1 | 3 0 0 0 3 | 7
| |
A_BASE10 3 | 2 0 0 0 2 |
2 | 1 0 0 0 1 |
1 | 3 0 0 0 3 | 6
| |
A_BASE11 4 | 7 0 0 0 7 |
3 | 5 0 0 0 5 |
2 | 2 0 0 0 2 |
1 | 4 0 0 0 4 | 18
| |
A_BASE12 3 | 3 0 0 0 3 |
2 | 5 0 0 0 5 |
1 | 7 0 0 0 7 | 15
| |
A_BASE13 3 | 3 0 0 0 3 |
2 | 7 0 0 0 7 |
1 | 7 0 0 0 7 | 17
| |
A_BASE14 4 | 0 0 0 2 2 |
3 | 4 0 0 0 4 |
2 | 4 0 0 0 4 |
1 | 6 0 0 0 6 | 16
| |
A_BASE15 3 | 3 0 0 0 3 |
2 | 3 0 0 0 3 |
1 | 6 0 0 0 6 | 12
----------------------------------------------------------------------------------------

</pre>

=== Cargo Ship ===

<pre>

Original Game

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
CARGO00 4 | 3 0 0 1 4 |
3 | 1 0 0 0 1 |
2 | 3 3 0 0 6 |
1 | 13 0 0 0 13 | 24
| |
CARGO01 4 | 4 0 0 0 4 |
3 | 11 1 0 0 12 |
2 | 5 0 0 0 5 |
1 | 7 0 0 0 7 | 28
| |
CARGO02 2 | 1 0 0 0 1 | 1
----------------------------------------------------------------------------------------

Fixed Game

Map name Level | Spawn points on the level | Spawn points on the map
| Small Any Large Flying Total | in total
--------------------|----------------------------------------|--------------------------
CARGO00 4 | 4 0 0 2 6 |
3 | 3 0 0 0 3 |
2 | 10 17 0 0 27 |
1 | 27 0 0 0 27 | 63
| |
CARGO01 4 | 15 8 0 0 23 |
3 | 20 4 0 0 24 |
2 | 7 0 0 0 7 |
1 | 17 20 0 0 37 | 91
| |
CARGO02 2 | 1 0 0 0 1 | 1
----------------------------------------------------------------------------------------

</pre>

= UFO:EU Routes Fixes =

My fixes to UFO:EU routes: [[File:Eu_routes.zip]]

THESE ARE FIXES to the Combo Patch! They may not work with an unmodified version of the game. All maps have been checked.

Basic premises:

1. If a given node is marked "Small", then all links going from it and coming to it may not be marked for "Any" units.

2. Nodes on eastern and southern borders cannot be marked "Any", they are for small units only. The only exception is NW part of Hangars.

3. Additional nodes for Aliens have been added to Access Lift.

4. Isolated nodes on XBASE_20 and PLANE have been deleted.

Other changes:

• All links between nodes have been checked if set for proper distances (and corrected if necessary).

• UFO_110 - links between nodes 0 and 10 as well as between 0 and 3 are bidirectional again.

• UFO_130 - link from 13 to 25 nodes have been changed from FlyingLarge to Flying.

• UFO_150 - the unnecessary pillar on the level 2 has been removed.

• MARS00, MARS01 - existing nodes (for "Any" units) converted to spawn ones (because there is little spawn nodes for large units in Cydonia).

• UBASE_15, CULTA14 - one of the nodes has been moved by one square in order to give way for large units.

• DESERT: 03, 07, 08, 09, 10, 11; FOREST: 09, 10, 11; MOUNT: 05, 06, 07, 08, 10, 11, 12 - because of converting southern and eastern nodes to "Small", East and South Exits (also for large units) have been added to other nodes.

• CULTA16 - links added on Level 2 (they seemed to have existed and next removed).

• MOUNT04 - another West Exit added (as the existing one is set Small).

• POLAR12 – nodes on water set Flying, added West Exit to the only "Any" node, and one link for flying units.

• POLAR13 – nodes on water set Flying, added North Exit to the only "Any" node, and two links for flying units.

= TFTD Routes Fixes =

My fixes to XCom: TFTD routes: [[File:Tftd_routes.zip]]

As for now, the package contains only maps and routes of:

• Alien subs,

• Xcom ships,

• Alien Artifact Site (both phases),

• Alien Base (both phases),

• Cargo Ship.

Basic premises:

1. Exits (N/S/W/E) should exist on all terrain and subs maps (in the original game, they do not exist on sub maps, except UFO04 and UFO05).

2. A sufficient number of spawn nodes for all units (including large ones) must exist on maps. In the unmodified game there are too few of them.

3. If a given node is marked "Small", then all links going from it and coming to it may not be marked for "Any" units.

4. Nodes on eastern and southern borders of the map cannot be marked "Any", they are for small units only. The only exception is NW part of Hangars.

5. Isolated not-spawn nodes should be deleted or linked to others to make a net.

Notice: TFTD is known for a huge number of programmers' bugs and errors. There is so few spawn points on some maps in the unmodified game that some alien units cannot be rendered at all. And there is almost no places for large Aliens.

This should not be so. The number of spawn nodes for Xcom units should not be less than 26 (the highest number of soldiers in the ship with maximal capacity). The number of spawn nodes for non-Xcom units should exceed their maximal number ca. 1.5 - 3 times. Only then they will be posiotioned randomly! As the maximal number of them is 40, there sould not be less than 60 spawn nodes on the whole battlescape. Note that this is the number of expected spawn nodes on maps like CARGO01. In the original game there is only 24 spawn nodes there, so more than twice as much as there should.

This is why some of RMP files have been changed drastically.

Other routes fixes:

• Links between nodes have been checked if set for proper distances (and corrected if necessary).

• UFO04 - One (no spawn) node added to make a ring round the sub. A link added to let aliens use the stairs. A link 2-14 through a wall has been removed.

• UFO05 – Two nodes added on Level 3 for symmetry.

• UFO06 – Two nodes moved in order to make place for large units to spawn. 5 nodes for spawning large units and a path for them to exit the sub has been prepared. No more immobile Xarquids in walls and stairs!

• UFO07 – Added nodes in unused places of the sub. 8 nodes for spawning large units and a path for them to exit the sub has been prepared.

• GRUNGE04 – In the unmodified game there is only 11 Xcom spawn points in the alien colony. It is too little – note that in Alien Base there is 14 Xcom spawn points in one access module, and in UFO:EU there is 18 Xcom spawn points in one module. The unmodified map of Cargo Ship offers 26 nodes for XCom. Now, thanks to 2 additional Xcom spawn points, it is possible to have the maximum number of 26 Xcom units in the alien colony (if there are two access modules in it).

• ALART: 07, 09, 10, 11 – More spawn nodes added in order to give a chance for all aliens to appear.

• GRUNGE: 01, 03, 06, 09, 10, 11, 12, 13, 14, 15, 16 – More spawn nodes added in order to give a chance for all aliens to appear.

• Alien Base (ENTRY, A_BASE) – Spawn nodes not changed as there is enough of them, but added some links and not-spawn nodes in hidden places. Spawn net for commanders in the synomium room is isolated like in the unmodified game in order to prevent them from moving out (unless panicked).

• CARGO: 01, 02 – The total number of spawn points increased very much. No more lacking Triscenes!

MAP fixes

Most changes have no visible effect but may correct subtle bugs like in lines of sight.

• ALART: 07, 09, 10, 11 - Restored missing ground tiles.

• ALART10 – In the NW corner of the pyramid (lev1), corrected the western wall which was mistaken as contents; removed unnecessary pillars (as contents) from the other corners (cf. other pyramids on ALART maps).

• GRUNGE - Various ground titles and walls corrected (especially GRUNGE15 where lots of walls are missing in the original file). The alternative map of Synomium (probably never being used by the game) has also been corrected (walls have been restored on the place of buggy doors).

• ENTRY03 – Repaired the alien structure, level 2 (an incorrectly placed northern wall).

• A_BASE – Some corners are no longer impassable. 01 – The lift between 1 and 2 level repaired. 03, 05, 09, 11, 13, 14 – holes in the ground repaired.

MORE TO COME!

File:Tftd routes.zip

2013-02-03T19:47:46Z

Sherlock: ====== TFTD Patches ====== As for now, the package contains only maps and routes of: • Alien subs, • Xcom ships, • Alien Artifact Site (both phases), • Alien Base (both phases), • Cargo Ship.

====== TFTD Patches ======

As for now, the package contains only maps and routes of:
• Alien subs,
• Xcom ships,
• Alien Artifact Site (both phases),
• Alien Base (both phases),
• Cargo Ship.

User:Sherlock

2013-02-03T19:42:20Z

Sherlock: /* TFTD Spawn Points */

User:Sherlock

2013-02-01T13:59:34Z

Sherlock: /* Number of Spawn Points */

User:Sherlock

2013-02-01T13:59:06Z

Sherlock: /* Spawn Points in UFO:EU */

File:Eu routes.zip

2013-02-01T13:17:36Z

Sherlock: uploaded a new version of "File:Eu routes.zip"

Patches to UFO:EU routes

File:Eu routes.zip

2013-02-01T13:12:07Z

Sherlock: uploaded a new version of "File:Eu routes.zip": Fixed routes of all UFO:EU maps that needed fixing. The patch is complete, further changes are possible only to missed errors.

Patches to UFO:EU routes

User:Sherlock

2013-02-01T13:10:31Z

Sherlock: /* UFO:EU Routes Fix */

User:Sherlock

2013-01-31T20:23:32Z

Sherlock: /* Number of Spawn Points */

File:Eu routes.zip

2013-01-31T20:18:45Z

Sherlock: uploaded a new version of "File:Eu routes.zip": Fixed routemaps for Alien Ships in UFO:EU. Mostly minor edits.

Patches to UFO:EU routes

User:Sherlock

2013-01-31T20:17:22Z

Sherlock: /* UFO:EU Routes Fix */

File:Eu routes.zip

2013-01-31T17:18:11Z

Sherlock: Patches to UFO:EU routes

Patches to UFO:EU routes

User:Sherlock

2013-01-31T17:17:09Z

Sherlock:

User:Sherlock

2013-01-31T17:15:52Z

Sherlock:

Talk:Triscene

2013-01-31T12:37:23Z

Sherlock:

For some reason, Triscenes may be present in UNITREF.DAT but not seen in the tactical game. It may be a game bug, and one of reasons for which they are so rare in some campaigns. See [[File:Nstm.zip]] savegames for testing, explanation inside the archive.

[[User:Sherlock|Sherlock]] 20:27, 30 January 2013 (EST)

:I would guess this is down to a shortage of spawn points.

:Not all route nodes work as spawn points. Of those that do, many have restrictions placed on them so that they only accept certain types of units (eg, if a node is too close to a wall, or in an enclosed area, it might not be able to support large four-tile units).

:The Triscenes are near the end of the unit list, so by the time the game gets around to spawning them, those places they could've gone have already been used up by their smaller alien brethren (nodes can't be flagged as "large units only"). With nowhere to go, they simply don't appear.

:You can actually make a killing out of node shortages during base defence. If yours lacks enough nodes to place the alien forces after your own, then some (or all) of the aliens DON'T get placed, and so you've got a much easier battle on your hands. But - and this is a big "but" - that doesn't stop you from recovering all their weapons when you win!

:-  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 02:10, 31 January 2013 (EST)

Yes, and no. As MapView shows, the Cargo00 terrain (used for the first part of a cargo terror mission) contains 24 spawn points in total (in RMP), of which 3 are "any" (all on the second level), and 1 is "flying" (4th level); the other 20 spawn points are "small" (13 on the 1st level, 3 on the 2nd, 1 on the 3rd, and 3 on the 4th level of the map). So, the rmp file is buggy as does not give enough spawn points. Both the total number of spawn points and especially the number of spawn points for large units is too small.

In the first example given in my archive (1\GAME_4) we have 2 Aquatoids, 6 Tasoths, 3 Bio-Drones, 5 (invisible) Triscenes, 1 Xarquid and 11 Civilian Males. They all would need 28 spawn points, including 6 for big units (1 Xarquid and 5 Triscenes). None of the units is flying, so there is only 23 free spawn points. Indeed, only 23 units are spawned. This explains why 5 Triscenes are not seen in the game, if we assume that they are placed last.

But in the 2nd example (2\GAME_5) we have 2 Aquatoids, 6 Tasoths, 3 Bio-Drones, 1 visible Triscene and 3 invisible ones, 1 Xarquid, 11 visible Civilian Males and 1 invisible one, so 28 units (xcomutil.exe shows only visible units why X-Com Hack v3.1 shows all units, also the invisible ones). So, 24 units have spawned even if only 23 spawn points are available. Note that in this save game 23 small units are spawned like in the previous one, and they are exactly the same types of units - but, in addition, 1 Triscene can somehow be spawned as well. Why?

Conclusions: (1) Sometimes the game can place at least one additional unit even if no span points are left (and sometimes it cannot), (2) RMP files of TFTD maps are buggy as having too small number of spawn points. I am just working on a patched versions.

[[User:Sherlock|Sherlock]] 07:21, 31 January 2013 (EST)

Oops, Bio-Drones can fly! This can explain the point (1).

Talk:Triscene

2013-01-31T12:21:33Z

Sherlock:

User talk:Morgan525

2013-01-31T10:28:48Z

Sherlock: /* Incorrect Calculation of Remaining Stores Capacity */

=Questions&Feedback=
Any questions or feedback one may have.... (please be sure to leave a signature: "~" three times in a row, four to time-and-date stamp it.)

'''FYI: I've created a new [[UFOextender|UFO Extender page]]. If you are having a problem on this, please use the discussion page located there. If your message is about UFO Extender, you can leave it here but I may start copying it to the UFO page and leaving my reply there.'''

== Decompiled accuracy algorithm? ==
Hi Morgan/Tycho

Is the algorithm you describe above, what you have decompiled from the standard game? Or is it a variant for UFOExtender? Great news if you have decompiled what the game actually uses - I will need to check some of my firepower calculations to make sure they are still in line with the algorithm.

cheers,
[[User:Spike|Spike]] 09:37, 30 June 2012 (EDT)

''It is an extender version of the original formula if one chooses to enable it. The original is the one that has been noted already: [1+(3/UFOsize)]/2 * Weapon Accuracy ... UFO sizes going from 5 for very small to 1 for very large. The calculation starts at offset 0x446DCD of the CE version. The original UFO accuracy algorithm is a flat 60% chance to hit despite the difficulty level (and no penalty for the Xcraft being in cautious mode.)''

[[User:Morgan525|Tycho]] 19:23, 30 June 2012 (EDT)

== Question on new Installation ==

Going through the same steps from the UFO Extended page.

However every time I try to launch through Steam or within the installation file I crash. I am wondering if it's because the newer versions of UFO extender here: http://www.ufopaedia.org/index.php?title=File:UFOLoader.zip is just a patcher.dll file.[[User:Lowpro|Lowpro]] 21:22, 3 October 2012 (EDT)
:''You will need to download the full version and then download the latest patch file. Follow the link on my page to the download section. Download both files, extract the full version into your game folder, then extract the patch into the same folder and choose 'yes' to overwrite the current file.-'' [[User:Morgan525|Tycho]] 22:44, 3 October 2012 (EDT)

When I try to launch the game through Steam, I crash (screenshot of the error http://i388.photobucket.com/albums/oo324/chipkimble/XCOMerror_zps7c86e23e.png) . When I choose the the "Launch Windows 9x/XP Version", I crash. When I drag-and-drop the "UFO Defense.exe" over my "dosbox.exe" I crash. I do this because previously I used the UFO Extender steps found here http://forums.steampowered.com/forums/showthread.php?t=1146530 and part of launching without crashing meant I had to drag and drop the UFO Defense.exe file. However with that particular 2010 version I'd crash as soon as I researched some live aliens (be it researching a Medic or a Soldier etc)I'm trying to play catch-up at the moment with troublefixes but can't find a golden one yet. Thanks again! -[[User:Lowpro|Lowpro]] 20:22, 4 October 2012 (EDT)
:''You should be using v1.28 and patch 1.28.3. Extender doesn't work in DOS and can't be run through DOSbox, but I don't think this is your problem. Using within the steam framework requires some modifications to the steam shortcut and may require other changes that I don't know about. Some people choose to copy the Windows' version to a folder and run it outside of steam. Don't forget that the new INI only has a basic configuration: You might check that it is set to run D3D for video. I can't offer much support integrating into the steam interface because I don't use it and don't know it. If you want to run the game in a stand-alone folder, I can definitely help. If you want to run through steam, you might be better going to the strategycore topic on UFO Extender [http://www.strategycore.co.uk/forums/topic/10013-ufo-extender-128/]and posting your problem there. Several members say that have gotten it or TFTD Extender to work on their systems. I belive there are several discussions on getting the Extenders to work through Steam on the steam forums as well.-'' [[User:Morgan525|Tycho]]
''Disable the 'skip intro' in the video section and see if the Extender will run. The crash on researching a medic is a known bug for which no solution has been found as yet. - -''[[User:Morgan525|Tycho]]

== Source ==

Hi Tycho

Do you make the source code for TFTD Extender and UFO Extender available somewhere? I'm interested in seeing if I can help to hunt down bugs / develop new features. Cheers, [[User:Spike|Spike]] 08:23, 4 October 2012 (EDT)
:''I just uploaded a new version of the UFOExtender source files to Seb's list.- -''[[User:Morgan525|Tycho]] 06:04, 6 October 2012 (EDT)
:''Source code for TFTDExtender is now available from my user page. -[[User:Morgan525|Tycho]]''

== How to start modifying the game code ==

I like some of the changes made in the UFO extender but dislike others. I'm also running X-Com through DOSbox so it's a moot point anyway. Essentially I'd like to be able to make modifications to the game - like fixing the dismantled structure bug - myself. Where should I start? I have some experience with object oriented programming through languages like C# (most familiar) and Java.

[[User:Juke|Juke]] 21:04, 16 October 2012 (EDT)

:''Your first step is going to be to become very familiar with Disassembly and Disassemblers. Most people use IDA. Then your going to have to be able to understand the language itself. Take a look at the few examples on my page and see what it looks like. That code comes from the CE version, the DOS version doesn't disassemble as well (at least with any free dissassembler that I've found). [[User:Morgan525|Tycho]] 23:24, 16 October 2012 (EDT)''

I am running the game on steam with the DOSBox. Will I still be able to make changes to the source code? Thanks for the info btw.
[[User:Juke|Juke]] 22:03, 28 October 2012 (EDT)

:''I started using the DOS version under DOSbox and making simple changes to the data points via a hex editor. However, it is really hard to do more than that.
:''The problem is knowing where to make changes since no free program is able to disassemble the DOS version well. For that reason, I switched to the Windows version.''

== Shifting 5 shot laser mod to other weapons ==

Is there any easy way to shift the 5 shot mod that's currently on the heavy laser on to other weapons? I plan on getting the source code and working on it a bit (it's been years since I've touched assembly, I mostly code in C# now), but it'd be helpful to have a clue of where to start looking. I'd love to contribute to the project as well. [[User:KingMob4313|KingMob4313]] 09:27, 17 October 2012 (EDT)
:''I'm sure it can be done. I focus on providing content that will enhance the challenge of the game from a somewhat logical viewpoint without making changes just to make the game harder. The source code for Extender is available and mostly written in C++ so you shouldn't have much trouble understanding it. You will need a disassembler, such as IDA, for the actual game executable and be familiar with how to decipher the tangled mess of assembly code that IDA provides. For some features, I can write the code in C++ but, for a lot of fixes, I find writing in assembly much easier to insert into the proper subroutines. - [[User:Morgan525|Tycho]] 09:54, 17 October 2012 (EDT)''
::I should have just read some of the above responses, I am sorry. I will take your advice and pick up the disassembler and try to familiarize myself with the code a bit. Seems that everything works via a hook-system, where it waits for the calls to the subroutines and replaces it, correct? In any case, I appreciate the quick answer. [[User:KingMob4313|KingMob4313]] 12:30, 17 October 2012 (EDT)
:''The hardest part of familiarizing youself with the code is that the subroutines and variables are just offsets with no identifiers. If you take the time to match offsets to labels given in the xcom.h file (in the Extender source) you can manually transfer the labels yourself. This will make analyzing the code much easier. - [[User:Morgan525|Tycho]] 20:07, 17 October 2012 (EDT)''

== We're all... feeling... so... sleepy ==

Hi Tycho

Well, I was not expecting that! Your TSL-firing Hallucinoids just kicked my *ss on a Superhuman Colony Assault. They kept firing their TSL-like built in weapons - in fact it looks like it's an auto burst TSL? - right into the transport door. And I kept popping another guy out of the door to grab the bodies outside and take out the Tasoth with a TSL I presumed was out there. I could never see the Tasoth, just some stupid Hallucinoid floating around - and they're never a threat, right? Wrong!

Brilliant, in one stroke you have breathed new life into a previously-ignored enemy, making it as frightening as it always should have been. I hope you don't mind me adding a slight spoiler to the Bug Fixes section - if you do, feel free to revert it so you can surprise others like you surprised me. :) Cheers, [[User:Spike|Spike]] 18:46, 21 October 2012 (EDT):

:''Hehehe. >;) No, its not autofiring but the Hallucinoid has a high reaction score and the cost to fire their weapon is 33%. However, they don't often move so they always have most of their TUs. Now that they have a valid range weapon, they are extemely deadly in outdoor settings. Indoors, they tend to stun themselves too often. I'm thinking they might need to have their immunity to stun increased or build in an exception into the alien spawn routine that turns off their TSL attack indoors.-[[User:Morgan525|Tycho]] 19:53, 21 October 2012 (EDT)''
:: Ah, good explanation, thanks. Yes I think it would be a good idea to increase their Freeze resistance considerably. After all they are (now) the definitive freeze-using monster from the deep. As a four square unit they will take extra damage from their own attack, approaching 3-4x at point blank, so think it would be fine to give them a very high immunity, maybe take only 20% damage from Freeze. Or even 10% / completely immune. In fact it's probably simpler just to say they are immune (0%). [[User:Spike|Spike]] 20:50, 21 October 2012 (EDT)

== Bugs and wishes :o) ==
I am using your extender and it is great thing! I am using it together with modiffied UFO Defense.exe that uses MP3play.dll to play MP3 files because the routine you have implemented in loader pause the game every time the music is changing. The MP3play.dll doesn´t do that and is able to play intro music in MP3 as well. So I have now the best version ever ;) because I moddified the music by Lorcan to synchronize it with the intro, so I have the intro with MP3s instead of MIDs :)
But I have found some little problems with the game. I have found that when I ended the tactical mission and when the returned to the geoscape the game shows me the first screen line garbled in some windows. When I open "Build new facilities" window there is some bug at the top of the screen and also in the window noticing me there is terror somewhere. The first line of this window is missing everytime (compared with the original DOS UFO) in the Windows (collectors edition) version. So it is the bug in the CE version, but can you repair it by the loader?

----

And - sometimes - the game crashes to me after the second move (maybe because I have set on "First move crash bug" on, if I have it set off it sometimes crashes on the firts move :) I don´t know exactly the reason when it happenings but I have an idea :) What about to implement the AUTO save option to a folder named e.g. AUTO which will be automaticaly saved before you turn at the first time (before the battlescape appear after you equip your mens). This will temporarily evade that bug, but if you can find what is hapenning, surely the better way is to fix that bug :)
I hope I did´t made some chaos in messages here, I am newbie here, and I haven´t found another way how to contact you.
Thank you very much!
Lukas
Czech Republic
I will write my reports to here..--[[User:ElfKaa|ElfKaa]] 19:30, 01 January 2013 (EDT)

== Incorrect Calculation of Remaining Stores Capacity ==

You seem to have removed my text from [[Talk:TFTDExtender]], compare http://www.ufopaedia.org/index.php?title=Talk%3ATFTDextender&action=historysubmit&diff=44262&oldid=44261.
Was it anything wrong with that text? Or you just moved it to another article?
[[User:Sherlock|Sherlock]] 17:24, 30 January 2013 (EST)

:''This is already reported under 'Base Storage Anomalies' in the 'Known Bugs' for Enemy Unknown. - [[User:Morgan525|Tycho]]''

Hmmm... I'm not sure. The information given there is general. There is a more detailed discussion under [[Talk:Base_Stores#Base_Stores_Anomalies]]. However, rounding/truncating is pointed there as the main reason for displaying anomalies. In the same time, if my suspection is correct, the reason may also be different. If you unload craft, you may exceed the storage limit, for example, 50. The actual storage space may be, for example, 56. It is counted correctly but shown incorrectly as 50. Now if you load your craft, you may free, say, 2 places of storage capacity. The game will count the total space correctly as 54 (the result: "insufficient space"), but the space will be shown as 48. It is so not because of rounding but because the game engine took the shown incorrect value of 50 as actual, and lowered it by 2.

In other words: the game cannot add while it can still subtract. So, the reason (of the described behaviour) is completely different than rounding. When the game engine shows the storage space as 50 while it actualy exceeds the limit, and next you take some items from the storage, the game will subtract the taken space from the shown space of 50. The result is that it shows 48 while it is 54 for real.

I would suggest to check it and, if it is true, to add a note on this somewhere, maybe under [[Talk:Base_Stores#Base_Stores_Anomalies]]. Besides, this error (if works as suggested) should not be very hard to correct with extenders... It should be enough to compare the shown storage capacity with the actual capacity, and if needed, to correct the shown value. As for now, TFTDextender does not offer this. This is why I have placed my note on TFTDextender talk page.

BTW, have you looked at [[Talk:Known_Bugs_%28TFTD%29#Disappearing_Triscenes]] yet? It seems to me that this is a not-yet-reported bug of the game.

[[User:Sherlock|Sherlock]] 05:28, 31 January 2013 (EST)

== TFTDextender 1.61 p2 ==

On my computer (Win XP Pro), this version of dll hangs the game at the beginning of the tactical part. p1 works all right.

[[User:Sherlock|Sherlock]] 20:40, 30 January 2013 (EST)

:''The answer to this is already noted on the post with the download in the strategycore forums and as a reply to the first report of the error. - [[User:Morgan525|Tycho]]''

User talk:Morgan525

2013-01-31T01:40:40Z

Sherlock: /* TFTDextender 1.61 p2 */

=Questions&Feedback=
Any questions or feedback one may have.... (please be sure to leave a signature: "~" three times in a row, four to time-and-date stamp it.)

'''FYI: I've created a new [[UFOextender|UFO Extender page]]. If you are having a problem on this, please use the discussion page located there. If your message is about UFO Extender, you can leave it here but I may start copying it to the UFO page and leaving my reply there.'''

== Decompiled accuracy algorithm? ==
Hi Morgan/Tycho

Is the algorithm you describe above, what you have decompiled from the standard game? Or is it a variant for UFOExtender? Great news if you have decompiled what the game actually uses - I will need to check some of my firepower calculations to make sure they are still in line with the algorithm.

cheers,
[[User:Spike|Spike]] 09:37, 30 June 2012 (EDT)

''It is an extender version of the original formula if one chooses to enable it. The original is the one that has been noted already: [1+(3/UFOsize)]/2 * Weapon Accuracy ... UFO sizes going from 5 for very small to 1 for very large. The calculation starts at offset 0x446DCD of the CE version. The original UFO accuracy algorithm is a flat 60% chance to hit despite the difficulty level (and no penalty for the Xcraft being in cautious mode.)''

[[User:Morgan525|Tycho]] 19:23, 30 June 2012 (EDT)

== Question on new Installation ==

Going through the same steps from the UFO Extended page.

However every time I try to launch through Steam or within the installation file I crash. I am wondering if it's because the newer versions of UFO extender here: http://www.ufopaedia.org/index.php?title=File:UFOLoader.zip is just a patcher.dll file.

[[User:Lowpro|Lowpro]] 21:22, 3 October 2012 (EDT)

:''maybe. You will need to download the full version and then download the latest patch file. This is a problem when people make links directly to the file and not the download page. Follow the link on my page to the download section. Download both files, extract the full version into your game folder, then extract the patch into the same folder and choose 'yes' to overwrite the current file. If your still getting an error, you'll need to contact the person who wrote the UFO Extended page. You might need to configure your steam shortcut in some way.-'' [[User:Morgan525|Tycho]] 22:44, 3 October 2012 (EDT)

Thanks for the reply. I'll give you my rundown and maybe we can track down my issue. I followed your page but again I'm taken to the File:UFOLoader.zip page. I downloaded the August 6th version which has: COPYING, ENGLISH.DAT, patcher.dll, UFOExtender.ini and its Readme.txt file,UFOLoader.exe, and a version txt. After I extract that to my XCOM installation folder I also download the latest patcher.dll file (The September 27th version) and overwrite.

When I try to launch the game through Steam, I crash (screenshot of the error http://i388.photobucket.com/albums/oo324/chipkimble/XCOMerror_zps7c86e23e.png) . When I choose the the "Launch Windows 9x/XP Version I crashs"

When I drag-and-drop the "UFO Defense.exe" over my "dosbox.exe" I crash. I do this because previously I used the UFO Extender steps found here http://forums.steampowered.com/forums/showthread.php?t=1146530 and part of launching without crashing meant I had to drag and drop the UFO Defense.exe file. However with that particular 2010 version I'd crash as soon as I researched some live aliens (be it researching a Medic or a Soldier etc)
I'm trying to play catch-up at the moment with troublefixes but can't find a golden one yet.
Thanks again! -[[User:Lowpro|Lowpro]] 20:22, 4 October 2012 (EDT)
:''You should be using v1.28 and patch 1.28.3. Extender doesn't work in DOS and can't be run through DOSbox, but I don't think this is your problem. Using within the steam framework requires some modifications to the steam shortcut (setting it to run UFOloader.exe and not UFO Defense.exe). Don't forget that the new INI only has a basic configuration: You might check that it is set to run D3D for video. I can't offer much support integrating into the steam interface because I don't use it and don't know it. If you want to run the game in a stand-alone folder, I can definitely help. If you want to run through steam, you might be better going to the strategycore topic on UFO Extender [http://www.strategycore.co.uk/forums/topic/10013-ufo-extender-128/]and posting your problem there. Several members say that have gotten it or TFTD Extender to work on their systems. I belive there are several discussions on getting the Extenders to work through Steam on the steam forums as well.-'' [[User:Morgan525|Tycho]]

''Disable skip intro in the video section and see if the Extender will run.-[[User:Morgan525|Tycho]]''

''The occasional crash on researching a medic is a known bug for which no solution has been found as yet. - -''[[User:Morgan525|Tycho]] 02:14, 9 October 2012 (EDT)

== Source ==

Hi Tycho

Do you make the source code for TFTD Extender and UFO Extender available somewhere? I'm interested in seeing if I can help to hunt down bugs / develop new features. Cheers, [[User:Spike|Spike]] 08:23, 4 October 2012 (EDT)

:''I'm getting to it. Tonight is the first time I have been able to look at the code. I did manage to find the problem with the loader and the game executable. -''[[User:Morgan525|Tycho]]

''I just uploaded a new version of the UFOExtender source files to Seb's list.- -''[[User:Morgan525|Tycho]] 06:04, 6 October 2012 (EDT)

''Source code for TFTDExtender is now available from my user page. -[[User:Morgan525|Tycho]]''

== How to start modifying the game code ==

I like some of the changes made in the UFO extender but dislike others. I'm also running X-Com through DOSbox so it's a moot point anyway. Essentially I'd like to be able to make modifications to the game - like fixing the dismantled structure bug - myself. Where should I start? I have some experience with object oriented programming through languages like C# (most familiar) and Java.

[[User:Juke|Juke]] 21:04, 16 October 2012 (EDT)

Your first step is going to be to become very familiar with Disassembly and Disassemblers. Most people use IDA. Then your going to have to be able to understand the language itself. Take a look at the few examples on my page and see what it looks like. That code comes from the CE version, the DOS version doesn't disassemble as well (at least with any free dissassembler that I've found). [[User:Morgan525|Tycho]] 23:24, 16 October 2012 (EDT)

I am running the game on steam with the DOSBox. Will I still be able to make changes to the source code? Thanks for the info btw.
[[User:Juke|Juke]] 22:03, 28 October 2012 (EDT)

:''I started using the DOS version under DOSbox and making simple changes to the data points via a hex editor. However, it is really hard to do more than that.
:''The problem is knowing where to make changes since no free program is able to disassemble the DOS version well. For that reason, I switched to the Windows version.''

== Shifting 5 shot laser mod to other weapons ==

Is there any easy way to shift the 5 shot mod that's currently on the heavy laser on to other weapons? I plan on getting the source code and working on it a bit (it's been years since I've touched assembly, I mostly code in C# now), but it'd be helpful to have a clue of where to start looking. I'd love to contribute to the project as well. [[User:KingMob4313|KingMob4313]] 09:27, 17 October 2012 (EDT)
:''I'm sure it can be done. I focus on providing content that will enhance the challenge of the game from a somewhat logical viewpoint without making changes just to make the game harder. The source code for Extender is available and mostly written in C++ so you shouldn't have much trouble understanding it. You will need a disassembler, such as IDA, for the actual game executable and be familiar with how to decipher the tangled mess of assembly code that IDA provides. For some features, I can write the code in C++ but, for a lot of fixes, I find writing in assembly much easier to insert into the proper subroutines. - [[User:Morgan525|Tycho]] 09:54, 17 October 2012 (EDT)''
::I should have just read some of the above responses, I am sorry. I will take your advice and pick up the disassembler and try to familiarize myself with the code a bit. Seems that everything works via a hook-system, where it waits for the calls to the subroutines and replaces it, correct? In any case, I appreciate the quick answer. [[User:KingMob4313|KingMob4313]] 12:30, 17 October 2012 (EDT)
:''The hardest part of familiarizing youself with the code is that the subroutines and variables are just offsets with no identifiers. If you take the time to match offsets to labels given in the xcom.h file (in the Extender source) you can manually transfer the labels yourself. This will make analyzing the code much easier. - [[User:Morgan525|Tycho]] 20:07, 17 October 2012 (EDT)''

== We're all... feeling... so... sleepy ==

Hi Tycho

Well, I was not expecting that! Your TSL-firing Hallucinoids just kicked my *ss on a Superhuman Colony Assault. They kept firing their TSL-like built in weapons - in fact it looks like it's an auto burst TSL? - right into the transport door. And I kept popping another guy out of the door to grab the bodies outside and take out the Tasoth with a TSL I presumed was out there. I could never see the Tasoth, just some stupid Hallucinoid floating around - and they're never a threat, right? Wrong!

Brilliant, in one stroke you have breathed new life into a previously-ignored enemy, making it as frightening as it always should have been. I hope you don't mind me adding a slight spoiler to the Bug Fixes section - if you do, feel free to revert it so you can surprise others like you surprised me. :) Cheers, [[User:Spike|Spike]] 18:46, 21 October 2012 (EDT):

:''Hehehe. >;) No, its not autofiring but the Hallucinoid has a high reaction score and the cost to fire their weapon is 33%. However, they don't often move so they always have most of their TUs. Now that they have a valid range weapon, they are extemely deadly in outdoor settings. Indoors, they tend to stun themselves too often. I'm thinking they might need to have their immunity to stun increased or build in an exception into the alien spawn routine that turns off their TSL attack indoors.-[[User:Morgan525|Tycho]] 19:53, 21 October 2012 (EDT)''
:: Ah, good explanation, thanks. Yes I think it would be a good idea to increase their Freeze resistance considerably. After all they are (now) the definitive freeze-using monster from the deep. As a four square unit they will take extra damage from their own attack, approaching 3-4x at point blank, so think it would be fine to give them a very high immunity, maybe take only 20% damage from Freeze. Or even 10% / completely immune. In fact it's probably simpler just to say they are immune (0%). [[User:Spike|Spike]] 20:50, 21 October 2012 (EDT)

== Bugs and wishes :o) ==

Hi Tycho

I am using your extender and it is great thing! I am using it together with modiffied UFO Defense.exe that uses MP3play.dll to play MP3 files because the routine you have implemented in loader pause the game every time the music is changing. The MP3play.dll doesn´t do that and is able to play intro music in MP3 as well. So I have now the best version ever ;) because I moddified the music by Lorcan to synchronize it with the intro, so I have the intro with MP3s instead of MIDs :)

But I have found some little problems with the game. I have found that when I ended the tactical mission and when the returned to the geoscape the game shows me the first screen line garbled in some windows. When I open "Build new facilities" window there is some bug at the top of the screen and also in the window noticing me there is terror somewhere. The first line of this window is missing everytime (compared with the original DOS UFO) in the Windows (collectors edition) version. So it is the bug in the CE version, but can you repair it by the loader?

----

<s>The other thing it does to me that when I activate Animations Speed=1 in the ini file the arrow showing above my men slowdown the animation, but many other things like UFO Power device or the UFO navigation screens goes even that set on very fast. And there appears a bug that cause the smokes didn´t probbably stoped animation at all when the bullets go through it or a man is walking through - it looks like it goes surrounded by some box (it looks to me it is the other (not correct) frame of the smoke displayed behind the man or bullet).
Can you correct these bugs, please?</s>(corrected in version 1.29 using battlescape speed settings)

----

And - sometimes - the game crashes to me after the second move (maybe because I have set on "First move crash bug" on, if I have it set off it sometimes crashes on the firts move :) I don´t know exactly the reason when it happenings but I have an idea :) What about to implement the AUTO save option to a folder named e.g. AUTO which will be automaticaly saved before you turn at the first time (before the battlescape appear after you equip your mens). This will temporarily evade that bug, but if you can find what is hapenning, surely the better way is to fix that bug :)
I hope I did´t made some chaos in messages here, I am newbie here, and I haven´t found another way how to contact you.
Thank you very much!
Lukas
Czech Republic
<s>
Underline:
I am new here and I don´t know if I could write here my qestion and feedback to UFOLoader that you made because I haven´t found any of your e-mail somewhere. If there is another way to contact you, can you please send me a message to here how can I contact you? Or put here please an email address or send me a message to lukop ("@") seznam.cz. Then you can delete my added message here..
Thank you!
</s>

I will write my reports to here..

--[[User:ElfKaa|ElfKaa]] 19:30, 01 January 2013 (EDT)

[[User:ElfKaa|ElfKaa]]

== UFOLoader ver. 1.29 Bugs ==

Hi Tycho

I have probably found some bug in new version of the UFOLoader.

It is very nice that the geoscape works fluently now with the Geoscape speed set to 1 but I think this cause problems with the game speed at all.

I tried to compare the game played with this speed settings on and off and I have noticed that there are less detections of UFOs with the settings on then with off.

The other not good behavior happend to zoom by mouse - with ON it is very slow if you have 5 seconds mode, in 1 Day mode it is fluent.
I think - this could also moddifies the game heart speed so the first ufo is detected after few more days (it is very complicated to confirm that behavior, but you can try DOSBox UFO and see the difference and also it works better if you turn the Geoscape speed setting off.

The other thing is that the mouse affecting the speed of animations when is moving (but it does also in all previous versions) - it could be seen on the radar lines in the interception screen.

Can you please check the speed and the detection of UFOs? It seems to me that because of the speed modification the detection notification doesn´t appears so often and happening randomly.

Thank you very much!
Lukas
Czech Republic

--[[User:ElfKaa|ElfKaa]] 19:50, 01 January 2013 (EDT)
[[User:ElfKaa|ElfKaa]]

[[User:ElfKaa|ElfKaa]]

== Incorrect Calculation of Remaining Stores Capacity ==

Hello,

You seem to have removed my text from [[Talk:TFTDExtender]], compare http://www.ufopaedia.org/index.php?title=Talk%3ATFTDextender&action=historysubmit&diff=44262&oldid=44261. This is the text:

To reproduce this error, do as follows. (1) Place Ajax Launcher(s) on your craft. (2) Fill your stores with whatever you want. They should be full. (3) Rearm your craft, exchanging Ajax into D.U.P. Now your stores should be overloaded. (4) Stores free capacity indicator (on Bases screen) shows that there is some space left (ex. 48:50) but it is not true. To check it, just sum all the place taken with all your stored materials.

Indeed, even if "technically" you have free place in stores, you cannot unload your transporter, and if you try, you receive a message that there is no free space left.

Not sure if this is an original error either.

This file may be useful for testing: [[File:store_error.zip]]

[[User:Sherlock|Sherlock]] 05:51, 21 January 2013 (EST)

Was it anything wrong with that text? Or you just moved it to another article?

[[User:Sherlock|Sherlock]] 17:24, 30 January 2013 (EST)

== TFTDextender 1.61 p2 ==

On my computer (Win XP Pro), this version of dll hangs the game at the beginning of the tactical part. p1 works all right.

[[User:Sherlock|Sherlock]] 20:40, 30 January 2013 (EST)

Talk:Known Bugs (TFTD)

2013-01-31T01:31:04Z

Sherlock: /* Disappearing Triscenes */

==More Unconscious Bugs==

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

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

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

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

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

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

== Gill-men reported as Snakemen ==

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

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

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

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

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

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

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

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

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

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

[[User:Spike|Spike]] 05:47, 22 August 2009 (EDT)

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

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

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

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

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

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

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

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

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

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

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

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

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

Any objections? [[User:Magic9mushroom|Magic9mushroom]] 19:47, 25 August 2009 (EDT)

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

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

...and done! [[User:Magic9mushroom|Magic9mushroom]] 08:32, 26 August 2009 (EDT)

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

== Multi-part map ammo loss ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

:; Actually, 2.0 only resolves this issue in the case that you KILL everything in part 1. If you placed your guys in the exit zone and hit abort, you might still lose stuff. You definitely don't get the loot in this case. [[User:Jasonred|Jasonred]] 14:34, 27 April 2011 (EDT)

== Land missions reaction fire bug ==

This is an expansion of a bug known as [http://www.ufopaedia.org/index.php?title=Known_Bugs_%28TFTD%29#X-COM_Equipment_Glitches "X-COM underwater-only weapons fire on land missions"]. The bug may actually be more serious than that and it may extend to all present units.

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

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

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

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

: I wonder if it's like the Launch command for the Blaster/Disrupter Torpedo launcher, it may use its own routine that bypasses the normal snap attack? -[[User:NKF|NKF]] 13:59, 24 February 2012 (EST)
::I know that the shot Deep Ones fire when mind-controlled is NOT the shot they fire normally, so there certainly is some special code for their attack. [[User:Magic9mushroom|Magic9mushroom]] 00:52, 25 February 2012 (EST)
::The Celatid in Enemy Unknown had a special routine to make its shots have an arc and a limited range. This routine is based on the unit number. Since the Deep One replaced the Celatid in that spot, the Deep One wound up with the same form of attack. Whether or not this was intentional...?[[User:Morgan525|Tycho]] 23:21, 17 September 2012 (EDT)
::: I just looked at a TFTD Extender game save file from a game I was playing, using XcomUtil DIS, and I noticed the Deep Ones carrying Gauss Rifles. I like it! Is that part of your fix for the hold over Celatid acid spit grenade attack, Tycho? Or just some weird XcomUtil bug? [[User:Spike|Spike]] 04:24, 18 September 2012 (EDT)
::I put that into the unit generation routine when I eliminated the spit attack. It puts them closer to the image in the UFOpaedia. I had to use the gauss rifle since you can't access the image for the gun they are carrying in the article. However, they aren't actually carrying anything: I just set the hand image of the unit to the gauss rifle. It makes them look pretty bad@$$ in the battlescape.[[User:Morgan525|Tycho]]

== Female/Male voices ==

It seems nobody else has ever noticed that in TFD all of your aquanauts use a male sounding "scream" when they die as opposed to EU where men/women had different voices.

: Not really a bug, there's only the one scream clip and it's shared between them. Not sure why they did that considering it worked very well in UFO. [[User:NKF|NKF]] 01:40, 6 August 2012 (EDT)

== Reverting Gauss Craft Ammo Exploit, Exploit Section and Link ==

Hi Tycho / Morgan. I don't know if you intended to roll back my edits, but if so, we should probably discuss first, not least because they represent a fair amount of research time on my part, so if they are going to be moved off this page, I'd like them at least to be moved somewhere - even if it's back to my own page. I am going to revert the Gauss Craft Ammo stuff, but I've left alone your changes to the TFTD Extender section since it's only fair that that is 'yours', and a lot of your other changes. Also quite happy to discuss changes. We should keep in mind maintaining a ''neutral point of view'', as a primary goal of this wiki. That would also apply to the 'questionable logic' section (regardless of how it's capitalised). There's also a healthy historical debate on what's a bug / feature / exploit, so we should all try to respect the diversity of opinion on this too. Cheers, [[User:Spike|Spike]] 08:30, 16 September 2012 (EDT)
:Was the section deleted? I don't recall _intentionally_ deleting any part of anyone discussions. If I did, it was an accident and I'm sorry for the confusion. [[User:Morgan525|Tycho]] 03:16, 17 September 2012 (EDT)
:: Ah no worries! I thought it may well have been accidental - easily done if there are two edits in progress at the same time. The wiki engine is not great at detecting edit conflicts. I hope my 'restored' version still reflects your edits ok? [[User:Spike|Spike]] 15:30, 17 September 2012 (EDT)
:::To my recollection, the only change I made to the page was just to add a notation next to the issues that the Extender fixes. [[User:Morgan525|Tycho]] 23:22, 17 September 2012 (EDT)

I highly suspect you hit the rollback button by mistake. It's a one-click action and doesn't ask for confirmation and it gets actioned right away. Hmm, that's actually rather dangerous! -[[User:NKF|NKF]] 01:57, 18 September 2012 (EDT)

== And what about Research Tree Bugs? ==

There is an article on [[TRTBAG|how to avoid TFTD Research Tree Bugs]] in order to recover everything possible and to finish the game. However, the [[Research_(TFTD)|research tree]] has also bugs of a different kind. They do not harm in the mentioned sense (i.e. despite of them you may finish the game and learn about (almost) everything) but they make some parts of the game quite illogical. Where is the right place just for numbering them?

So, here is the list:

1. Only 4 new objects can be allowed to produce after finishing a research topic. If you already finished with Gauss Cannon, Sonic Oscillator and P.W.T. Cannon before, and now you have finished with New Fighter Flying Sub, you should get 5 new items to produce: Manta, Coelacanth/Gauss, Displacer/Sonic, Displacer/P.W.T., and P.W.Torpedo. However, because of this buggy limitation you can get only 4 of them, while the 5th one will appear only after finishing another research. The result: you have all that you need, and you still cannot start production, only because a stupid limitation (and incorrect construction of the research tree, see below). A bug or not?

2. Finishing of examination of a live alien does not lead to further examination of its body. This is a bug of the same type as bad physics of the game (and the lack of a difference between behaviour of various objects on the land and under the sea). What do our scientists do with dead bodies after the examination of live aliens? Eat them or what? The same bug is present in UFO EU. Hopefully it has been corrected in Apocalypse by X-COM series programmers - so, this is a real bug, worth to be noticed in the article.

3. And another logical inconsistency of the game. We will get information on some products of the alien technology only when we examine aliens' bodies. Presence of the products in our stores is not required. So, our scientists can make 1:1 copies of alien objects not even having seen them! So, we may get Aqua Plastics - but it will not help us with know anything about this product of the alien technology. But if we examine a corpse of a Deep One, somehow we will guess the exact structure of Alien Plastics, and then we will be able to duplicate this product even without comparing it with genuine Alien Plastics! Where is any sense in it? Do Deep Ones have written records inside their bodies how to make Aqua Plasics? It would be a bit more logical a situation if we could get information from live aliens. Or if the dead body of a Deep One were needed together with Aqua Plastics. But it is not so in the game.

4. Exactly the same logical inconsistency can be observed towards melee weapons. We can find a Vibroblade by an alien corpse, but it is all the same for us if we found it or not. But if we get a Calcinite Corpse, we will get a kind of enlightenment somehow! Not even having looked at the device itself, we will guess all details of its complex construction just looking at the corpse! The bug is not in the fact that we need the corpse but rather in the fact that we do not need the device which we examine.

5. One more example of miraculous illumination in our scientists' minds is Thermic Lance which they "invent" looking at the corpse of a Gill Man.

6. Yet more mysterious example of our scientists' genius is guessing all details of Heavy Thermic Lance without any help, and - naturally - without examining the device itself. Simply they guess its construction, and then - what a surprise! - it appears that the aliens have been able to invent exactly the same device!

7. A similar bug: you do not need to know anything about Zrbite in order to finish with Ion Armor. This is extremely strange as Zrbite is needed to produce Ion Armor. You must examine a live Deep One instead of Zrbite.

8. In order to produce (very buggy besides) Coelacanth/Gauss, you need to have examined New Fighter Flying Sub first. What is it for? Coelacanth cannot fly - or rather float, or move vertically. This is an obvious misconception in the game, one of the things which make it illogical. Why having examined all Gauss weapon is not enough to construct this tank? But it is just another type of Coelacanth. We know two other types from the beginning. All we needed to construct it was its weapon. The requirement of New Fighter Flying Sub is really stupid, and this is an obvious bug in the game. Moreover, this makes the tank totally useless. But when we finish with Manta, we will also be able to construct much better, "flying" tanks, Displacers. In this very moment Coelacanth (of each type) is outdated technology. And which is more, another proof that the requirement of having finished Manta examination in order to invent Coelacanth/Gauss is just a bug of the game (or: an involuntary result of programming the game) is the above-mentioned 4-product limit. If we remove the requirement of Manta being a prerequisite of Coelacanth/Gauss, we would never have an occasion to experience results of the limit.

9. Bombardment Shield is another element of the game which is completely useless. It is so because in order to start working on it, we have to have the Latest Flying Sub already examined. And this is the source of the problems. Namely, inventing of Bombardment Shield lasts rather long, and during this time we can build Leviathan. All we should know on T'leth, we learnt even before starting inventing the Latest Flying Sub (from Lobsterman Commander). And in order to build a Bombardment Shield, we would have to wait more than a month. What for? wouldn't it better just fly to T'leth and finish with the aliens? Just compare research trees of [http://grzegorj.orangespace.pl/xc/obrazki/tree1.png UFO:EU] and [http://grzegorj.orangespace.pl/xc/obrazki/tree2.png TFTD]. Grav Shield in UFO:EU is ready to be examined just after New Fighter Transporter (Lightning). And if it was similarly in TFTD (Bombardment Shield just after Hammerhead), everything would be OK. But it is not so, and this is why Bombardment Shield is more a curio than a real weapon.

10. In addition to this list: The extreme unconcern of the game programmers has resulted in PLENTY of errors on TFTD maps. Among others, objects that look like Examination Room (in Ufopedia), are recognized by the game engine as Alien Implanter or even something more bizarre (because of wrong data in *.MCD files). As a result, without patching the game or some hacker tricks we will never get Examination Room on a mission. And we will not be able to examine it.

[[User:Sherlock|Sherlock]] 11:51, 5 January 2013 (EST)

== Disappearing Triscenes ==

Sometimes Triscenes are generated in UNITREF.DAT but they are invisible in the tactical game (in the mission). For some reason, they are not counted as present. This way you can go through a whole campaign, not having seen this creature even once. An example is in the attached save games: [[File:Nstm.zip]]. See inside the archive for explanations. It is probably a game bug, not noticed so far.

[[User:Sherlock|Sherlock]] 20:31, 30 January 2013 (EST)

Talk:Triscene

2013-01-31T01:27:22Z

Sherlock: /* Disappearing Triscenes */

Talk:MISSIONS.DAT

2013-01-31T01:24:46Z

Sherlock: /* Non-scheduled Terror Missions */

Some questions [Zaimoni: now answered empirically]:
* What is going on with the start time for 0/0 on Research missions? The Jan 1999 one is always 2.5h, but I recently saw an Antarctica Research mission at 3d for 0/0.
* How consistently does the time to the next UFO react to a successful Battlescape game? (I just saw a Retaliation 1/1 go from 7Eh to 136h upon successful completion.)

--[[User:Zaimoni|Zaimoni]], 6:50 Sept 21 2006 CDT

I couldn't understand much of your research but it made me wonder about one question: is it possible to determine the amount of UFO missions and their types that you will see during a month (and also the areas?). Or are those set in a total random fashion?

If so this could be considered as spoilers but it could also be used for an article describing alien strategy on the field manual.

--[[User:Hobbes|Hobbes]] 18:39, 21 September 2006 (PDT)

MISSIONS.DAT is a spoiler, definitely. It stores the time (in 30-minute increments) for all non-Supply scheduled UFOs that have not arrived yet. While it won't tell you all of the UFOs arriving in the month, it will positively ID arrival time, mission, physical type, and race of each one in the queue. I'm in the middle of redocumenting it.

My current conjecture is that the 0..3 sequence indexes the "size" of the UFO. The legacy content just listing ufo-c coordinates is misleading (it seems to be enumerating the visible sequence of ufos), but I want to positively observe the entire sequence of ufo-c/ufo-sub-c pairs before updating.

At all times, the current mission types and areas are in MISSIONS.DAT...except for supply missions. You really want a Hyperwave Decoder covering each alien base you're harvesting. So far, Beginner and Superhuman schedule the same at the beginning of the months after Jan 1999: 1 Terror mission, one non-terror mission. I don't know the criteria for scheduling Retaliation missions. (I've never seen them show up except immediately after Battlescape missions, but that obviously isn't exhaustive.]

Particularly interesting: Battlescape messes with the arrival time of the next mission after the one you're cleaning up on. This needs more careful analysis (e.g., is it just mission completion?)

--[[User:Zaimoni|Zaimoni]], 22:35 Sept 21 2006 CDT

The increase in time to next UFO occurs either (or both) at shootdown, or at the start of the Battlescape mission. Since I used XCOMUtil interceptor with six soldiers for this test, I can't tell which one. No change between the beginning and the end of the Battlescape mission. [But a genuine Terrorship will happen soon enough...that gets a no-crew Interceptor and a full Skyranger.]

--[[User:Zaimoni|Zaimoni]], 23:51 Sept 21 2006 CDT
:After a shootdown, the next UFO for that mission is delayed between 1 and ~9 days ( the formula is 48+RAND()*400 half hours ). A retaliation mission will be scheduled if RAND()*100 < 4*(24-difficultyLevel).
:If RAND()*100 < (50-6*difficultyLevel), the retaliation mission will use the same zone as the shot UFO, else it'll be the zone containing the base the craft in coming from. The first UFO is scheduled in 100 half-hours (the value is taken from the table I speak of later at the bottom of this page).
:[[User:Seb76|Seb76]] 18:56, 12 July 2008 (PDT)
<hr>

I don't think I'll be continuing this savegame, but I just had a Feb 1999 that only generated a new Terror Mission. The other mission...not visible. [I may have messed it up — I did edit the Jan 1999 Terror mission from Europe to Southern Africa.]

--[[User:Zaimoni|Zaimoni]], 10:38 Dec 30 2006 CDT

== Retaliation ==

Zaimoni, I've been thinking about the comment about HWD's activating retaliation missions from the start. Are you able to check the mission types of the first couple of UFOs through mission.dat without editing the HWD stats onto the base? I'm not entirely convinced that retaliation missions are instigated by having a hyperwave decoder (stats or the module).

- [[User:NKF|NKF]]

: Yes, I can check (and have checked) that by hex editor. [It's a moderately different game with total information on arrival times and mission types...much easier to resume after a month or so hiatus.] I haven't tested with a game whose Hyperwave detection was edited.

: I normally save immediately after starting a new game to apply my custom soldier editor to the game. While I'm at it, I check MISSIONS.DAT. I have always gotten two missions: a Research mission in the same region as my starting base, and a terror mission with a decidedly non-uniform random distribution of location that I haven't bothered to try to analyze.

: I'm not sure whether there's a random component to getting a Retalation series scheduled by shooting down the first Research UFO, or whether it's just hypersensitive to some sort of detail. If the series is not significantly interfered with, the base defense mission would happen 2-3 weeks in.

: --[[User:Zaimoni|Zaimoni]], 3:23 Mar 20 2007 CDT

Just ran some quick checks, nothing too intensive.
* Editing hyperwave detection in a hex editor: no obvious effect, but would have to tweak the initial MISSIONS.DAT (move the Terror Act to within range) to be absolutely sure. The game does not transmogrify Research UFOs in real-time; I need to test Terror UFOs.
* Start a new game after abandoning one: race information is not cleared in MISSIONS.DAT, but other information is cleared. In particular, both ufo-c and subufo-c are overwritten to their defaults.

--[[User:Zaimoni|Zaimoni]], 23:11 Apr 11 2007 CDT

'''so''', the question which should be asked:

Is it too difficult to make an editor which changes the sequences? I dunno anything with hex-editors, programming, high level mathematics, etc. It would be interesting to have an opportunity to spawn multiple UFO everyday and not be able to shoot them all down as which is the case for the current mode of EU (and TFTD). The only thing that comes close to something of this current scenario is an inflitration mission where you have 5+ alien ships all at once and not having the capability to deal with them all. I dunno... i just wish having more tweaks to make it harder would be a good thing as opposite to just using editors to dull the technology of xcom to increase difficulty.

Six terror sites at once??? hell yeah! [[User:EsTeR|EsTeR]]

: It should be safe to create Retaliation acts and Terror acts by directly editing MISSIONS.DAT, there will be no internal consistency issues with other files. Editing existing entries in MISSIONS.DAT to other valid entries should be safe (note that not all mission types have been authoritatively mapped). Editing duration should be safe, but problems could happen with invalid races or UFO c/sub-c pairs. Creating other mission types will require counter-editing ACTS.DAT. I haven't specifically checked the behavior of ZONAL.DAT when spawning new acts.

: The ufo-c/ufo-sub-c pair 0/0 is always valid, at least.

: Research, Base, Terror, and Retaliation have fully documented ufo-c/ufo-sub-c pairs. I haven't done any verification at all for Abduction or Infiltration.

: Changing the relative durations between UFOs, time delays incurred when shooting down UFOs, or number of missions spawned per month, requires finding that information first. --[[User:Zaimoni|Zaimoni]], 10:16 Oct 17 2007 CDT

Just a note to add to this section lest I forget, and as late follow up to the notes that re on the page: back when I first got the idea that the first UFO was on a retaliation mission, I did not know that there was a 2% chance for every UFO to generate a retaliation mission. Armed with this knowledge, this is probably the sequence of events that happened to me at the time: I shot down the first UFO, recovered it and then got my base attacked. The 2% might've triggered then. This would very well the impression I had that UFOs could start on retaliation missions. They don't, but they can generate an attack. -[[User:NKF|NKF]] 03:10, 3 June 2010 (EDT)

== Alien missions data discovered in geoscape.exe [finally ;-)] ==

OK guys, here's a big one: alien missions data is located in the executable at offset 0x70E70 (gold edition) ; it starts with these values (all 16bit words):

.data:00470E70 structAlienMission <5, 1, 0, 12Ch>
.data:00470E70 structAlienMission <6, 1, 2, 104h>
.data:00470E70 structAlienMission <7, 2, 4, 12Ch>
.data:00470E70 structAlienMission 5 dup(<0FFFFh, 0FFFFh, 0FFFFh, 0FFFFh>)
...
It goes on for 64x4x2 bytes (7 mission types and possible data for additional 'supply' type mission).

Every mission type has 8 entries consisting of 4 words.
First word is the ship type, second is the number of ship of this type to spawn successively (each uses the same time counter), and 4th correspond to the time counter in [[MISSIONS.DAT]]. 3rd one is unknown for now.

The example below is for research mission: one small scout (type 5), then one medium scout (type 6) and finally 2 large scouts (type 7).
The time counter is calculated like this: time*RAND()+time/2.
Anyone care to hack the binaries to confirm this? [[User:Seb76|Seb76]] 10:58, 9 March 2008 (PDT)

: Time calculation looks good for those UFOs with randomized time (there are a few known exceptions). -- [[User:Zaimoni|Zaimoni]] 10:16 10 March 2008 (CDT)

: It would be very good to locate what controls fixed vs randomized times for the normal missions. -- [[User:Zaimoni|Zaimoni]] 10:59 13 July 2008 (CDT)

The 3rd word of missions is UFO_trajectory_type. It refers into table at address .data:00471070. So there are 10 types of trajectories possible, with maximum 8 waypoints.
.data:00471070 ufo_10_types_52___ dw 5 ; UFO_Waypoint_count
.data:00471070 dw 5, 0, 0, 1, 5, -1, -1, -1; UFO_Waypoint_Site
.data:00471070 dw 4, 3, 1, 1, 2, 0, 0, 0; UFO_Waypoint_Altitude
.data:00471070 dw 100, 74, 28, 47,100, 0, 0, 0; UFO_Waypoint_Speed
.data:00471070 dw 3000 ; Ground_Timer
--[[User:Volutar|Volutar]] 05:59, 14 April 2011 (EDT)

==Clarification pls==

- So all these missions, once started, will continue in the precise sequence no matter what?

:: Yes; only most of these tables have been verified by inspection of the savegame files in a hex editor, however. Infiltration has not. Matching the savegame file behavior against the in-game data Seb76 has located is tricky. -- [[User:Zaimoni|Zaimoni]]

- What about the whole thing with whether it's found the site or not (e.g. Terror Ships finding/not finding a city to raid, Battleships finding/not finding your base)? Does this apply to all missions?

:: The base assault battleships are not on the Retaliation Act sequence, they're controlled by [[XBASES.DAT]]. Reverse-engineering how the Retaliation Act ships find bases hasn't been precisely done yet (don't let the UFOs get too close to the base), mind shielding reduces the range at which a UFO can spot a base.

::: So the two battleships that don't ever spot your base are unrelated to the battleships that come if you're spotted? [[User:magic9mushroom]]

:::: Correct. I've had entire Retaliation Acts cycle without scheduling a base attack battleship, but this was with [[XBASES.DAT]] never flagging a base for retaliation.

:: As for Terror Ships: whether a UFO lands or not, appears to be controlled by its ufo-c/ufo-sub-c indexing. If they have orders to land, they won't have problems finding an appropriate site. -- [[User:Zaimoni|Zaimoni]]

::: So that means that of the two Terror Ship indexes you have listed, only one occurs in any given mission? [[User:magic9mushroom]]

:::: For all act types, the indexes are incremented in strictly increasing order (with all ufo-sub-c indexes run through before the ufo-c index is incremented). It may take more than one hour for a ufo to reach hyperwave detection with incomplete hyperwave coverage. -- [[User:Zaimoni|Zaimoni]]

:::::So are there two Terror Ships per mission or not?

:::::: The separation between Terror Ship 2/0 and Terror Ship 3/0 is a few days, so it's conceptually two missions with one Terror Ship each with the Terror Act. Empirical research into ufo behavior suggests that if they are not shot down, Terror Ship 2/0 never lands, while Terror Ship 3/0 always lands (and gives you a terror site). -- [[User:Zaimoni|Zaimoni]]

- With the infiltration, what does the "it starts again" mean? Does that mean that once an infiltration mission has started in a zone, endless infiltrations will run there until all countries there are infiltrated?

:: Infiltration is the only mission type that loops. It will continue even after all countries in the zone have been infiltrated. Russia is empirically immune to infiltration in all versions higher than DOS 1.0. -- [[User:Zaimoni|Zaimoni]]

::: So what happens at the conclusion of an Infiltration mission after all countries in the zone are infiltrated? Does a country outside the zone get infiltrated? Does no country get infiltrated? [[User:magic9mushroom]]

::::Nothing happens. Was rather fortunate to experience this a few times - and when I ran a no-funding-country scenario where I edited the save and flagged all the countries as withdrawn. Rather amusing to see them infiltrate an already infiltrated country and yield no results. In this case, the only real impact is the area activity points, which the neighbours will notice. -[[User:NKF|NKF]] 05:30, 10 August 2009 (EDT)

- It says the order for infiltrations is Terror ship -> Battleship -> Supply ship -> Battleship, but my own experience contradicts this - I shot down each UFO in an infiltration run, and the sequence was Terror ship -> Supply ship -> Battleship -> Battleship.

:: While Infiltration has not been verified by me in-game yet, the tables all assume that all UFOs in the sequence are detected. This is more interesting if this was with the Hyperwave Decoder. -- [[User:Zaimoni|Zaimoni]], 8:42, 9 August 2009 (CDT)

::: It was with a Hyper-Wave Decoder and I shot down each before the next appeared. [[User:Magic9mushroom|Magic9mushroom]] 04:07, 10 August 2009 (EDT)

:::: All eight are in the executable, in the order specified in MISSIONS.DAT. However, the four mentioned are pretty much "in a row": the sixth should arrive exactly one hour later after the fifth, and so on. That is, you have one hour to shoot down the Terror Ship to delay the three others by ~2 weeks. -- [[User:Zaimoni|Zaimoni]], 9:37, 10 August 2009 (CDT)

::::: Well, it was days between detecting each one. They definitely arrived in the order Terror Ship, Supply Ship, Battleship, Battleship.

:::::: See it in the executable, fixing that now. (Mapping duration from executable to empirical is tricky, as is estimating turning points and landing counts.) -- [[User:Zaimoni|Zaimoni]], 9:37, 10 August 2009 (CDT)

Thanks in advance. [[User:Magic9mushroom|Magic9mushroom]] 04:14, 9 August 2009 (EDT)

I understood what mean third entry in section Alien Data Missions at executable file.
As I said in forum Seeing speeds of USO sub we can determine the mission of this USO sub even without transmission resolver - even in january 2040
Every USO sub in every missions (interdiction, colony, probe and other) have unique speeds and we can determine mission of USO on their speed
And we can determine what amount of times a sub touch down on his mission - because every mission has unique rule for touch down USO subs
And we can determine what amount of time USO Sub will touch down on their mission - because every Sub in every mission has unique and ALWAYS equal amoun of time to touch down (p.s. this time we can see in file Loc.dat)

And third entry - it's index of speeds of sub.

I have table of speeds of all USO subs. Where can locate it?

== Non-scheduled Terror Missions ==

What is it known on terror missions which are NOT in MISSIONS.DAT? At least in TFTD, such missions are, as a rule, on the 1st of each month, 1:00 (are they always ship route attacks?). Saving the game before the attack but after the midnight (1st, 0:00), and next loading and continuing it, always leads to a mission in the same (exact) location, on the same type of the ship, and with the same alien race (or Mixed Crew). Only numbers of particular creatures of a given race can change. So, the mission properties must be stored somewhere between the midnight and 1:00 (when the attack occurs). The game must store this information somewhere, and it is not MISSION.DAT for sure.

Such a first-o'clock alien terror mission does not influence the normal, scheduled alien missions (so, it is even possible to have another terror mission just few hours after the first one, if only the other mission had been scheduled). Where is it stored?

Does a similar phenomenon occur in UFO:EU as well?

[[File:Nstm.zip]] - a set of savegames for tests, the explanation inside.

[[User:Sherlock|Sherlock]] 20:24, 30 January 2013 (EST)

File:Nstm.zip

2013-01-31T01:24:31Z

Sherlock: Save games from TFTD for testing non-scheduled terror missions and disappearing triscenes

Save games from TFTD for testing non-scheduled terror missions and disappearing triscenes

Talk:LOC.DAT

2013-01-31T00:10:55Z

Sherlock: /* TFTD/Mixed Crew */

===Altitude===
Shouldn't the altitude be set in this file as well? Probably one of the Unknown values, and XCOM and Alien Bases might have rubbish data in them. --[[User:Pi Masta|Pi Masta]] 15:27, 8 February 2007 (PST)

===Count Down===
I have some doubts about offset 6-7. The page says that it is the horizontal destination, it looks more like the time left before crash/terror site will disappear (or maybe the offset has two usages depending on the type of the location?). It is reset to 3 for as long as there is a craft targeting the site. [[User:Seb76|Seb76]] 10:45, 26 April 2008 (PDT)

: As neither crash nor terror sites have meaningful destinations anyway (only start locations), there's no reason why these offsets can't be overloaded to mean something else in these cases. -- [[User:Zaimoni|Zaimoni]] 14:32, 26 April 2008 (CDT)

My experience confirm that offset 6-7 is time to count-down.
If this is a terror or crash sub - time meeasure in hours. In example, if we show time = 10 that means this site 'll disappear through 10 hours

If this is landed Alien Sub - that time 'll fly up. It time measuring in 5-seconds. 1 minute = value 12.
When I checked time to lands Alien Subs, I 'll became to convince it.

As far as I see, offset 6 (word) indeed used for countdown, both set, updated and checked. But offset 8 is very weird. I haven't found use of this field value anywhere. Yes, it set, updated, but never checked. How's that?
There are couple of places where ''field6=5400/speed'' and ''field8=5400%speed'' and another with ''field6=latitude/speed'' and ''field8=latitude%speed'', and I have no idea what are they doing this for...
It looks like some companion field of offset6, but apparently not used.
--[[User:Volutar|Volutar]] 06:59, 13 April 2011 (EDT)

=== Field 08 (vertical destination??) ===

I have found strange algo with weird formula of transferring data from offset8 to offset6 (countdown field)

v44 = [0/5400/7560] + location->field_8;
location->field_6 = v44 / craft->CurrentSpeed;
location->field_8 = v44 % craft->CurrentSpeed;

This 0/5400/7560 value is calculated in function of craft position update.
Any ideas?
--[[User:Volutar|Volutar]] 08:03, 13 April 2011 (EDT)

I think I've found what this field_8 is and what these 5400/7560 values are.
This is a fractional part of latitude/longitude coordinate which is accumulated when craft is flying (this is omnidirectional value of how much craft moved away from "grid" center). Say, 2880 units is whole 360 degrees (along equator). 8 units per one degree... That's too much really. So they've splitted up this coordinate grid into "subgrid" 5400 units long and 7560 along diagonal (1/1.4, quite close to 1/sqrt(2)) and logically connected with craft speed units.
Thereby craft move from (300,300) to (302,303) will take 2 straight moves and one diagonal. Maximum craft speed is...? Right, 5400! So this craft will be flying right 1/8 degree per 1 game frame (which is 5sec). Slower crafts will require more game frames to fly through 1 xcom geographic unit.
--[[User:Volutar|Volutar]] 12:11, 13 April 2011 (EDT)

== field 06 & 08 ==
So Field_6 is
a) static object countdown timer until vanish
b) moveable object "distance" to the next globe coord in game ticks (distance / speed).
Field_8 is fractional part of distance (distance % speed).

Moving from one coord to another is discrete, i.e. can be either straight (5400 meters), or diagonal (7560 meters), only 8 directions. Each game tick this integer part is decreased, and when reaching 0 next coord taken (fractional part added to next portion of distance). Visually objects are moving by integer coordinates (2880x1440), and these frame-based intermediate values don't affect on visual representation, though they could.
--[[User:Volutar|Volutar]] 13:33, 13 April 2011 (EDT)

===Multiple interpretations===

It turns out that LOC.DAT also contains/indexes key data for configuring alien bases. One of my attempts at manually constructing an alien base entry critically backfired.

For a Floater base, the Reapers are instantiated in a post-processing pass; they start out as Floaters at the *front* of the alien unit list. The game knew enough not to arm the would-be Reapers, but with key fields in LOC.DAT bungled the pass to convert would-be Reapers to Reapers did not execute. -- [[User:Zaimoni|Zaimoni]] 21:34, 4 December 2008 (CDT)

: Alien ranks higher than Soldier also are created in a post-processing pass; their equipment, however, was templated properly based on what their rank would have been from where the entries were in the file. The proto-Reapers did not have Soldier rank either. -- [[User:Zaimoni|Zaimoni]] 21:51, 4 December 2008 (CDT)

== Supply ship requests ==

Just to jot a thought down before I forget:

Since supply ships aren't scheduled to happen as such in [[ACTS.DAT]]/[[MISSIONS.DAT]], and are instead requested directly by the alien base, would the base's loc.dat entry store a timer that counts down between the when it makes its next supply ship request? Or are supply ships just generated at fixed times during the month?

- [[User:NKF|NKF]] 04:41, 30 April 2010 (EDT)

edit: Shot this idea down as soon as it came to me. An alien base's information is fairly static in loc.dat. I can only guess that the game randomly decides whether or not to create a supply ship each day at 00:00am, with the supply ship's being 'ping'ed for the first time by your radars at 00:30am. Had a few supply ships show up in the span of a few days in one game, then after reloading none appeared until close to the end of the month. -[[User:NKF|NKF]] 05:16, 30 April 2010 (EDT)
:I think I wrote it somewhere, but once a day each base has a 5% chance of generating an alien supply mission. You can change the "6" there to increase the probability:
.text:00441DC6 66 3D 06 00 cmp ax, 6
:[[User:Seb76|Seb76]] 14:49, 30 April 2010 (EDT)

== TFTD/Mixed Crew ==

Byte 1: if contains 4, it means mixed crew. Of both types? Or the value of 5 for Mixed Crew Type 2?

[[User:Sherlock|Sherlock]] 19:10, 30 January 2013 (EST)

Talk:XcomUtil

2013-01-30T22:58:55Z

Sherlock: /* Using XcomUtil without installation */

=XcomUtil 9.7=

9.7 is available on www.bladefirelight.com

==Release Notes==

New in this version.

*Major overhaul of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New sub folders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran at least once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
**Force Split EXE on STEAM. Fixes issues with setup failing.
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*RunXcom can detect if it's in DosBox. Allowing XcuSetup to be run from windows and RunXcom run from DosBox.
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort and use of current setting.
*"debug" command arugument createds XcomUtil\Debug.txt and adds debug info to XcomUtil\XcomUtil.log
*Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

Removed from this versions

*New Desert and Urban terrain. (Will be added once I have a C++ version of the Java Terrain Edit.)
*Expanded capacity Laviathan, Hammerhead and Avenger (maps available in XcomUtil\Patches)
*Unit placement for Alien Bases

Bugs fixed
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Improve randomness by using current time instead of game date/time in srand()

NOTE: If you use DosBox, this requires DosBox 0.74 (Does not work on 0.73 due to buffer overflow setting ERRORLVEL)

==Beta Discussion==

===Build 435===
: I hope the improved randomness doesn't apply to the Aliens' d100 during AutoCombat. Otherwise, one could load-scum for success. [[User:Cesium|Cesium]] 06:33, 11 March 2010 (EST)
:: Actually it does. I can see what your getting at, but why do it that way. if you want to win the "WIN" command line option is faster and you get better loot from the UFO. also using the combat date would also swing the other way with an unwindable autocombat with an fully loaded avenger vs a survey ship. --[[User:BladeFireLight|BladeFireLight]] 17:41, 11 March 2010 (EST)
: In the setup question for sound files: "were replace" should be "were replaced". [[User:Cesium|Cesium]] 06:53, 11 March 2010 (EST)

----

Excellent! For the first time xcusetup.bat completed for me in Dosbox in Ubuntu. Previously the SDUMP commands were hanging it.

For the first time ever, I ran the sound setup utility. It did not response to any cursor keys, enter, tab, etc. The only key that worked was Escape, and I'm not sure what this did.

One point on the xcusetup.bat script - Ctrl C does not seem to work. On all those "press a key to continue" prompts could we also have "or 'q' to quit"?

[[User:Spike|Spike]] 18:41, 13 March 2010 (EST)

: "press a key to continue" is the Pause command. Ctrl + C works fine in Windows. DOSBox does not. The reason for the use of Pause is because an number of new players kept exiting setup early when I gave the option. Aborting early makes a mess and I dont want to have to troubleshoot it for Joe user. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
:: OK I see, that makes a lot of sense. [[User:Spike|Spike]] 06:52, 14 March 2010 (EDT)

----

Does the SHP flag still work, after the changes to how XCOMUTIL.CFG is assembled? I just tried it, after rerunning XCUSETUP.BAT (Dosbox 0.72 under Ubuntu). XCOMUTIL SHP produces no output. XCOMUTIL SHP:CFG WRT writes GEOSCAPE.EXE, but nothing seems to change. During XCUSETUP I see the expected "Patch applied, ship data updated from CFG" (or whatever). [[User:Spike|Spike]] 17:40, 16 March 2010 (EDT)
:: Yes it works fine. your mistyping the command. it's "xcomutil ufoexe shp:cfg wrt" Second argument must be the target folder. Line 42 and 1266 of XcommUtil.txt.
::: Thanks! And I thought I'd read the manual. [[User:Spike|Spike]] 20:31, 16 March 2010 (EDT)

===Build 442===
Bugs or features?
*BFG random generated a Martian landscape with its signature craters and bunkers for my crashed medium scout mission.
*BFG random generated a forest/farm map for my terror mission in Los Angeles. Nothing wrong with the enemy/civilian units though.
*Randomized small ufo's often seem to have elevators. Could/should it be set so that one level high ufo's would not get an elevator? I saw a 3x3 elevator in a large scout.
--[[User:Ras|Ras]] 04:43, 8 July 2010 (EDT)

*BFG will randomly choose a terrain unless you choose prompt in XcuSetup. This is how it's always been.
*Random floor plans is a complicated thing. It will chose elevator rooms defined in the rms file at random. They do look strange but it's the best Scott and I have come up with so far.
--[[User:BladeFireLight|BladeFireLight]] 21:07, 11 July 2010 (EDT)
:Good enough. --[[User:Ras|Ras]] 03:42, 12 July 2010 (EDT)

==Open Bugs==
*There's no Italian text for the Alternate Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons.
:*Anyone want to translate the text into Italian? --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
*The number of aliens in the mission report is inconsistent with the number of live aliens captured per research help. See [[Image:Alien_numbers_mismatch.zip]] and [[Image:Dead_alien_count.zip]].
* Morale is random at start of second stage after autocombat of first stage?
:* Actually Morale is used as the clip size and time units as the weapon damage. Don't ask me why. It would take a major re-write of auto combat to fix this. --[[User:BladeFireLight|BladeFireLight]] 19:34, 23 February 2010 (EST)
*RPL bug, when you turn creatures into Gill Men, they are reported as Snakemen
:* Reported how? Is this consistent? The name's used are from xcomutil.cfg. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
::*Sorry. It's reported in morale failure pop up messages. Though maybe this is an original TFTD bug rather than an XComUtil bug. [[User:Spike|Spike]] 19:21, 21 February 2010 (EST)
:::* See this: [http://www.youtube.com/watch?v=uGlSghf7aTU]. In that case, all Gill man (were lobster man before RPL) were reported as snakemen.. [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST)
*RPL bug, when you turn Lobstermen into other creatures (e.g. Gill Men), they are very hard to kill despite having the stats of the creature they turned in to. Possibly they are keeping their damage resistance? Maybe the race is stored in more than one place, for different purposes, and XComUtil misses one of these places?
:: I will look into this --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: The RPL only changes the basics; The race, rank, name, TimeUnits, Health, Energy, Reactions, Armor(front,back,left,right), Strenght and PSI Strenght. All other stats are left as-is. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::: I'm not so sure about this. See 05:00 mark at [http://www.youtube.com/watch?v=y-_zLdjhUHI]. The armour doesn't match the one Gill man should have (per UFOpaedia, at least). [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST). See also 04:17 mark at [http://www.youtube.com/watch?v=z5LfzFSkRnI] for reason to suspect resistances aren't always changed. It's possible he just was unlucky though... [[User:Cesium|Cesium]] 19:53, 21 February 2010 (EST)
::::: Actually the function is something like this
<pre>#define UpdateStat(x,y) pur->x = (unsigned char) \
( ( (unsigned int)pur->x \
* (unsigned int)pasTo->y \
) / (unsigned int)pasFrom->y )
UpdateStat( TimeUnits0, TimeUnits );
UpdateStat( Health0, Health );
UpdateStat( Energy0, Energy );
UpdateStat( Reactions0, Reactions );
UpdateStat( AFront0, AFront2 );
UpdateStat( ALeft0, ALeft2 );
UpdateStat( ARight0, ARight2 );
UpdateStat( ARear0, ARear2 );
UpdateStat( AUnder0, AUnder2 );
UpdateStat( Strength, Strength );
UpdateStat( PsiStrength, PsiStrength );
</pre>
::::: the 0's are values at start of tactical.
::::: I read that as Current(from game_x) * Target default(from xcomutil.cfg) / source default (from Xcomutil.cfg) so the stats will be different. --[[User:BladeFireLight|BladeFireLight]] 21:33, 21 February 2010 (EST)
:::::: I'd have expected Current(game_x) == Source default if applied on first turn? This would end up with result == Target default, no? Hmmm... We already saw some compiler multiplication wackiness with the research help bug. Possibly this affected these calculations too?
:::::: As for the code, you're not updating PsiSkill, so non Psi-users can't get Psi after RPL. [[User:Cesium|Cesium]] 22:03, 21 February 2010 (EST)
::::::: I didn't write this. I'm amusing Scott did it this way to adjust for difficulty because XcomUtil.cfg has the beginner level stats. It need's an overhaul to use the full stat entries including the unknowns adjusted correctly for the level. Something for latter. --[[User:BladeFireLight|BladeFireLight]] 22:09, 21 February 2010 (EST)
:::::::: For this specific issue I think you will need to update 0x37 of [[UNITREF.DAT]] which is the Damage Modifier. For the general problem you will need to update the Psi Strength and also Firing Accuracy, energy regen rate, movement class... loads of stuff. And of course LOFTEMPS. So with current RPL not changing LOFTEMPS, changed aliens are the wrong size and shape probably. This would be visible using the LOFTEMPS map viewer I suppose. [[User:Spike|Spike]] 18:39, 9 March 2010 (EST)
*[[Known Bugs#XComUtil Inventory Stacking Bug]]
:* I hope to overcome this but Scott's notes point to a technical limitation. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Fusion Ball Launcher fixes - detailed discussion moved to [[Talk:Fusion_Ball_Launcher#XComUtil_FBL_Issues]]
** Profitability (inconsistency item) - becomes most profitable item when using Alternate Laser (and Plasma) Tech option. Recommendation - workshop space and Engineer hours x10, 4 Alloys, 20 Elerium. And make it more useful (see below).
** Usefulness ''(wish list item)'' - perceived as being not very useful with standard stats. Recommendation - increase ammo to 3. Leave damage as-is to allow for Tougher UFOs (see Wish List).
*Zrbite lying around in odd places. Objects lying around in odd places in general - these are map modifying errors, probably only occur when customising terrain etc.
:: Will be part of an overhaul of the BFG --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*There is a small problem in editing/customising craft using '''XComUtil.cfg'''. Certain X-Com craft weapon values - the rate of fire value - can't be set. Or more specifically, they can be set (patched) in the executable but it has no effect in the game. To avoid confusion they should perhaps be removed from the format of custom craft, or commented out. (This rate of fire patching ''might'' work on UFOs, haven't tested it).
:: Can you be more specific? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: There is a section in '''xcomutil.cfg''' which is used for patching XCom craft weapon characteristics. This is where Scott changed values for the Laser Cannon, etc. Probably very few people use these fields. I only used them because I was doing research into the game mechanics. One of the values changed in this section is the reload time. These values are present in the executable, and can be patched, but patching them has no effect (other than to change the UFOPaedia entry). The reload time seems to be hard coded elsewhere in the executable, based (broadly) on the class of weapon. So you might want to comment this column with an a note saying "cannot be modified for combat". On the other hand I could be wrong, or someone still might want to modify these fields. Discussion is at [[Talk:UFO_Interception#Observed_Rates_of_Fire]]. Offsets are at [[Talk:GEOSCAPE.EXE#Craft_weapon_stats]]. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
:::: Or maybe change these display-only values so that they reflect the [[Talk:UFO_Interception#Observed_Rates_of_Fire|observed reload rates]]? I am not yet 100% sure I have got these right, might want to wait until I do some more confirmation tests. [[User:Spike|Spike]] 15:26, 22 February 2010 (EST)

*Research Help from Captured Aliens awards research help without checking first if you have Alien Containment at the base of origin. Resulting in dead aliens helping you with your enquiries! Possibly only applies to AutoCombat? [[User:Spike|Spike]] 21:05, 14 March 2010 (EDT)
:: Ideally it would not only check for containment but also have a research item for it and check on how many scientist days had been reduced since the last combat and use that as a value for how much you get form the aliens still in containment. But that could just be a pipe dream. Checking for containment for now is a good idea. --[[User:BladeFireLight|BladeFireLight]] 15:35, 16 March 2010 (EDT)

* (Build 442) Prompts for "Pistol" not "Dart Gun" mod in TFTD. Also "Psionics" not "M.C.". [[User:Spike|Spike]] 21:53, 1 November 2010 (UTC)

* (Build 442) Steam instructions are confusing - should I run XCUSetup.bat first, then run SteamSetup.bat, then run Steam? Probably not. I think I should run SteamSetup.bat, then Steam, which will run XCUSetup.bat (or then I will directly run XCUSetup.bat). But it's not very clear. Although the instructions are pretty explicit, why doesn't XCUSetup.bat terminate when it detects Steam? That's what confused me I think. I didn't expect to have to hit Ctrl-C at that point. [[User:Spike|Spike]] 21:53, 1 November 2010 (UTC)
**As a nice to have, tell me to hit Ctrl-C to abort XCUSetup (and run SteamSetup.bat) when Steam is detected
**As a nice to have, ''don't'' tell me to abort and run SteamSetup.bat, if I've already run SteamSetup.bat. [[User:Spike|Spike]] 20:18, 3 November 2010 (UTC)

==Fixed Bugs==
*don't prevent patching windows version while running in dosbox, or vice versa
:*Fixed: XcuSetup can be run independently to the OS RunXcom is used in.
*4DOS and MS-DOS 5 dont like "-" in variable names.
:*Fixed
*Enviroment space reached quickly on most DOS environments.
:*Partly Fixed: Requirement has been drastically reduced to to ~1024 use of Command.com /e:xxxx still may be required
*EnvClean.bat has an error in line 172: ser -> set.
:* Fixed in build 204.
*ANSI escape sequences aren't necessarily supported on a real dos environment/emulation
:*Fixed: ANSI only used in DOSBox
*If all the aliens are down (some of them stunned), the last save is named "AutoCombat" and I end turn, XcomUtil may still run "AutoCombat" phase. This may have slightly different results than end of combat would have had
:*Fixed: Autocombat will not run if you have already won.
*A fully loaded Hammerhead's initial deployment has three aquanauts outside the craft.
:*Fixed: the unit placement for the default 12 unit craft has been added to XcomUtil.cfg
*Select terrain: doesn't appear until after I select a terrain in BFG prompting
:*Fixed
*geodata/obdata.dat gets truncated with selecting any improved weapon.
:*Fixed: This happens because a full backup did not complete but XcuSetup does not detect it. Backup script's changed to avoid xcopy timeout on some versions of DOS. (Backups are required by SDUMP to apply patches)
*I get this error during backup "16-bit MS-DOS Subsystem NTVDM has encountered a System Error The handle is invalid."
:*Fixed: All NT based OS's now using 32bit EXE's
* You can get X-COM MIA if you abort a mission, even if everyone is in the exit. Possibly a second stage bug only? See [[Image:X-COM_MIA.zip]]. Note that this only affects the report - after mission all the X-COM troops are still available.
:*NOT Fixed: This happens even on vanilla TFTD with that save. Given it's TFTD it could be an issue with the mapfiles. --[[User:BladeFireLight|BladeFireLight]] 00:23, 24 February 2010 (EST)
*Various second stage bugs - ammo clip recovery, crashes after autocombat of first stage, etc. Mainly for TFTD, but possibly Cydonia in UFO is also affected.
:*Fixed: Clip recovery no longer ran between parts of 2-3 part missions. Autocombat only crashes on two part if you are aborting the second stage and the save in slot 10 is from the first stage. Stage comparisons are now done to abort autocombat if you do this.
:*Fixed: [[Talk:Known Bugs (TFTD)#Multi-part map ammo loss|Multi-part map ammo loss]].
*Removal of Small Scout map / Survey Ship map, making it impossible to do these Battlescape missions.
:*Fixed: 9.7 only removes the maps if you use the BFG. I hope to have 9.8 not remove them at all. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*The XcuSetup prompt for the option of less-profitable weapons manufacturing is misleadingly called "new laser weapons".
:*Fixed: Renamed to Alternate Lasor weapons.
* SteamSetup.bat won't run from DOSBox. It says "This needs to be run from Windows". Though, does it make any sense to run SteamSetup.bat under DOSBox (eg for a linux system with no Steam)? [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
:*NOT Fixed: STEAM doesnt give access by default to the command prompt. If you know how to add that then you should know enough of DOS not to need the STEAM menu. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
* '''cfg/ShipDefU.txt''' has the XCU values for improved Laser Cannon (35/35/35), not the original values (21/35/70). Is this correct - is this file supposed to be the original defaults? [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)
:*Fixed: I was unaware that this had been changed. The weapons are not prompted for any change so they should not be changed. I'm reseting them all to defaults and looking to see if Scott had anything about them in the notes. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
* standalone patches the fix the difficulty bug
:*Partialy Fixed: 9.7 min install is the difficulty patch and changing Copy protection questions to all 0's.
*Version detection issues with obscure versions (Italian, 1.2a, etc.) causing corruption or lack of patching.
:*Fixed: Added support and patching offsets.
*Various default options make the game easier, not harder (''harder'' being the intent of XComUtil, right?). These should not be defaults. (More discussion at [[Talk:Enemy_Unknown_Extended#Standard_Config_Discussions]]) E.g.
::: 9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skipped but not the others). All other options are default to NO.
::: As for the intent of XcomUtil. Scott added features to
:::# Increase difficulty.
:::# Make useless items useful.
:::# Get the game Started faster.
::: I have added:
:::# Don't make unwanted changes.
:::# Fix game bugs
:::::Yes all of those are very sensible. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
::::Latter versions of XcomUtil will turn the last two forced items to prompted. with only the Difficulty bug and the split EXE as Default=Yes. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Basic tanks using advanced tank stats
**Improved High Explosive - very powerful in favour of X-Com, especially as alien spawn points and routes aren't set up to cover holes in UFO hulls.
:*Gauss weapons have infinite ammo
::: 9.7 has a second option to just the increase power to closer match UFO.
:*Using fighters as transports (carrying soldiers)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Using transports as fighters (weapon hardpoints)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Improved Heavy Laser / Heavy Gauss. OK, this should maybe be a ''recommended'' option since the unpatched weapons are nearly pointless. But, it does make the game easier. [[User:Spike|Spike]] 20:12, 7 February 2010 (EST)
*FreeDOS breaks horribly during Setup
:*This is most likely an issue with the limits of FreeDOS.
:** Actually, this seems to work well for the latest builds (tested with FreeCOM 0.84 under dosemu). [[User:Cesium|Cesium]] 18:07, 14 March 2010 (EDT)
*EQL only works on turn 1
:: Fixed
*Units not on the craft during Autocombat are MIA
:: This has been fixed. Autocombat now processes one round of fatal wounds first. Any surviving units are then marked as in the craft and MIA score removed. --[[User:BladeFireLight|BladeFireLight]] 18:24, 26 March 2010 (EDT)

=XComUtil Wish List=
Things that are not bugs or inconsistencies in XComUtil but would be Nice To Have

== Features for 9.7 - Interface, consistency and bug fixes ==

=== Categorise Config Options ===

For each option, in the prompt, note which category of option this is, according your list above. E.g. faster start, making the game harder, making useless items useful, bug fix, variant game, etc. [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)

:Actually it might be even better to organise the options questions into sections, thematically grouped by these categories. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

:: Items are currently sorted like this.
* Windows EXE
* Game Fixes
* Game Mods
** Sound
** Craft
** Base
** Equipment
** Research
** Units
** Battlefield
** Alien Craft
** Misc
--[[User:BladeFireLight|BladeFireLight]] 19:25, 10 March 2010 (EST)

=== Improved Pistol Modification ===
*Remove 3rd burst for Pistol
Detailed discussion moved to [[Talk:Pistol#XComUtil_Burst_Mode_Pistol]] to de-clutter this page. Summarised recommendations will be posted back here based on whatever consensus emerges.

Current recommendation: Reduce auto accuracy from 60% to 20%, with the same TUs (54%).When prompting, point out that no improvements are required to the Pistol to make it useful. [[User:Spike|Spike]] 08:12, 14 March 2010 (EDT)

* Dart Gun

On the other hand, the Dart Gun really is useless, even as a last ditch personal defence weapon. Auto mode, with very low accuracy (10%?), would at least give it some value as a defensive sidearm for medics, heavy weapons troops, etc. Scouts and others carrying a scanner or grenade in the other hand would still be better off using a Jet Harpoon, or even an AP HydroJet Cannon, one-handed. [[User:Spike|Spike]] 03:47, 16 March 2010 (EDT)

=== Fusion weapons inconsistently exempted from Alternate Laser Tech ===
* Fusion weapons inconsistently exempted from the "more difficult" energy weapons manufacturing option ("alternate laser Tech"). Blaster Bombs and Blaster Launchers, Fusion hovertanks and ammo, and Fusion Balls and Fusion Ball Launchers - none of these are harder to build or use with the "alternate Tech" option. Why make laser weapons/tanks and plasma weapons/tanks harder but not Fusion weapons? It's not consistent. I wonder if Scott didn't look at these because he never used Blaster Launchers or Fusion Hovertanks, as he considered them to unbalancing already? And ignored FBLs because, well, most people ignore them? But this should be consistent. Or, the "harder weapons" option could be broken down into sub options, e.g. for each weapon technology:
** Much more expensive (typically: add some exotic materials, 10x workshop space and 10x Engineer hours)
** Can/can't manufacture the battlescape weapons/tanks (pure alien weapons only)
** Can/can't manufacture the ammo (pure alien weapons only)
:Personally I would prefer it to be all-or-nothing but include the Fusion weapons as being more difficult to make and use. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
* In the meantime (ahead of introducing any changes), maybe change the prompt to "Alternate Laser and Plasma Tech"/"Alternate Gauss and Sonic Tech", and/or point out explicitly that the changes don't affect any Fusion/Blaster/Pulse Wave weapons. [[User:Spike|Spike]] 08:15, 14 March 2010 (EDT)

=== AutoCombat issues ===
* All Civilians are dead if AutoCombat is used to end a Terror mission. It's too not much of a problem, since score is likely to be positive anyway. It would possibly be an improvement to assume all civs from first stage are dead (if ran at second stage) and get a random number (using mission seed) for dead civs at current stage? [[User:Cesium|Cesium]] 07:00, 22 February 2010 (EST)
:* This is odd. Autocombat is supposed to skip over civilians when using the kill function. --[[User:BladeFireLight|BladeFireLight]] 00:18, 24 February 2010 (EST)
::*Maybe kill civilians (or not) according to the force ratios. If XCom has only enough force to win the mission, all Civilians are dead. If XCom bring a certain amount of "excessive force", all or nearly all Civilians are saved. By the way I love AutoCombat, it is great for avoiding repetitive combat and only playing the new, interesting bits. [[User:Spike|Spike]] 15:53, 22 February 2010 (EST)
:::* Thinking about this, I recalled the scenario where someone fights the mission and uses AutoCombat to hunt the last aliens (another reason AutoCombat is great). Spike's suggestion is better from pure RNG, since in this case probably all civs that were at risk already died. So lets see what we suggest XcomUtil do:
:::# Count civs from first stage if there was one as dead (since IIRC XcomUtil has no memory of first stage when exiting second stage, so we can't take them into account?).
:::# Deduct dead civs from current stage.
:::# Calculate extra dead civs using force ratio to bias the RNG (I prefer merely biasing the RNG rather than precluding results, since Xcom in general has a large variance in almost every gameplay mechanic). [[User:Cesium|Cesium]] 18:27, 22 February 2010 (EST)
* Day vs Night
** The Day/night algorithm breaks. For example, at any point when XCom has more than twice as many flare-carrying soldiers than there are remaining aliens, XCom is actually ''stronger'' in darkness than it would be in full daylight. Toward the end of a battle this is a very common situation. But fixing the algorithm is tricky. What might work is to give -10 for each Soldier in darkness, reduce from -20 to -10 for each Alien in darkness, then add back +10 for every soldier with a light source. Thus there is no way XCom can go 'net positive' from light sources.
:: If you have more units then they do you can see more of the battle field. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:::It never makes sense for XCom to be stronger at night, than during the day, for the same force ratio. But that is what happens. An example. 10 XCom soldiers with flares and 3 aliens. At night there is an extra -30 modifier for the aliens, but a +100 modifier for XCom, net +70. The same 10 soldiers against the same 3 aliens are +70 ''more'' effective in darkness than they would be in daylight. It does not make any sense. [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
** The definition of a light source should be expanded to include a Flare ''or'' an Incendiary weapon. In fact, one Incendiary-capable weapon of any type (AC/HC/HjC/GC), with appropriate Incendiary rounds carried, should be enough for the entire squad to be considered as having a light source. But this may be hard to implement without a special flag and a special pre-search for a valid Incendiary weapon, since AutoCombat normally scores by individual soldiers, not by whole squads.
:: This would take a rewrite. currently the ammo is not used by W: --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
** To be honest I would prefer that each soldier without a light source in darkness is 50% effective, each soldier with a light source (personal or squad), is 75% effective. Meanwhile how about this:

//Darkness - Tested OK (except IN Rkt)
-10 L:-9 u:-2 // Human in Darkness

+10 L:-9 u:-2 W:-27 U:- // Human in Darkness w/Flare -OR-
+10 L:-9 u:-2 W:-4 W:-7 U:- // Human in Darkness w/In ammo and launcher HC/GC-IN -OR-
+10 L:-9 u:-2 W:-8 W:-11 U:- // Human in Darkness w/In ammo and launcher AC/HjC-IN -OR-
+10 L:-9 u:-2 W:-12 W:-15 U:- // Human in Darkness w/In ammo and launcher IN Rkt/Torp

-10 L:-9 u:4-14 // Alien in Darkness

:: Only thing I see is that this ''must'' come at the end. The U:- removes the unit from further consideration. --[[User:BladeFireLight|BladeFireLight]] 19:58, 9 March 2010 (EST)
::: Yes, to use the U: flag for this "OR" function, it must come at the end of the section for humans. That's how I have it my updated AutCombt.txt, these fragments are a bit out of context. It's not critical to have the "OR", it's just nice-to-have as it stops someone cheating by having a flare and one of each loaded incendiary launcher weapon in each hand and in their backpack, to get quadruple score. But hopefully people are unlikely to cheat at AutoCombat, there are easier ways such as the WIN flag. [[User:Spike|Spike]] 20:39, 9 March 2010 (EST)
* The Zombie is rated the same as a tank, a Chrysallid/Tentaculat or an effective Psi alien (-50). I think this is too high, as Zombies are much weaker than those units. A Zombie should be maybe -25.
: Disagree. the zombie should be slightly higher then a Chrysallid/Tentaculat as it will become one and you have to kill it twice. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:: OK good point! [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
* Area effect weapons (HE, IN, Small Launcher) should have at least the same bonus as effective-on-Auto weapons (+5). This is because they can damage/kill multiple targets. (The AC/HjC should not get both bonuses however.)

//Area Weapons. To be Tested. These values are probably too high.
//NB we are not indicating damage here, that is already calculated by the "effective" function. we are just
//factoring in the possibility of hitting multiple targets because of the area effect
//ToDo: needs compensating bonus for aliens (grenades?). should not be cumulative on the same unit.
//Also: add check if weapon is "effective" (at GZ) ?
+25 u:-2 W:-40 W:-41 //U: // Human w/ Blaster/DP Launcher and ammo
+10 u:-2 W:-12 W:-13 //U: // Human w/HE ammo and launcher Sm HE Rkt/Torp
+10 u:-2 W:-12 W:-13 //U: // Human w/HE ammo and launcher Lg HE Rkt/Torp
+10 u:-2 W:-42 W:-43 //U: // Human w/ Stun/Shok Launcher and ammo
+5 u:-2 W:-4 W:-6 //U: // Human w/HE ammo and launcher HC/GC-HE
+5 u:-2 W:-8 W:-10 //U: // Human w/HE ammo and launcher AC/HjC-HE

-25 u:4-14 W:-40 W:-41 //U: // Alien w/ Blaster/DP Launcher and ammo
-10 u:4-14 W:-42 W:-43 //U: // Alien w/ Stun/Shok Launcher and ammo

::Having tested the HC and AC rules, the first rule (HC-HE) does not work unless you remove the ammo specifier W:-6, making it just a test for an HC. But weirdly the second rule (AC-HE) works fine with its ammo specifier in place. Odd. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: The problem was due to [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Ammo loaded into a weapon by the game automatically prior to the equip phase is not caught by the W: function. When the ammo is loaded manually, both rules works fine. [[User:Spike|Spike]] 18:16, 13 March 2010 (EST)

* Pistols with the burst mode option should not count as Auto weapons (maybe they don't).
: Burst and snap are based on default stats --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
* Blaster Launchers / DPLs (with ammo) should be worth as much as a tank, e.g. +/- 50 (including the single shot effective bonus it should already get - see suggested rule above under area weapons)
* Should distinguish between tanks. Even with improved armour, a Tank/Cannon is not the same as a Fusion Hovertank. I would suggest a range of 25 for a Tank/Cannon to 75 for a Hovertank/Fusion. Maybe 40 for a Tank/Rocket, 50 for Tank/Laser, 60 for a Hovertank/Plasma?
:This does not seem to be possible with the existing ruleset as all Tanks are unit type 3
::Hmm, byte 42 of [[UNITREF.DAT]] is Rank but also Tank chassis. So this ''might'' allow distinguishing tracked tanks from hover tanks, at least. An alternative approach would be to pick some stat (that has a StatStrings statid) and set it to a different unique value for each tank type. [[User:Spike|Spike]] 18:32, 9 March 2010 (EST)
::This rule set might work:

// Tanks - distinguish chassis types. To be tested
+40 u:3-3 R:0-0 // Tank, Tracked (Cannon, Rocket, Laser)//To Test
+60 u:3-3 R:1-1 // Tank, Hover (Plasma, Fusion) //To Test

* Flying units (either side) should be worth say +/- 5
:Not possible for XCom as no statid makes a distinction between Power Suit and Flying Suit. Would be possible for aliens eg:

-1 T:0- u:6-6 // Flying Alien - Ethereal
-1 T:0- u:8-8 // Flying Alien - Floater
-1 T:1- u:13-13 // "Flying" Alien - Hallucinoid
-1 T:1- u:11-11 // "Flying" Alien - Tentaculat

::On reflection flying is hardly any advantage for aliens, it usually just makes them easier targets with no cover. I guess it helps with avoiding HE splash. [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

* If the squad is carrying some Smoke or Dye that should be worth maybe +5 - +10. But since the aliens don't ever carry that, you need some balancing factor for them.

+1 u:-2 W:-20 // +1 per human with smoke grenade(s) (not +1 per grenade!) //Tested OK

* Effective melee weapons should be counted. This is particularly important in TFTD when ranged weapons may be ineffective, e.g. vs Lobstermen.
* Similarly if the enemy are in heavy armour and therefore a soldier/alien does not have an effective weapon, any HE Pack / Alien Grenade / Sonic Pulser should be counted for something (if it is "effective").

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
<s>+5 u:-2 W:3-26 // Human w/ effective Stun Rod (cumulative to above)</s>

::The second rule doesn't work at all, it looks like it counts all items of types 3-6. The "superiority" function (first value before the hyphen) does not seem to operate, probably because it is a melee weapon. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: did you try W:255-26 ? not that I know if it would work. AutoCombat doesn't recognize stun rods as weapons when applying damage.--[[User:BladeFireLight|BladeFireLight]] 21:01, 9 March 2010 (EST)
:::: OK, if AutoCombat rates stun rods as doing no damage, the lower range of the W: function ("superiority") will likely never work. So we can't tell whether or not a Stun Rod is "effective" vs the current enemy. In general, the Stun Rod is a pretty effective weapon. So instead we generalise and just use something like this rule set:

//Melee weapons
+3 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod //Tested OK
+3 u:-2 W:-26 // Human w/ effective Stun Rod (cumulative to above) //Tested OK

//It would be nice if AutoCombat checked for the presence of Stun Rods and used them to increase the chance of an alien casualty being stunned rather than killed.

//To Do: check if TFTD melee weapons are included in "effective" weapons by the W: statid.

//Grenades (this needs to be an OR block, so it's not cumulative for each grenade type)
+2 u:-2 W:1- W:-44 // Human w/o effective ranged weapon but w/ effective Alien grenade(s)
+2 u:-2 W:1- W:-22 // Human w/o effective ranged weapon but w/ effective HE pack(s)
+2 u:-2 W:1- W:-21 // Human w/o effective ranged weapon but w/ effective prox grenade(s)
+2 u:-2 W:1- W:-19 // Human w/o effective ranged weapon but w/ effective grenade(s)

-5 u:4-14 W:3-44 // -5 per Alien with effective Alien Grenade(s) (not -5 per grenade!)
:: Only one per unit. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)
::: One per unit tested ok too! [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
* AutoCombat victories should award all UFO Components, not just some Navigation, Elerium and Alloys.
* Every Civilian on the map should be a penalty to XCom of maybe -5, due to the distraction effects of trying to save them / avoid killing them.

-5 u:15-16 U:- // Civilian distraction effect, no further effect //Tested OK

Let me know if I should try to work some of this up as AutoCombat rules. Some of it requires new coding of course, but a lot of it could probably be done with existing rules. [[User:Spike|Spike]] 13:15, 7 March 2010 (EST)
: I dont plan on any changing to the underlying code yet. Your welcome to make up a new set of rules and testing them out. --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
:: OK added some rules above. I have not tested them yet, some of the syntax might not work. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)
::: Syntax looks good to me. Give them a test and let me know how they go.
::: Just a quick note on how AutoCombat works. First the success percent chance is calculated using the AutoCombat StatStrings, dead and unconscious units dont count. (those that bleed to death are considers alive, need to fix this). If it's below AbortThreshold it aborts. If it's 100-199 then change to 90. 200+ change to 95 (success is never a guarantee.) Aliens roll d100, if over your success chance you lose. If You win. Then average damage by each side is calculated based on Loaded weapon being carried and time units. All aliens are killed or stunned by X-Com unit chosen at random. Each Alien gets a chance to wound an X-Com unit based on Success Percentage. Randomly choose unit using random damage (max is average alien damage) Leave at least one X-Com Unit alive. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)

* It would be nice, in a future version of AutoCombat, to have some way of ORing rules together. Using the U: construct as a 'break' only allows you to have one single OR block per unit type (I think). [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

* The battle report screen after AutoCombat does not report the number of Alien Artefacts recovered. This gives score I believe. Is it because it's hard to populate whatever data structure the game reads in order to generate the Artefact count? As I understand it, anything you haven't yet researched is an Artefact, and awards some score for recovering it. Anyway, fixing this would be nice-to-have. [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

* It would be nice to compensate for the [[Known_Bugs#Equip_Phase_Ammo_Load_Error|Equip Phase Ammo Load Bug]] [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

=== Focused Research Help ===

There is a minor and probably unintended consequence of Research Help from Captured Aliens. Normally when you capture a new alien artefact that opens up a new research project, you start the research project - typically with 0 Scientists - and then immediately sell the artefact. The problem with this for Research Help is that you soon have a huge number of projects underway. Then any Research Help tends to get very widely dispersed across all active projects (since it always goes to the project where the biggest reduction can be made, i.e. the projects furthest from completion). The result is that projects are completed only rarely, and progress is made on a broad front but without delivering much. Currently, to avoid this, it is necessary to keep single alien artefacts around in Stores, waiting for the time when the project they open up becomes a priority. In a way, this is interesting and challenging. In another way, it is a headache and take away vital cash.

You might argue that the trick above is a kind of exploit and should not be done. I don't know, maybe. But it is a common practice.

A solution, hopefully fairly easy to implement, is to only consider Research Help for projects which have actually made some progress, e.g. more than 1 scientist day has been applied to them.

In the meantime, maybe put a warning to players in the XCUSETUP script, to keep their research projects to a smaller number when using Research Help from Aliens. [[User:Spike|Spike]] 21:10, 16 March 2010 (EDT)

== Features for 9.8+ - New features ==

=== TFTD Gauss Tank Research Fix ===
*Have the option to make the Gauss Tank require only Gauss Cannon research - this can make it more distinct than the Sonic Displacer and maybe slightly useful for a while
:*I plan on it. just not this version. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

=== Improved Base Comes At Cost ===

The Improved Base is supposed to be a "faster start" option rather than a "make the game easier" option. But it does make the game easier, not least because it gives you a load of free base facility improvements. (Not to mention not having to struggle along the first month with only Small Radar and no Alien Containment) To partly avoid making the game easier, please add a sub-option that subtracts the cost of the extra facilities from your starting cash. This should be the ''full'' cost of the extra facilities, not just the difference between e.g. a Small Radar and a Large Radar.
[[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
: I dont have the offsets to the starting money ranges. so I cant do this. --[[User:BladeFireLight|BladeFireLight]] 19:13, 10 March 2010 (EST)
:: I never realised that the starting money is slightly random, I see ranges from $4,125,000 to $4,153,000, in ten samples. Does not seem to depend on Difficulty or starting base location. That is going to be a hard offset to find. [[User:Spike|Spike]] 20:36, 11 March 2010 (EST)
::: I believe there is no "starting money" anywhere to be found, or rather the starting money is effectively zero but it soon changes: the first thing the game does when you begin a new game is perform a hidden monthly report which grants you money from the funding nations. Only way to decrease it is to lower your rating toward countries (you should be able to hack the starting diplomacy data located at 0x4728F8). Or I could just patch the initial money to be negative instead of zero thus providing lower overall starting money. [[User:Seb76|Seb76]] 15:52, 12 March 2010 (EST)
:::: That makes a lot of sense. The initial money is the same as the initial funding. Doh! I should've realised that. The solution to poke a negative number into the money field, prior to the "hidden funding round", sounds a great idea.
:::: Looking at initial money vs funding, your initial cash is always $1,860,000 less than your initial funding. This $1.86M is probably made up of the first 3 rows (only) of your initial Monthly Costs: $500K transport rental, $1200K Interceptor rental, and $160K salary (not hiring fees) for 8 Soldiers. The salary (and hiring fees) for 10 Scientists and 10 Engineers are ignored. The Base Maintenance costs, $224K for a standard starting base, are also ignored. This generosity saves you at least $774K. Could this be considered a bug? Possibly.
:::: The cash value of the XComUtil Improved Base is a whopping $4.5M. This is $1.6M of facilities (Alien Containment, Large Radar, 2nd Living Quarters) and $2.9M of personnel (+10 Engineers, +40 Scientists). $4.5M would wipe out all starting cash and players would begin the game with a negative balance - quite challenging! For XComUtil, it might be best to break improved Facilities and Extra Starting Personnel into 2 options, with each having a sub-option to pay for the improvements. ''"These extra facilities/staff would cost $1.6M/$2.9M, do you want to deduct that amount from your starting cash?"'' [[User:Spike|Spike]] 20:48, 12 March 2010 (EST)

=== Easier Inventory Management ===
Inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
: The manager of any facility has to deal with generalities of space issues. The clerk tells you if that fancy new tank you just bought will fit. He has to put it in storage and keep track of what shelf the ammo is on. --[[User:BladeFireLight|BladeFireLight]] 22:27, 9 February 2010 (EST)
:: That's the clerk's problem and if he complains too much I'll have him peel potatoes until his hands drop. In any event, the limit doesn't make any sense:
::* General stores size is 8x8x2 (8x8x3 in TFTD) per base defence map, and should have no problem storing more than 50 items.
::: The items taking up 1 item unit are typically about the size of humanoid body. I think it's not unreasonable to have no more than 50 of those in the area that the General Stores takes up.
:::: I can't find a list on the wiki of storage space requirements for items, so I'm not sure which items take up 1 item unit. Typically the main space wasters are Heavy Plasma ammo/Blaster Bombs/Stun Bombs (late game) and/or HWPs and avalanches (early game). These either are definitely not the size of a human body (ammo/Bombs), or shouldn't be stored in stores at all (HWPs gain nothing, and might as well lay around somewhere else in base).
::* The size of a fully built X-Com base is about the size of a city block (judging by comparison of base defence to terror missions), and should easily be able to hold hundreds of items even in the starting base if it's willing to put some stuff not in the general stores.
::* The space limit makes no sense. Why do Blaster Bombs and Heavy Plasma ammo take so much space whereas in the inventory view it doesn't take any more than normal ammo? Who stores <s>mini tanks</s> HWPs in the same compartment as light weapons? And the way X-Com (probably) stores ammo and explosives is scary...
::: As you suggest, extremely powerful ammunition probably requires a lot more space for safe and secure storage in-base, versus on a tactical mission. Imagine what would happen if a Blaster Bomb exploded in a base? Or was stolen? They probably use nuclear warhead style storage facilities for those. And similarly for Avalanche warheads, alien artifacts, Elerium, etc. Segregating dangerous/explosive items from other items probably uses up a lot of overhead in the construction of the storage space - think armoured, bomb-proof lockers and bulkheads, advanced security systems, airlocks, scanners, etc. This is not just like piling stuff up in your shed! And the Commander who left Elerium or Avalanche warheads lying around in his hanger or corridors would justifiably be sacked on the spot by XCom High Command. [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Well, judging by all the explosives in the hangar during base defence and the X-COM 1.0 Elerium bug, Elerium and explosive warheads ''are'' lying around in the base... And all the equipment in the General Stores is stored in ordinary lockers according to the General Stores map ;-) More to the point, if X-COM wants to store explosives safely (judging by said warheads X-COM doesn't care too much) they need a special facility for this, not to store them in the room which also contains all the base's weapons and priceless alien artifacts.

:::: Furthermore, I expect X-COM to improvise on storage in the interest of actually winning the war. X-COM does do this and ignore the limit when manufacturing stuff in-base or getting loot from missions. All that's needed is that X-COM will improvise for transfers too. I can't imagine a quartermaster informing the commander there isn't any room for the new armour and that the troops should go without. Maybe the reason X-COM doesn't pay quartermasters each month is that they keep getting themselves lynched by enraged X-COM troops...
::* Gameplay wise, inventory micromanagement is just no fun, especially in the late game when you have all the cash you need but still has to sell stuff after each combat (which can be prolonged if you haven't sold for awhile), otherwise you can't transfer items to the base where your main team is at.
::* Maybe this entire "stores" thing is a plot by the CFN to force X-Com to share its technology with them by forcing X-Com to sell sell sell. It's not like they pay X-Com the real worth of the technology anyway. [[User:Cesium|Cesium]] 23:47, 9 February 2010 (EST)
::: I think a lot of people do find the inventory management tedious, or unrealistically low. Personally I think it's about right for large equipment (missiles, tanks, bodies), but too low for small arms and personal equipment. And yes, it only reflects using the General Stores modules, not storing stuff at random points in the base - maybe fair enough. If the right offset to patch can be found, the storage limits could easily be raised. The last few bytes of [[BASE.DAT]] could be a good place to look for this offset. BASE.DAT can store up to 9,999 units of each item per base. The total limit for items per base would need to be found by experiment, but 9,999 might work for those who want to ignore inventory. For those who feel inventory management is OK but the limits set too tight, the capacity of each General Stores could be increased from 50 to 100 - assuming we can find the offset for this to patch it. [[User:Spike|Spike]] 19:50, 10 February 2010 (EST)
::::Maybe you can try there:
.text:00439C85 66 81 C5 F4 01 add bp, 500
::::[[User:Seb76|Seb76]] 13:03, 11 February 2010 (EST)
::::: Yes that works nicely. E.g. patch '''66 81 C5 E8 03''' at that location and you get 100 space per General Stores. Thanks Seb! [[User:Spike|Spike]] 18:21, 13 February 2010 (EST)
:::::: Now if only I had the offsets or search signature so we can add that as an options --[[User:BladeFireLight|BladeFireLight]] 18:24, 13 February 2010 (EST)
::::::: UFO 1.4 dos: offset 143748. TFTD 2.1 dos: offset 178462. TFTD v1 dos: offset 176861. TFTD CE: offset 252795. UFO CE: offset 236680. (all offsets are in decimal and point to the "F4 01" value to be patched).
::::::: Patching to "E8 03" has been tested on dos versions (not on CE) and it works. The "base information" screen will display the correct value, though the values to line length scale is such that the line will max at 250. [[User:Cesium|Cesium]] 05:57, 14 February 2010 (EST)
::::::::Are the preceding bytes the same from TFTD 1 and 2x? --[[User:BladeFireLight|BladeFireLight]] 17:26, 15 February 2010 (EST)
::::::::: Yes they are. '''81 C3 F4 01''' is the add instruction. [[User:Cesium|Cesium]] 17:48, 15 February 2010 (EST)
::::::::: Sig for UFO Dos is '''81 C6 F4 01''' --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
:::::::::: Do you also have the preceding bytes for UFO? with the signatures I can create a patch file for all versions --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
::::::::::: I am not sure I understand your question.. Judging the the two UFO versions I have available (1.3 per xcusetup and 1.4) the common preceding bytes are ''80 78 16 07 75 0C 80 78 3A 00 75 06'' (followed by the sig). You could try to use the sig alone - it exists only once in the file. [[User:Cesium|Cesium]] 19:35, 15 February 2010 (EST)
:::::::::::: Offset Locations are something I'm collecting but also the unique series of bytes to find them for the two geoscape/tactical that I dont have. (UFO Spanish, TFTD Italian) I hope to add a lot more options in the in the future. I do feel this one nerfs the storage system anything to get the game up and going faster is always a plus. --[[User:BladeFireLight|BladeFireLight]] 22:01, 15 February 2010 (EST)
::::::::::::: Well, you may want to add another General Stores to the improved starting base if you want to achieve the faster startup effect without "nerfing" storage system for rest of game (I prefer a "nerf" due to late-game reasons). Also, I suggest you add an message in Xcusetup to ask people to get in contact with you if they use an unknown/unrecognized version. [[User:Cesium|Cesium]] 14:27, 16 February 2010 (EST)
::: Inventory management is just as much a pain in the early game, where you almost always are out of space until your 2nd general stores is built. I like realistic constraints, but not tedium. Maybe upping the space per Stores from 50 units to 100 units would be a generally acceptable approach (now that Seb76 has kindly found the offset)? [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Yeah, that would be a great improvement. [[User:Cesium|Cesium]] 15:45, 13 February 2010 (EST)

:I can confirm Seb76 is correct, as ever. The 2 bytes at offsets '''0x39c88''' and '''0x39c89''' in geoscape.exe code for the capacity of each General Stores. Default value is 500 ('''F4 01''') which equates to 50 in-game internal capacity units. (Smallest item uses 0.1 in game capacity so I guess that is 1 unit in internal units). I am not sure about a signature. From what I can tell, the preceding bytes '''66 81 C5''' are unique in geoscape.exe, which seems pretty odd, so someone else should verify that. [[User:Spike|Spike]] 19:48, 13 February 2010 (EST)
:: Yes it is unique to CE. it does not exist in any DOS EXE, but "F4 01" can be found in 79 places. Trial and error could locate it. --[[User:BladeFireLight|BladeFireLight]] 20:50, 13 February 2010 (EST)

=== AutoCombat ===

==== Firepower Factors ====
You might want to consider replacing the weapon offensive weighting factors for Autocombat with some factors that are (inversely) related to the [[Weapon_Analysis#Quantitative_Analysis|% TUs Per Kill]]. I've tabulated these for each weapon (including tanks) vs each alien race. You would still need to account for Psi, light/darkness, and XCom armour. Plus you would need a similar offensive factor for the aliens' attacks. But I could probably help with that, I have the data that's directly comparable to the % TUs per Kill for XCom weapons. [[User:Spike|Spike]] 22:06, 12 February 2010 (EST)

==== AutoWithdrawal ====

One of the most tedious things you can try to do in XCom is to scavenge the battlefield and retreat to landing craft for an Abort. A great option would be an AutoWithdrawal, similar to an AutoCombat, but with an easier threshold of XCom vs Alien combat power.

Basically it would scavenge all loose equipment off the Battlescape - dropped friendly and alien items, friendly and alien corpses and wounded, all go back into the landing craft. Elerium, Alloys, and UFO Components would not be recovered, as this is (normally) impossible apart from full tactical victory. All friendly troops return to the landing craft. Friendly losses, and equipment recovered, would be proportional to the offensive factor ratios but much more favourable than for AutoCombat. E.g. as long as XCom factors were at least equal to Alien factors, they would be able to scavenge everything and recover without casualties. If the aliens were stronger than XCom, they would only recover part of the scavenged equipment, and risk partial casualties, at say one third the rate of AutoCombat. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

: It's too easy compared to actual game IMHO. Every time a battle went FUBAR for me, it got FUBAR all the way and I was lucky if I could salvage my own team/equipment and maybe a single alien weapon/body. An AutoWithdrawal without salvage might be useful, but perhaps instead we should change AutoCombat failure mode to work better (e.g. Make some X-COM people survive a failed AutoCombat, depending on strength vs aliens). [[User:Cesium|Cesium]] 15:00, 7 March 2010 (EST)

:: Yes fair point. I was not thinking of the FUBAR situations, and you are right about how hairy those are. I was thinking of the situation where you control a certain part of the battlefield, but you either don't want to go on an endless hunt for the last few aliens, or you pretty much know you can't take on the aliens that are left (e.g. in the UFO or some other stronghold) without getting creamed. You can exercise a safe withdrawal, it's just tedious to carry out all the bodies and equipment. But it's pretty hard for an AutoCombat algorithm to detect which of those situations it is - FUBAR, boredom, or tactical withdrawal. I'll have to think about that, there may be no realistic solution at all. And there is the existing "teleport loose items back to base" command line option to XComUtil, maybe that's enough. [[User:Spike|Spike]] 16:08, 7 March 2010 (EST)

=== Tougher UFOs ===

[[Wish_List_(EU)#Tougher_UFOs|Tougher UFOs]]
As this is entirely implemented by patching data and data files it is a good candidate for XComUtil rather than [[UFO Extender]].
: That would definitely make the game harder. 9.7 is about the installer and the bug fixes. This would be a good candidate for 9.8. --[[User:BladeFireLight|BladeFireLight]] 01:38, 19 February 2010 (EST)
:: Cool! [[User:Spike|Spike]] 02:25, 19 February 2010 (EST)

=== Rebalanced Craft Weapons ===

This fits under the "making useless things usefull" category. It would be a 9.8 or later option. The idea is to make the Cannon, Stingray, Laser Cannon and Fusion Ball Launcher useful. Hopefully it breaks up the monotony of Dual Avalanches followed by Dual Plasma Beams, every game.

There is one common element in the approach, and two options. The common element is to fix the stats on the Fusion Ball Launcher. The two options are to use a stat-based approach, or a cost-based approach, to fix the other weapons.

NB This proposal is still a draft and will need tweaking, but I've got it to the point where it is worth discussing. Feedback is welcome!

''(Ultimately, the Plasma Beam still ends up being pretty much the optimum weapon in the end game. To mitigate this, it is a good idea to select the existing Alternate Energy Weapons Manufacturing option in XComUtil.)''

==== Fusion Ball Launcher ====

Increase the ammo capacity from 2 to 3. Don't mess with the damage. Job done.

See [[User:Spike#Fusion_Ball_Launcher]] and discussions linked from there.

==== Cost Based Approach ====

This uses historically realistic costs to restore game balance between different craft weapons. The stand off advantage of Avalanche missiles is now purchased at a price which is significant in terms of XCom budgets and mission yields. Stingrays and Cannons become significantly cheaper alternatives. The Laser Cannon, with similar capabilities to Stingrays but free to operate, also becomes very attractive. Mounting dual launched weapons becomes a very expensive luxury.

*Increase Avalanche missile Purchase cost to $386,000
*Increase Stingray missile Purchase cost to $125,000
*Leave Sell prices unmodified (to avoid creating a cash reservoir at the start of the game)
*Leave Launcher buy/sell prices unmodified

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

This provides a benefit trade-off to shorter range weapons, by increasing their firepower or effectiveness relative to longer range weapons.

*Increase Cannon stats to 15 Damage, 50% hit. Firepower is tripled, slightly ahead of (unmodified) Avalanches launching in Aggressive mode. Increase rearming rate to 200.
*Increase Stingray accuracy to 80%. Decrease Avalanche accuracy to 60%. Stingray now has 50% more firepower relative to Avalanche. Increase Stingray rearming rate to 2, so a full craft can be re-armed in the same time period with either weapon (instead of twice as long for Stingray).
*Increase Laser Cannon stats to 100 Damage, 50% hit. Firepower is doubled, 20% more than (unmodified) Avalanches launching in Aggressive mode, 2/3rds of Plasma Beam firepower.

To avoid advanced XCom aircraft exploiting the extra firepower of the Cannon weapons and disregarding the return fire from UFOs, this is best used alongside the Tougher UFOs option.

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

Primarily this means making the Rifle a bit stronger, and probably making the Pistol a bit weaker.

=== Advanced Laser Cannon ===
The "Advance Laser Weapons" option only nerfs the Laser Cannon (raising cost and reducing profitability but not changing any damage/range values. Previously xcomutil modified them unconditionally). I wonder if that's the best result - should damage and/or range be raised to make the cannon useful or to compensate? Most commanders don't use the cannon as is, but maybe it's prejudice... [[User:Cesium|Cesium]] 21:36, 16 March 2010 (EDT)

: Note this isn't a "rebalancing issue" compared to the other weapons - I'm talking about (maybe) balancing for the increased cost of production and lower profit. [[User:Cesium|Cesium]] 21:41, 16 March 2010 (EDT)
:: I guess the craft weapon rebalancing options listed just above, either the cost-based or the stat-based, would help out here. The intent of "Alternate Laser Weapons" is purely to make the game harder, which it definitely does. Is it necessary to "balance" something that deliberately makes the game harder? I don't think so. But I do think the general principle should be that there are no "pointless" items of equipment. So either way the Laser Cannon deserves a buff. Personally I never thought the previous XCU buff to Laser Cannon made it worth using. What it gave with one hand (range increase, but still lousy range), it took away with the other (firepower). I would actually rather have the standard Laser Cannon than the old XCU "buffed" one. [[User:Spike|Spike]] 22:11, 16 March 2010 (EDT)

=== Rebalanced X-COM craft ===

Is there any thought being put towards perhaps rebalancing the X-COM craft themselves?

The problem, as I see it, is that the Firestorm and the Lightning are fairly comparable to the Interceptor and the Skyranger, but the Avenger makes them all obsolete in every possible way — and once you have the Firestorm/Lightning, the Avenger is just a single research "hop" away, so they're obsolete almost immediately.

And realistically, how is the Avenger really the "ultimate" craft if you '''don't''' need a transport and just want to shoot things down fast? There's no obvious reason X-COM couldn't come up with a smaller, more compact, more streamlined version of the Avenger that goes even faster but can't transport anything. Or, if we assume we've somehow maxed out the alien propulsion technology's speed, you could use the exact same craft, but put more craft weapons in all that cargo space. (Notwithstanding the current hardcoded limit of two weapons per craft.) Either way, it's just not sensible to say that the Avenger is the best available technology for shooting down UFOs, when a ton of internal space is "wasted" on troops and tanks.

A full rebalancing, IMO, would make the Avenger slowest and least armed (maybe unarmed) but with the most capacity, the Firestorm fastest and most heavily armed but with no transport capability, and the Lightning somewhere inbetween. There's also the possibility of changing the names around, maybe even the research order, though some game text updates would certainly be required at that point.

If the primary goal is to avoid making UFO interception any easier, the Firestorm could take the current Avenger role, at 5400 speed and two weapons, while the Lightning would be slower with one weapon and not really be suitable for taking out battleships, but can otherwise take out anything it can outrun (due to plasma beam range). The Avenger would be the slowest and have no weapons, i.e. a pure transport.

Alternatively, to be "backwards compatible" with current Avenger-style tactics (i.e. a whole fleet of dual-role, battleship-killing craft), the Lightning could take the current Avenger role (5400 speed, two weapons). The Firestorm could be even faster, and the Avenger could be slower with just a single weapon, but (again) can kill anything it can (even temporarily) outrun, short of battleships. But of course, this makes interception even easier overall, particularly with easier four-pack battleship intercepts and reduced fuel consumption.

Either approach would keep all three craft useful throughout the game, rather than the monotonous (and IMO unrealistic for reasons above) Avenger-only force you end up with at the end of the game. Just a thought. I'll be trying some of this with my own game. — [[User:Wisq|Wisq]] 20:58, 18 April 2010 (EDT)

=== SWP switch expansion ===

Just chronicling my thoughts here about some possible changes to the SWP switch (related to the [http://www.strategycore.co.uk/forums/Playing-the-bad-guys-with-XcomUtil-t8079.html&gopid=95894#entry95894 Playing the bad guys with XcomUtil] discussion thread over at Strategycore). It would be nice for a more robust SWP option with a few options to control how it behaves. For any reason, from personal play, testing purposes or if you are indeed playing a hot-seat/e-mailed battle (which was what it was intended for originally).

A few ideas off the top of my head:

* Geoscape and Tactical soldier linking - either erase the links so that they don't count for this battle. Maybe a choice to unload the soldiers so that you don't lose the soldiers even if the Skyranger is lost. Or, an option to transfer the links over to the aliens.
* Improved civilian handling during swaps - either exclude them from the swap, or even provide an option to delete them from the map.
* Improve the shroud of war and light map handling. This one's a bit tricky, but there should be more options than its current setting of making the map visible. There's no way to remember previously visited areas for the individual sides unless you also control dual copies of the shroud and light maps. Or just black out everything and light up the immediate areas around the active side's units. Hard call this one.

Not the most important of features to expand on, but worth considering now that a lot more is known about the game since the command was introduced. -[[User:NKF|NKF]] 02:06, 23 April 2010 (EDT)

=== Using XcomUtil without installation ===

XcomUtil needs installation in order to use it. Installation modifies some things, which the user may not want for some reason. But xcomutil.exe work well with an unmodified game. A good example is just listing things (LST or DIS) but in fact most (or even all) functions of the program do not depend on any changes made by XcomUtil installer - so in fact there is no need for installation. Despite of this, now, in order to use the program without any modification of the game, you must copy XcomUtil files, and next copy manually xcusetup.xcf from another installation to flags. An alternative method is to backup the original installation of the game, next to install XcomUtil, and next to copy back the original installation, with replacing all files.

It would be much simpler just to copy xcomutil.exe, and to have a possibility to run it without all that installing procedure. Unfortunately, as for now it is impossible as xcomutil.exe checks if the package has been installed or not. And if it does not find the flag file, it ends working.

[[User:Sherlock|Sherlock]] 17:58, 30 January 2013 (EST)

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

Is it possible when using the BattleFieldGenerator, for it to detect the actual conditions for the mission (terrain, enemy craft, and light level) and offer these as defaults? [[User:Spike|Spike]] 08:22, 13 February 2010 (EST)
:Press The esc key at the prompt. (Line 719 in Xcomutil.txt, not that I expect anyone to read the manual :) ) Enter should also work. --[[User:BladeFireLight|BladeFireLight]] 12:34, 13 February 2010 (EST)
:: RTFM eh? My biggest failing. Maybe you could add an explicit prompt "Esc or Enter = [whatever the unmodified value would be]". [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)
::: From what I can see, hitting Escape during BFG makes it continue with ''all'' values reverting to the original conditions. It would be nice to be able to select some but not all original conditions. My main use of this is to turn a night mission into a day mission without the hassle of keeping the landing craft hovering around until the terminator crosses the landing site. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
:::: You could just use the force all daylight option.
:::: After reviewing Scott's code. Esc leaves all setting as-is. Pressing enter or any other key not listed will randomly choose for you. I will see if I can change enter to leave as is. --[[User:BladeFireLight|BladeFireLight]] 11:00, 7 March 2010 (EST)
::::: This has been added --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)

= MISC =

* It's actually quite hard to downgrade to DOSBox 0.72 in Ubuntu. Only 0.73 is offered, there is no ability to Force back to a lower package level with Synaptic Package Manager. Unix guru skilz are required to rollback to 0.72, and I guess 0.74 is not around yet, or not packaged for Ubunut APT? Is there any way to fudge around this, e.g. by providing the command line arguments in an optional text file for xcusetup.bat to parse? Having said that, even with no command line arguments, xcusetup hangs on my 0.73 DOSBox while executing SDUMP. I had to reboot in Windows to run xcusetup.bat - something that is only possible on a dual boot machine / Wubi machine. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
** Try using a different batch interpreter like 4DOS [http://www.4dos.info] to execute xcusetup inside DosBox. I tested this throughly before under DosBox/Linux and it works well with recent 9.7 builds. I suggest running "config -set cpu core=dynamic" and "config -set cpu cycles=max" before xcusetup to speed it up (xcusetup doesn't detect DosBox when 4Dos is run, so it doesn't run these automatically unlike normal DosBox case). [[User:Cesium|Cesium]] 09:48, 7 March 2010 (EST)
** Oh, and downgrading isn't that difficult: Get a dosbox 0.72 deb, and run "dpkg -i" on it, and then do "echo dosbox hold | dpkg --set-selections" to prevent future upgrades. [[User:Cesium|Cesium]] 09:50, 7 March 2010 (EST)
** Another option is to install the dosemu package, and run xcusetup under that. EU/TFTD can be run under that, but it doesn't work as well there. (Oh, and there's no mount command there. UFO/TFTD needs to exist under ~/.dosemu/drive_c which is C:) [[User:Cesium|Cesium]] 11:42, 7 March 2010 (EST)

:Thanks Cesium I will check this out. I still think it would be good to have a solution that works for people who are not knowledgeable with the unix command line though. [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)

:: Why use Linux if you dont know how to use the console? It is a text mode OS with a separate GUI. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

::: Well Ubuntu is a bit different, as it's supposed to be an OS for the general public, where you never need to touch text mode! Incidentally I can't find any DEB or other packages for 0.72, all that is available on the DOSBox website is the source code. They really don't seem to realise that 0.73 is buggy! So I guess I will need to '''make''' it. Or just wait for 0.74 as I think it's out soon. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)

:::: See [http://archive.ubuntu.com/ubuntu/pool/universe/d/dosbox/] for 0.72 debs. Unlike Windows, package systems in Unix land are centralized, so best location to search is typically a package server mirror or a distro mirror, not a vendor's website. [[User:Cesium|Cesium]] 17:36, 9 March 2010 (EST)

= Read The Fine Manual =

As otherwise you'll be trying to run a modified Interceptor tactical mission without using the required batchfile, resulting in...
<blockquote>===Crewed Interceptor Issues===
By default, the DOS version (and possibly others) of XcomUtil will allow you to outfit interceptors with a crew and equipment. However, if you attempt to perform a tactical mission of any kind with an interceptor, the TACTICAL.EXE portion of the game will go to a black screen. Pressing escape or enter will cause the game to return to GEOSCAPE.EXE with a mission rating of 0, as if you had never attempted the mission at all. The worst part of this, however, is that the agents and equipment that were on board the interceptor will be lost.
This likely occurs for two reasons:
* The tactical portion of the mission fails because no battlescape configurations or terrain exist for the interceptor, since it was never meant to hold crew.
* Upon returning to the geoscape, it is likely that the game "realizes" that interceptors are not supposed to carry crew or equipment, and promptly destroys the passengers and equipment that it is carrying.</blockquote>
::I think that the reason for losing the crew and equipment actually is not due to the game waking up to the fact that interceptors cannot hold them. In fact even with the game modded to allow craft to transport said soldiers and material I would be willing to bet that you will still lose them if the battlescape fails due to there being no map for the ship. The reason is because when the mission is started it places those soldiers and equipment on the terrain, but for the craft which aren't normally capable of it the game doesn't know where to place them. Thus when the mission fails none of your soldiers or equipment were actually in the game map to be retrieved, resulting in their loss. In fact it is possible that even with the craft map and modifications to the exe, you may still lose all soldiers and equipment if you don't have XcomUtil to place them on the map built for that mission.[[User:Mannon|Mannon]] 19:01, 3 April 2011 (EDT)

User talk:Morgan525

2013-01-30T22:24:02Z

Sherlock: /* Incorrect Calculation of Remaining Stores Capacity */

=Questions&Feedback=
Any questions or feedback one may have.... (please be sure to leave a signature: "~" three times in a row, four to time-and-date stamp it.)

'''FYI: I've created a new [[UFOextender|UFO Extender page]]. If you are having a problem on this, please use the discussion page located there. If your message is about UFO Extender, you can leave it here but I may start copying it to the UFO page and leaving my reply there.'''

== Decompiled accuracy algorithm? ==
Hi Morgan/Tycho

Is the algorithm you describe above, what you have decompiled from the standard game? Or is it a variant for UFOExtender? Great news if you have decompiled what the game actually uses - I will need to check some of my firepower calculations to make sure they are still in line with the algorithm.

cheers,
[[User:Spike|Spike]] 09:37, 30 June 2012 (EDT)

''It is an extender version of the original formula if one chooses to enable it. The original is the one that has been noted already: [1+(3/UFOsize)]/2 * Weapon Accuracy ... UFO sizes going from 5 for very small to 1 for very large. The calculation starts at offset 0x446DCD of the CE version. The original UFO accuracy algorithm is a flat 60% chance to hit despite the difficulty level (and no penalty for the Xcraft being in cautious mode.)''

[[User:Morgan525|Tycho]] 19:23, 30 June 2012 (EDT)

== Question on new Installation ==

Going through the same steps from the UFO Extended page.

However every time I try to launch through Steam or within the installation file I crash. I am wondering if it's because the newer versions of UFO extender here: http://www.ufopaedia.org/index.php?title=File:UFOLoader.zip is just a patcher.dll file.

[[User:Lowpro|Lowpro]] 21:22, 3 October 2012 (EDT)

:''maybe. You will need to download the full version and then download the latest patch file. This is a problem when people make links directly to the file and not the download page. Follow the link on my page to the download section. Download both files, extract the full version into your game folder, then extract the patch into the same folder and choose 'yes' to overwrite the current file. If your still getting an error, you'll need to contact the person who wrote the UFO Extended page. You might need to configure your steam shortcut in some way.-'' [[User:Morgan525|Tycho]] 22:44, 3 October 2012 (EDT)

Thanks for the reply. I'll give you my rundown and maybe we can track down my issue. I followed your page but again I'm taken to the File:UFOLoader.zip page. I downloaded the August 6th version which has: COPYING, ENGLISH.DAT, patcher.dll, UFOExtender.ini and its Readme.txt file,UFOLoader.exe, and a version txt. After I extract that to my XCOM installation folder I also download the latest patcher.dll file (The September 27th version) and overwrite.

When I try to launch the game through Steam, I crash (screenshot of the error http://i388.photobucket.com/albums/oo324/chipkimble/XCOMerror_zps7c86e23e.png) . When I choose the the "Launch Windows 9x/XP Version I crashs"

When I drag-and-drop the "UFO Defense.exe" over my "dosbox.exe" I crash. I do this because previously I used the UFO Extender steps found here http://forums.steampowered.com/forums/showthread.php?t=1146530 and part of launching without crashing meant I had to drag and drop the UFO Defense.exe file. However with that particular 2010 version I'd crash as soon as I researched some live aliens (be it researching a Medic or a Soldier etc)
I'm trying to play catch-up at the moment with troublefixes but can't find a golden one yet.
Thanks again! -[[User:Lowpro|Lowpro]] 20:22, 4 October 2012 (EDT)
:''You should be using v1.28 and patch 1.28.3. Extender doesn't work in DOS and can't be run through DOSbox, but I don't think this is your problem. Using within the steam framework requires some modifications to the steam shortcut (setting it to run UFOloader.exe and not UFO Defense.exe). Don't forget that the new INI only has a basic configuration: You might check that it is set to run D3D for video. I can't offer much support integrating into the steam interface because I don't use it and don't know it. If you want to run the game in a stand-alone folder, I can definitely help. If you want to run through steam, you might be better going to the strategycore topic on UFO Extender [http://www.strategycore.co.uk/forums/topic/10013-ufo-extender-128/]and posting your problem there. Several members say that have gotten it or TFTD Extender to work on their systems. I belive there are several discussions on getting the Extenders to work through Steam on the steam forums as well.-'' [[User:Morgan525|Tycho]]

''Disable skip intro in the video section and see if the Extender will run.-[[User:Morgan525|Tycho]]''

''The occasional crash on researching a medic is a known bug for which no solution has been found as yet. - -''[[User:Morgan525|Tycho]] 02:14, 9 October 2012 (EDT)

== Source ==

Hi Tycho

Do you make the source code for TFTD Extender and UFO Extender available somewhere? I'm interested in seeing if I can help to hunt down bugs / develop new features. Cheers, [[User:Spike|Spike]] 08:23, 4 October 2012 (EDT)

:''I'm getting to it. Tonight is the first time I have been able to look at the code. I did manage to find the problem with the loader and the game executable. -''[[User:Morgan525|Tycho]]

''I just uploaded a new version of the UFOExtender source files to Seb's list.- -''[[User:Morgan525|Tycho]] 06:04, 6 October 2012 (EDT)

''Source code for TFTDExtender is now available from my user page. -[[User:Morgan525|Tycho]]''

== How to start modifying the game code ==

I like some of the changes made in the UFO extender but dislike others. I'm also running X-Com through DOSbox so it's a moot point anyway. Essentially I'd like to be able to make modifications to the game - like fixing the dismantled structure bug - myself. Where should I start? I have some experience with object oriented programming through languages like C# (most familiar) and Java.

[[User:Juke|Juke]] 21:04, 16 October 2012 (EDT)

Your first step is going to be to become very familiar with Disassembly and Disassemblers. Most people use IDA. Then your going to have to be able to understand the language itself. Take a look at the few examples on my page and see what it looks like. That code comes from the CE version, the DOS version doesn't disassemble as well (at least with any free dissassembler that I've found). [[User:Morgan525|Tycho]] 23:24, 16 October 2012 (EDT)

I am running the game on steam with the DOSBox. Will I still be able to make changes to the source code? Thanks for the info btw.
[[User:Juke|Juke]] 22:03, 28 October 2012 (EDT)

:''I started using the DOS version under DOSbox and making simple changes to the data points via a hex editor. However, it is really hard to do more than that.
:''The problem is knowing where to make changes since no free program is able to disassemble the DOS version well. For that reason, I switched to the Windows version.''

== Shifting 5 shot laser mod to other weapons ==

Is there any easy way to shift the 5 shot mod that's currently on the heavy laser on to other weapons? I plan on getting the source code and working on it a bit (it's been years since I've touched assembly, I mostly code in C# now), but it'd be helpful to have a clue of where to start looking. I'd love to contribute to the project as well. [[User:KingMob4313|KingMob4313]] 09:27, 17 October 2012 (EDT)
:''I'm sure it can be done. I focus on providing content that will enhance the challenge of the game from a somewhat logical viewpoint without making changes just to make the game harder. The source code for Extender is available and mostly written in C++ so you shouldn't have much trouble understanding it. You will need a disassembler, such as IDA, for the actual game executable and be familiar with how to decipher the tangled mess of assembly code that IDA provides. For some features, I can write the code in C++ but, for a lot of fixes, I find writing in assembly much easier to insert into the proper subroutines. - [[User:Morgan525|Tycho]] 09:54, 17 October 2012 (EDT)''
::I should have just read some of the above responses, I am sorry. I will take your advice and pick up the disassembler and try to familiarize myself with the code a bit. Seems that everything works via a hook-system, where it waits for the calls to the subroutines and replaces it, correct? In any case, I appreciate the quick answer. [[User:KingMob4313|KingMob4313]] 12:30, 17 October 2012 (EDT)
:''The hardest part of familiarizing youself with the code is that the subroutines and variables are just offsets with no identifiers. If you take the time to match offsets to labels given in the xcom.h file (in the Extender source) you can manually transfer the labels yourself. This will make analyzing the code much easier. - [[User:Morgan525|Tycho]] 20:07, 17 October 2012 (EDT)''

== We're all... feeling... so... sleepy ==

Hi Tycho

Well, I was not expecting that! Your TSL-firing Hallucinoids just kicked my *ss on a Superhuman Colony Assault. They kept firing their TSL-like built in weapons - in fact it looks like it's an auto burst TSL? - right into the transport door. And I kept popping another guy out of the door to grab the bodies outside and take out the Tasoth with a TSL I presumed was out there. I could never see the Tasoth, just some stupid Hallucinoid floating around - and they're never a threat, right? Wrong!

Brilliant, in one stroke you have breathed new life into a previously-ignored enemy, making it as frightening as it always should have been. I hope you don't mind me adding a slight spoiler to the Bug Fixes section - if you do, feel free to revert it so you can surprise others like you surprised me. :) Cheers, [[User:Spike|Spike]] 18:46, 21 October 2012 (EDT):

:''Hehehe. >;) No, its not autofiring but the Hallucinoid has a high reaction score and the cost to fire their weapon is 33%. However, they don't often move so they always have most of their TUs. Now that they have a valid range weapon, they are extemely deadly in outdoor settings. Indoors, they tend to stun themselves too often. I'm thinking they might need to have their immunity to stun increased or build in an exception into the alien spawn routine that turns off their TSL attack indoors.-[[User:Morgan525|Tycho]] 19:53, 21 October 2012 (EDT)''
:: Ah, good explanation, thanks. Yes I think it would be a good idea to increase their Freeze resistance considerably. After all they are (now) the definitive freeze-using monster from the deep. As a four square unit they will take extra damage from their own attack, approaching 3-4x at point blank, so think it would be fine to give them a very high immunity, maybe take only 20% damage from Freeze. Or even 10% / completely immune. In fact it's probably simpler just to say they are immune (0%). [[User:Spike|Spike]] 20:50, 21 October 2012 (EDT)

== Bugs and wishes :o) ==

Hi Tycho

I am using your extender and it is great thing! I am using it together with modiffied UFO Defense.exe that uses MP3play.dll to play MP3 files because the routine you have implemented in loader pause the game every time the music is changing. The MP3play.dll doesn´t do that and is able to play intro music in MP3 as well. So I have now the best version ever ;) because I moddified the music by Lorcan to synchronize it with the intro, so I have the intro with MP3s instead of MIDs :)

But I have found some little problems with the game. I have found that when I ended the tactical mission and when the returned to the geoscape the game shows me the first screen line garbled in some windows. When I open "Build new facilities" window there is some bug at the top of the screen and also in the window noticing me there is terror somewhere. The first line of this window is missing everytime (compared with the original DOS UFO) in the Windows (collectors edition) version. So it is the bug in the CE version, but can you repair it by the loader?

----

<s>The other thing it does to me that when I activate Animations Speed=1 in the ini file the arrow showing above my men slowdown the animation, but many other things like UFO Power device or the UFO navigation screens goes even that set on very fast. And there appears a bug that cause the smokes didn´t probbably stoped animation at all when the bullets go through it or a man is walking through - it looks like it goes surrounded by some box (it looks to me it is the other (not correct) frame of the smoke displayed behind the man or bullet).
Can you correct these bugs, please?</s>(corrected in version 1.29 using battlescape speed settings)

----

And - sometimes - the game crashes to me after the second move (maybe because I have set on "First move crash bug" on, if I have it set off it sometimes crashes on the firts move :) I don´t know exactly the reason when it happenings but I have an idea :) What about to implement the AUTO save option to a folder named e.g. AUTO which will be automaticaly saved before you turn at the first time (before the battlescape appear after you equip your mens). This will temporarily evade that bug, but if you can find what is hapenning, surely the better way is to fix that bug :)
I hope I did´t made some chaos in messages here, I am newbie here, and I haven´t found another way how to contact you.
Thank you very much!
Lukas
Czech Republic
<s>
Underline:
I am new here and I don´t know if I could write here my qestion and feedback to UFOLoader that you made because I haven´t found any of your e-mail somewhere. If there is another way to contact you, can you please send me a message to here how can I contact you? Or put here please an email address or send me a message to lukop ("@") seznam.cz. Then you can delete my added message here..
Thank you!
</s>

I will write my reports to here..

--[[User:ElfKaa|ElfKaa]] 19:30, 01 January 2013 (EDT)

[[User:ElfKaa|ElfKaa]]

== UFOLoader ver. 1.29 Bugs ==

Hi Tycho

I have probably found some bug in new version of the UFOLoader.

It is very nice that the geoscape works fluently now with the Geoscape speed set to 1 but I think this cause problems with the game speed at all.

I tried to compare the game played with this speed settings on and off and I have noticed that there are less detections of UFOs with the settings on then with off.

The other not good behavior happend to zoom by mouse - with ON it is very slow if you have 5 seconds mode, in 1 Day mode it is fluent.
I think - this could also moddifies the game heart speed so the first ufo is detected after few more days (it is very complicated to confirm that behavior, but you can try DOSBox UFO and see the difference and also it works better if you turn the Geoscape speed setting off.

The other thing is that the mouse affecting the speed of animations when is moving (but it does also in all previous versions) - it could be seen on the radar lines in the interception screen.

Can you please check the speed and the detection of UFOs? It seems to me that because of the speed modification the detection notification doesn´t appears so often and happening randomly.

Thank you very much!
Lukas
Czech Republic

--[[User:ElfKaa|ElfKaa]] 19:50, 01 January 2013 (EDT)
[[User:ElfKaa|ElfKaa]]

[[User:ElfKaa|ElfKaa]]

== Incorrect Calculation of Remaining Stores Capacity ==

Hello,

You seem to have removed my text from [[Talk:TFTDExtender]], compare http://www.ufopaedia.org/index.php?title=Talk%3ATFTDextender&action=historysubmit&diff=44262&oldid=44261. This is the text:

To reproduce this error, do as follows. (1) Place Ajax Launcher(s) on your craft. (2) Fill your stores with whatever you want. They should be full. (3) Rearm your craft, exchanging Ajax into D.U.P. Now your stores should be overloaded. (4) Stores free capacity indicator (on Bases screen) shows that there is some space left (ex. 48:50) but it is not true. To check it, just sum all the place taken with all your stored materials.

Indeed, even if "technically" you have free place in stores, you cannot unload your transporter, and if you try, you receive a message that there is no free space left.

Not sure if this is an original error either.

This file may be useful for testing: [[File:store_error.zip]]

[[User:Sherlock|Sherlock]] 05:51, 21 January 2013 (EST)

Was it anything wrong with that text? Or you just moved it to another article?

[[User:Sherlock|Sherlock]] 17:24, 30 January 2013 (EST)

Talk:TFTDextender

2013-01-21T10:51:17Z

Sherlock: /* Incorrect Calculation of Remaining Stores Capacity */

=Questions or Comments=
'''A place to provide feedback or ask questions:'''
:''Thanks to Kyrub, Spike, and numerous others who help to troubleshoot problems, provide feedback on releases, and innumerable other activities to help make TFTDextender and the game better! -'' [[User:Morgan525|Tycho]]

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

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

== Bug Reports ==
===Major Bugs===
==== Crash when starting a landed/crashed USO battle ====

:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."

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

=== Minor Bugs ===
==== Stunned Carried Aquanauts MIA on Abort ====

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)

:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. Your right, carried objects won't have their location updated until they are dropped or thrown. At least it is a manageable issue: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)

==== Incorrect Calculation of Remaining Stores Capacity ====

To reproduce this error, do as follows. (1) Place Ajax Launcher(s) on your craft. (2) Fill your stores with whatever you want. They should be full. (3) Rearm your craft, exchanging Ajax into D.U.P. Now your stores should be overloaded. (4) Stores free capacity indicator (on Bases screen) shows that there is some space left (ex. 48:50) but it is not true. To check it, just sum all the place taken with all your stored materials.

Indeed, even if "technically" you have free place in stores, you cannot unload your transporter, and if you try, you receive a message that there is no free space left.

Not sure if this is an original error either.

This file may be useful for testing: [[File:store_error.zip]]

[[User:Sherlock|Sherlock]] 05:51, 21 January 2013 (EST)

== Things that TFTDextender does not fix ==

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

* Does not fix the apparent swap of the ground map for the VERY SMALL Survey Ship (1 occupant) with the SMALL Escort (half-dozen or more occupants). So you get the VERY SMALL sub occupying about 25 squares of usable area on the Battlescape, and the supposedly larger SMALL sub occupying one square of usable area on the Battlescape, begging the question of how all those aliens got inside there in the first place. XcomUtil will fix this, as will the original patches that XcomUtil incorporates.
* Does not fix the incorrect pictures for the large USO in the interception window.
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]
* Does not fix the Dart Gun to make it any less utterly useless. Though you can do this yourself via the OBDATA.DAT section of TFTDextender. (Suggestion: don't fix it. The useless Dart Gun is all part of the "oh no we're all gonna die" experience of the beginning of TFTD.)
* Does not improve the armour and effectiveness of the basic Aqua-Jet and Gas Cannon Coelecanths (it does upgrade the Coelecanth/Gauss). (Again, suggestion: this is a good thing - XCOM should start the game hopelessly outclassed, and scramble to catch up).
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.
* Does not allow you to have 360 degree vision out of your sub before exiting it. (What kind of coward would want that?). XComUtil does this.

*When I try to send any Leviathan to T'Leth, I get an immediate crash: "XCOM crashed at 0x458822 with error 0xC0000005 trying to access 0xFA6C8304.".
:It happens when the CE version doesn't find the RISE animation: Specifically, it needs ANIMS\RISE.IDX and ANIMS\RISE.VID - If RISE.IDX is missing, it crashes with the error code above, if RISE.VID is missing, it crashes with another error. Some experimenting suggests that RISE.VID can be any valid .VID file, while RISE.IDX can either be empty (producing a black screen that can be skipped by clicking) or the "appropriate" .IDX for the used .VID...[[User:AMX|AMX]] 13 November 2012 (EST)

=Resolved Reported Problems=
===<s> Save Equipment not working</s> ===

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

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

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

:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

===<s> Weight Issues or "Weightless" Ammo Bug </s>===

while playing TFD with TFD extender (v. 1.05 patch 1.1) I've noticed a stange thing: some soldiers have their weight > 0 (2-5) even when their inventory is empty! Bug?... [[User:PavelB|PavelB]] 05:17, 27 September 2012 (EDT)
:If you drop a loaded weapon, even if you loaded it manually, the weight of the ammo still stays with the Aquanaut. Workaround: unload each weapon manually before dropping it. If you forget (and if you notice) it's possible to pick the weapon up again, unload it, and correctly lose the weight by dropping the weapon and clip separately. It's possible to build up huge amounts of phantom weight on a Soldier by repeatedly loading, and then dropping, different weapons. It's also possible to move lots of weapons with weightless clips to one Soldier, increasing the amount of 'free' weight that one Soldier gets. Both of these effects are probably aspects of the original bug, not anything that UFOExtender has done. [[User:Spike|Spike]] 11:15, 27 September 2012 (EDT)
::This Weight error is a side effect of an original game error that Seb never quite fixed. Removing clips from a Soldier or Aquanaut does not remove the clips' weight. This is because the clips are not correctly assigned to the Soldier or Aquanaut in the first place. See [[Talk:TFTDextender#Weightless Ammo Bug]].
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)

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

===<s> Items on transport floor lost on Abort</s> ===

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

:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

===<s> Coelacanth/Gauss mutates into Coelacanth/G.C.</s> ===

In my current game (using the Steam version) I observed it twice that, when a Coelacanth/Gauss is removed from a sub due to lack of ammo, it turns into a Coelacanth/Gas Cannon.
Note that I'm using only the Gauss Tank Ammo Fix, but not the Gauss Tank Turret Stats Fix, nor the Improved Gauss Tank mod.
[[User:AMX|AMX]] 09:09, 1 November 2012 (EDT)

:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

===<s> Cannot build Leviathan </s> ===

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

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

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

===<s> Executable directive </s>===
''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)

=== <s>Extra Artefacts Reported</s> ===
''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)
:'''Fixed in the patch 3.1-'''[[User:Morgan525|Tycho]]
: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)

===<s>Manufacturing Projects Minimum Production</s> ===

In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)

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

:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)
''' Changed the output to display "$unlimited$".'''[[User:Morgan525|Tycho]]

===<s>Stunned MC'd Aquanauts MIA on Abort </s> ===

This is a subset of MC'd Aquanauts go MIA [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]. In this case Aquanauts are MC'd by the aliens, then stunned (by friendlies), then the mission is Aborted with the stunned X-Com Aquanauts aboard the transport. The Aquanauts then disappear from the roster forever. I'm not sure if it's due to Abort rather than Victory, or due to them being stunned first. This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)
:'''I now have the code in place to uncontrol any creature that has been rendered unconscious. Available in patch 3.1- -'''[[User:Morgan525|Tycho]]

====<s> Crewed Flying Sub Lost on Abort </s>====

Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)
:''I found the nature of the issue here: This only will happen with a tank present. On one hand, all parts of the tank are being counted separately but then the End of Battle routine calculates the number of units correctly (ignores three of the sections of a tank) but when it goes to locate the units on the battlefield, the three other parts of the tank are being counted and thus the last three aquanauts are not checked since the 4 areas of the tank are first in the UNITPOS.DAT file.-[[User:Morgan525|Tycho]] 09:47, 24 October 2012 (EDT)''

'''Fixed in 105 patch 4.'''-[[User:Morgan525|Tycho]]

=== <s>Grenade Resistance in INI file </s> ===
:''I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]

===<s> Materials deducted from wrong base </s>===
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)

===<s> OBDATA / Dye Grenade mod not working? </s>===
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)

=== <s>Displacer/Sonic damage fix</s> ===

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

===<s> Weight Display in Inventory not Localised </s> ===

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

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

= Feature Requests and Suggestions =

== Useful alien species research ==

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

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

Definite +1. It would be equally valid to add to UFO Extender. I suppose it could also be implemented using Vulnerabilities (no Vulnerabilities are in effect until the Autopsy is completed), or Resistances (across-the-board increased Resistances until Autopsy is completed). If that's easier.
:''The bonus to hp was an initial thought. Later, I decided against it since it would make aliens more resistant to HE and stun, which don't rely on hitting the right locations. Increasing resistances would be the most appropriate but the damage routine code is very tight and adding anything new that won't break the existing variable stack pointers is tough. Tycho ''
::''A new idea for this that I recently have been toying with, would be on the damage generation routine: Most direct fire damage is <s>0-200</s> 50-150%, with anything over 100% considered a "critical hit". If autopsy hasn't been preformed, then the base damage would be 0-100% and a small chance (maybe 25%) of another 0-50% for that lucky shot. With autopsy done, the game reverts back to the usual <s>0-200</s>% on any hit.''
That works. And it makes doing Alien Autopsies a no-brainer, as it should be. It is pretty much inconceivable that XCom wouldn't prioritise the autopsy of any newly encountered alien. And any player playing the game for the first time would do autopsies too. This mod will help experienced players to stop playing as if they've "seen it all before". Spike 10:35, 15 September 2012 (EDT)

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

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

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

== All Units Can "Fly" In Water ==

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

== Aliens Pick Up Weapons ==

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.

: 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)
:''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)''

==General Tank Modding ==

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

Thanks,
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)

== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==

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.

This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.

== Fix Interception and Navigation Course Algorithms ==

Or just find the algorithms and I volunteer to fix them!

=== Use Great Circle Routes ===

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!).

=== Use Predictive Interception ===

For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.

=== Show Degree Headings ===

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.
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.

== Interception Craft vs Touched Down Alien Craft ==

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.

For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach.

== Fun, not Funky, Fire ==

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.

== Retaliate for Colony Assault ==

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.

== TFTDextender and XComUtil ==

I suggest adding a section on co-operating with XComUtil. As for now the article informs that the the exe split as done by XComUtil is incorrect, and there is a cure for this problem (btw., why not to correct XComUtil itself?). But this is not the only problem. XComUtil installer can detect UFOextender - but has no procedures for TFTDextender at all. You may suppose that installing both is possible this way:
1. copy TFTDextender files into the folder where TFTD CE is installed,
2. install XComUtil to that copy of the game,
3. copy BB's Toolkit into the game folder and correct the exe split,
4. rename TFTDextender.exe into UFOloader.exe (and .ini as well?),
5. copy sebLoader.xcf from an existing instalation of XComUtil for UFO:EU CE + UFOextender.
Perhaps it will work. Has such a combination ever been tested to work properly?

And why it should be so complicated? Is it possible to make needed changes in XComUtil? But it has support for UFOextender - why not for TFTDextender?

== Trojan Horse? ==

AVG Anti-Virus reports that TFTDExtender.exe contains a Trojan Horse (Generic30.MKG). Could you fix this somehow?

[[User:Sherlock|Sherlock]] 05:21, 14 January 2013 (EST)

== Another patch to the research tree ==

Thanks to TFTDextender, Coelacanth/Gauss is no more dependent on the alien-based sub technology, and this is fully correct, bravo! I would like to call your attention to another strange research tree dependency. I mean you can start with working on Bombardment Shield only after finishing with The Latest Flying Sub. It makes the shield completely useless. Namely: it is not enough to finish with New Fighter Transporter, next you must examine Lobster Man Commander. Assuming that you have already investigated The Ultimate Threat, when you finish with that beast, you will get two new topics: T'leth the Alien's City, and The Latest Flying Sub. Let's assume you will investigate the sub first. When finished, you may start constructing Leviathan. In the same time you can work on T'leth. In practice, when Leviathan is ready, you will also finish with T'leth. In this very moment you can float to T'leth and finish the game, even not having started the Bombardment Shield topic. So, where is the use of Bombardment Shield?

But assume that despite of all you very much want to see how it looks and how it works. So, OK, after having investigated Leviathan, you can start the Bombardment Shield topic. In the same time you can construct the sub. It is very likely that you will have Leviathan at your disposal when you finish with investigating Bombardment Shield. Now you can start investigating T'leth, and constructing the facility. But this is a little problem - the constructing of Bombardment Shield needs 38 days! It means that even in this scenario you will be ready to go to T'leth before you have even constructed the facility! And if you really wanted to see how it works, you would have to wait a month or even longer, until a hostile sub appears at your gates. What for should you wait if you are ready to go to the heart of the aliens' empire, and finish with them? Such a game when there is no more to investigate is just boring.

Hence my proposal to make Bombardment Shield to be similar to Grav Shield in UFO:EU. If the topic depended on New Fighter Transporter as a prerequisite instead of The Latest Flying Sub, you would have some use of this facility. It could be ready to work even before having any Leviathan constructed. And you would have a chance to see it working.

My personal opinion is that the dependency of Bombardment Shield on The Latest Flying Sub is another mistake of TFTD programmers. So, it is a bug, and such a change of the research tree would not be a mod but a patch rather.

[[User:Sherlock|Sherlock]] 05:56, 14 January 2013 (EST)

== A proposal for another alternate research tree ==

Alien technology is based on Zrbite and Aqua Plastics. When you investigate a product of alien technology, you will be able to reproduce it in your workshops. How is it possible without having an idea on materials of which they are constructed?

Both UFO:EU and TFTD research trees basically ignore the need of knowledge on alien materials. It is quite logical as long as you just use alien weapon - but it becomes really strange when you produce the weapon. How to work with a material when you do not know its features?

My first question - would be possible to separate of using an object and reproducing it? If yes, it is all right to obtain e.g. a sonic pulser, next to examine it, and when finished, to use it. But not to produce it, until you learn on zrbite. The basic idea is that only after finishing your zrbite investigation, you should have possibility to construct your own sonic pulsers.

The first possibility is that it could be done by a very simple metod. When you get a crystal of zrbite or a sample of aqua plastics, it could be just artefacts unless you have them investigated. Then you will be able to use e.g. sonic weapons (after having them investigated) - but as you would not see zrbite and aqua plastics as such, you would not make any use of them, including making sonic weapons by your own.

The other idea is that nothing can be understood if we have not obtained knowledge on alien materials which are needed to produce the investigated object. It means to make them real prerequisites for investigations. Now Disruptor Ammo needs Zrbite for producing, and it needs the Zrbite topic finished as its prerequisite as well. I mean to make Zrbite a prerequisite also for all three clips for sonic weapons, Thermal Shok Bomb, Sonic Pulser, Vibro Blade (and both thermic lances), Ion-Beam Accelerators, Ion Armour (and Magnetic IA), M.C. Reader (and M.C. Disruptor) - as they all need Zrbite when produced. And also to make Aqua Plastics a prerequisite for all three sonic weapons, Thermal Shok Launcher, Disruptor Pulse Launcher (and P.W.T. Cannon), Ion-Beam Accelerators, Magnetic Navigation, M.C. Reader (and M.C. Disruptor) - as they all need Aqua Plastics when produced.

I have tested such a modification of the research tree just by stopping any investigations of objects from the two lists above until Zrbite and (Deep One Corpse +) Aqua Plastics topics are finished. In my opinion it does not unbalance the game except it gives another argument for using Gauss technology first than sonic. Namely, under this condition it is enough to finish just three topics: Gauss Technology, Gauss Pistol and Gauss Pistol Clip, in order to have a little more effective weapon at one's disposal. But if you want to use sonic instead, you must obtain a dead Deep One on a mission, plus some samples of Zrbite (and Aqua Plastics - in fact there is not such a condition), and you need to have researched five topics altogether: Deep One Corpse, Aqua Plastics, Sonic Pistol, Zrbite, Pistol Power Clip.

It would be a modification of the game as nothing similar is implemented in either UFO:EU or TFTD (except the need of knowing Zrbite in order to start investigation of Disruptor Ammo).

[[User:Sherlock|Sherlock]] 07:16, 14 January 2013 (EST)

== The research tree - Yet another bug? ==

Now you do not have to have some objects in your stores in order to examine (?) it. It looks like your engineers are so genius that they can guess how those objects look like, not even having a single look on them. Your invented copy appears to be just like the genuine alien object. Is this scenario logical at all? I think it is not, and it is just another bug which should be removed. The only problem (?) is, however, that this bug (?) makes the game easier. So, patching it would make the game harder.

Namely, I think that 4 objects: Aqua Plastics, Vibro Blade, Thermic Lance and Heavy Thermic Lance should be present in stores to start examination on them, naturally when other conditions are fulfilled. So, for example, you will still have to examine Deep One Corpse, but it will not give you a way to inventing Aqua Plastics. First you will have to get them, and keep them in your stores. And only them, after finishing Deep One Corpse, you will be able to start examining (not: inventing!) Aqua Plastics.

And the same with the finished Calcinite Corpse topic and a stored Vibro Blade, the finished Vibro Blade and Gill Man Corpse topics and a stored Thermic Lance, and also the finished Thermic Lance topic and a stored Heavy Thermic lance.

[[User:Sherlock|Sherlock]] 07:27, 14 January 2013 (EST)

== The Calcinite Dilemma ==

The need of researching both Deep One Corpse and a live Deep One has been named the Deep One Dilemma. Personally, I cannot see a problem in there, and I really cannot understand the other players. I have played TFTD many times, and I have never any least problems with obtaining both corpse and a live specimen of this creature. In a result, I do not understand why it can harm anyone. But you can buy Thermal Tazers at the very beginning of your campaign. They are cheap and easy to use. Deep Ones always appear several times in early missions. They are not too dangerous, and you can enough safely freeze one. And even more, if you use human weapons like darts, you have a high chance to get one live without any freezing.

So, what is the source of this dilemma? You know you need this creature. You have enough numerous possibilities to hunt for it. You have weapons which are suitable for this. So, where is the problem? If you do not want to capture a Deep One, and you prefer just shooting and kill'em'all-ing instead of playing, do not complain then that you have no progress in your research. Just keep shooting... I do not believe that killing aliens is the only objective of the game. It is OK that there is a possibility to eliminate the need of Deep One to research Ion Armour - but it is nothing but a cheat. I do not like it, and I will not use it. Just like adding money or making my aquanauts superhumans.

But Calcinites and the need of the body of the creature for starting with examinating melee weapons is a completely different problem. As I said, I have played the game many times. And I have never spotted a single calcinite during first months of the game, and telling the truth, I have whole campaignes without any single creature of this kind. I believe there is an error in the game which prevents from appearing aquatoids on terror missions.

And hence my question: is it possible for TFTDextender to control which alien race starts an alien mission in the game? It would be the solution of the calcinite problem I would like much. Instead of manipulating with the research tree, it would be enough to forse some mission types from the same beginning. If aquatoid + calcinite missions, as well as gill men + deep ones mission were still present during all the game, nobody could also complain that he/she cannot capture a live deep one. And it would give a better chance for getting melee weapons earlier (without hacking, cheating and changing the research tree).

[[User:Sherlock|Sherlock]] 07:50, 14 January 2013 (EST)

== And yet another reason for forcing some alien mission types ==

In TFTD some terror races are seen mainly or exclusively on lands while other under the sea. Let's assume a Battleship is heading to an island, a port, or a human ship, in order to start a terror. Save the game, and shoot it down (if you can...). Go to a mission. And what will you see? If it was a aquatoid mission (very rarely!), you will fight with Hallucinoids. If it were Gill Men aboard, you will have unpleasurement with Xarquids (btw. does it mean Xark = Shark + Squid?). Break your game, and load it from the save. Let the sub land, and go for the terror mission. Now you will see Calcinites with Aquatoids, or Deep Ones with Gill Men.

How is it possible? The same sub, the same alien squad. And different results! It would be pretty easy to understand if there were not aquatic creatures on land missions: they were aboard on the Battleship but they did not get off. The sub floated back with them, leaving the main race and their land pets on the land, terrorizing people. But if it was so, you should spot both land and aquatic races when having the sub shot down. And it would be really great if it was so.

In UFO:EU mutons are associated with silacoids and celatids in the same time. When you spot one terror race, there is a very big chance to spot the other as well. In TFTD things go otherwise. Both Bio-Drones and Triscenes are associated with Tasoths on land missions, but they probably never happen side-by-side. Contrary to Mutons, Tasoths have either Bio-Drones or Triscenes, never both on the same mission.

Both games have the same engine, so it should not be a problem to force it to generate more various alien squads. First, I mean both Bio-Drones and Triscenes together on the same terror mission with their masters - Tasoths. Telling the truth, I have seen Triscenes once, maybe twice, in all my TFTD campaignes. Tasoths rarely make land missions, so to see a Triscene is like to see a USO in the real world. It seems it really needs a correction, and TFTDextender would be an appropriate candidate for it. So, my first proposal is to change Tasoths + Bio-Drones and Tasoth + Triscenes missions into Tasoth + Bio-Drones + Triscenes missions (by analogy to Mutons + Celatids + Silacoids in UFO: EU).

And another proposal. In order to make the game fiction a little more plausible, I think all races should appear in underwater missions. There are several arguments for that. The first is discussed above. If a landed sub provides e.g. Aquatoids + Calcinites on a terror mission, they should also be present in the sub when it has been shot. So, I would see:
# Aquatoids + Calcinites + Hallucinoids,
# Gill Men + Deep Ones + Xarquids,
# Lobster Men + Bio-Drones + Tentaculats,
# Tasoths + Bio-Drones + Triscenes (see above) + Tentaculats
on undersea missions, at least when a battleship is downed (a terror mission is cancelled by XCom).

The other argument is to make some alien races available throughout the whole campaign (for those who forget to capture such or another creature). Note that UFO: EU does not have such stupid limitations like disappearing some races during the game. Managing alien mission types, as well as the content of the alien squad on the mission, would be a great solution of this problem.

Yet another argument is that some races do not like to make terror missions at all. If any alien creature could be spotted under the sea, it would eliminate the problem of meeting some types (like Calcinites, and especially Triscenes).

The game does not prevent land races on underwater missions completely. Namely, sometimes Deep Ones are seen under the sea (probably only with a mixed crew missions). So, there is not a base objection to place land terror races under water.

And the final argument. The main alien races are undersea creatures. They do not like land, except terror missions (and Xcom bases assaults). So, ALL their pets (= terror races) should be able to live under water as well. Can you imagine a thinking fish who looks after a cat as his/her pet?

And this is not all. Tentaculats and Xarquids do not look like able to live on the land, and during first missions they are not spotted on the land indeed. Unfortunately, the game does not prevent them from being seen on land mission completely. Namely, in further stages of the campaign, so called Mixed Crews appears. In fact they are Tasoths (1st type) or Lobster Men (2nd type) plus Aquatoids missions, with their own pets, with Gill Men pets instead of Aquatoids pets possible as well (hence Tasoths + Aquatoids + Triscenes + Calcinites is a possible (?) terror mission, as well as Tasoths + Aquatoids + Triscenes + Deep Ones should be possible).

Unfortunately, in the real game, Xarquids can accompany Tasoths and Aquatoids mixed crew on the land. It looks like a game error when these undersea creatures levitate in a port, really. Or in an XCom base. I think Xarquids, as obviously sea creatures, should be eliminated from all land missions, and replaced by Deep Ones.

And for a similar unknown reason Tentaculats somehow appear sometimes in Xcom bases during an alien mixed crew assault. It is so rare phenomenon that removing this possibility would do severe unbalancing to the game, I think.

So, my requests are 1) to place both Bio-Drones and Triscenes in Tasoth missions, 2) to place all land races (Calcinites, Deep Ones, Bio-Drones, and Triscenes) on underwater missions, together with underwater races, 3) to eliminate underwater races (Xarquids and Tentaculats) from any land missions (Hallucinoids are eliminated now, so they are OK in this point).

[[User:Sherlock|Sherlock]] 08:55, 14 January 2013 (EST)

== More various missions ==

I have found a "diary" of a TFTD campaign. It has never been finished even if all researches have already been made. The last record is Alien Sub-273, and the time is August 2041. I have tried to down as many subs as possible, and to have as many missions as I could (naturally with all touched-down subs as well).

During that campaign triscenes did not appear even once (and the are in the Ufopedia only because of medics). Calcinites were seen only twice, as part of the crew of a downed dreadnought which was Sub-209, and on an island terror (Terror-10 mission) between Sub-237 and Sub-238. Any mixed crew was never spot, during 1,5 year of the campaign! Heavy Cruiser was first seen as Sub-137, and was seen four times more (so, 5 Subs of the total number of 273, were Heavy Cruisers. Hunter was seen 9 times, so it was also very rare. There were only 11 terror missions altogether (at 273 recorded subs!), and 13 alien base assaults, including 2 alien activities missions, and 11 colonies. My bases were attacked only twice (!).

So, some alien races, some alien vessels, and some alien mission types are extremely rare in campaigns. Not always results as as described. I did see mixed crew subs but not in that campaign. I remember a campaign with no calcinites at all, and with no Hunters at all.

And I think that what people say on alien revenge is false. When you down an alien sub with a certain mission, it can stop their further activity in that mission. But if you let the aliens make their activity, they continue their mission. People write that harming aliens cause their response, and larger and larger subs are sent by them to that mission. I have stated that it is quite the way round - if you do not harm aliens, they send larger and larger subs. Last 4 subs in the described campaign were with the same mission. They were uso type 1, 2, 3, and 5 (Hunter) - only the last one was downed by me.

Conclusion: the game neeeds some patching. It would be really nice if TFTDextender could control alien missions, forcing the game to more variety of alien races, subs, and to more terror missions (as they are a perfect source of some races). Apearing of some main alien races, including mixed crew types, is also not as it should be. The tables in the article [[Alien Appearance Ratios (TFTD)]] do NOT describe the real game behaviour. How is it possible not to appear any mixed crew for 18 months of the game's time? They SHOULD appear at 20-30% rate. But they CAN appear with 0% rate!

[[User:Sherlock|Sherlock]] 09:22, 14 January 2013 (EST)

File:Store error.zip

2013-01-21T10:50:31Z

Sherlock:

User talk:Bomb Bloke

2013-01-20T11:12:28Z

Sherlock: /* Splitter */

= Redundant Images / Pages =
Here be a list of images and / or pages that I think can be deleted safely (because they've been replaced with other files or links, or created by accident).

*[[:Image:SCANG.gif‎]]
*[[:Image:SCANG_(TFTD).gif]]

= You Have New Messages =
Now that I've started using this talk page again, I get the message "You have new messages" attached to the top of every page (other then this one) that I visit. Most annoying. Anyone know how to get rid of it? - BB

----
Do you still get those messages BB? --[[User:Zombie|Zombie]] 00:04, 11 September 2006 (PDT)

----

I just figured out the answer a couple of days ago. Up the top of the page is an watch/unwatch link that toggles. Whenever a new post is made on the messages page, the page becomes "watched", and you have to click it before the notifications stop. - [[User:Bomb Bloke|Bomb Bloke]] 03:16, 11 September 2006 (PDT)

= Firing Accuracy =
Section moved [[User talk:Bomb Bloke:Firing Accuracy|here]] so that this user page doesn't take so long to load on my poor slow internet connection.

= Can't get Hybrid to work =

Hey BB, I've downloaded your Hybrid program but I can't seem to be able to run. I got latest Java, I unzipped Hybrid to the UFO folder and I have changed the Hybrid.bat file to:
set CLASSPATH=D:\Terror\
Every time i ran it though I get an exception- Can you please tell me what i've been doing wrong? [[User:Hobbes|Hobbes]] 10:34, 22 March 2008 (PDT)

----

Edit edit edit, I forgot how this thing worked...

Ok, extract the archive into your game folder, open up a prompt window. If UFO is in D:\UFO, the program should end up in D:\UFO\Hybrid. Change to that folder and run it with the other game's path as a parameter. eg:

Hybrid D:\Terror

If that gives an exception, lemme know what it is.

The classpath line should be left as it was. It's just required on some systems for java to work correctly.

- [[User:Bomb Bloke|Bomb Bloke]] 16:17, 22 March 2008 (PDT)

= Inventory screens =

Hi Bomb Bloke

I really love your Map editor, which in fairness is a full Battlescape editor. It crashes for me a lot but probably that's because I have other mods messing with the files.

My question is - do your cool Inventory screens work with the actual game? I would love to see my weight and TUs while loading up my guys. Otherwise you need paper and pencil and printouts.

thanks! [[User:Spike|Spike]] 11:28, 25 March 2008 (PDT)

----

The alien portraits do, the editor tweaks the save files so the actual game will use them. I'll be making that optional though (because if the saves are then transferred to a system that doesn't have the extra graphics the game could crash).

I'm afraid I can't add the weight display stats to the original game. [[User:Seb76|Seb76]] or one of the other machine coders out there might be able to pull it off, but it's a big ask (right up there with adding stuff to the tech tree).
:You mean stuff like that? [[Image:Ufo weight.zip]] ;-) [[User:Seb76|Seb76]] 18:09, 28 March 2008 (PDT)

::That's pretty impressive... :O Reckon you could get it to display unit strength as well? [[User:Bomb Bloke|Bomb Bloke]] 20:53, 28 March 2008 (PDT)

::: You are correct, I could have done it. Have a look at the updated version ;-) [[User:Seb76|Seb76]] 10:23, 29 March 2008 (PDT)

:: That's nearly perfect, but... well, there's always a catch, isn't there? ;)

:: For whatever reason, the weight carried by some troopers won't display. Here's a sample save game: [[Image:GAME_4.zip]] (check the guy in front of the ramp). I've tried loading up the units in concern and they do get their TU penalty if I go over their limit, but the weight carried always shows up as "0" on their inventory screens.

:: In most of my saves (just about any that involve flying suits) it doesn't work for any units. [[User:Bomb Bloke|Bomb Bloke]] 19:53, 29 March 2008 (PDT)

::: I'm using offset 0x28 of unitref.dat to get the soldier.dat index (to in turn get the carried weigth via an already builtin function). Strangely it is set to 0xff for some units. Did you mess too much with this file? Or maybe offset 0x28 is not yet completely understood. [[User:Seb76|Seb76]] 02:07, 30 March 2008 (PDT)

::: I think I nailed it. Care for another try? [[User:Seb76|Seb76]] 02:42, 30 March 2008 (PDT)

:: Yes, this one seems to be working perfectly. Mind if I build it into a patcher tomorrow and stick it up on StrategyCore, so it can be used with other mods? (or does it add code to the end of the executable, like Mok's does)?
::: Some code is added in the executable in a padding section (unused space in the binary) so the file has still the same size. It'll conflict with other patches if they use the same place in the executable to inject their code (the patch specifics are available on the download page). I have no account in SC so I don't know what other mods do... Perhaps a bit of testing is required before posting this (does it works if you MC an alien and go to its inventory screen?). [[User:Seb76|Seb76]] 10:09, 30 March 2008 (PDT)

:: That offset isn't used by non-X-Com troopers (the trooper in front of the ramp was created with my editor, which "wipes" that offset for clones). So it should've also failed for civilians and aliens.

:: Not sure why it failed for my flying suit troopers. I was starting to think large units might've been messing up the calculation. [[User:Bomb Bloke|Bomb Bloke]] 08:34, 30 March 2008 (PDT)
::: The first version was faulty anyway: it used the soldier.dat entry index instead of unitpos index. It worked as long as noone died else things start to get out of sync. [[User:Seb76|Seb76]] 10:09, 30 March 2008 (PDT)

If you know specific methods to crash the editor, or have certain save games it won't load, I'd love to see them. I'm forever working bugs out of the thing but I'm limited in that I never get any actual bug reports. :(

I do know that it probably won't load XcomUtil based saves that use alternate terrain sets (eg. Hobbes's maps).

- [[User:Bomb Bloke|Bomb Bloke]] 19:02, 25 March 2008 (PDT)

----
Thanks BB. What tends to happen is the editor hangs during file load, on the saved games list screen. The only clue is that the mouse pointer is visible/movable(normally the pointer disappears during file load). Back in the BBmap_edit.bat Dos window, it will have an "Array out of bounds" error (generic, I know). Will try to get a reproducible bug and send you the game save dir. Cheers, [[User:Spike|Spike]] 01:56, 27 March 2008 (PDT)

=Categorization Guidelines=
Hey BB, I've noticed that you've removed some categories from a few pages and stated you reason as 'redundant categories'. My first thought was that there isn't such thing as a redundant category (the more the merrier since I see them as tags for the articles that help connect common theme pages together) but I've been reading Wikipedia's policy regarding categorization and while I do not agree with all aspects of their policy I think it might be better if we set a common guideline of our own. What do you think should be accepted regarding categorization? [[User:Hobbes|Hobbes]] 13:06, 18 December 2009 (EST)

----

The way I see it, pages should be in as few categories as possible, and preferably child categories at that. If you want an example as to why, take a look at the [[:Category:Apocalypse|Apocalypse]] cat - it's downright ''broken''. Page one tells you there are 199 articles - there's actually 271 at present (and four sub-cats, only ''one'' of which is visible on the first page - hardly intuitive for finding stuff!), but you won't be given that information unless you jump to page two. And as for using a list like that to locate articles on a specific theme? There's too much junk to read through, you can only get anywhere if you already know exactly what you're looking for!

In comparison, try looking at the [[:Category:Enemy Unknown/UFO Defense|Enemy Unknown/UFO Defense]] category. You should find it dead easy to get to a page about any given topic that's categorised in there, even if you didn't start out knowing what it was called. Obviously I still consider there to be some more work to be done (base modules, X-COM craft + their weapons, not to mention the game files), but I'm sure you get the general idea of how that style of things affects practicality.

If an article looks like it belongs in two categories, ask yourself - should one of those categories actually belong in the other as well? If so, then the article certainly doesn't need to be placed in both.

We also had not one, but two categories for UFO - one called "Enemy Unknown/UFO Defense" and one called just "EU". I've since moved all articles out of EU.

Ideally, all categories will eventually link back to one "master" category, sorta like how all articles lead back (eventually) to the main page.

-[[User:Bomb Bloke|Bomb Bloke]] 17:57, 18 December 2009 (EST)

----

OK, makes sense, my idea originally for the categories was that we should look at them simply by looking into the page elements and creating cats for each for them, making as much associations between pages as possible (an 'horizontal' view, i guess). Your 'vertical' helps to keep things tidier but at the same time i'm wondering if it doesn't prevent the creation of common categories to which all games can be related. [[User:Hobbes|Hobbes]] 17:50, 19 December 2009 (EST)

----

It allows for common categories ([[:Category:UFOs/USOs|assuming you mean stuff like this?]]), but unfortunately most of the obvious names to use for them are dedicated to UFO:EU articles - meaning a whole bunch of pages need to be moved to allow for it.

But what the heck. I'm up for that.

- [[User:Bomb Bloke|Bomb Bloke]] 17:55, 19 December 2009 (EST)

----

Come to think of it, I'm tempted to just scrap the [[:Category:UFOs/USOs|UFOs/USOs category]] and just throw the contents in the generic [[:Category:Craft|Craft category]]. Can't see the need to have both. - [[User:Bomb Bloke|Bomb Bloke]] 18:08, 19 December 2009 (EST)

----

We now have a [[:Category:Main|primary category]]. - [[User:Bomb Bloke|Bomb Bloke]] 19:29, 19 December 2009 (EST)

----

OK, it's making sense to me right now how the Category: Apocalypse should be reorganized. It is still a mess but it helps that you don't have to look for all Apoc related pages since they are already there :) [[User:Hobbes|Hobbes]] 20:24, 21 December 2009 (EST)

----

Indeed. There's a couple of hundred pages related to the other games that simply aren't sorted at all. - [[User:Bomb Bloke|Bomb Bloke]] 06:33, 22 December 2009 (EST)

=Windows 7 64-bit + XcomUtil + bb_tact=
"This version of D:\games\ufo\BBReset.exe is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher."

I'm getting the above message on every switch between geoscape and tactical when using your mod with XcomUtil. Does that mean your mod won't run, or am I doing something wrong? [[User:Rovlad|Rovlad]] 19:37, 5 May 2010 (EDT)
:Nevermind, I figured it out after skimmering through .bat files a bit. For some reason your installer did not detect my system to be 64 bit (could be because it's not AMD-based). I've manually replaced BBReset.exe with BBReset32.exe and it works fine now.
Cheers! [[User:Rovlad|Rovlad]] 20:31, 5 May 2010 (EDT)

That's odd; last I knew, it used the same check that XcomUtil uses for its own executables. Having users manually moving files about isn't an ideal solution, so I'll have to take a closer look at it. Thanks for the heads-up. - [[User:Bomb Bloke|Bomb Bloke]] 21:10, 5 May 2010 (EDT)
:No problem, let me know if you need any specific information on the system, steps taken during setup process or whatever. One thing for certain, XcomUtil has detected 64-bit correctly right off the bat. Perhaps your installer could just check for "64-bit system" flag from XcuSetup to set everything up accordingly? It would not be a perfect solution, but since running XcomUtil is the only way to use bb_tact with 64-bit system (at least for now), it probably still is a feasible thought. [[User:Rovlad|Rovlad]] 08:06, 6 May 2010 (EDT)
:Actually, never mind that. I've digged a bit more and discovered that Example.txt file in \XcomUtil\Addon directory is a bit outdated in terms of detecting 64-bit OS. You can fix your installation script by taking a look at \XcomUtil\batch\SysCheck.bat to see how it handles system detection now. [[User:Rovlad|Rovlad]] 10:19, 14 May 2010 (EDT)

=Night vision goggles for soldiers during night missions=
Hello there again.

I have drawn some graphics today which replace several images to add night vision goggles on soldiers' heads (for overalls and personal armor troopers). There are 19 images for both xcom_0.pck and xcom_1.pck, 38 in total. I've compiled them into pck files for testing (using your tools, of course!) and they seem to be working properly.

Thing is, I'm not very keen in actual modding, and seeing as your camouflage mod serves the very similar purpose (being purely a visual enhancement), I was wondering if you would be interested in using these for your own mod. As far as I understand, it would require a pre-battle check to see if it's a night mission, and only use new graphics in this case.

Anyway, let me know what you think.

- [[User:Rovlad|Rovlad]] 20:05, 14 May 2010 (EDT)

----

I think that sounds awesome. Right off the bat, you'd be able to tell whether night-rules were in effect for that battle or not, simply by checking how your soldiers are outfitted. Though, I don't suppose you could also update the [[Inventory_Backgrounds|SPKs for inventory screens]]? There's a tool in my pack for converting those back and forth, works much the same way as the PCK one.

Actually, I could even take it a step further: Make it so that, when using the goggles, mission light-levels are capped at the point ''just before'' "night-time" rules come into effect. So that it's visibly "dusky" to the user, but your troops still have full range of vision (like when you're in a base defense mission for eg). It always seemed rather silly that soldiers didn't have ''some'' sort of attached visual aid (like, say, a flashlight).

- [[User:Bomb Bloke|Bomb Bloke]] 02:38, 22 May 2010 (EDT)

==Clean Up==
If it is in your abilities can you erase all these Russian blank pages (and their discussions)? They are redundant and left after vandals invasion. Thanks. ---[[User:Ufo.mesh|ufo.mesh]] 05:32, 27 August 2010 (EDT)

----

=BBmod.bat error: "dont find xcloader"=

I cant install the BB mod set. When I run the BBMod.bat, the game begins with the intro without sounds and I get a black screen. When swap to the desktop I see the error message: unable to locate "xcloader". But, the xcloader.exe is in the folder.
I have xcomutil and the seb76 extended mod installed. I run xcusetup and recognices the BBmod. But when a mission beggins the game crashes: error, unable to find kevlar brown...(the BBMod.bat dont worked)

- user: man.manza (juny 2011)

:Sorry, I made some changes the other week and probably didn't test them too well before uploading.

:Am sick at the moment, and not really in the mood to smooth it all out. You should be able to work around the main issue though.

:Grab a fresh copy of [http://www.strategycore.co.uk/files/index.php?dlid=21 f0dder's loader]. In the "xcom1" folder of the archive, there's a file "patch.dll", you'll need to replace the one BBMod had with this. If you're running TFTD then don't worry about getting the new patch file.

:There is no good reason why the batch wouldn't be able to find XCLoader, which is included in the toolkit archive now, so I'm assuming you're seeing the prompt to locate the game EXE instead... Either way I have no clue why the game would've started anyway.

:Anyway, if that doesn't sort things, odds are it's unhappy because you didn't run "UniGen.bat" from the bb_tact folder before starting the mod. I'd tried to rig things so that you didn't need to do this unless you wanted to use the uniform manager, but I may have messed that up - if so, you'll probably need to reinstall the game and try again from scratch (backup your save folders if you're worried they'll be affected).

:If you're still having trouble, I'll need some more info to go off. OS? Windows Collectors Edition, or through DOSBox? Which release of the game - Steam, GameTap, original disks/CD?...

:By the by, you can automatically generate a signature for your comments by typing four tiles (<nowiki>~~~~</nowiki>).

:-  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 07:28, 22 June 2011 (EDT)

Sorry, my previous post show a lack of information.

My PC: AMD Phenom II X4 965 processor, 2.18Ghz, 3,25Gb ram. WindowsXP ue.

And detailed steps:
-clean copy of Steam "ufo defense" (windows CE version... I think)
-Applied the seb76 extended mod. (The game runs successfully).
-Copy the BB tool files in the ufo folder. (xcloader.exe is there)
-Check bb_tact\Config\BBmod.ini: uniforms: off
-run BBModBat...
-black screen. Nothing happens...
-press enter, again, and again...
-at least several error messages:
error: cant find personal armor set "alloy"
using default instead...
...path not found in module BBreset at address 26EC:19Ac
unable to found xcloader...
etc...
-I exit to the desktop. A windows tell me: "unable to fing xcloader.exe etc..."
-I finish the process at the task manager.

Delete the entire ufo folder.

Download again from steam.

-New clean copy. Now without Seb76 Extended mod.
-Check the vanilla game. Run "UFO Defense.exe". OK. Exit game.
-Copy the BBtoolpack files in the game folder
-This time I run the UniGen.bat first: ...procesing. It works.
-I enable the uniforms in BBmod.ini
-Run the BBMod.bat
-intro without sound, black screen, exits to desktop, and the same windows message: "unable to fing xcloader.exe etc..."

-Copy the files from the xcom1 folder of xcombugfix091 (the file you linked me) and replace patch.dll.
-Same error.

--[[User:Man.manza|Man.manza]] 12:34, 22 June 2011 (EDT)

:Ok, if it's the Steam release, try this.

:Goto the folder that contains the DOSBox executable and configuration file. This will typically be:

:C:\Program Files\Steam\steamapps\common\xcom ufo defense

:In there is "dosbox.conf", open that in a text editor (eg drag'n'drop the file into a Notepad window) and scroll right down to the bottom of it.

:You'll see a line that states "call ufocd.bat", change this to "call bbmod.bat", then save the file. Run "dosbox.exe" (or just launch the game through the Steam interface, which uses DOSBox by default) and it should work. If you want to go back to running the game normally, just change the line in "dosbox.conf" back to "call ufocd.bat" again.

:The idea is that BBMod seems to be getting confused by the fact that the Steam release contains BOTH DOS and Windows versions of UFO. It sees the DOS version first and tries to run that, but fails horribly unless you use DOSBox. There's plenty of irony there, because I'm the one who requested that it be that way... -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 23:01, 22 June 2011 (EDT)

::If, on the other hand, you want to force it to use CE, then delete UFOEXE\Black.exe and run BBMod.bat directly. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 23:22, 22 June 2011 (EDT)

:Remember when editing wiki pages that when you hit submit, the page is replaced with whatever you had in the edit box. Meaning that if you hit edit, wait a few hours, then submit the page... if anyone has made any other changes within to the page within that time, they'll be lost. Best to re-press the edit button if you've left it a while, just in case the page version you're looking at is no longer up to date.

:You can keep track of when a page was last changed using the "history" link at the very top of the article, or, using the "recent changes" link listed in the toolbox to the left. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 18:30, 23 June 2011 (EDT)

= Convusopedia? =

Why to keep in the toolpack a ready to use script for converting Ufopedia while not another one for TFTD?
There is one here: [[File:convusopedia.zip]], perhaps you will add it to your pack?

= UFO/TFTD CE EXE Splitter / Merger =

Files produced by this splitter differs from that produced with XComUtil. And even if we took the correction for TFTDextender error when exiting geoscape, there are still 5 bytes different. What is it for?

BTW., the newest version of TFTDextender generates Geoscape-exiting errors with any known version of the split exe.~Perhaps any further corrections are needed.

[[User:Sherlock|Sherlock]] 06:12, 20 January 2013 (EST)

User talk:Bomb Bloke

2013-01-20T10:58:40Z

Sherlock: /* Convusopedia */

= Redundant Images / Pages =
Here be a list of images and / or pages that I think can be deleted safely (because they've been replaced with other files or links, or created by accident).

*[[:Image:SCANG.gif‎]]
*[[:Image:SCANG_(TFTD).gif]]

= You Have New Messages =
Now that I've started using this talk page again, I get the message "You have new messages" attached to the top of every page (other then this one) that I visit. Most annoying. Anyone know how to get rid of it? - BB

----
Do you still get those messages BB? --[[User:Zombie|Zombie]] 00:04, 11 September 2006 (PDT)

----

I just figured out the answer a couple of days ago. Up the top of the page is an watch/unwatch link that toggles. Whenever a new post is made on the messages page, the page becomes "watched", and you have to click it before the notifications stop. - [[User:Bomb Bloke|Bomb Bloke]] 03:16, 11 September 2006 (PDT)

= Firing Accuracy =
Section moved [[User talk:Bomb Bloke:Firing Accuracy|here]] so that this user page doesn't take so long to load on my poor slow internet connection.

= Can't get Hybrid to work =

Hey BB, I've downloaded your Hybrid program but I can't seem to be able to run. I got latest Java, I unzipped Hybrid to the UFO folder and I have changed the Hybrid.bat file to:
set CLASSPATH=D:\Terror\
Every time i ran it though I get an exception- Can you please tell me what i've been doing wrong? [[User:Hobbes|Hobbes]] 10:34, 22 March 2008 (PDT)

----

Edit edit edit, I forgot how this thing worked...

Ok, extract the archive into your game folder, open up a prompt window. If UFO is in D:\UFO, the program should end up in D:\UFO\Hybrid. Change to that folder and run it with the other game's path as a parameter. eg:

Hybrid D:\Terror

If that gives an exception, lemme know what it is.

The classpath line should be left as it was. It's just required on some systems for java to work correctly.

- [[User:Bomb Bloke|Bomb Bloke]] 16:17, 22 March 2008 (PDT)

= Inventory screens =

Hi Bomb Bloke

I really love your Map editor, which in fairness is a full Battlescape editor. It crashes for me a lot but probably that's because I have other mods messing with the files.

My question is - do your cool Inventory screens work with the actual game? I would love to see my weight and TUs while loading up my guys. Otherwise you need paper and pencil and printouts.

thanks! [[User:Spike|Spike]] 11:28, 25 March 2008 (PDT)

----

The alien portraits do, the editor tweaks the save files so the actual game will use them. I'll be making that optional though (because if the saves are then transferred to a system that doesn't have the extra graphics the game could crash).

I'm afraid I can't add the weight display stats to the original game. [[User:Seb76|Seb76]] or one of the other machine coders out there might be able to pull it off, but it's a big ask (right up there with adding stuff to the tech tree).
:You mean stuff like that? [[Image:Ufo weight.zip]] ;-) [[User:Seb76|Seb76]] 18:09, 28 March 2008 (PDT)

::That's pretty impressive... :O Reckon you could get it to display unit strength as well? [[User:Bomb Bloke|Bomb Bloke]] 20:53, 28 March 2008 (PDT)

::: You are correct, I could have done it. Have a look at the updated version ;-) [[User:Seb76|Seb76]] 10:23, 29 March 2008 (PDT)

:: That's nearly perfect, but... well, there's always a catch, isn't there? ;)

:: For whatever reason, the weight carried by some troopers won't display. Here's a sample save game: [[Image:GAME_4.zip]] (check the guy in front of the ramp). I've tried loading up the units in concern and they do get their TU penalty if I go over their limit, but the weight carried always shows up as "0" on their inventory screens.

:: In most of my saves (just about any that involve flying suits) it doesn't work for any units. [[User:Bomb Bloke|Bomb Bloke]] 19:53, 29 March 2008 (PDT)

::: I'm using offset 0x28 of unitref.dat to get the soldier.dat index (to in turn get the carried weigth via an already builtin function). Strangely it is set to 0xff for some units. Did you mess too much with this file? Or maybe offset 0x28 is not yet completely understood. [[User:Seb76|Seb76]] 02:07, 30 March 2008 (PDT)

::: I think I nailed it. Care for another try? [[User:Seb76|Seb76]] 02:42, 30 March 2008 (PDT)

:: Yes, this one seems to be working perfectly. Mind if I build it into a patcher tomorrow and stick it up on StrategyCore, so it can be used with other mods? (or does it add code to the end of the executable, like Mok's does)?
::: Some code is added in the executable in a padding section (unused space in the binary) so the file has still the same size. It'll conflict with other patches if they use the same place in the executable to inject their code (the patch specifics are available on the download page). I have no account in SC so I don't know what other mods do... Perhaps a bit of testing is required before posting this (does it works if you MC an alien and go to its inventory screen?). [[User:Seb76|Seb76]] 10:09, 30 March 2008 (PDT)

:: That offset isn't used by non-X-Com troopers (the trooper in front of the ramp was created with my editor, which "wipes" that offset for clones). So it should've also failed for civilians and aliens.

:: Not sure why it failed for my flying suit troopers. I was starting to think large units might've been messing up the calculation. [[User:Bomb Bloke|Bomb Bloke]] 08:34, 30 March 2008 (PDT)
::: The first version was faulty anyway: it used the soldier.dat entry index instead of unitpos index. It worked as long as noone died else things start to get out of sync. [[User:Seb76|Seb76]] 10:09, 30 March 2008 (PDT)

If you know specific methods to crash the editor, or have certain save games it won't load, I'd love to see them. I'm forever working bugs out of the thing but I'm limited in that I never get any actual bug reports. :(

I do know that it probably won't load XcomUtil based saves that use alternate terrain sets (eg. Hobbes's maps).

- [[User:Bomb Bloke|Bomb Bloke]] 19:02, 25 March 2008 (PDT)

----
Thanks BB. What tends to happen is the editor hangs during file load, on the saved games list screen. The only clue is that the mouse pointer is visible/movable(normally the pointer disappears during file load). Back in the BBmap_edit.bat Dos window, it will have an "Array out of bounds" error (generic, I know). Will try to get a reproducible bug and send you the game save dir. Cheers, [[User:Spike|Spike]] 01:56, 27 March 2008 (PDT)

=Categorization Guidelines=
Hey BB, I've noticed that you've removed some categories from a few pages and stated you reason as 'redundant categories'. My first thought was that there isn't such thing as a redundant category (the more the merrier since I see them as tags for the articles that help connect common theme pages together) but I've been reading Wikipedia's policy regarding categorization and while I do not agree with all aspects of their policy I think it might be better if we set a common guideline of our own. What do you think should be accepted regarding categorization? [[User:Hobbes|Hobbes]] 13:06, 18 December 2009 (EST)

----

The way I see it, pages should be in as few categories as possible, and preferably child categories at that. If you want an example as to why, take a look at the [[:Category:Apocalypse|Apocalypse]] cat - it's downright ''broken''. Page one tells you there are 199 articles - there's actually 271 at present (and four sub-cats, only ''one'' of which is visible on the first page - hardly intuitive for finding stuff!), but you won't be given that information unless you jump to page two. And as for using a list like that to locate articles on a specific theme? There's too much junk to read through, you can only get anywhere if you already know exactly what you're looking for!

In comparison, try looking at the [[:Category:Enemy Unknown/UFO Defense|Enemy Unknown/UFO Defense]] category. You should find it dead easy to get to a page about any given topic that's categorised in there, even if you didn't start out knowing what it was called. Obviously I still consider there to be some more work to be done (base modules, X-COM craft + their weapons, not to mention the game files), but I'm sure you get the general idea of how that style of things affects practicality.

If an article looks like it belongs in two categories, ask yourself - should one of those categories actually belong in the other as well? If so, then the article certainly doesn't need to be placed in both.

We also had not one, but two categories for UFO - one called "Enemy Unknown/UFO Defense" and one called just "EU". I've since moved all articles out of EU.

Ideally, all categories will eventually link back to one "master" category, sorta like how all articles lead back (eventually) to the main page.

-[[User:Bomb Bloke|Bomb Bloke]] 17:57, 18 December 2009 (EST)

----

OK, makes sense, my idea originally for the categories was that we should look at them simply by looking into the page elements and creating cats for each for them, making as much associations between pages as possible (an 'horizontal' view, i guess). Your 'vertical' helps to keep things tidier but at the same time i'm wondering if it doesn't prevent the creation of common categories to which all games can be related. [[User:Hobbes|Hobbes]] 17:50, 19 December 2009 (EST)

----

It allows for common categories ([[:Category:UFOs/USOs|assuming you mean stuff like this?]]), but unfortunately most of the obvious names to use for them are dedicated to UFO:EU articles - meaning a whole bunch of pages need to be moved to allow for it.

But what the heck. I'm up for that.

- [[User:Bomb Bloke|Bomb Bloke]] 17:55, 19 December 2009 (EST)

----

Come to think of it, I'm tempted to just scrap the [[:Category:UFOs/USOs|UFOs/USOs category]] and just throw the contents in the generic [[:Category:Craft|Craft category]]. Can't see the need to have both. - [[User:Bomb Bloke|Bomb Bloke]] 18:08, 19 December 2009 (EST)

----

We now have a [[:Category:Main|primary category]]. - [[User:Bomb Bloke|Bomb Bloke]] 19:29, 19 December 2009 (EST)

----

OK, it's making sense to me right now how the Category: Apocalypse should be reorganized. It is still a mess but it helps that you don't have to look for all Apoc related pages since they are already there :) [[User:Hobbes|Hobbes]] 20:24, 21 December 2009 (EST)

----

Indeed. There's a couple of hundred pages related to the other games that simply aren't sorted at all. - [[User:Bomb Bloke|Bomb Bloke]] 06:33, 22 December 2009 (EST)

=Windows 7 64-bit + XcomUtil + bb_tact=
"This version of D:\games\ufo\BBReset.exe is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher."

I'm getting the above message on every switch between geoscape and tactical when using your mod with XcomUtil. Does that mean your mod won't run, or am I doing something wrong? [[User:Rovlad|Rovlad]] 19:37, 5 May 2010 (EDT)
:Nevermind, I figured it out after skimmering through .bat files a bit. For some reason your installer did not detect my system to be 64 bit (could be because it's not AMD-based). I've manually replaced BBReset.exe with BBReset32.exe and it works fine now.
Cheers! [[User:Rovlad|Rovlad]] 20:31, 5 May 2010 (EDT)

That's odd; last I knew, it used the same check that XcomUtil uses for its own executables. Having users manually moving files about isn't an ideal solution, so I'll have to take a closer look at it. Thanks for the heads-up. - [[User:Bomb Bloke|Bomb Bloke]] 21:10, 5 May 2010 (EDT)
:No problem, let me know if you need any specific information on the system, steps taken during setup process or whatever. One thing for certain, XcomUtil has detected 64-bit correctly right off the bat. Perhaps your installer could just check for "64-bit system" flag from XcuSetup to set everything up accordingly? It would not be a perfect solution, but since running XcomUtil is the only way to use bb_tact with 64-bit system (at least for now), it probably still is a feasible thought. [[User:Rovlad|Rovlad]] 08:06, 6 May 2010 (EDT)
:Actually, never mind that. I've digged a bit more and discovered that Example.txt file in \XcomUtil\Addon directory is a bit outdated in terms of detecting 64-bit OS. You can fix your installation script by taking a look at \XcomUtil\batch\SysCheck.bat to see how it handles system detection now. [[User:Rovlad|Rovlad]] 10:19, 14 May 2010 (EDT)

=Night vision goggles for soldiers during night missions=
Hello there again.

I have drawn some graphics today which replace several images to add night vision goggles on soldiers' heads (for overalls and personal armor troopers). There are 19 images for both xcom_0.pck and xcom_1.pck, 38 in total. I've compiled them into pck files for testing (using your tools, of course!) and they seem to be working properly.

Thing is, I'm not very keen in actual modding, and seeing as your camouflage mod serves the very similar purpose (being purely a visual enhancement), I was wondering if you would be interested in using these for your own mod. As far as I understand, it would require a pre-battle check to see if it's a night mission, and only use new graphics in this case.

Anyway, let me know what you think.

- [[User:Rovlad|Rovlad]] 20:05, 14 May 2010 (EDT)

----

I think that sounds awesome. Right off the bat, you'd be able to tell whether night-rules were in effect for that battle or not, simply by checking how your soldiers are outfitted. Though, I don't suppose you could also update the [[Inventory_Backgrounds|SPKs for inventory screens]]? There's a tool in my pack for converting those back and forth, works much the same way as the PCK one.

Actually, I could even take it a step further: Make it so that, when using the goggles, mission light-levels are capped at the point ''just before'' "night-time" rules come into effect. So that it's visibly "dusky" to the user, but your troops still have full range of vision (like when you're in a base defense mission for eg). It always seemed rather silly that soldiers didn't have ''some'' sort of attached visual aid (like, say, a flashlight).

- [[User:Bomb Bloke|Bomb Bloke]] 02:38, 22 May 2010 (EDT)

==Clean Up==
If it is in your abilities can you erase all these Russian blank pages (and their discussions)? They are redundant and left after vandals invasion. Thanks. ---[[User:Ufo.mesh|ufo.mesh]] 05:32, 27 August 2010 (EDT)

----

=BBmod.bat error: "dont find xcloader"=

I cant install the BB mod set. When I run the BBMod.bat, the game begins with the intro without sounds and I get a black screen. When swap to the desktop I see the error message: unable to locate "xcloader". But, the xcloader.exe is in the folder.
I have xcomutil and the seb76 extended mod installed. I run xcusetup and recognices the BBmod. But when a mission beggins the game crashes: error, unable to find kevlar brown...(the BBMod.bat dont worked)

- user: man.manza (juny 2011)

:Sorry, I made some changes the other week and probably didn't test them too well before uploading.

:Am sick at the moment, and not really in the mood to smooth it all out. You should be able to work around the main issue though.

:Grab a fresh copy of [http://www.strategycore.co.uk/files/index.php?dlid=21 f0dder's loader]. In the "xcom1" folder of the archive, there's a file "patch.dll", you'll need to replace the one BBMod had with this. If you're running TFTD then don't worry about getting the new patch file.

:There is no good reason why the batch wouldn't be able to find XCLoader, which is included in the toolkit archive now, so I'm assuming you're seeing the prompt to locate the game EXE instead... Either way I have no clue why the game would've started anyway.

:Anyway, if that doesn't sort things, odds are it's unhappy because you didn't run "UniGen.bat" from the bb_tact folder before starting the mod. I'd tried to rig things so that you didn't need to do this unless you wanted to use the uniform manager, but I may have messed that up - if so, you'll probably need to reinstall the game and try again from scratch (backup your save folders if you're worried they'll be affected).

:If you're still having trouble, I'll need some more info to go off. OS? Windows Collectors Edition, or through DOSBox? Which release of the game - Steam, GameTap, original disks/CD?...

:By the by, you can automatically generate a signature for your comments by typing four tiles (<nowiki>~~~~</nowiki>).

:-  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 07:28, 22 June 2011 (EDT)

Sorry, my previous post show a lack of information.

My PC: AMD Phenom II X4 965 processor, 2.18Ghz, 3,25Gb ram. WindowsXP ue.

And detailed steps:
-clean copy of Steam "ufo defense" (windows CE version... I think)
-Applied the seb76 extended mod. (The game runs successfully).
-Copy the BB tool files in the ufo folder. (xcloader.exe is there)
-Check bb_tact\Config\BBmod.ini: uniforms: off
-run BBModBat...
-black screen. Nothing happens...
-press enter, again, and again...
-at least several error messages:
error: cant find personal armor set "alloy"
using default instead...
...path not found in module BBreset at address 26EC:19Ac
unable to found xcloader...
etc...
-I exit to the desktop. A windows tell me: "unable to fing xcloader.exe etc..."
-I finish the process at the task manager.

Delete the entire ufo folder.

Download again from steam.

-New clean copy. Now without Seb76 Extended mod.
-Check the vanilla game. Run "UFO Defense.exe". OK. Exit game.
-Copy the BBtoolpack files in the game folder
-This time I run the UniGen.bat first: ...procesing. It works.
-I enable the uniforms in BBmod.ini
-Run the BBMod.bat
-intro without sound, black screen, exits to desktop, and the same windows message: "unable to fing xcloader.exe etc..."

-Copy the files from the xcom1 folder of xcombugfix091 (the file you linked me) and replace patch.dll.
-Same error.

--[[User:Man.manza|Man.manza]] 12:34, 22 June 2011 (EDT)

:Ok, if it's the Steam release, try this.

:Goto the folder that contains the DOSBox executable and configuration file. This will typically be:

:C:\Program Files\Steam\steamapps\common\xcom ufo defense

:In there is "dosbox.conf", open that in a text editor (eg drag'n'drop the file into a Notepad window) and scroll right down to the bottom of it.

:You'll see a line that states "call ufocd.bat", change this to "call bbmod.bat", then save the file. Run "dosbox.exe" (or just launch the game through the Steam interface, which uses DOSBox by default) and it should work. If you want to go back to running the game normally, just change the line in "dosbox.conf" back to "call ufocd.bat" again.

:The idea is that BBMod seems to be getting confused by the fact that the Steam release contains BOTH DOS and Windows versions of UFO. It sees the DOS version first and tries to run that, but fails horribly unless you use DOSBox. There's plenty of irony there, because I'm the one who requested that it be that way... -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 23:01, 22 June 2011 (EDT)

::If, on the other hand, you want to force it to use CE, then delete UFOEXE\Black.exe and run BBMod.bat directly. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 23:22, 22 June 2011 (EDT)

:Remember when editing wiki pages that when you hit submit, the page is replaced with whatever you had in the edit box. Meaning that if you hit edit, wait a few hours, then submit the page... if anyone has made any other changes within to the page within that time, they'll be lost. Best to re-press the edit button if you've left it a while, just in case the page version you're looking at is no longer up to date.

:You can keep track of when a page was last changed using the "history" link at the very top of the article, or, using the "recent changes" link listed in the toolbox to the left. -  [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]]) 18:30, 23 June 2011 (EDT)

== Convusopedia? ==

Why to keep in the toolpack a ready to use script for converting Ufopedia while not another one for TFTD?
There is one here: [[File:convusopedia.zip]], perhaps you will add it to your pack?

File:Convusopedia.zip

2013-01-20T10:58:25Z

Sherlock: A script for BB's Toolpack for converting TFTD Ufopedia images into gif's.

A script for BB's Toolpack for converting TFTD Ufopedia images into gif's.

Talk:Mixed Crew

2013-01-19T15:37:11Z

Sherlock:

I'm trying to get more info on the mixed crew missions. I've just played a mixed crew cruise ship terror mission, on Experienced difficulty. The aliens were as follows:

On deck - 7 Tasoths, 2 Aquatoids, 2 Triscenes, 3 Bio-Drones and 1 Calcinite

Below deck - 6 Tasoths, 2 Aquatoids, 3 Triscenes, 4 Bio-Drones and 1 Xarquid.
--[[User:Darkpast|Darkpast]] 18:42, 6 September 2010 (EDT)

: I don't know if we have a crew/mission distribution table like we have for UFO, but that's something we ought to compile one of these days. It's easy enough to dredge this info directly out of the game executable if you know where to look. That's not really my forte, but if I can find some spare time I'll have a look. -[[User:NKF|NKF]] 01:45, 7 September 2010 (EDT)

Mixed Crew missions are not too frequent, and thre is a possibility that no such a mission happens during the whole campaign. Their contents is an interesting problem to solve.

I have never seen a mission with Bio-Drones and Triscenes side-by-side, either with Tasoths or Tasoths + Aquatoids. But, as I can remember, I have had a Tasoths + Triscenes (only) (shipping route) mission once, as well as some Tasoths + Bio-Drones (only) missions. When repeating them from the same save made before the mission (on geoscape), the content of the crew was still the same (only the number changed) the "ethnic" content of the terror seems to be set at the very beginning of the attack. So, there are two sub-types of Tasoth land missions, with Bio-Drones and with Triscenes. I do not know if the third sub-type, of Tasoths + Bio-Drones + Triscenes, is also possible. If yes, it would be a special kind of "mixed crew". Even if Mutons in UFO:EU are, as a rule, accompanied by both Silacoids and Celatids side-by side, Tasoths's normal behaviour seems to be appearing with only one race of their terrorists on land missions. So, both races with Tasoths would really be a special kind of a mixed crew.

I wonder if there are further sub-types of (true) mixed crew missions. I.e. if a given mission is Mixed Crew Type I, will we always obtain Tasoths + Triscenes + Bio-Drones + Aquatoids + Calcinites + Xarquids? Or are there sub-types with Tasoths + Triscenes but no Bio-Drones, and Tasoths + Bio-Drones but no Triscenes, as it is possible for Tasoth-only missions? I mean situations when the same alien surface attacks, recorded before the beginning of the tactical part, will always lead to the same "racial" contents of the mission, regardless on how many times you repeat the game. Unfortunately, I have no savegames to test this.

I also wonder if Xarquids and Calcinites may occur side-by-side. Anyway, Xarquids are also possible on a port attack mission (unfortunately I cannot remember if with Calcinites or not).

And yet another question. It seems that Tasoths (type I) and Lobster Men (type II) are generally accompanied by their pets, i.e. Tasoths by Triscenes or/and Bio-Drones on land, Lobster Men by Bio-Drones on land, and either race by Tentaculats underwater. At the same time Aquatoids may be accompanied by either their own pets (Calcinites on land and Hallucinoids underwater) or Gill Men's pets (Deep One or/and Xarquids, also in somewhat unexpected configurations, i.e. in improper environment for a race - perhaps this is a bug of the game, Xarquids and Tentaculats do not really look like able to live on land). So, are you completely sure that the formula for Mixed Crew Type II (from the article):

''Primarily Lobster Men with Bio-Drones/Calcinites (on land) or Tentaculats/Hallucinoids (underwater) for terror units, with some Aquatoids mixed in and a tiny number of Deep Ones (on land) or Xarquids (underwater)''

is fully correct?

One would expect that Calcinites accompany Aquatoids, not Lobster Men. A practical difference is that a land mission with Lobster Man + Calcinites + Aquatoids + Deep Ones (with no "correct" Lobster Men's pets) would be possible if you were right. I have not seen such a mission at all, have you?

[[User:Sherlock|Sherlock]] 10:37, 19 January 2013 (EST)

Talk:Alien Appearance Ratios (TFTD)

2013-01-19T14:49:11Z

Sherlock:

Talk:Alien Appearance Ratios (TFTD)

2013-01-19T14:35:13Z

Sherlock: /* Tasoth appearance time error or an unknown feature of the game */

Talk:Alien Appearance Ratios (TFTD)

2013-01-19T14:12:44Z

Sherlock:

Talk:TFTDextender

2013-01-14T14:22:55Z

Sherlock: /* And yet another reason for forcing some alien mission types */

=Questions or Comments=
'''A place to provide feedback or ask questions:'''
:''Thanks to Kyrub, Spike, and numerous others who help to troubleshoot problems, provide feedback on releases, and innumerable other activities to help make TFTDextender and the game better! -'' [[User:Morgan525|Tycho]]

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

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

== Bug Reports ==
===Major Bugs===
==== Crash when starting a landed/crashed USO battle ====

:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."

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

=== Minor Bugs ===
==== Stunned Carried Aquanauts MIA on Abort ====

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)

:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. Your right, carried objects won't have their location updated until they are dropped or thrown. At least it is a manageable issue: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)

== Things that TFTDextender does not fix ==

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

* Does not fix the apparent swap of the ground map for the VERY SMALL Survey Ship (1 occupant) with the SMALL Escort (half-dozen or more occupants). So you get the VERY SMALL sub occupying about 25 squares of usable area on the Battlescape, and the supposedly larger SMALL sub occupying one square of usable area on the Battlescape, begging the question of how all those aliens got inside there in the first place. XcomUtil will fix this, as will the original patches that XcomUtil incorporates.
* Does not fix the incorrect pictures for the large USO in the interception window.
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]
* Does not fix the Dart Gun to make it any less utterly useless. Though you can do this yourself via the OBDATA.DAT section of TFTDextender. (Suggestion: don't fix it. The useless Dart Gun is all part of the "oh no we're all gonna die" experience of the beginning of TFTD.)
* Does not improve the armour and effectiveness of the basic Aqua-Jet and Gas Cannon Coelecanths (it does upgrade the Coelecanth/Gauss). (Again, suggestion: this is a good thing - XCOM should start the game hopelessly outclassed, and scramble to catch up).
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.
* Does not allow you to have 360 degree vision out of your sub before exiting it. (What kind of coward would want that?). XComUtil does this.

*When I try to send any Leviathan to T'Leth, I get an immediate crash: "XCOM crashed at 0x458822 with error 0xC0000005 trying to access 0xFA6C8304.".
:It happens when the CE version doesn't find the RISE animation: Specifically, it needs ANIMS\RISE.IDX and ANIMS\RISE.VID - If RISE.IDX is missing, it crashes with the error code above, if RISE.VID is missing, it crashes with another error. Some experimenting suggests that RISE.VID can be any valid .VID file, while RISE.IDX can either be empty (producing a black screen that can be skipped by clicking) or the "appropriate" .IDX for the used .VID...[[User:AMX|AMX]] 13 November 2012 (EST)

=Resolved Reported Problems=
===<s> Save Equipment not working</s> ===

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

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

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

:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

===<s> Weight Issues or "Weightless" Ammo Bug </s>===

while playing TFD with TFD extender (v. 1.05 patch 1.1) I've noticed a stange thing: some soldiers have their weight > 0 (2-5) even when their inventory is empty! Bug?... [[User:PavelB|PavelB]] 05:17, 27 September 2012 (EDT)
:If you drop a loaded weapon, even if you loaded it manually, the weight of the ammo still stays with the Aquanaut. Workaround: unload each weapon manually before dropping it. If you forget (and if you notice) it's possible to pick the weapon up again, unload it, and correctly lose the weight by dropping the weapon and clip separately. It's possible to build up huge amounts of phantom weight on a Soldier by repeatedly loading, and then dropping, different weapons. It's also possible to move lots of weapons with weightless clips to one Soldier, increasing the amount of 'free' weight that one Soldier gets. Both of these effects are probably aspects of the original bug, not anything that UFOExtender has done. [[User:Spike|Spike]] 11:15, 27 September 2012 (EDT)
::This Weight error is a side effect of an original game error that Seb never quite fixed. Removing clips from a Soldier or Aquanaut does not remove the clips' weight. This is because the clips are not correctly assigned to the Soldier or Aquanaut in the first place. See [[Talk:TFTDextender#Weightless Ammo Bug]].
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)

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

===<s> Items on transport floor lost on Abort</s> ===

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

:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

===<s> Coelacanth/Gauss mutates into Coelacanth/G.C.</s> ===

In my current game (using the Steam version) I observed it twice that, when a Coelacanth/Gauss is removed from a sub due to lack of ammo, it turns into a Coelacanth/Gas Cannon.
Note that I'm using only the Gauss Tank Ammo Fix, but not the Gauss Tank Turret Stats Fix, nor the Improved Gauss Tank mod.
[[User:AMX|AMX]] 09:09, 1 November 2012 (EDT)

:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

===<s> Cannot build Leviathan </s> ===

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

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

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

===<s> Executable directive </s>===
''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)

=== <s>Extra Artefacts Reported</s> ===
''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)
:'''Fixed in the patch 3.1-'''[[User:Morgan525|Tycho]]
: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)

===<s>Manufacturing Projects Minimum Production</s> ===

In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)

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

:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)
''' Changed the output to display "$unlimited$".'''[[User:Morgan525|Tycho]]

===<s>Stunned MC'd Aquanauts MIA on Abort </s> ===

This is a subset of MC'd Aquanauts go MIA [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]. In this case Aquanauts are MC'd by the aliens, then stunned (by friendlies), then the mission is Aborted with the stunned X-Com Aquanauts aboard the transport. The Aquanauts then disappear from the roster forever. I'm not sure if it's due to Abort rather than Victory, or due to them being stunned first. This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)
:'''I now have the code in place to uncontrol any creature that has been rendered unconscious. Available in patch 3.1- -'''[[User:Morgan525|Tycho]]

====<s> Crewed Flying Sub Lost on Abort </s>====

Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)
:''I found the nature of the issue here: This only will happen with a tank present. On one hand, all parts of the tank are being counted separately but then the End of Battle routine calculates the number of units correctly (ignores three of the sections of a tank) but when it goes to locate the units on the battlefield, the three other parts of the tank are being counted and thus the last three aquanauts are not checked since the 4 areas of the tank are first in the UNITPOS.DAT file.-[[User:Morgan525|Tycho]] 09:47, 24 October 2012 (EDT)''

'''Fixed in 105 patch 4.'''-[[User:Morgan525|Tycho]]

=== <s>Grenade Resistance in INI file </s> ===
:''I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]

===<s> Materials deducted from wrong base </s>===
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)

===<s> OBDATA / Dye Grenade mod not working? </s>===
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)

=== <s>Displacer/Sonic damage fix</s> ===

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

===<s> Weight Display in Inventory not Localised </s> ===

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

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

= Feature Requests and Suggestions =

== Useful alien species research ==

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

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

Definite +1. It would be equally valid to add to UFO Extender. I suppose it could also be implemented using Vulnerabilities (no Vulnerabilities are in effect until the Autopsy is completed), or Resistances (across-the-board increased Resistances until Autopsy is completed). If that's easier.
:''The bonus to hp was an initial thought. Later, I decided against it since it would make aliens more resistant to HE and stun, which don't rely on hitting the right locations. Increasing resistances would be the most appropriate but the damage routine code is very tight and adding anything new that won't break the existing variable stack pointers is tough. Tycho ''
::''A new idea for this that I recently have been toying with, would be on the damage generation routine: Most direct fire damage is <s>0-200</s> 50-150%, with anything over 100% considered a "critical hit". If autopsy hasn't been preformed, then the base damage would be 0-100% and a small chance (maybe 25%) of another 0-50% for that lucky shot. With autopsy done, the game reverts back to the usual <s>0-200</s>% on any hit.''
That works. And it makes doing Alien Autopsies a no-brainer, as it should be. It is pretty much inconceivable that XCom wouldn't prioritise the autopsy of any newly encountered alien. And any player playing the game for the first time would do autopsies too. This mod will help experienced players to stop playing as if they've "seen it all before". Spike 10:35, 15 September 2012 (EDT)

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

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

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

== All Units Can "Fly" In Water ==

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

== Aliens Pick Up Weapons ==

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.

: 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)
:''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)''

==General Tank Modding ==

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

Thanks,
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)

== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==

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.

This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.

== Fix Interception and Navigation Course Algorithms ==

Or just find the algorithms and I volunteer to fix them!

=== Use Great Circle Routes ===

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!).

=== Use Predictive Interception ===

For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.

=== Show Degree Headings ===

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.
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.

== Interception Craft vs Touched Down Alien Craft ==

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.

For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach.

== Fun, not Funky, Fire ==

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.

== Retaliate for Colony Assault ==

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.

== TFTDextender and XComUtil ==

I suggest adding a section on co-operating with XComUtil. As for now the article informs that the the exe split as done by XComUtil is incorrect, and there is a cure for this problem (btw., why not to correct XComUtil itself?). But this is not the only problem. XComUtil installer can detect UFOextender - but has no procedures for TFTDextender at all. You may suppose that installing both is possible this way:
1. copy TFTDextender files into the folder where TFTD CE is installed,
2. install XComUtil to that copy of the game,
3. copy BB's Toolkit into the game folder and correct the exe split,
4. rename TFTDextender.exe into UFOloader.exe (and .ini as well?),
5. copy sebLoader.xcf from an existing instalation of XComUtil for UFO:EU CE + UFOextender.
Perhaps it will work. Has such a combination ever been tested to work properly?

And why it should be so complicated? Is it possible to make needed changes in XComUtil? But it has support for UFOextender - why not for TFTDextender?

== Trojan Horse? ==

AVG Anti-Virus reports that TFTDExtender.exe contains a Trojan Horse (Generic30.MKG). Could you fix this somehow?

[[User:Sherlock|Sherlock]] 05:21, 14 January 2013 (EST)

== Another patch to the research tree ==

Thanks to TFTDextender, Coelacanth/Gauss is no more dependent on the alien-based sub technology, and this is fully correct, bravo! I would like to call your attention to another strange research tree dependency. I mean you can start with working on Bombardment Shield only after finishing with The Latest Flying Sub. It makes the shield completely useless. Namely: it is not enough to finish with New Fighter Transporter, next you must examine Lobster Man Commander. Assuming that you have already investigated The Ultimate Threat, when you finish with that beast, you will get two new topics: T'leth the Alien's City, and The Latest Flying Sub. Let's assume you will investigate the sub first. When finished, you may start constructing Leviathan. In the same time you can work on T'leth. In practice, when Leviathan is ready, you will also finish with T'leth. In this very moment you can float to T'leth and finish the game, even not having started the Bombardment Shield topic. So, where is the use of Bombardment Shield?

But assume that despite of all you very much want to see how it looks and how it works. So, OK, after having investigated Leviathan, you can start the Bombardment Shield topic. In the same time you can construct the sub. It is very likely that you will have Leviathan at your disposal when you finish with investigating Bombardment Shield. Now you can start investigating T'leth, and constructing the facility. But this is a little problem - the constructing of Bombardment Shield needs 38 days! It means that even in this scenario you will be ready to go to T'leth before you have even constructed the facility! And if you really wanted to see how it works, you would have to wait a month or even longer, until a hostile sub appears at your gates. What for should you wait if you are ready to go to the heart of the aliens' empire, and finish with them? Such a game when there is no more to investigate is just boring.

Hence my proposal to make Bombardment Shield to be similar to Grav Shield in UFO:EU. If the topic depended on New Fighter Transporter as a prerequisite instead of The Latest Flying Sub, you would have some use of this facility. It could be ready to work even before having any Leviathan constructed. And you would have a chance to see it working.

My personal opinion is that the dependency of Bombardment Shield on The Latest Flying Sub is another mistake of TFTD programmers. So, it is a bug, and such a change of the research tree would not be a mod but a patch rather.

[[User:Sherlock|Sherlock]] 05:56, 14 January 2013 (EST)

== A proposal for another alternate research tree ==

Alien technology is based on Zrbite and Aqua Plastics. When you investigate a product of alien technology, you will be able to reproduce it in your workshops. How is it possible without having an idea on materials of which they are constructed?

Both UFO:EU and TFTD research trees basically ignore the need of knowledge on alien materials. It is quite logical as long as you just use alien weapon - but it becomes really strange when you produce the weapon. How to work with a material when you do not know its features?

My first question - would be possible to separate of using an object and reproducing it? If yes, it is all right to obtain e.g. a sonic pulser, next to examine it, and when finished, to use it. But not to produce it, until you learn on zrbite. The basic idea is that only after finishing your zrbite investigation, you should have possibility to construct your own sonic pulsers.

The first possibility is that it could be done by a very simple metod. When you get a crystal of zrbite or a sample of aqua plastics, it could be just artefacts unless you have them investigated. Then you will be able to use e.g. sonic weapons (after having them investigated) - but as you would not see zrbite and aqua plastics as such, you would not make any use of them, including making sonic weapons by your own.

The other idea is that nothing can be understood if we have not obtained knowledge on alien materials which are needed to produce the investigated object. It means to make them real prerequisites for investigations. Now Disruptor Ammo needs Zrbite for producing, and it needs the Zrbite topic finished as its prerequisite as well. I mean to make Zrbite a prerequisite also for all three clips for sonic weapons, Thermal Shok Bomb, Sonic Pulser, Vibro Blade (and both thermic lances), Ion-Beam Accelerators, Ion Armour (and Magnetic IA), M.C. Reader (and M.C. Disruptor) - as they all need Zrbite when produced. And also to make Aqua Plastics a prerequisite for all three sonic weapons, Thermal Shok Launcher, Disruptor Pulse Launcher (and P.W.T. Cannon), Ion-Beam Accelerators, Magnetic Navigation, M.C. Reader (and M.C. Disruptor) - as they all need Aqua Plastics when produced.

I have tested such a modification of the research tree just by stopping any investigations of objects from the two lists above until Zrbite and (Deep One Corpse +) Aqua Plastics topics are finished. In my opinion it does not unbalance the game except it gives another argument for using Gauss technology first than sonic. Namely, under this condition it is enough to finish just three topics: Gauss Technology, Gauss Pistol and Gauss Pistol Clip, in order to have a little more effective weapon at one's disposal. But if you want to use sonic instead, you must obtain a dead Deep One on a mission, plus some samples of Zrbite (and Aqua Plastics - in fact there is not such a condition), and you need to have researched five topics altogether: Deep One Corpse, Aqua Plastics, Sonic Pistol, Zrbite, Pistol Power Clip.

It would be a modification of the game as nothing similar is implemented in either UFO:EU or TFTD (except the need of knowing Zrbite in order to start investigation of Disruptor Ammo).

[[User:Sherlock|Sherlock]] 07:16, 14 January 2013 (EST)

== The research tree - Yet another bug? ==

Now you do not have to have some objects in your stores in order to examine (?) it. It looks like your engineers are so genius that they can guess how those objects look like, not even having a single look on them. Your invented copy appears to be just like the genuine alien object. Is this scenario logical at all? I think it is not, and it is just another bug which should be removed. The only problem (?) is, however, that this bug (?) makes the game easier. So, patching it would make the game harder.

Namely, I think that 4 objects: Aqua Plastics, Vibro Blade, Thermic Lance and Heavy Thermic Lance should be present in stores to start examination on them, naturally when other conditions are fulfilled. So, for example, you will still have to examine Deep One Corpse, but it will not give you a way to inventing Aqua Plastics. First you will have to get them, and keep them in your stores. And only them, after finishing Deep One Corpse, you will be able to start examining (not: inventing!) Aqua Plastics.

And the same with the finished Calcinite Corpse topic and a stored Vibro Blade, the finished Vibro Blade and Gill Man Corpse topics and a stored Thermic Lance, and also the finished Thermic Lance topic and a stored Heavy Thermic lance.

[[User:Sherlock|Sherlock]] 07:27, 14 January 2013 (EST)

== The Calcinite Dilemma ==

The need of researching both Deep One Corpse and a live Deep One has been named the Deep One Dilemma. Personally, I cannot see a problem in there, and I really cannot understand the other players. I have played TFTD many times, and I have never any least problems with obtaining both corpse and a live specimen of this creature. In a result, I do not understand why it can harm anyone. But you can buy Thermal Tazers at the very beginning of your campaign. They are cheap and easy to use. Deep Ones always appear several times in early missions. They are not too dangerous, and you can enough safely freeze one. And even more, if you use human weapons like darts, you have a high chance to get one live without any freezing.

So, what is the source of this dilemma? You know you need this creature. You have enough numerous possibilities to hunt for it. You have weapons which are suitable for this. So, where is the problem? If you do not want to capture a Deep One, and you prefer just shooting and kill'em'all-ing instead of playing, do not complain then that you have no progress in your research. Just keep shooting... I do not believe that killing aliens is the only objective of the game. It is OK that there is a possibility to eliminate the need of Deep One to research Ion Armour - but it is nothing but a cheat. I do not like it, and I will not use it. Just like adding money or making my aquanauts superhumans.

But Calcinites and the need of the body of the creature for starting with examinating melee weapons is a completely different problem. As I said, I have played the game many times. And I have never spotted a single calcinite during first months of the game, and telling the truth, I have whole campaignes without any single creature of this kind. I believe there is an error in the game which prevents from appearing aquatoids on terror missions.

And hence my question: is it possible for TFTDextender to control which alien race starts an alien mission in the game? It would be the solution of the calcinite problem I would like much. Instead of manipulating with the research tree, it would be enough to forse some mission types from the same beginning. If aquatoid + calcinite missions, as well as gill men + deep ones mission were still present during all the game, nobody could also complain that he/she cannot capture a live deep one. And it would give a better chance for getting melee weapons earlier (without hacking, cheating and changing the research tree).

[[User:Sherlock|Sherlock]] 07:50, 14 January 2013 (EST)

== And yet another reason for forcing some alien mission types ==

In TFTD some terror races are seen mainly or exclusively on lands while other under the sea. Let's assume a Battleship is heading to an island, a port, or a human ship, in order to start a terror. Save the game, and shoot it down (if you can...). Go to a mission. And what will you see? If it was a aquatoid mission (very rarely!), you will fight with Hallucinoids. If it were Gill Men aboard, you will have unpleasurement with Xarquids (btw. does it mean Xark = Shark + Squid?). Break your game, and load it from the save. Let the sub land, and go for the terror mission. Now you will see Calcinites with Aquatoids, or Deep Ones with Gill Men.

How is it possible? The same sub, the same alien squad. And different results! It would be pretty easy to understand if there were not aquatic creatures on land missions: they were aboard on the Battleship but they did not get off. The sub floated back with them, leaving the main race and their land pets on the land, terrorizing people. But if it was so, you should spot both land and aquatic races when having the sub shot down. And it would be really great if it was so.

In UFO:EU mutons are associated with silacoids and celatids in the same time. When you spot one terror race, there is a very big chance to spot the other as well. In TFTD things go otherwise. Both Bio-Drones and Triscenes are associated with Tasoths on land missions, but they probably never happen side-by-side. Contrary to Mutons, Tasoths have either Bio-Drones or Triscenes, never both on the same mission.

Both games have the same engine, so it should not be a problem to force it to generate more various alien squads. First, I mean both Bio-Drones and Triscenes together on the same terror mission with their masters - Tasoths. Telling the truth, I have seen Triscenes once, maybe twice, in all my TFTD campaignes. Tasoths rarely make land missions, so to see a Triscene is like to see a USO in the real world. It seems it really needs a correction, and TFTDextender would be an appropriate candidate for it. So, my first proposal is to change Tasoths + Bio-Drones and Tasoth + Triscenes missions into Tasoth + Bio-Drones + Triscenes missions (by analogy to Mutons + Celatids + Silacoids in UFO: EU).

And another proposal. In order to make the game fiction a little more plausible, I think all races should appear in underwater missions. There are several arguments for that. The first is discussed above. If a landed sub provides e.g. Aquatoids + Calcinites on a terror mission, they should also be present in the sub when it has been shot. So, I would see:
# Aquatoids + Calcinites + Hallucinoids,
# Gill Men + Deep Ones + Xarquids,
# Lobster Men + Bio-Drones + Tentaculats,
# Tasoths + Bio-Drones + Triscenes (see above) + Tentaculats
on undersea missions, at least when a battleship is downed (a terror mission is cancelled by XCom).

The other argument is to make some alien races available throughout the whole campaign (for those who forget to capture such or another creature). Note that UFO: EU does not have such stupid limitations like disappearing some races during the game. Managing alien mission types, as well as the content of the alien squad on the mission, would be a great solution of this problem.

Yet another argument is that some races do not like to make terror missions at all. If any alien creature could be spotted under the sea, it would eliminate the problem of meeting some types (like Calcinites, and especially Triscenes).

The game does not prevent land races on underwater missions completely. Namely, sometimes Deep Ones are seen under the sea (probably only with a mixed crew missions). So, there is not a base objection to place land terror races under water.

And the final argument. The main alien races are undersea creatures. They do not like land, except terror missions (and Xcom bases assaults). So, ALL their pets (= terror races) should be able to live under water as well. Can you imagine a thinking fish who looks after a cat as his/her pet?

And this is not all. Tentaculats and Xarquids do not look like able to live on the land, and during first missions they are not spotted on the land indeed. Unfortunately, the game does not prevent them from being seen on land mission completely. Namely, in further stages of the campaign, so called Mixed Crews appears. In fact they are Tasoths (1st type) or Lobster Men (2nd type) plus Aquatoids missions, with their own pets, with Gill Men pets instead of Aquatoids pets possible as well (hence Tasoths + Aquatoids + Triscenes + Calcinites is a possible (?) terror mission, as well as Tasoths + Aquatoids + Triscenes + Deep Ones should be possible).

Unfortunately, in the real game, Xarquids can accompany Tasoths and Aquatoids mixed crew on the land. It looks like a game error when these undersea creatures levitate in a port, really. Or in an XCom base. I think Xarquids, as obviously sea creatures, should be eliminated from all land missions, and replaced by Deep Ones.

And for a similar unknown reason Tentaculats somehow appear sometimes in Xcom bases during an alien mixed crew assault. It is so rare phenomenon that removing this possibility would do severe unbalancing to the game, I think.

So, my requests are 1) to place both Bio-Drones and Triscenes in Tasoth missions, 2) to place all land races (Calcinites, Deep Ones, Bio-Drones, and Triscenes) on underwater missions, together with underwater races, 3) to eliminate underwater races (Xarquids and Tentaculats) from any land missions (Hallucinoids are eliminated now, so they are OK in this point).

[[User:Sherlock|Sherlock]] 08:55, 14 January 2013 (EST)

== More various missions ==

I have found a "diary" of a TFTD campaign. It has never been finished even if all researches have already been made. The last record is Alien Sub-273, and the time is August 2041. I have tried to down as many subs as possible, and to have as many missions as I could (naturally with all touched-down subs as well).

During that campaign triscenes did not appear even once (and the are in the Ufopedia only because of medics). Calcinites were seen only twice, as part of the crew of a downed dreadnought which was Sub-209, and on an island terror (Terror-10 mission) between Sub-237 and Sub-238. Any mixed crew was never spot, during 1,5 year of the campaign! Heavy Cruiser was first seen as Sub-137, and was seen four times more (so, 5 Subs of the total number of 273, were Heavy Cruisers. Hunter was seen 9 times, so it was also very rare. There were only 11 terror missions altogether (at 273 recorded subs!), and 13 alien base assaults, including 2 alien activities missions, and 11 colonies. My bases were attacked only twice (!).

So, some alien races, some alien vessels, and some alien mission types are extremely rare in campaigns. Not always results as as described. I did see mixed crew subs but not in that campaign. I remember a campaign with no calcinites at all, and with no Hunters at all.

And I think that what people say on alien revenge is false. When you down an alien sub with a certain mission, it can stop their further activity in that mission. But if you let the aliens make their activity, they continue their mission. People write that harming aliens cause their response, and larger and larger subs are sent by them to that mission. I have stated that it is quite the way round - if you do not harm aliens, they send larger and larger subs. Last 4 subs in the described campaign were with the same mission. They were uso type 1, 2, 3, and 5 (Hunter) - only the last one was downed by me.

Conclusion: the game neeeds some patching. It would be really nice if TFTDextender could control alien missions, forcing the game to more variety of alien races, subs, and to more terror missions (as they are a perfect source of some races). Apearing of some main alien races, including mixed crew types, is also not as it should be. The tables in the article [[Alien Appearance Ratios (TFTD)]] do NOT describe the real game behaviour. How is it possible not to appear any mixed crew for 18 months of the game's time? They SHOULD appear at 20-30% rate. But they CAN appear with 0% rate!

[[User:Sherlock|Sherlock]] 09:22, 14 January 2013 (EST)

Talk:TFTDextender

2013-01-14T13:55:17Z

Sherlock: /* And yet another reason for forcing some alien mission types */

=Questions or Comments=
'''A place to provide feedback or ask questions:'''
:''Thanks to Kyrub, Spike, and numerous others who help to troubleshoot problems, provide feedback on releases, and innumerable other activities to help make TFTDextender and the game better! -'' [[User:Morgan525|Tycho]]

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

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

== Bug Reports ==
===Major Bugs===
==== Crash when starting a landed/crashed USO battle ====

:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."

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

=== Minor Bugs ===
==== Stunned Carried Aquanauts MIA on Abort ====

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)

:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. Your right, carried objects won't have their location updated until they are dropped or thrown. At least it is a manageable issue: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)

== Things that TFTDextender does not fix ==

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

* Does not fix the apparent swap of the ground map for the VERY SMALL Survey Ship (1 occupant) with the SMALL Escort (half-dozen or more occupants). So you get the VERY SMALL sub occupying about 25 squares of usable area on the Battlescape, and the supposedly larger SMALL sub occupying one square of usable area on the Battlescape, begging the question of how all those aliens got inside there in the first place. XcomUtil will fix this, as will the original patches that XcomUtil incorporates.
* Does not fix the incorrect pictures for the large USO in the interception window.
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]
* Does not fix the Dart Gun to make it any less utterly useless. Though you can do this yourself via the OBDATA.DAT section of TFTDextender. (Suggestion: don't fix it. The useless Dart Gun is all part of the "oh no we're all gonna die" experience of the beginning of TFTD.)
* Does not improve the armour and effectiveness of the basic Aqua-Jet and Gas Cannon Coelecanths (it does upgrade the Coelecanth/Gauss). (Again, suggestion: this is a good thing - XCOM should start the game hopelessly outclassed, and scramble to catch up).
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.
* Does not allow you to have 360 degree vision out of your sub before exiting it. (What kind of coward would want that?). XComUtil does this.

*When I try to send any Leviathan to T'Leth, I get an immediate crash: "XCOM crashed at 0x458822 with error 0xC0000005 trying to access 0xFA6C8304.".
:It happens when the CE version doesn't find the RISE animation: Specifically, it needs ANIMS\RISE.IDX and ANIMS\RISE.VID - If RISE.IDX is missing, it crashes with the error code above, if RISE.VID is missing, it crashes with another error. Some experimenting suggests that RISE.VID can be any valid .VID file, while RISE.IDX can either be empty (producing a black screen that can be skipped by clicking) or the "appropriate" .IDX for the used .VID...[[User:AMX|AMX]] 13 November 2012 (EST)

=Resolved Reported Problems=
===<s> Save Equipment not working</s> ===

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

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

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

:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

===<s> Weight Issues or "Weightless" Ammo Bug </s>===

while playing TFD with TFD extender (v. 1.05 patch 1.1) I've noticed a stange thing: some soldiers have their weight > 0 (2-5) even when their inventory is empty! Bug?... [[User:PavelB|PavelB]] 05:17, 27 September 2012 (EDT)
:If you drop a loaded weapon, even if you loaded it manually, the weight of the ammo still stays with the Aquanaut. Workaround: unload each weapon manually before dropping it. If you forget (and if you notice) it's possible to pick the weapon up again, unload it, and correctly lose the weight by dropping the weapon and clip separately. It's possible to build up huge amounts of phantom weight on a Soldier by repeatedly loading, and then dropping, different weapons. It's also possible to move lots of weapons with weightless clips to one Soldier, increasing the amount of 'free' weight that one Soldier gets. Both of these effects are probably aspects of the original bug, not anything that UFOExtender has done. [[User:Spike|Spike]] 11:15, 27 September 2012 (EDT)
::This Weight error is a side effect of an original game error that Seb never quite fixed. Removing clips from a Soldier or Aquanaut does not remove the clips' weight. This is because the clips are not correctly assigned to the Soldier or Aquanaut in the first place. See [[Talk:TFTDextender#Weightless Ammo Bug]].
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)

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

===<s> Items on transport floor lost on Abort</s> ===

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

:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

===<s> Coelacanth/Gauss mutates into Coelacanth/G.C.</s> ===

In my current game (using the Steam version) I observed it twice that, when a Coelacanth/Gauss is removed from a sub due to lack of ammo, it turns into a Coelacanth/Gas Cannon.
Note that I'm using only the Gauss Tank Ammo Fix, but not the Gauss Tank Turret Stats Fix, nor the Improved Gauss Tank mod.
[[User:AMX|AMX]] 09:09, 1 November 2012 (EDT)

:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

===<s> Cannot build Leviathan </s> ===

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

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

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

===<s> Executable directive </s>===
''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)

=== <s>Extra Artefacts Reported</s> ===
''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)
:'''Fixed in the patch 3.1-'''[[User:Morgan525|Tycho]]
: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)

===<s>Manufacturing Projects Minimum Production</s> ===

In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)

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

:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)
''' Changed the output to display "$unlimited$".'''[[User:Morgan525|Tycho]]

===<s>Stunned MC'd Aquanauts MIA on Abort </s> ===

This is a subset of MC'd Aquanauts go MIA [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]. In this case Aquanauts are MC'd by the aliens, then stunned (by friendlies), then the mission is Aborted with the stunned X-Com Aquanauts aboard the transport. The Aquanauts then disappear from the roster forever. I'm not sure if it's due to Abort rather than Victory, or due to them being stunned first. This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)
:'''I now have the code in place to uncontrol any creature that has been rendered unconscious. Available in patch 3.1- -'''[[User:Morgan525|Tycho]]

====<s> Crewed Flying Sub Lost on Abort </s>====

Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)
:''I found the nature of the issue here: This only will happen with a tank present. On one hand, all parts of the tank are being counted separately but then the End of Battle routine calculates the number of units correctly (ignores three of the sections of a tank) but when it goes to locate the units on the battlefield, the three other parts of the tank are being counted and thus the last three aquanauts are not checked since the 4 areas of the tank are first in the UNITPOS.DAT file.-[[User:Morgan525|Tycho]] 09:47, 24 October 2012 (EDT)''

'''Fixed in 105 patch 4.'''-[[User:Morgan525|Tycho]]

=== <s>Grenade Resistance in INI file </s> ===
:''I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]

===<s> Materials deducted from wrong base </s>===
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)

===<s> OBDATA / Dye Grenade mod not working? </s>===
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)

=== <s>Displacer/Sonic damage fix</s> ===

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

===<s> Weight Display in Inventory not Localised </s> ===

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

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

= Feature Requests and Suggestions =

== Useful alien species research ==

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

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

Definite +1. It would be equally valid to add to UFO Extender. I suppose it could also be implemented using Vulnerabilities (no Vulnerabilities are in effect until the Autopsy is completed), or Resistances (across-the-board increased Resistances until Autopsy is completed). If that's easier.
:''The bonus to hp was an initial thought. Later, I decided against it since it would make aliens more resistant to HE and stun, which don't rely on hitting the right locations. Increasing resistances would be the most appropriate but the damage routine code is very tight and adding anything new that won't break the existing variable stack pointers is tough. Tycho ''
::''A new idea for this that I recently have been toying with, would be on the damage generation routine: Most direct fire damage is <s>0-200</s> 50-150%, with anything over 100% considered a "critical hit". If autopsy hasn't been preformed, then the base damage would be 0-100% and a small chance (maybe 25%) of another 0-50% for that lucky shot. With autopsy done, the game reverts back to the usual <s>0-200</s>% on any hit.''
That works. And it makes doing Alien Autopsies a no-brainer, as it should be. It is pretty much inconceivable that XCom wouldn't prioritise the autopsy of any newly encountered alien. And any player playing the game for the first time would do autopsies too. This mod will help experienced players to stop playing as if they've "seen it all before". Spike 10:35, 15 September 2012 (EDT)

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

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

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

== All Units Can "Fly" In Water ==

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

== Aliens Pick Up Weapons ==

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.

: 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)
:''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)''

==General Tank Modding ==

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

Thanks,
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)

== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==

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.

This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.

== Fix Interception and Navigation Course Algorithms ==

Or just find the algorithms and I volunteer to fix them!

=== Use Great Circle Routes ===

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!).

=== Use Predictive Interception ===

For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.

=== Show Degree Headings ===

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.
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.

== Interception Craft vs Touched Down Alien Craft ==

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.

For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach.

== Fun, not Funky, Fire ==

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.

== Retaliate for Colony Assault ==

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.

== TFTDextender and XComUtil ==

I suggest adding a section on co-operating with XComUtil. As for now the article informs that the the exe split as done by XComUtil is incorrect, and there is a cure for this problem (btw., why not to correct XComUtil itself?). But this is not the only problem. XComUtil installer can detect UFOextender - but has no procedures for TFTDextender at all. You may suppose that installing both is possible this way:
1. copy TFTDextender files into the folder where TFTD CE is installed,
2. install XComUtil to that copy of the game,
3. copy BB's Toolkit into the game folder and correct the exe split,
4. rename TFTDextender.exe into UFOloader.exe (and .ini as well?),
5. copy sebLoader.xcf from an existing instalation of XComUtil for UFO:EU CE + UFOextender.
Perhaps it will work. Has such a combination ever been tested to work properly?

And why it should be so complicated? Is it possible to make needed changes in XComUtil? But it has support for UFOextender - why not for TFTDextender?

== Trojan Horse? ==

AVG Anti-Virus reports that TFTDExtender.exe contains a Trojan Horse (Generic30.MKG). Could you fix this somehow?

[[User:Sherlock|Sherlock]] 05:21, 14 January 2013 (EST)

== Another patch to the research tree ==

Thanks to TFTDextender, Coelacanth/Gauss is no more dependent on the alien-based sub technology, and this is fully correct, bravo! I would like to call your attention to another strange research tree dependency. I mean you can start with working on Bombardment Shield only after finishing with The Latest Flying Sub. It makes the shield completely useless. Namely: it is not enough to finish with New Fighter Transporter, next you must examine Lobster Man Commander. Assuming that you have already investigated The Ultimate Threat, when you finish with that beast, you will get two new topics: T'leth the Alien's City, and The Latest Flying Sub. Let's assume you will investigate the sub first. When finished, you may start constructing Leviathan. In the same time you can work on T'leth. In practice, when Leviathan is ready, you will also finish with T'leth. In this very moment you can float to T'leth and finish the game, even not having started the Bombardment Shield topic. So, where is the use of Bombardment Shield?

But assume that despite of all you very much want to see how it looks and how it works. So, OK, after having investigated Leviathan, you can start the Bombardment Shield topic. In the same time you can construct the sub. It is very likely that you will have Leviathan at your disposal when you finish with investigating Bombardment Shield. Now you can start investigating T'leth, and constructing the facility. But this is a little problem - the constructing of Bombardment Shield needs 38 days! It means that even in this scenario you will be ready to go to T'leth before you have even constructed the facility! And if you really wanted to see how it works, you would have to wait a month or even longer, until a hostile sub appears at your gates. What for should you wait if you are ready to go to the heart of the aliens' empire, and finish with them? Such a game when there is no more to investigate is just boring.

Hence my proposal to make Bombardment Shield to be similar to Grav Shield in UFO:EU. If the topic depended on New Fighter Transporter as a prerequisite instead of The Latest Flying Sub, you would have some use of this facility. It could be ready to work even before having any Leviathan constructed. And you would have a chance to see it working.

My personal opinion is that the dependency of Bombardment Shield on The Latest Flying Sub is another mistake of TFTD programmers. So, it is a bug, and such a change of the research tree would not be a mod but a patch rather.

[[User:Sherlock|Sherlock]] 05:56, 14 January 2013 (EST)

== A proposal for another alternate research tree ==

Alien technology is based on Zrbite and Aqua Plastics. When you investigate a product of alien technology, you will be able to reproduce it in your workshops. How is it possible without having an idea on materials of which they are constructed?

Both UFO:EU and TFTD research trees basically ignore the need of knowledge on alien materials. It is quite logical as long as you just use alien weapon - but it becomes really strange when you produce the weapon. How to work with a material when you do not know its features?

My first question - would be possible to separate of using an object and reproducing it? If yes, it is all right to obtain e.g. a sonic pulser, next to examine it, and when finished, to use it. But not to produce it, until you learn on zrbite. The basic idea is that only after finishing your zrbite investigation, you should have possibility to construct your own sonic pulsers.

The first possibility is that it could be done by a very simple metod. When you get a crystal of zrbite or a sample of aqua plastics, it could be just artefacts unless you have them investigated. Then you will be able to use e.g. sonic weapons (after having them investigated) - but as you would not see zrbite and aqua plastics as such, you would not make any use of them, including making sonic weapons by your own.

The other idea is that nothing can be understood if we have not obtained knowledge on alien materials which are needed to produce the investigated object. It means to make them real prerequisites for investigations. Now Disruptor Ammo needs Zrbite for producing, and it needs the Zrbite topic finished as its prerequisite as well. I mean to make Zrbite a prerequisite also for all three clips for sonic weapons, Thermal Shok Bomb, Sonic Pulser, Vibro Blade (and both thermic lances), Ion-Beam Accelerators, Ion Armour (and Magnetic IA), M.C. Reader (and M.C. Disruptor) - as they all need Zrbite when produced. And also to make Aqua Plastics a prerequisite for all three sonic weapons, Thermal Shok Launcher, Disruptor Pulse Launcher (and P.W.T. Cannon), Ion-Beam Accelerators, Magnetic Navigation, M.C. Reader (and M.C. Disruptor) - as they all need Aqua Plastics when produced.

I have tested such a modification of the research tree just by stopping any investigations of objects from the two lists above until Zrbite and (Deep One Corpse +) Aqua Plastics topics are finished. In my opinion it does not unbalance the game except it gives another argument for using Gauss technology first than sonic. Namely, under this condition it is enough to finish just three topics: Gauss Technology, Gauss Pistol and Gauss Pistol Clip, in order to have a little more effective weapon at one's disposal. But if you want to use sonic instead, you must obtain a dead Deep One on a mission, plus some samples of Zrbite (and Aqua Plastics - in fact there is not such a condition), and you need to have researched five topics altogether: Deep One Corpse, Aqua Plastics, Sonic Pistol, Zrbite, Pistol Power Clip.

It would be a modification of the game as nothing similar is implemented in either UFO:EU or TFTD (except the need of knowing Zrbite in order to start investigation of Disruptor Ammo).

[[User:Sherlock|Sherlock]] 07:16, 14 January 2013 (EST)

== The research tree - Yet another bug? ==

Now you do not have to have some objects in your stores in order to examine (?) it. It looks like your engineers are so genius that they can guess how those objects look like, not even having a single look on them. Your invented copy appears to be just like the genuine alien object. Is this scenario logical at all? I think it is not, and it is just another bug which should be removed. The only problem (?) is, however, that this bug (?) makes the game easier. So, patching it would make the game harder.

Namely, I think that 4 objects: Aqua Plastics, Vibro Blade, Thermic Lance and Heavy Thermic Lance should be present in stores to start examination on them, naturally when other conditions are fulfilled. So, for example, you will still have to examine Deep One Corpse, but it will not give you a way to inventing Aqua Plastics. First you will have to get them, and keep them in your stores. And only them, after finishing Deep One Corpse, you will be able to start examining (not: inventing!) Aqua Plastics.

And the same with the finished Calcinite Corpse topic and a stored Vibro Blade, the finished Vibro Blade and Gill Man Corpse topics and a stored Thermic Lance, and also the finished Thermic Lance topic and a stored Heavy Thermic lance.

[[User:Sherlock|Sherlock]] 07:27, 14 January 2013 (EST)

== The Calcinite Dilemma ==

The need of researching both Deep One Corpse and a live Deep One has been named the Deep One Dilemma. Personally, I cannot see a problem in there, and I really cannot understand the other players. I have played TFTD many times, and I have never any least problems with obtaining both corpse and a live specimen of this creature. In a result, I do not understand why it can harm anyone. But you can buy Thermal Tazers at the very beginning of your campaign. They are cheap and easy to use. Deep Ones always appear several times in early missions. They are not too dangerous, and you can enough safely freeze one. And even more, if you use human weapons like darts, you have a high chance to get one live without any freezing.

So, what is the source of this dilemma? You know you need this creature. You have enough numerous possibilities to hunt for it. You have weapons which are suitable for this. So, where is the problem? If you do not want to capture a Deep One, and you prefer just shooting and kill'em'all-ing instead of playing, do not complain then that you have no progress in your research. Just keep shooting... I do not believe that killing aliens is the only objective of the game. It is OK that there is a possibility to eliminate the need of Deep One to research Ion Armour - but it is nothing but a cheat. I do not like it, and I will not use it. Just like adding money or making my aquanauts superhumans.

But Calcinites and the need of the body of the creature for starting with examinating melee weapons is a completely different problem. As I said, I have played the game many times. And I have never spotted a single calcinite during first months of the game, and telling the truth, I have whole campaignes without any single creature of this kind. I believe there is an error in the game which prevents from appearing aquatoids on terror missions.

And hence my question: is it possible for TFTDextender to control which alien race starts an alien mission in the game? It would be the solution of the calcinite problem I would like much. Instead of manipulating with the research tree, it would be enough to forse some mission types from the same beginning. If aquatoid + calcinite missions, as well as gill men + deep ones mission were still present during all the game, nobody could also complain that he/she cannot capture a live deep one. And it would give a better chance for getting melee weapons earlier (without hacking, cheating and changing the research tree).

[[User:Sherlock|Sherlock]] 07:50, 14 January 2013 (EST)

== And yet another reason for forcing some alien mission types ==

In TFTD some terror races are seen mainly or exclusively on lands while other under the sea. Let's assume a Battleship is heading to an island, a port, or a human ship, in order to start a terror. Save the game, and shoot it down (if you can...). Go to a mission. And what will you see? If it was a aquatoid mission (very rarely!), you will fight with Hallucinoids. If it were Gill Men aboard, you will have unpleasurement with Xarquids (btw. does it mean Xark = Shark + Squid?). Break your game, and load it from the save. Let the sub land, and go for the terror mission. Now you will see Calcinites with Aquatoids, or Deep Ones with Gill Men.

How is it possible? The same sub, the same alien squad. And different results! It would be pretty easy to understand if there were not aquatic creatures on land missions: they were aboard on the Battleship but they did not get off. The sub floated back with them, leaving the main race and their land pets on the land, terrorizing people. But if it was so, you should spot both land and aquatic races when having the sub shot down. And it would be really great if it was so.

In UFO:EU mutons are associated with silacoids and celatids in the same time. When you spot one terror race, there is a very big chance to spot the other as well. In TFTD things go otherwise. Both Bio-Drones and Triscenes are associated with Tasoths on land missions, but they probably never happen side-by-side. Contrary to Mutons, Tasoths have either Bio-Drones or Triscenes, never both on the same mission.

Both games have the same engine, so it should not be a problem to force it to generate more various alien squads. First, I mean both Bio-Drones and Triscenes together on the same terror mission with their masters - Tasoths. Telling the truth, I have seen Triscenes once, maybe twice, in all my TFTD campaignes. Tasoths rarely make land missions, so to see a Triscene is like to see a USO in the real world. It seems it really needs a correction, and TFTDextender would be an appropriate candidate for it. So, my first proposal is to change Tasoths + Bio-Drones and Tasoth + Triscenes missions into Tasoth + Bio-Drones + Triscenes missions (by analogy to Mutons + Celatids + Silacoids in UFO: EU).

And another proposal. In order to make the game fiction a little more plausible, I think all races should appear in underwater missions. There are several arguments for that. The first is discussed above. If a landed sub provides e.g. Aquatoids + Calcinites on a terror mission, they should also be present in the sub when it has been shot. So, I would see:
# Aquatoids + Calcinites + Hallucinoids,
# Gill Men + Deep Ones + Xarquids,
# Lobster Men + Bio-Drones + Tentaculats,
# Tasoths + Bio-Drones + Triscenes (see above) + Tentaculats
on undersea missions, at least when a battleship is downed (a terror mission is cancelled by XCom).

The other argument is to make some alien races available throughout the whole campaign (for those who forget to capture such or another creature). Note that UFO: EU does not have such stupid limitations like disappearing some races during the game. Managing alien mission types, as well as the content of the alien squad on the mission, would be a great solution of this problem.

Yet another argument is that some races do not like to make terror missions at all. If any alien creature could be spotted under the sea, it would eliminate the problem of meeting some types (like Calcinites, and especially Triscenes).

The game does not prevent land races on underwater missions completely. Namely, sometimes Deep Ones are seen under the sea (probably only with a mixed crew missions). So, there is not a base objection to place land terror races under water.

And the final argument. The main alien races are undersea creatures. They do not like land, except terror missions (and Xcom bases assaults). So, ALL their pets (= terror races) should be able to live under water as well. Can you imagine a thinking fish who looks after a cat as his/her pet?

And this is not all. Tentaculats and Xarquids do not look like able to live on the land, and during first missions they are not spotted on the land indeed. Unfortunately, the game does not prevent them from being seen on land mission completely. Namely, in further stages of the campaign, so called Mixed Crews appears. In fact they are Tasoths (1st type) or Lobster Men (2nd type) plus Aquatoids missions, with their own pets, with Gill Men pets instead of Aquatoids pets possible as well (hence Tasoths + Aquatoids + Triscenes + Calcinites is a possible (?) terror mission, as well as Tasoths + Aquatoids + Triscenes + Deep Ones should be possible).

Unfortunately, in the real game, Xarquids can accompany Tasoths and Aquatoids mixed crew on the land. It looks like a game error when these undersea creatures levitate in a port, really. Or in an XCom base. I think Xarquids, as obviously sea creatures, should be eliminated from all land missions, and replaced by Deep Ones.

And for a similar unknown reason Tentaculats somehow appear sometimes in Xcom bases during an alien mixed crew assault. It is so rare phenomenon that removing this possibility would do severe unbalancing to the game, I think.

So, my requests are 1) to place both Bio-Drones and Triscenes in Tasoth missions, 2) to place all land races (Calcinites, Deep Ones, Bio-Drones, and Triscenes) on underwater missions, together with underwater races, 3) to eliminate underwater races (Xarquids and Tentaculats) from any land missions (Hallucinoids are eliminated now, so they are OK in this point).

[[User:Sherlock|Sherlock]] 08:55, 14 January 2013 (EST)

Talk:TFTDextender

2013-01-14T12:50:19Z

Sherlock: /* The Calcinite Dilemma */

=Questions or Comments=
'''A place to provide feedback or ask questions:'''
:''Thanks to Kyrub, Spike, and numerous others who help to troubleshoot problems, provide feedback on releases, and innumerable other activities to help make TFTDextender and the game better! -'' [[User:Morgan525|Tycho]]

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

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

== Bug Reports ==
===Major Bugs===
==== Crash when starting a landed/crashed USO battle ====

:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."

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

=== Minor Bugs ===
==== Stunned Carried Aquanauts MIA on Abort ====

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)

:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. Your right, carried objects won't have their location updated until they are dropped or thrown. At least it is a manageable issue: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)

== Things that TFTDextender does not fix ==

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

* Does not fix the apparent swap of the ground map for the VERY SMALL Survey Ship (1 occupant) with the SMALL Escort (half-dozen or more occupants). So you get the VERY SMALL sub occupying about 25 squares of usable area on the Battlescape, and the supposedly larger SMALL sub occupying one square of usable area on the Battlescape, begging the question of how all those aliens got inside there in the first place. XcomUtil will fix this, as will the original patches that XcomUtil incorporates.
* Does not fix the incorrect pictures for the large USO in the interception window.
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]
* Does not fix the Dart Gun to make it any less utterly useless. Though you can do this yourself via the OBDATA.DAT section of TFTDextender. (Suggestion: don't fix it. The useless Dart Gun is all part of the "oh no we're all gonna die" experience of the beginning of TFTD.)
* Does not improve the armour and effectiveness of the basic Aqua-Jet and Gas Cannon Coelecanths (it does upgrade the Coelecanth/Gauss). (Again, suggestion: this is a good thing - XCOM should start the game hopelessly outclassed, and scramble to catch up).
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.
* Does not allow you to have 360 degree vision out of your sub before exiting it. (What kind of coward would want that?). XComUtil does this.

*When I try to send any Leviathan to T'Leth, I get an immediate crash: "XCOM crashed at 0x458822 with error 0xC0000005 trying to access 0xFA6C8304.".
:It happens when the CE version doesn't find the RISE animation: Specifically, it needs ANIMS\RISE.IDX and ANIMS\RISE.VID - If RISE.IDX is missing, it crashes with the error code above, if RISE.VID is missing, it crashes with another error. Some experimenting suggests that RISE.VID can be any valid .VID file, while RISE.IDX can either be empty (producing a black screen that can be skipped by clicking) or the "appropriate" .IDX for the used .VID...[[User:AMX|AMX]] 13 November 2012 (EST)

=Resolved Reported Problems=
===<s> Save Equipment not working</s> ===

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

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

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

:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

===<s> Weight Issues or "Weightless" Ammo Bug </s>===

while playing TFD with TFD extender (v. 1.05 patch 1.1) I've noticed a stange thing: some soldiers have their weight > 0 (2-5) even when their inventory is empty! Bug?... [[User:PavelB|PavelB]] 05:17, 27 September 2012 (EDT)
:If you drop a loaded weapon, even if you loaded it manually, the weight of the ammo still stays with the Aquanaut. Workaround: unload each weapon manually before dropping it. If you forget (and if you notice) it's possible to pick the weapon up again, unload it, and correctly lose the weight by dropping the weapon and clip separately. It's possible to build up huge amounts of phantom weight on a Soldier by repeatedly loading, and then dropping, different weapons. It's also possible to move lots of weapons with weightless clips to one Soldier, increasing the amount of 'free' weight that one Soldier gets. Both of these effects are probably aspects of the original bug, not anything that UFOExtender has done. [[User:Spike|Spike]] 11:15, 27 September 2012 (EDT)
::This Weight error is a side effect of an original game error that Seb never quite fixed. Removing clips from a Soldier or Aquanaut does not remove the clips' weight. This is because the clips are not correctly assigned to the Soldier or Aquanaut in the first place. See [[Talk:TFTDextender#Weightless Ammo Bug]].
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)

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

===<s> Items on transport floor lost on Abort</s> ===

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

:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

===<s> Coelacanth/Gauss mutates into Coelacanth/G.C.</s> ===

In my current game (using the Steam version) I observed it twice that, when a Coelacanth/Gauss is removed from a sub due to lack of ammo, it turns into a Coelacanth/Gas Cannon.
Note that I'm using only the Gauss Tank Ammo Fix, but not the Gauss Tank Turret Stats Fix, nor the Improved Gauss Tank mod.
[[User:AMX|AMX]] 09:09, 1 November 2012 (EDT)

:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

===<s> Cannot build Leviathan </s> ===

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

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

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

===<s> Executable directive </s>===
''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)

=== <s>Extra Artefacts Reported</s> ===
''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)
:'''Fixed in the patch 3.1-'''[[User:Morgan525|Tycho]]
: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)

===<s>Manufacturing Projects Minimum Production</s> ===

In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)

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

:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)
''' Changed the output to display "$unlimited$".'''[[User:Morgan525|Tycho]]

===<s>Stunned MC'd Aquanauts MIA on Abort </s> ===

This is a subset of MC'd Aquanauts go MIA [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]. In this case Aquanauts are MC'd by the aliens, then stunned (by friendlies), then the mission is Aborted with the stunned X-Com Aquanauts aboard the transport. The Aquanauts then disappear from the roster forever. I'm not sure if it's due to Abort rather than Victory, or due to them being stunned first. This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)
:'''I now have the code in place to uncontrol any creature that has been rendered unconscious. Available in patch 3.1- -'''[[User:Morgan525|Tycho]]

====<s> Crewed Flying Sub Lost on Abort </s>====

Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)
:''I found the nature of the issue here: This only will happen with a tank present. On one hand, all parts of the tank are being counted separately but then the End of Battle routine calculates the number of units correctly (ignores three of the sections of a tank) but when it goes to locate the units on the battlefield, the three other parts of the tank are being counted and thus the last three aquanauts are not checked since the 4 areas of the tank are first in the UNITPOS.DAT file.-[[User:Morgan525|Tycho]] 09:47, 24 October 2012 (EDT)''

'''Fixed in 105 patch 4.'''-[[User:Morgan525|Tycho]]

=== <s>Grenade Resistance in INI file </s> ===
:''I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]

===<s> Materials deducted from wrong base </s>===
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)

===<s> OBDATA / Dye Grenade mod not working? </s>===
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)

=== <s>Displacer/Sonic damage fix</s> ===

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

===<s> Weight Display in Inventory not Localised </s> ===

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

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

= Feature Requests and Suggestions =

== Useful alien species research ==

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

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

Definite +1. It would be equally valid to add to UFO Extender. I suppose it could also be implemented using Vulnerabilities (no Vulnerabilities are in effect until the Autopsy is completed), or Resistances (across-the-board increased Resistances until Autopsy is completed). If that's easier.
:''The bonus to hp was an initial thought. Later, I decided against it since it would make aliens more resistant to HE and stun, which don't rely on hitting the right locations. Increasing resistances would be the most appropriate but the damage routine code is very tight and adding anything new that won't break the existing variable stack pointers is tough. Tycho ''
::''A new idea for this that I recently have been toying with, would be on the damage generation routine: Most direct fire damage is <s>0-200</s> 50-150%, with anything over 100% considered a "critical hit". If autopsy hasn't been preformed, then the base damage would be 0-100% and a small chance (maybe 25%) of another 0-50% for that lucky shot. With autopsy done, the game reverts back to the usual <s>0-200</s>% on any hit.''
That works. And it makes doing Alien Autopsies a no-brainer, as it should be. It is pretty much inconceivable that XCom wouldn't prioritise the autopsy of any newly encountered alien. And any player playing the game for the first time would do autopsies too. This mod will help experienced players to stop playing as if they've "seen it all before". Spike 10:35, 15 September 2012 (EDT)

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

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

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

== All Units Can "Fly" In Water ==

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

== Aliens Pick Up Weapons ==

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.

: 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)
:''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)''

==General Tank Modding ==

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

Thanks,
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)

== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==

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.

This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.

== Fix Interception and Navigation Course Algorithms ==

Or just find the algorithms and I volunteer to fix them!

=== Use Great Circle Routes ===

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!).

=== Use Predictive Interception ===

For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.

=== Show Degree Headings ===

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.
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.

== Interception Craft vs Touched Down Alien Craft ==

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.

For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach.

== Fun, not Funky, Fire ==

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.

== Retaliate for Colony Assault ==

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.

== TFTDextender and XComUtil ==

I suggest adding a section on co-operating with XComUtil. As for now the article informs that the the exe split as done by XComUtil is incorrect, and there is a cure for this problem (btw., why not to correct XComUtil itself?). But this is not the only problem. XComUtil installer can detect UFOextender - but has no procedures for TFTDextender at all. You may suppose that installing both is possible this way:
1. copy TFTDextender files into the folder where TFTD CE is installed,
2. install XComUtil to that copy of the game,
3. copy BB's Toolkit into the game folder and correct the exe split,
4. rename TFTDextender.exe into UFOloader.exe (and .ini as well?),
5. copy sebLoader.xcf from an existing instalation of XComUtil for UFO:EU CE + UFOextender.
Perhaps it will work. Has such a combination ever been tested to work properly?

And why it should be so complicated? Is it possible to make needed changes in XComUtil? But it has support for UFOextender - why not for TFTDextender?

== Trojan Horse? ==

AVG Anti-Virus reports that TFTDExtender.exe contains a Trojan Horse (Generic30.MKG). Could you fix this somehow?

[[User:Sherlock|Sherlock]] 05:21, 14 January 2013 (EST)

== Another patch to the research tree ==

Thanks to TFTDextender, Coelacanth/Gauss is no more dependent on the alien-based sub technology, and this is fully correct, bravo! I would like to call your attention to another strange research tree dependency. I mean you can start with working on Bombardment Shield only after finishing with The Latest Flying Sub. It makes the shield completely useless. Namely: it is not enough to finish with New Fighter Transporter, next you must examine Lobster Man Commander. Assuming that you have already investigated The Ultimate Threat, when you finish with that beast, you will get two new topics: T'leth the Alien's City, and The Latest Flying Sub. Let's assume you will investigate the sub first. When finished, you may start constructing Leviathan. In the same time you can work on T'leth. In practice, when Leviathan is ready, you will also finish with T'leth. In this very moment you can float to T'leth and finish the game, even not having started the Bombardment Shield topic. So, where is the use of Bombardment Shield?

But assume that despite of all you very much want to see how it looks and how it works. So, OK, after having investigated Leviathan, you can start the Bombardment Shield topic. In the same time you can construct the sub. It is very likely that you will have Leviathan at your disposal when you finish with investigating Bombardment Shield. Now you can start investigating T'leth, and constructing the facility. But this is a little problem - the constructing of Bombardment Shield needs 38 days! It means that even in this scenario you will be ready to go to T'leth before you have even constructed the facility! And if you really wanted to see how it works, you would have to wait a month or even longer, until a hostile sub appears at your gates. What for should you wait if you are ready to go to the heart of the aliens' empire, and finish with them? Such a game when there is no more to investigate is just boring.

Hence my proposal to make Bombardment Shield to be similar to Grav Shield in UFO:EU. If the topic depended on New Fighter Transporter as a prerequisite instead of The Latest Flying Sub, you would have some use of this facility. It could be ready to work even before having any Leviathan constructed. And you would have a chance to see it working.

My personal opinion is that the dependency of Bombardment Shield on The Latest Flying Sub is another mistake of TFTD programmers. So, it is a bug, and such a change of the research tree would not be a mod but a patch rather.

[[User:Sherlock|Sherlock]] 05:56, 14 January 2013 (EST)

== A proposal for another alternate research tree ==

Alien technology is based on Zrbite and Aqua Plastics. When you investigate a product of alien technology, you will be able to reproduce it in your workshops. How is it possible without having an idea on materials of which they are constructed?

Both UFO:EU and TFTD research trees basically ignore the need of knowledge on alien materials. It is quite logical as long as you just use alien weapon - but it becomes really strange when you produce the weapon. How to work with a material when you do not know its features?

My first question - would be possible to separate of using an object and reproducing it? If yes, it is all right to obtain e.g. a sonic pulser, next to examine it, and when finished, to use it. But not to produce it, until you learn on zrbite. The basic idea is that only after finishing your zrbite investigation, you should have possibility to construct your own sonic pulsers.

The first possibility is that it could be done by a very simple metod. When you get a crystal of zrbite or a sample of aqua plastics, it could be just artefacts unless you have them investigated. Then you will be able to use e.g. sonic weapons (after having them investigated) - but as you would not see zrbite and aqua plastics as such, you would not make any use of them, including making sonic weapons by your own.

The other idea is that nothing can be understood if we have not obtained knowledge on alien materials which are needed to produce the investigated object. It means to make them real prerequisites for investigations. Now Disruptor Ammo needs Zrbite for producing, and it needs the Zrbite topic finished as its prerequisite as well. I mean to make Zrbite a prerequisite also for all three clips for sonic weapons, Thermal Shok Bomb, Sonic Pulser, Vibro Blade (and both thermic lances), Ion-Beam Accelerators, Ion Armour (and Magnetic IA), M.C. Reader (and M.C. Disruptor) - as they all need Zrbite when produced. And also to make Aqua Plastics a prerequisite for all three sonic weapons, Thermal Shok Launcher, Disruptor Pulse Launcher (and P.W.T. Cannon), Ion-Beam Accelerators, Magnetic Navigation, M.C. Reader (and M.C. Disruptor) - as they all need Aqua Plastics when produced.

I have tested such a modification of the research tree just by stopping any investigations of objects from the two lists above until Zrbite and (Deep One Corpse +) Aqua Plastics topics are finished. In my opinion it does not unbalance the game except it gives another argument for using Gauss technology first than sonic. Namely, under this condition it is enough to finish just three topics: Gauss Technology, Gauss Pistol and Gauss Pistol Clip, in order to have a little more effective weapon at one's disposal. But if you want to use sonic instead, you must obtain a dead Deep One on a mission, plus some samples of Zrbite (and Aqua Plastics - in fact there is not such a condition), and you need to have researched five topics altogether: Deep One Corpse, Aqua Plastics, Sonic Pistol, Zrbite, Pistol Power Clip.

It would be a modification of the game as nothing similar is implemented in either UFO:EU or TFTD (except the need of knowing Zrbite in order to start investigation of Disruptor Ammo).

[[User:Sherlock|Sherlock]] 07:16, 14 January 2013 (EST)

== The research tree - Yet another bug? ==

Now you do not have to have some objects in your stores in order to examine (?) it. It looks like your engineers are so genius that they can guess how those objects look like, not even having a single look on them. Your invented copy appears to be just like the genuine alien object. Is this scenario logical at all? I think it is not, and it is just another bug which should be removed. The only problem (?) is, however, that this bug (?) makes the game easier. So, patching it would make the game harder.

Namely, I think that 4 objects: Aqua Plastics, Vibro Blade, Thermic Lance and Heavy Thermic Lance should be present in stores to start examination on them, naturally when other conditions are fulfilled. So, for example, you will still have to examine Deep One Corpse, but it will not give you a way to inventing Aqua Plastics. First you will have to get them, and keep them in your stores. And only them, after finishing Deep One Corpse, you will be able to start examining (not: inventing!) Aqua Plastics.

And the same with the finished Calcinite Corpse topic and a stored Vibro Blade, the finished Vibro Blade and Gill Man Corpse topics and a stored Thermic Lance, and also the finished Thermic Lance topic and a stored Heavy Thermic lance.

[[User:Sherlock|Sherlock]] 07:27, 14 January 2013 (EST)

== The Calcinite Dilemma ==

The need of researching both Deep One Corpse and a live Deep One has been named the Deep One Dilemma. Personally, I cannot see a problem in there, and I really cannot understand the other players. I have played TFTD many times, and I have never any least problems with obtaining both corpse and a live specimen of this creature. In a result, I do not understand why it can harm anyone. But you can buy Thermal Tazers at the very beginning of your campaign. They are cheap and easy to use. Deep Ones always appear several times in early missions. They are not too dangerous, and you can enough safely freeze one. And even more, if you use human weapons like darts, you have a high chance to get one live without any freezing.

So, what is the source of this dilemma? You know you need this creature. You have enough numerous possibilities to hunt for it. You have weapons which are suitable for this. So, where is the problem? If you do not want to capture a Deep One, and you prefer just shooting and kill'em'all-ing instead of playing, do not complain then that you have no progress in your research. Just keep shooting... I do not believe that killing aliens is the only objective of the game. It is OK that there is a possibility to eliminate the need of Deep One to research Ion Armour - but it is nothing but a cheat. I do not like it, and I will not use it. Just like adding money or making my aquanauts superhumans.

But Calcinites and the need of the body of the creature for starting with examinating melee weapons is a completely different problem. As I said, I have played the game many times. And I have never spotted a single calcinite during first months of the game, and telling the truth, I have whole campaignes without any single creature of this kind. I believe there is an error in the game which prevents from appearing aquatoids on terror missions.

And hence my question: is it possible for TFTDextender to control which alien race starts an alien mission in the game? It would be the solution of the calcinite problem I would like much. Instead of manipulating with the research tree, it would be enough to forse some mission types from the same beginning. If aquatoid + calcinite missions, as well as gill men + deep ones mission were still present during all the game, nobody could also complain that he/she cannot capture a live deep one. And it would give a better chance for getting melee weapons earlier (without hacking, cheating and changing the research tree).

[[User:Sherlock|Sherlock]] 07:50, 14 January 2013 (EST)

Talk:TFTDextender

2013-01-14T12:27:51Z

Sherlock: /* The research tree - Yet another bug? */

=Questions or Comments=
'''A place to provide feedback or ask questions:'''
:''Thanks to Kyrub, Spike, and numerous others who help to troubleshoot problems, provide feedback on releases, and innumerable other activities to help make TFTDextender and the game better! -'' [[User:Morgan525|Tycho]]

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

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

== Bug Reports ==
===Major Bugs===
==== Crash when starting a landed/crashed USO battle ====

:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."

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

=== Minor Bugs ===
==== Stunned Carried Aquanauts MIA on Abort ====

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)

:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. Your right, carried objects won't have their location updated until they are dropped or thrown. At least it is a manageable issue: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)

== Things that TFTDextender does not fix ==

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

* Does not fix the apparent swap of the ground map for the VERY SMALL Survey Ship (1 occupant) with the SMALL Escort (half-dozen or more occupants). So you get the VERY SMALL sub occupying about 25 squares of usable area on the Battlescape, and the supposedly larger SMALL sub occupying one square of usable area on the Battlescape, begging the question of how all those aliens got inside there in the first place. XcomUtil will fix this, as will the original patches that XcomUtil incorporates.
* Does not fix the incorrect pictures for the large USO in the interception window.
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]
* Does not fix the Dart Gun to make it any less utterly useless. Though you can do this yourself via the OBDATA.DAT section of TFTDextender. (Suggestion: don't fix it. The useless Dart Gun is all part of the "oh no we're all gonna die" experience of the beginning of TFTD.)
* Does not improve the armour and effectiveness of the basic Aqua-Jet and Gas Cannon Coelecanths (it does upgrade the Coelecanth/Gauss). (Again, suggestion: this is a good thing - XCOM should start the game hopelessly outclassed, and scramble to catch up).
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.
* Does not allow you to have 360 degree vision out of your sub before exiting it. (What kind of coward would want that?). XComUtil does this.

*When I try to send any Leviathan to T'Leth, I get an immediate crash: "XCOM crashed at 0x458822 with error 0xC0000005 trying to access 0xFA6C8304.".
:It happens when the CE version doesn't find the RISE animation: Specifically, it needs ANIMS\RISE.IDX and ANIMS\RISE.VID - If RISE.IDX is missing, it crashes with the error code above, if RISE.VID is missing, it crashes with another error. Some experimenting suggests that RISE.VID can be any valid .VID file, while RISE.IDX can either be empty (producing a black screen that can be skipped by clicking) or the "appropriate" .IDX for the used .VID...[[User:AMX|AMX]] 13 November 2012 (EST)

=Resolved Reported Problems=
===<s> Save Equipment not working</s> ===

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

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

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

:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

===<s> Weight Issues or "Weightless" Ammo Bug </s>===

while playing TFD with TFD extender (v. 1.05 patch 1.1) I've noticed a stange thing: some soldiers have their weight > 0 (2-5) even when their inventory is empty! Bug?... [[User:PavelB|PavelB]] 05:17, 27 September 2012 (EDT)
:If you drop a loaded weapon, even if you loaded it manually, the weight of the ammo still stays with the Aquanaut. Workaround: unload each weapon manually before dropping it. If you forget (and if you notice) it's possible to pick the weapon up again, unload it, and correctly lose the weight by dropping the weapon and clip separately. It's possible to build up huge amounts of phantom weight on a Soldier by repeatedly loading, and then dropping, different weapons. It's also possible to move lots of weapons with weightless clips to one Soldier, increasing the amount of 'free' weight that one Soldier gets. Both of these effects are probably aspects of the original bug, not anything that UFOExtender has done. [[User:Spike|Spike]] 11:15, 27 September 2012 (EDT)
::This Weight error is a side effect of an original game error that Seb never quite fixed. Removing clips from a Soldier or Aquanaut does not remove the clips' weight. This is because the clips are not correctly assigned to the Soldier or Aquanaut in the first place. See [[Talk:TFTDextender#Weightless Ammo Bug]].
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)

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

===<s> Items on transport floor lost on Abort</s> ===

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

:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

===<s> Coelacanth/Gauss mutates into Coelacanth/G.C.</s> ===

In my current game (using the Steam version) I observed it twice that, when a Coelacanth/Gauss is removed from a sub due to lack of ammo, it turns into a Coelacanth/Gas Cannon.
Note that I'm using only the Gauss Tank Ammo Fix, but not the Gauss Tank Turret Stats Fix, nor the Improved Gauss Tank mod.
[[User:AMX|AMX]] 09:09, 1 November 2012 (EDT)

:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

===<s> Cannot build Leviathan </s> ===

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

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

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

===<s> Executable directive </s>===
''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)

=== <s>Extra Artefacts Reported</s> ===
''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)
:'''Fixed in the patch 3.1-'''[[User:Morgan525|Tycho]]
: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)

===<s>Manufacturing Projects Minimum Production</s> ===

In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)

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

:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)
''' Changed the output to display "$unlimited$".'''[[User:Morgan525|Tycho]]

===<s>Stunned MC'd Aquanauts MIA on Abort </s> ===

This is a subset of MC'd Aquanauts go MIA [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]. In this case Aquanauts are MC'd by the aliens, then stunned (by friendlies), then the mission is Aborted with the stunned X-Com Aquanauts aboard the transport. The Aquanauts then disappear from the roster forever. I'm not sure if it's due to Abort rather than Victory, or due to them being stunned first. This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)
:'''I now have the code in place to uncontrol any creature that has been rendered unconscious. Available in patch 3.1- -'''[[User:Morgan525|Tycho]]

====<s> Crewed Flying Sub Lost on Abort </s>====

Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)
:''I found the nature of the issue here: This only will happen with a tank present. On one hand, all parts of the tank are being counted separately but then the End of Battle routine calculates the number of units correctly (ignores three of the sections of a tank) but when it goes to locate the units on the battlefield, the three other parts of the tank are being counted and thus the last three aquanauts are not checked since the 4 areas of the tank are first in the UNITPOS.DAT file.-[[User:Morgan525|Tycho]] 09:47, 24 October 2012 (EDT)''

'''Fixed in 105 patch 4.'''-[[User:Morgan525|Tycho]]

=== <s>Grenade Resistance in INI file </s> ===
:''I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]

===<s> Materials deducted from wrong base </s>===
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)

===<s> OBDATA / Dye Grenade mod not working? </s>===
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)

=== <s>Displacer/Sonic damage fix</s> ===

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

===<s> Weight Display in Inventory not Localised </s> ===

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

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

= Feature Requests and Suggestions =

== Useful alien species research ==

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

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

Definite +1. It would be equally valid to add to UFO Extender. I suppose it could also be implemented using Vulnerabilities (no Vulnerabilities are in effect until the Autopsy is completed), or Resistances (across-the-board increased Resistances until Autopsy is completed). If that's easier.
:''The bonus to hp was an initial thought. Later, I decided against it since it would make aliens more resistant to HE and stun, which don't rely on hitting the right locations. Increasing resistances would be the most appropriate but the damage routine code is very tight and adding anything new that won't break the existing variable stack pointers is tough. Tycho ''
::''A new idea for this that I recently have been toying with, would be on the damage generation routine: Most direct fire damage is <s>0-200</s> 50-150%, with anything over 100% considered a "critical hit". If autopsy hasn't been preformed, then the base damage would be 0-100% and a small chance (maybe 25%) of another 0-50% for that lucky shot. With autopsy done, the game reverts back to the usual <s>0-200</s>% on any hit.''
That works. And it makes doing Alien Autopsies a no-brainer, as it should be. It is pretty much inconceivable that XCom wouldn't prioritise the autopsy of any newly encountered alien. And any player playing the game for the first time would do autopsies too. This mod will help experienced players to stop playing as if they've "seen it all before". Spike 10:35, 15 September 2012 (EDT)

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

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

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

== All Units Can "Fly" In Water ==

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

== Aliens Pick Up Weapons ==

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.

: 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)
:''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)''

==General Tank Modding ==

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

Thanks,
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)

== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==

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.

This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.

== Fix Interception and Navigation Course Algorithms ==

Or just find the algorithms and I volunteer to fix them!

=== Use Great Circle Routes ===

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!).

=== Use Predictive Interception ===

For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.

=== Show Degree Headings ===

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.
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.

== Interception Craft vs Touched Down Alien Craft ==

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.

For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach.

== Fun, not Funky, Fire ==

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.

== Retaliate for Colony Assault ==

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.

== TFTDextender and XComUtil ==

I suggest adding a section on co-operating with XComUtil. As for now the article informs that the the exe split as done by XComUtil is incorrect, and there is a cure for this problem (btw., why not to correct XComUtil itself?). But this is not the only problem. XComUtil installer can detect UFOextender - but has no procedures for TFTDextender at all. You may suppose that installing both is possible this way:
1. copy TFTDextender files into the folder where TFTD CE is installed,
2. install XComUtil to that copy of the game,
3. copy BB's Toolkit into the game folder and correct the exe split,
4. rename TFTDextender.exe into UFOloader.exe (and .ini as well?),
5. copy sebLoader.xcf from an existing instalation of XComUtil for UFO:EU CE + UFOextender.
Perhaps it will work. Has such a combination ever been tested to work properly?

And why it should be so complicated? Is it possible to make needed changes in XComUtil? But it has support for UFOextender - why not for TFTDextender?

== Trojan Horse? ==

AVG Anti-Virus reports that TFTDExtender.exe contains a Trojan Horse (Generic30.MKG). Could you fix this somehow?

[[User:Sherlock|Sherlock]] 05:21, 14 January 2013 (EST)

== Another patch to the research tree ==

Thanks to TFTDextender, Coelacanth/Gauss is no more dependent on the alien-based sub technology, and this is fully correct, bravo! I would like to call your attention to another strange research tree dependency. I mean you can start with working on Bombardment Shield only after finishing with The Latest Flying Sub. It makes the shield completely useless. Namely: it is not enough to finish with New Fighter Transporter, next you must examine Lobster Man Commander. Assuming that you have already investigated The Ultimate Threat, when you finish with that beast, you will get two new topics: T'leth the Alien's City, and The Latest Flying Sub. Let's assume you will investigate the sub first. When finished, you may start constructing Leviathan. In the same time you can work on T'leth. In practice, when Leviathan is ready, you will also finish with T'leth. In this very moment you can float to T'leth and finish the game, even not having started the Bombardment Shield topic. So, where is the use of Bombardment Shield?

But assume that despite of all you very much want to see how it looks and how it works. So, OK, after having investigated Leviathan, you can start the Bombardment Shield topic. In the same time you can construct the sub. It is very likely that you will have Leviathan at your disposal when you finish with investigating Bombardment Shield. Now you can start investigating T'leth, and constructing the facility. But this is a little problem - the constructing of Bombardment Shield needs 38 days! It means that even in this scenario you will be ready to go to T'leth before you have even constructed the facility! And if you really wanted to see how it works, you would have to wait a month or even longer, until a hostile sub appears at your gates. What for should you wait if you are ready to go to the heart of the aliens' empire, and finish with them? Such a game when there is no more to investigate is just boring.

Hence my proposal to make Bombardment Shield to be similar to Grav Shield in UFO:EU. If the topic depended on New Fighter Transporter as a prerequisite instead of The Latest Flying Sub, you would have some use of this facility. It could be ready to work even before having any Leviathan constructed. And you would have a chance to see it working.

My personal opinion is that the dependency of Bombardment Shield on The Latest Flying Sub is another mistake of TFTD programmers. So, it is a bug, and such a change of the research tree would not be a mod but a patch rather.

[[User:Sherlock|Sherlock]] 05:56, 14 January 2013 (EST)

== A proposal for another alternate research tree ==

Alien technology is based on Zrbite and Aqua Plastics. When you investigate a product of alien technology, you will be able to reproduce it in your workshops. How is it possible without having an idea on materials of which they are constructed?

Both UFO:EU and TFTD research trees basically ignore the need of knowledge on alien materials. It is quite logical as long as you just use alien weapon - but it becomes really strange when you produce the weapon. How to work with a material when you do not know its features?

My first question - would be possible to separate of using an object and reproducing it? If yes, it is all right to obtain e.g. a sonic pulser, next to examine it, and when finished, to use it. But not to produce it, until you learn on zrbite. The basic idea is that only after finishing your zrbite investigation, you should have possibility to construct your own sonic pulsers.

The first possibility is that it could be done by a very simple metod. When you get a crystal of zrbite or a sample of aqua plastics, it could be just artefacts unless you have them investigated. Then you will be able to use e.g. sonic weapons (after having them investigated) - but as you would not see zrbite and aqua plastics as such, you would not make any use of them, including making sonic weapons by your own.

The other idea is that nothing can be understood if we have not obtained knowledge on alien materials which are needed to produce the investigated object. It means to make them real prerequisites for investigations. Now Disruptor Ammo needs Zrbite for producing, and it needs the Zrbite topic finished as its prerequisite as well. I mean to make Zrbite a prerequisite also for all three clips for sonic weapons, Thermal Shok Bomb, Sonic Pulser, Vibro Blade (and both thermic lances), Ion-Beam Accelerators, Ion Armour (and Magnetic IA), M.C. Reader (and M.C. Disruptor) - as they all need Zrbite when produced. And also to make Aqua Plastics a prerequisite for all three sonic weapons, Thermal Shok Launcher, Disruptor Pulse Launcher (and P.W.T. Cannon), Ion-Beam Accelerators, Magnetic Navigation, M.C. Reader (and M.C. Disruptor) - as they all need Aqua Plastics when produced.

I have tested such a modification of the research tree just by stopping any investigations of objects from the two lists above until Zrbite and (Deep One Corpse +) Aqua Plastics topics are finished. In my opinion it does not unbalance the game except it gives another argument for using Gauss technology first than sonic. Namely, under this condition it is enough to finish just three topics: Gauss Technology, Gauss Pistol and Gauss Pistol Clip, in order to have a little more effective weapon at one's disposal. But if you want to use sonic instead, you must obtain a dead Deep One on a mission, plus some samples of Zrbite (and Aqua Plastics - in fact there is not such a condition), and you need to have researched five topics altogether: Deep One Corpse, Aqua Plastics, Sonic Pistol, Zrbite, Pistol Power Clip.

It would be a modification of the game as nothing similar is implemented in either UFO:EU or TFTD (except the need of knowing Zrbite in order to start investigation of Disruptor Ammo).

[[User:Sherlock|Sherlock]] 07:16, 14 January 2013 (EST)

== The research tree - Yet another bug? ==

Now you do not have to have some objects in your stores in order to examine (?) it. It looks like your engineers are so genius that they can guess how those objects look like, not even having a single look on them. Your invented copy appears to be just like the genuine alien object. Is this scenario logical at all? I think it is not, and it is just another bug which should be removed. The only problem (?) is, however, that this bug (?) makes the game easier. So, patching it would make the game harder.

Namely, I think that 4 objects: Aqua Plastics, Vibro Blade, Thermic Lance and Heavy Thermic Lance should be present in stores to start examination on them, naturally when other conditions are fulfilled. So, for example, you will still have to examine Deep One Corpse, but it will not give you a way to inventing Aqua Plastics. First you will have to get them, and keep them in your stores. And only them, after finishing Deep One Corpse, you will be able to start examining (not: inventing!) Aqua Plastics.

And the same with the finished Calcinite Corpse topic and a stored Vibro Blade, the finished Vibro Blade and Gill Man Corpse topics and a stored Thermic Lance, and also the finished Thermic Lance topic and a stored Heavy Thermic lance.

[[User:Sherlock|Sherlock]] 07:27, 14 January 2013 (EST)

Talk:TFTDextender

2013-01-14T12:16:08Z

Sherlock: /* Another patch to the research tree */

=Questions or Comments=
'''A place to provide feedback or ask questions:'''
:''Thanks to Kyrub, Spike, and numerous others who help to troubleshoot problems, provide feedback on releases, and innumerable other activities to help make TFTDextender and the game better! -'' [[User:Morgan525|Tycho]]

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

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

== Bug Reports ==
===Major Bugs===
==== Crash when starting a landed/crashed USO battle ====

:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."

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

=== Minor Bugs ===
==== Stunned Carried Aquanauts MIA on Abort ====

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)

:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. Your right, carried objects won't have their location updated until they are dropped or thrown. At least it is a manageable issue: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)

== Things that TFTDextender does not fix ==

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

* Does not fix the apparent swap of the ground map for the VERY SMALL Survey Ship (1 occupant) with the SMALL Escort (half-dozen or more occupants). So you get the VERY SMALL sub occupying about 25 squares of usable area on the Battlescape, and the supposedly larger SMALL sub occupying one square of usable area on the Battlescape, begging the question of how all those aliens got inside there in the first place. XcomUtil will fix this, as will the original patches that XcomUtil incorporates.
* Does not fix the incorrect pictures for the large USO in the interception window.
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]
* Does not fix the Dart Gun to make it any less utterly useless. Though you can do this yourself via the OBDATA.DAT section of TFTDextender. (Suggestion: don't fix it. The useless Dart Gun is all part of the "oh no we're all gonna die" experience of the beginning of TFTD.)
* Does not improve the armour and effectiveness of the basic Aqua-Jet and Gas Cannon Coelecanths (it does upgrade the Coelecanth/Gauss). (Again, suggestion: this is a good thing - XCOM should start the game hopelessly outclassed, and scramble to catch up).
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.
* Does not allow you to have 360 degree vision out of your sub before exiting it. (What kind of coward would want that?). XComUtil does this.

*When I try to send any Leviathan to T'Leth, I get an immediate crash: "XCOM crashed at 0x458822 with error 0xC0000005 trying to access 0xFA6C8304.".
:It happens when the CE version doesn't find the RISE animation: Specifically, it needs ANIMS\RISE.IDX and ANIMS\RISE.VID - If RISE.IDX is missing, it crashes with the error code above, if RISE.VID is missing, it crashes with another error. Some experimenting suggests that RISE.VID can be any valid .VID file, while RISE.IDX can either be empty (producing a black screen that can be skipped by clicking) or the "appropriate" .IDX for the used .VID...[[User:AMX|AMX]] 13 November 2012 (EST)

=Resolved Reported Problems=
===<s> Save Equipment not working</s> ===

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

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

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

:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

===<s> Weight Issues or "Weightless" Ammo Bug </s>===

while playing TFD with TFD extender (v. 1.05 patch 1.1) I've noticed a stange thing: some soldiers have their weight > 0 (2-5) even when their inventory is empty! Bug?... [[User:PavelB|PavelB]] 05:17, 27 September 2012 (EDT)
:If you drop a loaded weapon, even if you loaded it manually, the weight of the ammo still stays with the Aquanaut. Workaround: unload each weapon manually before dropping it. If you forget (and if you notice) it's possible to pick the weapon up again, unload it, and correctly lose the weight by dropping the weapon and clip separately. It's possible to build up huge amounts of phantom weight on a Soldier by repeatedly loading, and then dropping, different weapons. It's also possible to move lots of weapons with weightless clips to one Soldier, increasing the amount of 'free' weight that one Soldier gets. Both of these effects are probably aspects of the original bug, not anything that UFOExtender has done. [[User:Spike|Spike]] 11:15, 27 September 2012 (EDT)
::This Weight error is a side effect of an original game error that Seb never quite fixed. Removing clips from a Soldier or Aquanaut does not remove the clips' weight. This is because the clips are not correctly assigned to the Soldier or Aquanaut in the first place. See [[Talk:TFTDextender#Weightless Ammo Bug]].
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)

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

===<s> Items on transport floor lost on Abort</s> ===

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

:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

===<s> Coelacanth/Gauss mutates into Coelacanth/G.C.</s> ===

In my current game (using the Steam version) I observed it twice that, when a Coelacanth/Gauss is removed from a sub due to lack of ammo, it turns into a Coelacanth/Gas Cannon.
Note that I'm using only the Gauss Tank Ammo Fix, but not the Gauss Tank Turret Stats Fix, nor the Improved Gauss Tank mod.
[[User:AMX|AMX]] 09:09, 1 November 2012 (EDT)

:'''Fixed in 1.05p4 - [[User:Morgan525|Tycho]]'''

===<s> Cannot build Leviathan </s> ===

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

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

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

===<s> Executable directive </s>===
''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)

=== <s>Extra Artefacts Reported</s> ===
''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)
:'''Fixed in the patch 3.1-'''[[User:Morgan525|Tycho]]
: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)

===<s>Manufacturing Projects Minimum Production</s> ===

In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)

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

:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)
''' Changed the output to display "$unlimited$".'''[[User:Morgan525|Tycho]]

===<s>Stunned MC'd Aquanauts MIA on Abort </s> ===

This is a subset of MC'd Aquanauts go MIA [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]. In this case Aquanauts are MC'd by the aliens, then stunned (by friendlies), then the mission is Aborted with the stunned X-Com Aquanauts aboard the transport. The Aquanauts then disappear from the roster forever. I'm not sure if it's due to Abort rather than Victory, or due to them being stunned first. This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)
:'''I now have the code in place to uncontrol any creature that has been rendered unconscious. Available in patch 3.1- -'''[[User:Morgan525|Tycho]]

====<s> Crewed Flying Sub Lost on Abort </s>====

Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)
:''I found the nature of the issue here: This only will happen with a tank present. On one hand, all parts of the tank are being counted separately but then the End of Battle routine calculates the number of units correctly (ignores three of the sections of a tank) but when it goes to locate the units on the battlefield, the three other parts of the tank are being counted and thus the last three aquanauts are not checked since the 4 areas of the tank are first in the UNITPOS.DAT file.-[[User:Morgan525|Tycho]] 09:47, 24 October 2012 (EDT)''

'''Fixed in 105 patch 4.'''-[[User:Morgan525|Tycho]]

=== <s>Grenade Resistance in INI file </s> ===
:''I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]

===<s> Materials deducted from wrong base </s>===
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)

===<s> OBDATA / Dye Grenade mod not working? </s>===
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)

=== <s>Displacer/Sonic damage fix</s> ===

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

===<s> Weight Display in Inventory not Localised </s> ===

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

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

= Feature Requests and Suggestions =

== Useful alien species research ==

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

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

Definite +1. It would be equally valid to add to UFO Extender. I suppose it could also be implemented using Vulnerabilities (no Vulnerabilities are in effect until the Autopsy is completed), or Resistances (across-the-board increased Resistances until Autopsy is completed). If that's easier.
:''The bonus to hp was an initial thought. Later, I decided against it since it would make aliens more resistant to HE and stun, which don't rely on hitting the right locations. Increasing resistances would be the most appropriate but the damage routine code is very tight and adding anything new that won't break the existing variable stack pointers is tough. Tycho ''
::''A new idea for this that I recently have been toying with, would be on the damage generation routine: Most direct fire damage is <s>0-200</s> 50-150%, with anything over 100% considered a "critical hit". If autopsy hasn't been preformed, then the base damage would be 0-100% and a small chance (maybe 25%) of another 0-50% for that lucky shot. With autopsy done, the game reverts back to the usual <s>0-200</s>% on any hit.''
That works. And it makes doing Alien Autopsies a no-brainer, as it should be. It is pretty much inconceivable that XCom wouldn't prioritise the autopsy of any newly encountered alien. And any player playing the game for the first time would do autopsies too. This mod will help experienced players to stop playing as if they've "seen it all before". Spike 10:35, 15 September 2012 (EDT)

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

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

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

== All Units Can "Fly" In Water ==

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

== Aliens Pick Up Weapons ==

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.

: 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)
:''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)''

==General Tank Modding ==

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

Thanks,
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)

== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==

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.

This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.

== Fix Interception and Navigation Course Algorithms ==

Or just find the algorithms and I volunteer to fix them!

=== Use Great Circle Routes ===

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!).

=== Use Predictive Interception ===

For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.

=== Show Degree Headings ===

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.
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.

== Interception Craft vs Touched Down Alien Craft ==

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.

For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach.

== Fun, not Funky, Fire ==

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.

== Retaliate for Colony Assault ==

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.

== TFTDextender and XComUtil ==

I suggest adding a section on co-operating with XComUtil. As for now the article informs that the the exe split as done by XComUtil is incorrect, and there is a cure for this problem (btw., why not to correct XComUtil itself?). But this is not the only problem. XComUtil installer can detect UFOextender - but has no procedures for TFTDextender at all. You may suppose that installing both is possible this way:
1. copy TFTDextender files into the folder where TFTD CE is installed,
2. install XComUtil to that copy of the game,
3. copy BB's Toolkit into the game folder and correct the exe split,
4. rename TFTDextender.exe into UFOloader.exe (and .ini as well?),
5. copy sebLoader.xcf from an existing instalation of XComUtil for UFO:EU CE + UFOextender.
Perhaps it will work. Has such a combination ever been tested to work properly?

And why it should be so complicated? Is it possible to make needed changes in XComUtil? But it has support for UFOextender - why not for TFTDextender?

== Trojan Horse? ==

AVG Anti-Virus reports that TFTDExtender.exe contains a Trojan Horse (Generic30.MKG). Could you fix this somehow?

[[User:Sherlock|Sherlock]] 05:21, 14 January 2013 (EST)

== Another patch to the research tree ==

Thanks to TFTDextender, Coelacanth/Gauss is no more dependent on the alien-based sub technology, and this is fully correct, bravo! I would like to call your attention to another strange research tree dependency. I mean you can start with working on Bombardment Shield only after finishing with The Latest Flying Sub. It makes the shield completely useless. Namely: it is not enough to finish with New Fighter Transporter, next you must examine Lobster Man Commander. Assuming that you have already investigated The Ultimate Threat, when you finish with that beast, you will get two new topics: T'leth the Alien's City, and The Latest Flying Sub. Let's assume you will investigate the sub first. When finished, you may start constructing Leviathan. In the same time you can work on T'leth. In practice, when Leviathan is ready, you will also finish with T'leth. In this very moment you can float to T'leth and finish the game, even not having started the Bombardment Shield topic. So, where is the use of Bombardment Shield?

But assume that despite of all you very much want to see how it looks and how it works. So, OK, after having investigated Leviathan, you can start the Bombardment Shield topic. In the same time you can construct the sub. It is very likely that you will have Leviathan at your disposal when you finish with investigating Bombardment Shield. Now you can start investigating T'leth, and constructing the facility. But this is a little problem - the constructing of Bombardment Shield needs 38 days! It means that even in this scenario you will be ready to go to T'leth before you have even constructed the facility! And if you really wanted to see how it works, you would have to wait a month or even longer, until a hostile sub appears at your gates. What for should you wait if you are ready to go to the heart of the aliens' empire, and finish with them? Such a game when there is no more to investigate is just boring.

Hence my proposal to make Bombardment Shield to be similar to Grav Shield in UFO:EU. If the topic depended on New Fighter Transporter as a prerequisite instead of The Latest Flying Sub, you would have some use of this facility. It could be ready to work even before having any Leviathan constructed. And you would have a chance to see it working.

My personal opinion is that the dependency of Bombardment Shield on The Latest Flying Sub is another mistake of TFTD programmers. So, it is a bug, and such a change of the research tree would not be a mod but a patch rather.

[[User:Sherlock|Sherlock]] 05:56, 14 January 2013 (EST)

== A proposal for another alternate research tree ==

Alien technology is based on Zrbite and Aqua Plastics. When you investigate a product of alien technology, you will be able to reproduce it in your workshops. How is it possible without having an idea on materials of which they are constructed?

Both UFO:EU and TFTD research trees basically ignore the need of knowledge on alien materials. It is quite logical as long as you just use alien weapon - but it becomes really strange when you produce the weapon. How to work with a material when you do not know its features?

My first question - would be possible to separate of using an object and reproducing it? If yes, it is all right to obtain e.g. a sonic pulser, next to examine it, and when finished, to use it. But not to produce it, until you learn on zrbite. The basic idea is that only after finishing your zrbite investigation, you should have possibility to construct your own sonic pulsers.

The first possibility is that it could be done by a very simple metod. When you get a crystal of zrbite or a sample of aqua plastics, it could be just artefacts unless you have them investigated. Then you will be able to use e.g. sonic weapons (after having them investigated) - but as you would not see zrbite and aqua plastics as such, you would not make any use of them, including making sonic weapons by your own.

The other idea is that nothing can be understood if we have not obtained knowledge on alien materials which are needed to produce the investigated object. It means to make them real prerequisites for investigations. Now Disruptor Ammo needs Zrbite for producing, and it needs the Zrbite topic finished as its prerequisite as well. I mean to make Zrbite a prerequisite also for all three clips for sonic weapons, Thermal Shok Bomb, Sonic Pulser, Vibro Blade (and both thermic lances), Ion-Beam Accelerators, Ion Armour (and Magnetic IA), M.C. Reader (and M.C. Disruptor) - as they all need Zrbite when produced. And also to make Aqua Plastics a prerequisite for all three sonic weapons, Thermal Shok Launcher, Disruptor Pulse Launcher (and P.W.T. Cannon), Ion-Beam Accelerators, Magnetic Navigation, M.C. Reader (and M.C. Disruptor) - as they all need Aqua Plastics when produced.

I have tested such a modification of the research tree just by stopping any investigations of objects from the two lists above until Zrbite and (Deep One Corpse +) Aqua Plastics topics are finished. In my opinion it does not unbalance the game except it gives another argument for using Gauss technology first than sonic. Namely, under this condition it is enough to finish just three topics: Gauss Technology, Gauss Pistol and Gauss Pistol Clip, in order to have a little more effective weapon at one's disposal. But if you want to use sonic instead, you must obtain a dead Deep One on a mission, plus some samples of Zrbite (and Aqua Plastics - in fact there is not such a condition), and you need to have researched five topics altogether: Deep One Corpse, Aqua Plastics, Sonic Pistol, Zrbite, Pistol Power Clip.

It would be a modification of the game as nothing similar is implemented in either UFO:EU or TFTD (except the need of knowing Zrbite in order to start investigation of Disruptor Ammo).

[[User:Sherlock|Sherlock]] 07:16, 14 January 2013 (EST)

Talk:TFTDextender

2013-01-14T10:56:45Z

Sherlock: /* Another patch to the research tree */

Talk:TFTDextender

2013-01-14T10:21:51Z

Sherlock: /* Trojan Horse? */

Talk:TFTDextender

2013-01-14T10:17:04Z

Sherlock: /* Retaliate for Colony Assault */

Talk:Known Bugs (TFTD)

2013-01-05T16:51:50Z

Sherlock: /* And what about Research Tree Bugs? - yet another one */

Research (TFTD)

2013-01-05T11:43:11Z

Sherlock: /* Research Tree */

==Research (Terror From The Deep)==
'''Research''' is a decisive factor in the contest of Man versus Alien. X-COM forces start out badly outclassed by their alien foes, but as they master alien technology, the battle swings to the Humans' favor.

Through research, X-COM forces gain access to vastly improved [[Weapons (TFTD)|weapons]] technology, [[Armour (TFTD)|armour]], [[Base Facilities (TFTD)|base facilities]], interception and transport [[subs]], and a variety of other useful technologies. Researching captive live aliens provides information about the aliens' methods and traits, and is ultimately the only path toward [[T'leth|winning the game]].

==Research Tree==
<center>[[file:tree2.png|800px|thumb|center|TFTD Research Tree]]</center>
<center>[[file:tree2_ob_en.png|400px|thumb|center|Explanations]]</center>

==See also==
*[[Alien Research (TFTD)]]
*[[TRTBAG|TFTD Research Tree Bug Avoidance Guide]]
*[[TFTD Research Sequences]]

[[Category:Research (TFTD)]]

Research Trees

2013-01-05T10:59:20Z

Sherlock: /* Research Tree */

Here are sequences of research topics needed to unlock all the technologies in the game.

<big>'''Laser Weapons'''</big>
Laser Weapons (tech breakthrough)
|
[[Laser Pistol]]
|
[[Laser Rifle]]
|
[[Heavy Laser]]
|
[[Laser Cannon]]
([[Heavy Weapons Platforms|Laser Tank]])
|
[[Laser Defences|Laser Defense]]

<big>'''Plasma Weapons'''</big>
[[Heavy Plasma]] [[Plasma Rifle]]
| Heavy Plasma Clip | Plasma Rifle Clip
|___________| |__________|
| |
| |
|__________OR___________|
|
[[Plasma Beam|Plasma Cannon]]
([[Heavy Weapons Platforms|Hovertank/Plasma]])*
|
[[Plasma Defences|Plasma Defense]]

<nowiki>*</nowiki> [[#Craft|New Fighter Craft]] must also be researched before you can build hovertanks

<big>'''Fusion Weapons'''</big>
[[Blaster Launcher]] [[Blaster Bomb]]
|___________|
|
[[Fusion Ball Launcher|Fusion Ball]]
([[Heavy Weapons Platforms|Hovertank/Launcher]])*
|
[[Fusion Ball Defences|Fusion Ball Defense]]

<nowiki>*</nowiki> [[#Craft|New Fighter Craft]] must also be researched before you can build hovertanks.

<big>'''Armor'''</big>
[[Alien Alloys]]
|
[[Elerium-115]] [[Personal Armor]] [[UFO Power Source]]
|_____________|_________________|
|
|
[[Power Suit]] [[UFO Navigation]]
|_________________|
|
[[Flying Suit]]

<big>'''Craft'''</big>
Alien Elerium UFO UFO
Alloys 115 Power Source Navigation
|___________|___________|______________|
|
UFO Construction
|
|
New Fighter Craft*
([[Firestorm]])
|
New Fighter-Transporter
([[Lightning]])
__________|____________
| |
[[Grav Shield]] Ultimate Craft ([[Avenger]])

<nowiki>*</nowiki> New Fighter Craft must be researched before you can build hovertanks

<big>'''Psionics'''</big>
Any Live Psionic Alien
|
[[Psionic Laboratory|Psi Lab]]
|_______
| |
[[Psi-Amp]] [[Mind Shield]]

<big>'''Hyper-Wave Decoder'''</big>

Any Live Alien Navigator
|
[[Hyper-wave Decoder]]

<big>'''Endgame'''</big>

These research topics must be completed in order to travel to [[Cydonia]] and finish the game.

Any Live Alien
|
[[Alien Research#Alien Origins|Alien Origins]]
|
| Any Live Alien Leader
| /
[[Alien Research#The Martian Solution|The Martian Solution]]
|
| Any Live Alien Commander
| /
[[Alien Research#Cydonia or Bust|Cydonia or Bust]]
|
| [[Avenger]]
| /
[[Cydonia]] (mission)

Alien Commanders can be found on [[Battleship]]s, or in [[Alien Base Assault|alien bases]]. An alien Commander will also always accompany a [[Base Defense|base invasion]] force. The [http://www.xcomufo.com/usg.html Unofficial Strategy Guide] incorrectly states that only a Commander from an alien base can be used to give access to "Cydonia or Bust". In practice, any Commander will do -- so long as The Martian Solution has already been researched. Should you research a Commander prior to this, you'll have to capture another.

<big>'''Individual topics'''</big>

Researching these topics will not unlock any technologies beyond themselves.

* [[Medi-Kit]]
* [[Motion Scanner]]
* [[Alien Grenade]]
* [[Mind Probe]]

There are also four UFO Components which can be researched but which have no practical value:

* [[Alien Entertainment]]
* [[Alien Food]]
* [[Alien Surgery]]
* [[Examination Room]]

A fifth component, [[Alien Reproduction]], cannot normally be found in the game, although it can be researched if you add it to your General Stores using a game editor.

==Research Tree==
<center>[[file:tree1.png|800px|thumb|center|UFO:EU Research Tree]]</center>
<center>[[file:tree1_ob_en.png|400px|thumb|center|Explanations]]</center>

==See Also==
[[Research_(TFTD)]]
{{Research Navbar}}
[[Category:Research (EU)]]

User:Sherlock

2013-01-05T10:46:17Z

Sherlock:

User:Sherlock

2013-01-05T10:45:29Z

Sherlock:

User:Sherlock

2013-01-05T10:43:47Z

Sherlock:

File:Tree2 ob en.png

2013-01-05T10:40:03Z

Sherlock: Terror From The Deep Research Tree Explanations

Terror From The Deep Research Tree Explanations