UFOpaedia - User contributions [en]

Agents Armor (Apocalypse)

2010-01-12T01:36:14Z

Talon81:

There are three types of armor available in Apocalypse. Two standard suits sold by [[Megapol]] and [[Marsec]] and one suit crafted by [[X-COM (Apocalypse)|X-COM]].

There are five pieces for each set (helmet, chest, legs, left arm, right arm). Pieces can be mixed and matched. They do not need to be worn as a set, or even for complete coverage. Be warned that the mixture will not only look ugly, it will often *appear* to have holes which expose the agent underneath. Rest assured, this is only a cosmetic affect on your agent's paper doll image, the fact that there is a gap between the chest and leg pieces does not mean your agent will get shot in the stomach.

==Armor Types==

[[Image:Apoc_noarmor.png|Megapol Armor|right]]
* When your soldiers are hired they will all arrive without any armor. Going to battle without any armor is usually a bad idea unless you are conducting [[Stun Raid]]s.
<br clear="all"><br>

[[Image:Apoc_megapol_armor_equip.png|Megapol Armor|right]]
*[[Megapol Armor]] - Armored suit which is available at the start of the new game. It is the heaviest and the cheapest of the three types, and provides medium protection. Manufactured by [[Megapol]].
<br clear="all"><br>

[[Image:Apoc_marsec_armor_equip.png|Marsec Armor|right]]
*[[Marsec Armor]] - Flying suit available in the market after week 1. It is the weakest armor but it is lighter in weight than Megapol Armor. Manufactured by [[Marsec]].
<br clear="all"><br>

[[Image:Apoc_xcom_armor_equip.png|X-COM Disruptor Armor|right]]
*[[X-COM Disruptor Armor]] - Advanced suit based on disruptor technology offering the best protection and the lightest weight. It is also the more expensive armor. Requires [[Research (Apocalypse)|research]] and [[Manufacturing (Apocalypse)|manufacture]] by [[X-COM (Apocalypse)|X-COM]].
<br clear="all"><br>

==Mixing Armor==

When you start the game, you have little choice in wearing any form of armor beyond the Megapol Armor. It is heavy, so weak soldiers will suffer from wearing it by not being able to run for very long. You have a good chance of winning the earliest combats without any armor, since the first fights will usually be against [[Anthropod]]s armed with [[Brainsucker Launcher]]s. However, it is a big mistake for an agent to continue going into combat without any armor, since the aliens will start packing [[Disruptor Gun]]s and explosives, and many aliens will have built in projectile weapons.

[[Image:Apoc_armor_mixed1.png|left]]
As soon as you obtain Marsec Armor, you can start mixing and matching the armor sets to suit your needs. Though the torso plates are equal in weight, the weight difference of the Marsec limbs allow you some flexibility in adjusting your agent's load to reduce their encumbrance levels as necessary. For example, a hybrid who has only just been hired will not be able to carry very much equipment around while wearing a full suit of Megapol Armor. Instead, consider swapping the arms, or legs out with Marsec pieces. It still offers protection, and is much lighter than a full set of Megapol armor.

[[Image:Apoc_armor_mixed2.png|right]]The most popular and longest lasting setup is to wear the Marsec Torso plate and to wear the limb parts that provide the best protection. In the early game, Megapol limbs, in the late game X-COM Disruptor Armor limbs. To some this is considered the ultimate setup, providing moderate (but not perfect) protection along with absolute freedom of motion.

If you prefer to use ground troops, or use a mixture of flight and ground troops, the groundpounders should wear the best protection that they can afford. Though there is little choice early in the game, they can get away with it in pretty much any setup. In the late game, a full suit of X-COM Disruptor Armor provides the best solid round defense and near immunity to high explosive attacks as long as the armor holds out. Plus its light, allowing these troops to run for a lot longer. This is the second ultimate armor setup, superior in defense but weakened by its lack of flight.

[[Image:Apoc_armor_mixed3.png|left]]
If defensive or mobility are not a concern to you at all, then you can get a bit more creative as the armor plates are great for playing dress up! Each part from each set has a unique colour to identify itself. Silver for Megapol, red for Marsec and Blue for Disruptor Armor. You can use it to mark teams or roles, such as team 1 gets to wear all Megapol helmets while team 2 wear Marsec helmets. Or perhaps heavy weapon specialists get to wear a white and red arm, or squads of [[Hybrids (Apocalypse)|hybrids]] equipped with [[Mind Bender]]s get to Marsec pants.
<br clear="all">

== Mixing Armor with Technology ==

There are many tools available to you that go well with your armor setups. They supplement your armor, no matter which setup you use.

The simplest is probably the [[Megapol Smoke Grenade|Smoke Grenade]]. No matter how well protected you are, you don't really want to get hit by anything. Smoke lets you hide yourself on your approaches or your retreats.

[[Personal Disruptor Shield]]s are the biggest boon to any agent for defense. With a fully juiced shield, an agent can go into battle without wearing armor, and will not even suffer from any fall damage should they fall or jump off a great height.In addition to that, they can defend against the dreaded [[Entropy Launcher|Entropy missiles]]. Though this is the lightest form of armor available, it is also the most reckless. Shields can not be relied on to last a prolonged sustained attack. Armor should be worn as a contingency measure should the shields overload and fizzle out. Any of the setups mentioned earlier will do fine with one, two, three or even four Disruptor shields. One and two shields are the customary number of shields to carry. Three if you really need to protect that agent. Four shields is too much, resulting in the agent not being able to fight back. This can be useful for agents designated as ammo carriers, or even (spare) shield bearers.
In reality, shields use up energy ONE BY ONE... and when a shield unit's energy goes to zero, it is destroyed. So, overall, it is better to only carry one shield, and let the shield's energy recover over time. When you do use multiple shields, if you have taken any damage, drop the shield with the partial battery in a safe place or hand it to an agent (who is not actively participating in the combat) to let it recharge. This will put a fresh shield forward as the active shield while you wait for the other shield to recharge.

[[Personal Cloaking Field]]s make it harder for the enemy to spot you at a distance. It's like carrying your own localized smoke screen that only works against the enemy. They mesh particularly well with flying units as they are generally the most exposed. In real-time combat, this means a reduction in firepower, but does allow you to take more careful shots from a range.

Once you get [[Personal Teleporter]]s in the far portion of the late game, tactics change. The mobility advantage of the Marsec plate is negated as even ground troops will be able to scale tall places that they once could not. The teleporters still do not negate the Marsec plate's ability to levitate in mid air. It will let you teleport anywhere in the map in mid-air. Be warned that the teleporter requires some recharge time between jumps, a deficit not shared by the Marsec plate. Teleporters also render Disruptor Shields much more powerful, as you can simply teleport to a hidden corner of the map and let your shield recharge.

==Typical Use==
...to be continued

quickie: partial wearing tactics, best mix'n'match, weights + protection, prices, typical avial. quantities, how each helemt filters gases (+ & - of it all).

Note that removing the Marsec chestpiece during flight will cause the agent to plumet to the ground. Even while the game is paused. This allows sudden mid-air evasion of projectiles and missiles, assuming your reflexes are fast enough to reequip it before your agent hits the ground.

Best mix'n'match early game is Marsec chestpiece with Megapol armor for others. Later on, either all X-COM armor, or possibly X-COM armor + Marsec Chest Piece. Really late game, it is viable to use ONLY the Marsec Chest Piece + Shields.

==See Also==
*[[Armor|Armour (UFO)]]
*[[Armour (TFTD)]]

{{Equipment (Apocalypse) Navbar}}

[[Category:Agents Armour (Apocalypse)]]

Talk:Biochemistry

2009-12-07T23:21:21Z

Talon81:

it seems to me that the values under "cost" are WAY off. First off, I am making the assumption that by cost we mean "skill hours" and not financial cost. Some of them could be simply mistakes, such as the multiworm being listed as 90k and 15k, which is (according to Apoc'd) 9k and 15k; yet others are so different that it cannot have been a simple typo. Is there something I am missing? [[User:Talon81|Talon81]] 23:30, 18 November 2009 (EST)
: Looking at it the Hyperworm, Multiworm Egg and the Multiworm seem to have all typos. The original poster that added the skill hours was Blaimjos but he doesn't mentioned his source. Either he got it from one of the forums or from the Official Strategy Guide. Can you check with Apoc'd all of the values that don't match? [[User:Hobbes|Hobbes]] 05:57, 19 November 2009 (EST)
:: Yeah, I noticed those ones seem to be typos. I have only been around this wiki for at most a year, and only on Apoc wiki for a couple months. I didn't want to be presumptuous in making major edits, but I have fixed a few things here and there. Anyway, I am going to edit all of them to match Apoc'd now, and you can review my changes and undo anything you know to be wrong... but I am pretty certain Apoc'd is correct.[[User:Talon81|Talon81]] 14:00, 19 November 2009 (EST)
::: Modesty is a virtue but don't let it restrain you from doing edits if the information is incorrect or outdated. No one here holds the truth... perhaps someone will come in a year and tell us that Apoc'd values are all wrong :) [[User:Hobbes|Hobbes]] 14:42, 19 November 2009 (EST)
:::: BLASPHEMY!!! :-) [[User:J'ordos|J'ordos]] 07:02, 20 November 2009 (EST)
::::: Thus speaks the god J'ordos... we will all feel his wrath and anger now! ;) [[User:Hobbes|Hobbes]] 11:32, 20 November 2009 (EST)
::Sorry I'm not a regular contributor. My interest is usually tied to when I'm playing the game. My reference source was my now yellowing strategy guide. I've found some mistakes over 12+ years but didn't know about Apoc'd and figured more was better than less. I'll try to include my reference in the future. Thanks for seeing enough value to correct rather than revert!![[User:Blaimjos|Blaimjos]] 20:59, 6 December 2009 (EST)
::: No need to feel bad. There is so much conflicting information coming from different sources, and as it turns out just because its official doesnt make it correct. In any case, I wouldn't have corrected something that wasn't there to begin with, so your help is appreciated. ;-) [[User:Talon81|Talon81]] 18:21, 7 December 2009 (EST)

Base Locations (Apocalypse)

2009-11-20T06:57:55Z

Talon81: /* Superhuman Level */

The number of bases and their characteristics varies according to the difficulty level. You can read information about all the possible base sites below.

On the city maps, Yellow buildings are [[Warehouse (Apocalypse)|Warehouses]] while Red denotes [[Slums (Apocalypse)|Slums]].

==Novice Level==

[[Image:Apoc_1_bases.png|right|400 px]]

<table {{StdDescTable}}>
<th {{StdDescTable_Heading}}>Layout</th><th {{StdDescTable_Heading}}>Name<th {{StdDescTable_Heading}}>Cost</th><th {{StdDescTable_Heading}}>Area</th><th {{StdDescTable_Heading}}>Map Location</th><th {{StdDescTable_Heading}}>Cost/Area</th>

<tr><td>[[Image:Apoc_base3.png|left|50 px]]</td><td>Warehouse Three</td><td>30000</td><td>25</td><td>East</td><td>1200</td></tr>
<tr><td>[[Image:Apoc_base4.png|left|50 px]]</td><td>Warehouse Four</td><td>48000</td><td>29</td><td>North</td><td>1656</td></tr>
<tr><td>[[Image:Apoc_base2.png|left|50 px]]</td><td>Warehouse Seven</td><td>40000</td><td>24</td><td>Northeast</td><td>1667</td></tr>
<tr><td>[[Image:Apoc_base5.png|left|50 px]]</td><td>Warehouse Nine</td><td>50000</td><td>32</td><td>Northeast</td><td>1563</td></tr>
<tr><td>[[Image:Apoc_base1.png|left|50 px]]</td><td>Dickens Estate</td><td>112000</td><td>28</td><td>North</td><td>4000</td></tr>
<tr><td>[[Image:Apoc_base2.png|left|50 px]]</td><td>Heavenly Towers </td><td>96000</td><td>24</td><td>East</td><td>4000</td></tr>
</table>

===Notes===
Warehouse Four is the best building available because of cost, space, base defense and hit resistance, with Warehouse Seven as a second choice.

==Easy Level==

[[Image:Apoc_2_bases.png|right|400 px]]

<table {{StdDescTable}}>
<th {{StdDescTable_Heading}}>Layout</th><th {{StdDescTable_Heading}}>Name<th {{StdDescTable_Heading}}>Cost</th><th {{StdDescTable_Heading}}>Area</th><th {{StdDescTable_Heading}}>Map Location</th><th {{StdDescTable_Heading}}>Cost/Area</th>

<tr><td>[[Image:Apoc_base8.png|left|50 px]]</td><td>Warehouse One</td><td>70000</td><td>22</td><td>Northeast</td><td>3182</td></tr>
<tr><td>[[Image:Apoc_base1.png|left|50 px]]</td><td>Warehouse Two</td><td>30000</td><td>32</td><td>Northeast</td><td>938</td></tr>
<tr><td>[[Image:Apoc_base9.png|left|50 px]]</td><td>Warehouse Six</td><td>30000</td><td>24</td><td>East</td><td>1250</td></tr>
<tr><td>[[Image:Apoc_base10.png|left|50 px]]</td><td>Warehouse Nine</td><td>30000</td><td>24</td><td>North</td><td>1250</td></tr>
<tr><td>[[Image:Apoc_base6.png|left|50 px]]</td><td>Bakunin Block</td><td>80000</td><td>24</td><td>Center</td><td>3000</td></tr>
<tr><td>[[Image:Apoc_base7.png|left|50 px]]</td><td>Heavenly Towers</td><td>84000</td><td>28</td><td>Center</td><td>3333</td></tr>
</table>

===Notes===
Warehouses Two and Six are the best buys for their cost, space, base defense and hit resistance. Don't waste money on any of the slums.

==Medium Level==

[[Image:Apoc_3_bases.png|right|400 px]]

<table {{StdDescTable}}>
<th {{StdDescTable_Heading}}>Layout</th><th {{StdDescTable_Heading}}>Name<th {{StdDescTable_Heading}}>Cost</th><th {{StdDescTable_Heading}}>Area</th><th {{StdDescTable_Heading}}>Map Location</th><th {{StdDescTable_Heading}}>Cost/Area</th>

<tr><td>[[Image:Apoc_base5.png|left|50 px]]</td><td>Warehouse One</td><td>70000</td><td>32</td><td>Southwest</td><td>2188</td></tr>
<tr><td>[[Image:Apoc_base11.png|left|50 px]]</td><td>Warehouse Three</td><td>40000</td><td>20</td><td>South</td><td>2000</td></tr>
<tr><td>[[Image:Apoc_base4.png|left|50 px]]</td><td>Warehouse Six</td><td>96000</td><td>29</td><td>Southeast</td><td>3310</td></tr>
<tr><td>[[Image:Apoc_base12.png|left|50 px]]</td><td>Warehouse Seven</td><td>70000</td><td>36</td><td>East</td><td>1944</td></tr>
<tr><td>[[Image:Apoc_base9.png|left|50 px]]</td><td>Campesino Apartments</td><td>50000</td><td>24</td><td>Center</td><td>2083</td></tr>
<tr><td>[[Image:Apoc_base3.png|left|50 px]]</td><td>Hades Block</td><td>48000</td><td>25</td><td>Northeast</td><td>1920</td></tr>
<tr><td>[[Image:Apoc_base10.png|left|50 px]]</td><td>Oliver Twist Block</td><td>70000</td><td>24</td><td>South</td><td>2917</td></tr>

</table>

===Notes===
Warehouse Six is the best available realstate for defense, space and hit resistance, if you can spare the money for its price tag. The Campesino Apartments might be interesting if you don't mind the possibility of a unlucky stray shot hitting the wrong spot of the building and killing all personnel.
Warehouse Three is the cheapest but has the least space for expansion.

==Hard Level==

[[Image:Apoc_4_bases.png|right|400 px]]

<table {{StdDescTable}}>
<th {{StdDescTable_Heading}}>Layout</th><th {{StdDescTable_Heading}}>Name<th {{StdDescTable_Heading}}>Cost</th><th {{StdDescTable_Heading}}>Area</th><th {{StdDescTable_Heading}}>Map Location</th><th {{StdDescTable_Heading}}>Cost/Area</th>

<tr><td>[[Image:Apoc_base8.png|left|50 px]]</td><td>Warehouse One</td><td>72000</td><td>22</td><td>Northeast</td><td>3273</td></tr>
<tr><td>[[Image:Apoc_base7.png|left|50 px]]</td><td>Warehouse Five</td><td>84000</td><td>28</td><td>Southeast</td><td>3000</td></tr>
<tr><td>[[Image:Apoc_base12.png|left|50 px]]</td><td>Warehouse Six</td><td>48000</td><td>36</td><td>Southeast</td><td>1333</td></tr>
<tr><td>[[Image:Apoc_base14.png|left|50 px]]</td><td>Warehouse Eight</td><td>72000</td><td>27</td><td>South</td><td>2667</td></tr>
<tr><td>[[Image:Apoc_base13.png|left|50 px]]</td><td>Campesino Apartments</td><td>50000</td><td>32</td><td>Northwest</td><td>1463</td></tr>
<tr><td>[[Image:Apoc_base8.png|left|50 px]]</td><td>Chronos Block</td><td>72000</td><td>22</td><td>Northwest</td><td>3273</td></tr>
<tr><td>[[Image:Apoc_base5.png|left|50 px]]</td><td>Hades Block</td><td>112000</td><td>32</td><td>Center</td><td>3500</td></tr>

</table>

===Notes===
Warehouse Eight is a very interesting option because of its defense chokepoints. Warehouse Six has the biggest area and the smallest price but will require more [[Security Station (Apocalypse)|Security Stations]] to protect it from raids.

==Superhuman Level==

[[Image:Apoc_5_bases.png|right|400 px]]

<table {{StdDescTable}}>
<th {{StdDescTable_Heading}}>Layout</th><th {{StdDescTable_Heading}}>Name<th {{StdDescTable_Heading}}>Cost</th><th {{StdDescTable_Heading}}>Area</th><th {{StdDescTable_Heading}}>Map Location</th><th {{StdDescTable_Heading}}>Cost/Area</th>

<tr><td>[[Image:Apoc_base12.png|left|50 px]]</td><td>Warehouse One</td><td>56000</td><td>36</td><td>Northwest</td><td>1556</td></tr>
<tr><td>[[Image:Apoc_base16.png|left|50 px]]</td><td>Warehouse Two</td><td>98000</td><td>22</td><td>West</td><td>4455</td></tr>
<tr><td>[[Image:Apoc_base4.png|left|50 px]]</td><td>Warehouse Eight</td><td>20000</td><td>29</td><td>Southwast</td><td>690</td></tr>
<tr><td>[[Image:Apoc_base9.png|left|50 px]]</td><td>Warehouse
Ten</td><td>20000</td><td>24</td><td>East</td><td>833</td></tr>
<tr><td>[[Image:Apoc_base8.png|left|50 px]]</td><td>Warehouse
Eleven</td><td>32000</td><td>22</td><td>East</td><td>1455</td></tr>
<tr><td>[[Image:Apoc_base5.png|left|50 px]]</td><td>Lovecraft
Block</td><td>32000</td><td>32</td><td>South</td><td>1000</td></tr>
<tr><td>[[Image:Apoc_base13.png|left|50 px]]</td><td>Thomas Moore Tower</td><td>80000</td><td>32</td><td>Center</td><td>2500</td></tr>
<tr><td>[[Image:Apoc_base15.png|left|50 px]]</td><td>Grimoire Block</td><td>80000</td><td>28</td><td>Southeast</td><td>2857</td></tr>

</table>

===Notes===
Warehouses Eight and Ten are the best options. Warehouses Ten and Eleven are adjacent to one another.

==See Also==

* [[Bases (Apocalypse)|Bases]]
* [[Base Layouts (Apocalypse)|Base Layouts]]

[[Category: Apocalypse]]
[[Category: Bases (Apocalypse)]]

Base Locations (Apocalypse)

2009-11-20T06:56:04Z

Talon81: /* Superhuman Level */ Warehouse Ten was incorrectly named Twelve

The number of bases and their characteristics varies according to the difficulty level. You can read information about all the possible base sites below.

On the city maps, Yellow buildings are [[Warehouse (Apocalypse)|Warehouses]] while Red denotes [[Slums (Apocalypse)|Slums]].

==Novice Level==

[[Image:Apoc_1_bases.png|right|400 px]]

<table {{StdDescTable}}>
<th {{StdDescTable_Heading}}>Layout</th><th {{StdDescTable_Heading}}>Name<th {{StdDescTable_Heading}}>Cost</th><th {{StdDescTable_Heading}}>Area</th><th {{StdDescTable_Heading}}>Map Location</th><th {{StdDescTable_Heading}}>Cost/Area</th>

<tr><td>[[Image:Apoc_base3.png|left|50 px]]</td><td>Warehouse Three</td><td>30000</td><td>25</td><td>East</td><td>1200</td></tr>
<tr><td>[[Image:Apoc_base4.png|left|50 px]]</td><td>Warehouse Four</td><td>48000</td><td>29</td><td>North</td><td>1656</td></tr>
<tr><td>[[Image:Apoc_base2.png|left|50 px]]</td><td>Warehouse Seven</td><td>40000</td><td>24</td><td>Northeast</td><td>1667</td></tr>
<tr><td>[[Image:Apoc_base5.png|left|50 px]]</td><td>Warehouse Nine</td><td>50000</td><td>32</td><td>Northeast</td><td>1563</td></tr>
<tr><td>[[Image:Apoc_base1.png|left|50 px]]</td><td>Dickens Estate</td><td>112000</td><td>28</td><td>North</td><td>4000</td></tr>
<tr><td>[[Image:Apoc_base2.png|left|50 px]]</td><td>Heavenly Towers </td><td>96000</td><td>24</td><td>East</td><td>4000</td></tr>
</table>

===Notes===
Warehouse Four is the best building available because of cost, space, base defense and hit resistance, with Warehouse Seven as a second choice.

==Easy Level==

[[Image:Apoc_2_bases.png|right|400 px]]

<table {{StdDescTable}}>
<th {{StdDescTable_Heading}}>Layout</th><th {{StdDescTable_Heading}}>Name<th {{StdDescTable_Heading}}>Cost</th><th {{StdDescTable_Heading}}>Area</th><th {{StdDescTable_Heading}}>Map Location</th><th {{StdDescTable_Heading}}>Cost/Area</th>

<tr><td>[[Image:Apoc_base8.png|left|50 px]]</td><td>Warehouse One</td><td>70000</td><td>22</td><td>Northeast</td><td>3182</td></tr>
<tr><td>[[Image:Apoc_base1.png|left|50 px]]</td><td>Warehouse Two</td><td>30000</td><td>32</td><td>Northeast</td><td>938</td></tr>
<tr><td>[[Image:Apoc_base9.png|left|50 px]]</td><td>Warehouse Six</td><td>30000</td><td>24</td><td>East</td><td>1250</td></tr>
<tr><td>[[Image:Apoc_base10.png|left|50 px]]</td><td>Warehouse Nine</td><td>30000</td><td>24</td><td>North</td><td>1250</td></tr>
<tr><td>[[Image:Apoc_base6.png|left|50 px]]</td><td>Bakunin Block</td><td>80000</td><td>24</td><td>Center</td><td>3000</td></tr>
<tr><td>[[Image:Apoc_base7.png|left|50 px]]</td><td>Heavenly Towers</td><td>84000</td><td>28</td><td>Center</td><td>3333</td></tr>
</table>

===Notes===
Warehouses Two and Six are the best buys for their cost, space, base defense and hit resistance. Don't waste money on any of the slums.

==Medium Level==

[[Image:Apoc_3_bases.png|right|400 px]]

<table {{StdDescTable}}>
<th {{StdDescTable_Heading}}>Layout</th><th {{StdDescTable_Heading}}>Name<th {{StdDescTable_Heading}}>Cost</th><th {{StdDescTable_Heading}}>Area</th><th {{StdDescTable_Heading}}>Map Location</th><th {{StdDescTable_Heading}}>Cost/Area</th>

<tr><td>[[Image:Apoc_base5.png|left|50 px]]</td><td>Warehouse One</td><td>70000</td><td>32</td><td>Southwest</td><td>2188</td></tr>
<tr><td>[[Image:Apoc_base11.png|left|50 px]]</td><td>Warehouse Three</td><td>40000</td><td>20</td><td>South</td><td>2000</td></tr>
<tr><td>[[Image:Apoc_base4.png|left|50 px]]</td><td>Warehouse Six</td><td>96000</td><td>29</td><td>Southeast</td><td>3310</td></tr>
<tr><td>[[Image:Apoc_base12.png|left|50 px]]</td><td>Warehouse Seven</td><td>70000</td><td>36</td><td>East</td><td>1944</td></tr>
<tr><td>[[Image:Apoc_base9.png|left|50 px]]</td><td>Campesino Apartments</td><td>50000</td><td>24</td><td>Center</td><td>2083</td></tr>
<tr><td>[[Image:Apoc_base3.png|left|50 px]]</td><td>Hades Block</td><td>48000</td><td>25</td><td>Northeast</td><td>1920</td></tr>
<tr><td>[[Image:Apoc_base10.png|left|50 px]]</td><td>Oliver Twist Block</td><td>70000</td><td>24</td><td>South</td><td>2917</td></tr>

</table>

===Notes===
Warehouse Six is the best available realstate for defense, space and hit resistance, if you can spare the money for its price tag. The Campesino Apartments might be interesting if you don't mind the possibility of a unlucky stray shot hitting the wrong spot of the building and killing all personnel.
Warehouse Three is the cheapest but has the least space for expansion.

==Hard Level==

[[Image:Apoc_4_bases.png|right|400 px]]

<table {{StdDescTable}}>
<th {{StdDescTable_Heading}}>Layout</th><th {{StdDescTable_Heading}}>Name<th {{StdDescTable_Heading}}>Cost</th><th {{StdDescTable_Heading}}>Area</th><th {{StdDescTable_Heading}}>Map Location</th><th {{StdDescTable_Heading}}>Cost/Area</th>

<tr><td>[[Image:Apoc_base8.png|left|50 px]]</td><td>Warehouse One</td><td>72000</td><td>22</td><td>Northeast</td><td>3273</td></tr>
<tr><td>[[Image:Apoc_base7.png|left|50 px]]</td><td>Warehouse Five</td><td>84000</td><td>28</td><td>Southeast</td><td>3000</td></tr>
<tr><td>[[Image:Apoc_base12.png|left|50 px]]</td><td>Warehouse Six</td><td>48000</td><td>36</td><td>Southeast</td><td>1333</td></tr>
<tr><td>[[Image:Apoc_base14.png|left|50 px]]</td><td>Warehouse Eight</td><td>72000</td><td>27</td><td>South</td><td>2667</td></tr>
<tr><td>[[Image:Apoc_base13.png|left|50 px]]</td><td>Campesino Apartments</td><td>50000</td><td>32</td><td>Northwest</td><td>1463</td></tr>
<tr><td>[[Image:Apoc_base8.png|left|50 px]]</td><td>Chronos Block</td><td>72000</td><td>22</td><td>Northwest</td><td>3273</td></tr>
<tr><td>[[Image:Apoc_base5.png|left|50 px]]</td><td>Hades Block</td><td>112000</td><td>32</td><td>Center</td><td>3500</td></tr>

</table>

===Notes===
Warehouse Eight is a very interesting option because of its defense chokepoints. Warehouse Six has the biggest area and the smallest price but will require more [[Security Station (Apocalypse)|Security Stations]] to protect it from raids.

==Superhuman Level==

[[Image:Apoc_5_bases.png|right|400 px]]

<table {{StdDescTable}}>
<th {{StdDescTable_Heading}}>Layout</th><th {{StdDescTable_Heading}}>Name<th {{StdDescTable_Heading}}>Cost</th><th {{StdDescTable_Heading}}>Area</th><th {{StdDescTable_Heading}}>Map Location</th><th {{StdDescTable_Heading}}>Cost/Area</th>

<tr><td>[[Image:Apoc_base12.png|left|50 px]]</td><td>Warehouse One</td><td>56000</td><td>36</td><td>Northwest</td><td>1556</td></tr>
<tr><td>[[Image:Apoc_base16.png|left|50 px]]</td><td>Warehouse Two</td><td>98000</td><td>22</td><td>West</td><td>4455</td></tr>
<tr><td>[[Image:Apoc_base4.png|left|50 px]]</td><td>Warehouse Eight</td><td>20000</td><td>29</td><td>Southwast</td><td>690</td></tr>
<tr><td>[[Image:Apoc_base8.png|left|50 px]]</td><td>Warehouse
Ten</td><td>20000</td><td>24</td><td>East</td><td>833</td></tr>
<tr><td>[[Image:Apoc_base5.png|left|50 px]]</td><td>Lovecraft
Eleven</td><td>32000</td><td>22</td><td>East</td><td>1455</td></tr>
<tr><td>[[Image:Apoc_base9.png|left|50 px]]</td><td>Warehouse Block</td><td>32000</td><td>32</td><td>South</td><td>1000</td></tr>
<tr><td>[[Image:Apoc_base13.png|left|50 px]]</td><td>Thomas Moore Tower</td><td>80000</td><td>32</td><td>Center</td><td>2500</td></tr>
<tr><td>[[Image:Apoc_base15.png|left|50 px]]</td><td>Grimoire Block</td><td>80000</td><td>28</td><td>Southeast</td><td>2857</td></tr>

</table>

===Notes===
Warehouses Eight and Ten are the best options. Warehouses Ten and Eleven are adjacent to one another.

==See Also==

* [[Bases (Apocalypse)|Bases]]
* [[Base Layouts (Apocalypse)|Base Layouts]]

[[Category: Apocalypse]]
[[Category: Bases (Apocalypse)]]

Biochemistry

2009-11-19T20:43:00Z

Talon81: explained research cost

Biochemistry is the study of bio (life) and chem (the interactions of matter and energy). So this is the study of living organisms, pretty much, and their intended functions. I think. Anyway, this category can study a few items. Some are pretty neat, most are hit-you-over-the-head-why-did-I-have-to-do-this kind of thing. Toxins and weapons are cool, but I don't like to use them unless they have infinite ammo, which usually falls under the category of Quantum Physics.

Note that aliens must each be researched twice, once each for their living and dead states. Research cost is the "skill hours" required to complete a project. As your average biochemist contributes 80 (and perhaps much higher if you are being selective) skill hours per hour, that means that a research topic that takes 8000 will likely be complete in 20 hours when you put 5 biochemists to work on it (20*5*80=8000).

{| class="wikitable sortable" border="1"
! Topic !! Research Cost !! Required Bio-lab !! Type !! Direct Prerequisites !! Research Directly Requiring
|-
|[[Anthropod (Apocalypse)|Anthropod]] || 8,000/12,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Brainsucker]] || 7,000/9,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Multiworm (Apocalypse)|Multiworm]] || 9,000/15,000 || Standard ||Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat; The Alien Genetic Structure; The Alien Life Cycle
|-
|[[Multiworm Egg (Apocalypse)|Multiworm Egg]] || 8,000/12,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat; The Alien Genetic Structure
|-
|[[Hyperworm (Apocalypse)|Hyperworm]] || 6,000/9,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat; The Alien Genetic Structure; The Alien Life Cycle
|-
|[[Chrysalis (Apocalypse)|Chrysalis]] || 8,000/12,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat; The Alien Life Cycle
|-
|[[Skeletoid (Apocalypse)|Skeletoid]] || 10,000/15,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Micronoid Aggregate (Apocalypse)|Micronoid Aggregate]] || 20,000/26,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Popper (Apocalypse)|Popper]] || 6,000/9,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Spitter (Apocalypse)|Spitter]] || 6,000/9,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Megaspawn (Apocalypse)|Megaspawn]] || 12,000/20,000 || Advanced || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Psimorph (Apocalypse)|Psimorph]] || 12,000/20,000 || Advanced || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Queenspawn (Apocalypse)|Queenspawn]] || 15,000/25,000 || Advanced || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; Alien Gas
|-
|[[Overspawn (Apocalypse)|Overspawn]] || 20,000 || Advanced || Autopsy || Recovered Corpse || The Real Alien Threat
|-
|[[The Alien Genetic Structure (Apocalypse)|The Alien Genetic Structure]] || 25,000 || Advanced || Concept || Multiworm Egg Autopsy; Multiworm Autopsy; Hyperworm Autopsy || Biological Warfare
|-
|[[The Alien Life Cycle (Apocalypse)|The Alien Life Cycle]] || 30,000 || Standard || Concept || Multiworm; Multiworm Autopsy; Hyperworm; Hyperworm Autopsy; Chrysalis; Chrysalis Autopsy || Toxin Type B
|-
|[[The Real Alien Threat (Apocalypse)|The Real Alien Threat]] || 35,000 || Standard || Concept || All aliens and autopsies except for Quenspawn and Queenspawn Autopsy || Toxin Type C
|-
|[[Biological Warfare (Apocalypse)|Biological Warfare]] || 26,000 || Advanced || Agent Equipment || The Alien Genetic Structure || Toxin Type B
|-
|[[Toxin B (Apocalypse)|Toxin B]] || 15,000 || Advanced || Agent Equipment || The Alien Life Cycle; Biological Warfare || Toxin Type C
|-
|[[Toxin C (Apocalypse)|Toxin C]] || 15,000 || Advanced || Agent Equipment || The Real Alien Threat; Toxin Type B || Alien Gas
|-
|[[Alien Gas (Apocalypse)|Alien Gas]] || 28,000 || Advanced || Agent Equipment || Queenspawn; Queenspawn Autopsy; Toxin Type C || None
|-
|[[Brainsucker Launcher]] || 9,000 || Standard || Agent Equipment || Recovered Equipment || None
|-
|[[Brainsucker Pod]] || 6,000 || Standard || Agent Equipment || Recovered Equipment || None
|-
|[[Entropy Launcher]] || 9,000 || Standard || Agent Equipment || Recovered Equipment || None
|-
|[[Entropy Pod]] || 7,000 || Standard || Agent Equipment || Recovered Equipment || None
|-
|[[Sleeping Chamber|Alien Building 1]] || 38,000 || Standard || Mission Type || The Alien Dimension || None
|-
|[[Food Chamber|Alien Building 2]] || 42,000 || Standard || Mission Type || Completed Sleeping Chamber Mission || None
|-
|[[Alien Farm|Alien Building 3]] || 32,000 || Standard || Mission Type || Completed Food Chamber Mission || None
|-
|[[Maintenance Factory|Alien Building 4]] || 46,000 || Standard || Mission Type || Completed Alien Farm Mission || None
|-
|[[Incubator Chamber|Alien Building 5]] || 30,000 || Standard || Mission Type || Completed Maintenance Factory Mission || None
|-
|[[Control Chamber|Alien Building 6]] || 44,000 || Standard || Mission Type || Completed Incubator Chamber Mission || None
|-
|[[Spawning Chamber|Alien Building 7]] || 34,000 || Standard || Mission Type || Completed Control Chamber Mission || None
|-
|[[Organic Factory|Alien Building 8]] || 40,000 || Standard || Mission Type || Completed Spawning Chamber Mission || None
|-
|[[Megapod Chamber|Alien Building 9]] || 36,000 || Standard || Mission Type || Completed Organic Factory Mission || None
|-
|[[Dimension Gate Generator|Alien Building 10]] || 48,000 || Standard || Mission Type || Completed Megapod Chamber Mission || None
|-
|[[Bio-Transport Module (Apocalypse)|Bio-Transport Module]] || 9,000 || Standard || Vehicle Equipment || None || None
|-
|[[Advanced Biochemistry Lab (Apocalypse)|Advanced Biochemistry Lab]] || 16,000 || Standard || Base Facility || Any Live Alien Or Autopsy Except for Overspawn Autopsy || None
|}

==Suggested Research Path==
Biochemistry research is extremely important in the early part of the game. After your Bio-Transport Module is researched and manufactured, you should be bringing bunches of live aliens back from missions. (You <i>are</i> using lots of [[Megapol Stun Grenade |Stun Grenades]], right?) Your immediate goal is [[Toxigun |Toxiguns]] and Toxin-B, which can kill most aliens in two or three shots, have a high rate of fire, and ignore shields. Your ultimate goal is Toxin-C.

Your research should ideally follow roughly this order:

* Multiworm (or Autopsy)
* Advanced Biochemistry Lab. Begin construction (ideally at your second base) as soon as research completes.
* Multiworm Autopsy (or Live)
* Hyperworm
* Hyperworm Autopsy
* Chrysalis
* Chrysalis Autopsy
* Multiworm Egg
* Multiworm Egg Autopsy

By the time your Advanced Lab is complete, your biochemists should be finished with the above projects, unless they are horrible. After the above are complete, research the following in order:

* The Alien Genetic Structure
* Biological Warfare (Upon completion, begin building Toxiguns, but NOT Toxin A clips)
* The Alien Life Cycle
* Toxin B

From here, you ideally capture and research an example of every alien in the game alive and dead. They can be researched in any order, at which point you may research The Real Alien Threat, prerequisite to Toxin C - which makes Toxiguns the best general-purpose weapon in the game if you have the resources to keep up with producing the clips.

==See Also==
* [[Apocalypse]]
* [[Alien Life Forms (Apocalypse)|Alien Life Forms]]
* [[Toxigun]]
* [[The Real Alien Threat]]

[[Category: Apocalypse]]
[[Category: Research (Apocalypse)]]

[[Category: Bases (Apocalypse)]]

Biochemistry

2009-11-19T20:36:43Z

Talon81: corrected the "research cost" values, other minor changes

Biochemistry is the study of bio (life) and chem (the interactions of matter and energy). So this is the study of living organisms, pretty much, and their intended functions. I think. Anyway, this category can study a few items. Some are pretty neat, most are hit-you-over-the-head-why-did-I-have-to-do-this kind of thing. Toxins and weapons are cool, but I don't like to use them unless they have infinite ammo, which usually falls under the category of Quantum Physics.

(Note that aliens must each be researched twice, once each for their living and dead states).

{| class="wikitable sortable" border="1"
! Topic !! Research Cost !! Required Bio-lab !! Type !! Direct Prerequisites !! Research Directly Requiring
|-
|[[Anthropod (Apocalypse)|Anthropod]] || 8,000/12,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Brainsucker]] || 7,000/9,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Multiworm (Apocalypse)|Multiworm]] || 9,000/15,000 || Standard ||Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat; The Alien Genetic Structure; The Alien Life Cycle
|-
|[[Multiworm Egg (Apocalypse)|Multiworm Egg]] || 8,000/12,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat; The Alien Genetic Structure
|-
|[[Hyperworm (Apocalypse)|Hyperworm]] || 6,000/9,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat; The Alien Genetic Structure; The Alien Life Cycle
|-
|[[Chrysalis (Apocalypse)|Chrysalis]] || 8,000/12,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat; The Alien Life Cycle
|-
|[[Skeletoid (Apocalypse)|Skeletoid]] || 10,000/15,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Micronoid Aggregate (Apocalypse)|Micronoid Aggregate]] || 20,000/26,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Popper (Apocalypse)|Popper]] || 6,000/9,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Spitter (Apocalypse)|Spitter]] || 6,000/9,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Megaspawn (Apocalypse)|Megaspawn]] || 12,000/20,000 || Advanced || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Psimorph (Apocalypse)|Psimorph]] || 12,000/20,000 || Advanced || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Queenspawn (Apocalypse)|Queenspawn]] || 15,000/25,000 || Advanced || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; Alien Gas
|-
|[[Overspawn (Apocalypse)|Overspawn]] || 20,000 || Advanced || Autopsy || Recovered Corpse || The Real Alien Threat
|-
|[[The Alien Genetic Structure (Apocalypse)|The Alien Genetic Structure]] || 25,000 || Advanced || Concept || Multiworm Egg Autopsy; Multiworm Autopsy; Hyperworm Autopsy || Biological Warfare
|-
|[[The Alien Life Cycle (Apocalypse)|The Alien Life Cycle]] || 30,000 || Standard || Concept || Multiworm; Multiworm Autopsy; Hyperworm; Hyperworm Autopsy; Chrysalis; Chrysalis Autopsy || Toxin Type B
|-
|[[The Real Alien Threat (Apocalypse)|The Real Alien Threat]] || 35,000 || Standard || Concept || All aliens and autopsies except for Quenspawn and Queenspawn Autopsy || Toxin Type C
|-
|[[Biological Warfare (Apocalypse)|Biological Warfare]] || 26,000 || Advanced || Agent Equipment || The Alien Genetic Structure || Toxin Type B
|-
|[[Toxin B (Apocalypse)|Toxin B]] || 15,000 || Advanced || Agent Equipment || The Alien Life Cycle; Biological Warfare || Toxin Type C
|-
|[[Toxin C (Apocalypse)|Toxin C]] || 15,000 || Advanced || Agent Equipment || The Real Alien Threat; Toxin Type B || Alien Gas
|-
|[[Alien Gas (Apocalypse)|Alien Gas]] || 28,000 || Advanced || Agent Equipment || Queenspawn; Queenspawn Autopsy; Toxin Type C || None
|-
|[[Brainsucker Launcher]] || 9,000 || Standard || Agent Equipment || Recovered Equipment || None
|-
|[[Brainsucker Pod]] || 6,000 || Standard || Agent Equipment || Recovered Equipment || None
|-
|[[Entropy Launcher]] || 9,000 || Standard || Agent Equipment || Recovered Equipment || None
|-
|[[Entropy Pod]] || 7,000 || Standard || Agent Equipment || Recovered Equipment || None
|-
|[[Sleeping Chamber|Alien Building 1]] || 38,000 || Standard || Mission Type || The Alien Dimension || None
|-
|[[Food Chamber|Alien Building 2]] || 42,000 || Standard || Mission Type || Completed Sleeping Chamber Mission || None
|-
|[[Alien Farm|Alien Building 3]] || 32,000 || Standard || Mission Type || Completed Food Chamber Mission || None
|-
|[[Maintenance Factory|Alien Building 4]] || 46,000 || Standard || Mission Type || Completed Alien Farm Mission || None
|-
|[[Incubator Chamber|Alien Building 5]] || 30,000 || Standard || Mission Type || Completed Maintenance Factory Mission || None
|-
|[[Control Chamber|Alien Building 6]] || 44,000 || Standard || Mission Type || Completed Incubator Chamber Mission || None
|-
|[[Spawning Chamber|Alien Building 7]] || 34,000 || Standard || Mission Type || Completed Control Chamber Mission || None
|-
|[[Organic Factory|Alien Building 8]] || 40,000 || Standard || Mission Type || Completed Spawning Chamber Mission || None
|-
|[[Megapod Chamber|Alien Building 9]] || 36,000 || Standard || Mission Type || Completed Organic Factory Mission || None
|-
|[[Dimension Gate Generator|Alien Building 10]] || 48,000 || Standard || Mission Type || Completed Megapod Chamber Mission || None
|-
|[[Bio-Transport Module (Apocalypse)|Bio-Transport Module]] || 9,000 || Standard || Vehicle Equipment || None || None
|-
|[[Advanced Biochemistry Lab (Apocalypse)|Advanced Biochemistry Lab]] || 16,000 || Standard || Base Facility || Any Live Alien Or Autopsy Except for Overspawn Autopsy || None
|}

==Suggested Research Path==
Biochemistry research is extremely important in the early part of the game. After your Bio-Transport Module is researched and manufactured, you should be bringing bunches of live aliens back from missions. (You <i>are</i> using lots of [[Megapol Stun Grenade |Stun Grenades]], right?) Your immediate goal is [[Toxigun |Toxiguns]] and Toxin-B, which can kill most aliens in two or three shots, have a high rate of fire, and ignore shields. Your ultimate goal is Toxin-C.

Your research should ideally follow roughly this order:

* Multiworm (or Autopsy)
* Advanced Biochemistry Lab. Begin construction (ideally at your second base) as soon as research completes.
* Multiworm Autopsy (or Live)
* Hyperworm
* Hyperworm Autopsy
* Chrysalis
* Chrysalis Autopsy
* Multiworm Egg
* Multiworm Egg Autopsy

By the time your Advanced Lab is complete, your biochemists should be finished with the above projects, unless they are horrible. After the above are complete, research the following in order:

* The Alien Genetic Structure
* Biological Warfare (Upon completion, begin building Toxiguns, but NOT Toxin A clips)
* The Alien Life Cycle
* Toxin B

From here, you ideally capture and research an example of every alien in the game alive and dead. They can be researched in any order, at which point you may research The Real Alien Threat, prerequisite to Toxin C - which makes Toxiguns the best general-purpose weapon in the game if you have the resources to keep up with producing the clips.

==See Also==
* [[Apocalypse]]
* [[Alien Life Forms (Apocalypse)|Alien Life Forms]]
* [[Toxigun]]
* [[The Real Alien Threat]]

[[Category: Apocalypse]]
[[Category: Research (Apocalypse)]]

[[Category: Bases (Apocalypse)]]

User talk:Hobbes

2009-11-19T20:08:59Z

Talon81: /* Apocalypse updates */

== Geneva ==

Hiya Hobbes. Check out my 5th Geneva Convention on Talk:CFN and see what you think.

Some of the points it may need to address are: XCOM exclusive right to deal with Aliens; basing rights; military cooperation: however I see it as an overall document that permits new directives and regulations to be issued by the Council so it doesn't have to cover everything.

feel free to move / copy / edit.
[[User:Spike|Spike]] 02:22, 12 March 2008 (PDT)

== Unknown Menace ==

I've just started reading your first XCom novel and I'm hooked! But I'm going somewhere with only patchy internet. Is there a way I can download the whole novel as a zip file? [[User:Spike|Spike]] 16:30, 9 September 2008 (PDT)
: Here's the [http://area51.xcomufo.com/files/UM-Full-PDF.rar full book] in a pdf file (3.4 mb). Have fun :) [[User:Hobbes|Hobbes]] 17:23, 9 September 2008 (PDT)
:: Thanks. I had a bit of a struggle to convert the RAR to .zip - RAR's not so common on some types of computer. And I've just this morning finished reading the whole thing. I'm very impressed, it's a big work. Must've taken you a long time to write it. I really like your take on a lot of the back story behind XCom, CFN, etc. It's an exciting plot, a "page turner" as they say. [[User:Spike|Spike]] 13:44, 13 September 2008 (PDT)
:::Thanks. Took me over 2 years to finish it, and I about figured the time required for me to write it after 3 months! I didn't simply want to give the 'ingame' perspective of endless battles. :) [[User:Hobbes|Hobbes]] 14:12, 13 September 2008 (PDT)

== Apocalypse updates ==

Good work on the Apocalypse updates Hobbes. Problem I've always found with the wiki is that a lot of the articles are out of sight and therefore out of mind. With the updates, there looks like there are heaps of articles that need an overhaul and some of the not-entirely-canon bits left over from our earlier days that may need to be culled or revised. -[[User:NKF|NKF]]

:Thanks. Updating this section will be a long term project and but the Mega-Primus section is mostly done, all it requires now is more images for the buildings and tactical tips for each building. Most of the other material can be reused though, in many cases it is merely a matter of rewording (changing gender into a neutral 'it' helps) but there's non-canon bits that should be dropped. [[User:Hobbes|Hobbes]] 06:31, 2 November 2009 (EST)

Is there a reason for the (Apocalypse) suffix at the end of Apocalypse page names? I mean, there aren't any Queenspawns, Skeletoids or Psimorphs in the other X-COM games so there should be no confusion figuring out which game they belong to (even less confusion if they are listed in the Apocalypse section template). I thought our agreed-upon standard was to only use a suffix if the page could be disambiguous (for example: [[Medi-Kit]] and [[Medi-Kit (TFTD)]], and in this case the UFO variant of the Medi-Kit takes precedence and doesn't require a (UFO) suffix). So before we go all crazy adding pages with the (Apocalypse) suffix let's please agree upon a standard to use. ;) --[[User:Zombie|Zombie]] 22:22, 13 November 2009 (EST)

: Good idea :). First my apologies because I assumed that there wasn't an already existing standard published elsewhere on the wiki. I decided to start following the -suffix rule because it makes it easier to categorize pages and know which categories they belong and when I started to make categories common to all the games it looked to me to be an easier way to figure out which game they belong to. I think it makes it easier for people who aren't familiar with all the games to know where they belong. The downside of it is that it can increase the work in linking pages but you can always use the older links since they should be all redirects.
: Another argument I'd make is that I feel that UFO shouldn't have such a primacy over all the other games in the series, which happens using the current standard. To me UFO is the best game but Apocalypse is a clear second and it was the first I played. Using the suffixes for all the pages makes out that X-COM is a series of games, not just one centered on the first game (which happens to be the best one).
: That's basically my reasons. But I'm open to any standard, and I like this discussion because I want to start categorizing the entire site and it's better to do it using a system agreed by everyone. :) [[User:Hobbes|Hobbes]] 23:04, 13 November 2009 (EST)

No need to apologize for anything. I recall a discussion somewhere on this site (a long time ago as well) where we tried to hash out how to handle stuff like this but don't remember where it was. The only reason why we didn't decide on using a suffix for UFO was only because it was the first game in the series, not because it was more important or popular. But looking at how the wikipedia handles disambiguation we should really have a general Medi-Kit disambiguation page and then ask the user to click on the game specific Medi-Kit page - thus requiring a suffix (for example <i>Medi-Kit (UFO)</i> and <i>Medi-Kit (TFTD)</i>).

I agree 100% that if you have a page name which could be common to more than one game (for example Aliens or Alien Life Forms) that a suffix is crucial to distinguish between them. I'm only worried about obvious game-specific pages which shouldn't require one and all the extra redirects which only serve to tax the server. A person looking for information on the Popper isn't going to explicitly search for "Popper (Apocalypse)", they will search for just "Popper". And it seems to me that if someone knows what a Popper is, they will automatically know which game it belongs to. Maybe not though. Perhaps each page should have an introduction (or badge or box cover art) indicating what game it is about. For instance, we could start out the Popper page by saying "The Popper is another extremely dangerous unit found in Apocalypse". That way if a person is searching for something and lands on that page they will know what game it belongs to just by reading the first sentence. Or if we like the badge or the box cover art idea more, we could simply add that image at the start of a page. Another idea along these lines is a template containing the image. Add that to all Apocalypse pages and you will have basically categorized the entire game simply by searching for which games contain that template.

If none of these are appropriate, we could just create a template navigation bar at the bottom of like pages. I can see this being really helpful in Apocalypse where there are a lot more things which can be categorized. ;) --[[User:Zombie|Zombie]] 01:05, 14 November 2009 (EST)
: The scope of categorization really applies to all other games, since there are a lot of specific categories that can be added (UFO probably has even more categories than Apoc due to its number of pages). The templates navigation bar are really helpful in looking for related pages but categorization is a way to internally organize the pages and make it easier to identify and create internal links to pages. I don't know how much redirects tax the server but if the links have been updated and there are the relevant ones on the pages along with template navbars then most of the information can be found using the links with the prefix them instead of having to type the term on the search box (and would also mean less work for the server to process search requests?). And it is fairly easy to update the links. [[User:Hobbes|Hobbes]] 01:32, 14 November 2009 (EST)

From my perspective, I don't see too much of a problem with giving the Apocalypse pages its own suffix. Searches for Popper will jump you right to the Popper (Apocalypse) page - the search will match up with the first part of the article name just fine. The real work is for us editors who have to do a bit of double handling with the wikilink creation, but otherwise there's not going to be a lot of work for the casual browser looking for information.

UFO and TFTD on the other hand are a slightly different kettle of fish. UFO was the core material for the site and has had the most focus so far. TFTD shares a lot of the general information that is in UFO, and it needed the TFTD suffix to disambiguate its specific brand of pages that clashed with UFO. Back then, the scope was rather narrow.

Now that we've got other titles like Apocalypse and UFO2000 getting more content (and I'm hoping Interceptor and Enforcer might eventually get some attention), our scope is expanding. UFO/TFTD can remain as they are, but we may need to start handling the other sections differently. Of course, we could just do what we've always done and only disambiguate the pages as necessary.

I guess it can't hurt to go either way as long as we don't end up with a lot of duplicate pages with conflicting information. -[[User:NKF|NKF]] 02:14, 14 November 2009 (EST)

: I'm OK with either direction. Using the suffix immediately identifies the page with one of the games but that can be done as well by using Zombie's suggestion of having an image or some other template. Also, the more I look into the categories lists for Apocalypse the more it strikes me that the pages names with the suffix probably have too much visual clutter. Another thing that we should decide is the suffix for EU/UFO, not be used on the page names but on the categories. [[User:Hobbes|Hobbes]] 09:46, 14 November 2009 (EST)

:: Just found out the original discussion regarding suffixes on [[Talk:X-COM]] page. Essentially we are picking up the points left unanswered in that discussion since now Apocalypse sections have expanded. I propose keeping the pages without suffixes, except in the cases the names are the sames throughout the series (Battlescape, UFO, Research, etc.). In those cases a disambiguation page should be created. And regarding UFO/EU when names are shared throughout the series they get a suffix as well as the other games. Concerning categories they all have the suffix: as it is we all might know that <nowiki>[[Category: Facilities]]</nowiki> refers to facilities on the first game but for others that might not be so clear. (TFTD) and (Apocalypse) seem to be consentual, the main question is the first game. If we keep it an abreviation as TFTD then the logical choice would be (UFO:EU) or even just (EU) to simplify, using the name as it was first released.
:: Another thing related with the name for UFO:EU is that we should set the [[X-COM]] page on its own, describing the series and not having it as a redirect to UFO:EU. Whatever name we choose for the category regarding the first game it should also be the name for the page with the table containing all information about the first game. [[User:Hobbes|Hobbes]] 16:04, 14 November 2009 (EST)

A little off subject, but thanks for all the work on the wiki, Hobbes. I was dissappointed when I got a craving to play Apocalypse and saw how little info was available, after spending so much time in the information rich UFO Defense wiki. I will try to help you a little here and there, and if there is anything in particular you could use help with, send me a message. [[User:Talon81|Talon81]] 15:08, 19 November 2009 (EST)

Talk:Biochemistry

2009-11-19T19:00:43Z

Talon81: keep forgetting my tildes

Talk:Biochemistry

2009-11-19T19:00:17Z

Talon81:

Talk:Biochemistry

2009-11-19T04:30:37Z

Talon81:

Talk:Biochemistry

2009-11-19T04:30:04Z

Talon81: New page: it seems to me that the values under "cost" are WAY off. First off, I am making the assumption that by cost we mean "skill hours" and not financial cost. Some of them could be simply mista...

Biochemistry

2009-11-18T07:50:26Z

Talon81: /* Suggested Research Path */

Biochemistry is the study of bio (life) and chem (the interactions of matter and energy). So this is the study of living organisms, pretty much, and their intended functions. I think. Anyway, this category can study a few items. Some are pretty neat, most are hit-you-over-the-head-why-did-I-have-to-do-this kind of thing. Toxins and weapons are cool, but I don't like to use them unless they have infinite ammo, which usually falls under the category of Quantum Physics.

(Note that aliens must each be researched twice, once each for their living and dead states).

{| class="wikitable sortable" border="1"
! Topic !! Research Cost !! Required Bio-lab !! Type !! Direct Prerequisites !! Research Directly Requiring
|-
|[[Anthropod (Apocalypse)|Anthropod]] || 10,000/15,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Brainsucker]] || 7,000/12,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Multiworm (Apocalypse)|Multiworm]] || 90,000/15,000 || Standard ||Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat; The Alien Genetic Structure; The Alien Life Cycle
|-
|[[Multiworm Egg (Apocalypse)|Multiworm Egg]] || 80,000/12,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat; The Alien Genetic Structure
|-
|[[Hyperworm (Apocalypse)|Hyperworm]] || 70,000/15,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat; The Alien Genetic Structure; The Alien Life Cycle
|-
|[[Chrysalis (Apocalypse)|Chrysalis]] || 10,000/15,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat; The Alien Life Cycle
|-
|[[Skeletoid (Apocalypse)|Skeletoid]] || 12,000/18,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Micronoid Aggregate (Apocalypse)|Micronoid Aggregate]] || 20,000/26,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Popper (Apocalypse)|Popper]] || 6,000/9,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Spitter (Apocalypse)|Spitter]] || 8,000/12,000 || Standard || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Megaspawn (Apocalypse)|Megaspawn]] || 16,000/22,000 || Advanced || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Psimorph (Apocalypse)|Psimorph]] || 10,000/15,000 || Advanced || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; The Real Alien Threat
|-
|[[Queenspawn (Apocalypse)|Queenspawn]] || 26,000/32,000 || Advanced || Autopsy/Creature || Recovered Corpse/Creature || Advanced Biochemistry Lab; Alien Gas
|-
|[[Overspawn (Apocalypse)|Overspawn]] || 20,000 || Advanced || Autopsy || Recovered Corpse || The Real Alien Threat
|-
|[[The Alien Genetic Structure (Apocalypse)|The Alien Genetic Structure]] || 30,000 || Advanced || Concept || Multiworm Egg Autopsy; Multiworm Autopsy; Hyperworm Autopsy || Biological Warfare
|-
|[[The Alien Life Cycle (Apocalypse)|The Alien Life Cycle]] || 35,000 || Standard || Concept || Multiworm; Multiworm Autopsy; Hyperworm; Hyperworm Autopsy; Chrysalis; Chrysalis Autopsy || Toxin Type B
|-
|[[The Real Alien Threat (Apocalypse)|The Real Alien Threat]] || 45,000 || Standard || Concept || All aliens and autopsies except for Quenspawn and Queenspawn Autopsy || Toxin Type C
|-
|[[Biological Warfare (Apocalypse)|Biological Warfare]] || 26,000 || Advanced || Agent Equipment || The Alien Genetic Structure || Toxin Type B
|-
|[[Toxin B (Apocalypse)|Toxin B]] || 15,000 || Advanced || Agent Equipment || The Alien Life Cycle; Biological Warfare || Toxin Type C
|-
|[[Toxin C (Apocalypse)|Toxin C]] || 15,000 || Advanced || Agent Equipment || The Real Alien Threat; Toxin Type B || Alien Gas
|-
|[[Alien Gas (Apocalypse)|Alien Gas]] || 28,000 || Advanced || Agent Equipment || Queenspawn; Queenspawn Autopsy; Toxin Type C || None
|-
|[[Brainsucker Launcher]] || 8,000 || Standard || Agent Equipment || Recovered Equipment || None
|-
|[[Brainsucker Pod]] || 6,000 || Standard || Agent Equipment || Recovered Equipment || None
|-
|[[Entropy Launcher]] || 8,000 || Standard || Agent Equipment || Recovered Equipment || None
|-
|[[Entropy Pod]] || 5,000 || Standard || Agent Equipment || Recovered Equipment || None
|-
|[[Sleeping Chamber|Alien Building 1]] || 25,000 || Standard || Mission Type || The Alien Dimension || None
|-
|[[Food Chamber|Alien Building 2]] || 40,000 || Standard || Mission Type || Completed Sleeping Chamber Mission || None
|-
|[[Alien Farm|Alien Building 3]] || 25,000 || Standard || Mission Type || Completed Food Chamber Mission || None
|-
|[[Maintenance Factory|Alien Building 4]] || 25,000 || Standard || Mission Type || Completed Alien Farm Mission || None
|-
|[[Incubator Chamber|Alien Building 5]] || 25,000 || Standard || Mission Type || Completed Maintenance Factory Mission || None
|-
|[[Control Chamber|Alien Building 6]] || 35,000 || Standard || Mission Type || Completed Incubator Chamber Mission || None
|-
|[[Spawning Chamber|Alien Building 7]] || 25,000 || Standard || Mission Type || Completed Control Chamber Mission || None
|-
|[[Organic Factory|Alien Building 8]] || 25,000 || Standard || Mission Type || Completed Spawning Chamber Mission || None
|-
|[[Megapod Chamber|Alien Building 9]] || 40,000 || Standard || Mission Type || Completed Organic Factory Mission || None
|-
|[[Dimension Gate Generator|Alien Building 10]] || 35,000 || Standard || Mission Type || Completed Megapod Chamber Mission || None
|-
|[[Bio-Transport Module (Apocalypse)|Bio-Transport Module]] || 35,000 || Standard || Vehicle Equipment || None || None
|-
|[[Advanced Biochemistry Lab (Apocalypse)|Advanced Biochemistry Lab]] || 35,000 || Standard || Base Facility || Any Live Alien Or Autopsy Except for Overspawn Autopsy || None
|}

==Suggested Research Path==
Biochemistry research is extremely important in the early part of the game. After your Bio-Transport Module is researched and manufactured, you should be bringing bunches of live aliens back from missions. (You <i>are</i> using lots of [[Megapol Stun Grenade |Stun Grenades]], right?) Your ultimate goal is [[Toxigun |Toxiguns]] and Toxin-B, which can kill most aliens in two or three shots, have a high rate of fire, and ignore shields.

Your research should ideally follow roughly this order:

* Multiworm (or Autopsy)
* Advanced Biochemistry Lab. Begin construction (ideally at your second base) as soon as research completes.
* Multiworm Autopsy (or Live)
* Hyperworm
* Hyperworm Autopsy
* Chrysalis
* Chrysalis Autopsy
* Multiworm Egg
* Multiworm Egg Autopsy

By the time your Advanced Lab is complete, your biochemists should be finished with the above projects, unless they are horrible. After the above are complete, research the following in order:

* The Alien Genetic Structure
* The Alien Life Cycle
* Biological Warfare (Upon completion, begin building Toxiguns, but NOT Toxin A clips)
* Toxin B

From here, you ideally capture and research an example of every alien in the game alive and dead. They can be researched in any order, at which point you may research The Real Alien Threat, prerequisite to Toxin C - which makes Toxiguns the best general-purpose weapon in the game if you have the resources to keep up with producing the clips.

==See Also==
* [[Apocalypse]]
* [[Alien Life Forms (Apocalypse)|Alien Life Forms]]
* [[Toxigun]]
* [[The Real Alien Threat]]

[[Category: Apocalypse]]
[[Category: Research (Apocalypse)]]

[[Category: Bases (Apocalypse)]]

Hoverbike (Apocalypse)

2009-11-17T08:02:11Z

Talon81:

[[Image:Apoc_hoverbike_large.png|right]]

The hoverbike is the cheapest form of air travel and a classic favourite. It's cheap, convenient, fast and has a breakneck turning speed. Unfortunately, it also blows up very easily if hit too hard, but it is able to dodge incoming fire easily because of it's small size and agility. It sports a small weapon hardpoint that can mount a weapon as heavy as the [[Lineage Plasma Cannon (Apocalypse)|Lineage Plasma Cannon]] or the one-shot [[Justice Missile Launcher (Apocalypse)|Justice missile launcher]]. It also has a dedicated slot for a small [[Cyberweb]] [[Light Weapons Control (Apocalypse)|weapon control module]]. Two agents can ride the bike, but it's more efficient when utilised as an unmanned combat vehicle rather than as a light transport to and from combat sites. Best utilised in small hoverbike fleets except against ships with efficient anti-air weaponry or technology. (i.e. the [[Disruptor Multi-Bomb Launcher (Apocalypse)|Multibomb Launcher]])

'''''Official Entry:''''' "The unusual Hoverbike with 'side car' is used for military purposes or for the personal pleasure of wayward youth who enjoy speed and altitude. Its good power to weight ratio means that this is the most maneuverable air vehicle but it can only carry light armaments. The Hoverbike can be a valuable means of transport for the Agent on investigative missions where speed of response is essential."

==See Also==
* [[Marsec]]

{{Vehicles (Apocalypse) Navbar}}

[[Category: Apocalypse]]
[[Category: Craft]]

Talk:Ground Vehicles (Apocalypse)

2009-11-12T08:37:48Z

Talon81:

==Craft Icons==

Can't make my mind regarding the icons for the Craft, if it's better how it is right now or the older version with the grey box around them. I've used both for [[Organizations]]. Any suggestions? [[User:Hobbes|Hobbes]] 12:05, 1 November 2009 (EST)

My opinion... gray boxes. [[User:Talon81|Talon81]] 03:37, 12 November 2009 (EST)

Trade (Apocalypse)

2009-10-21T00:22:50Z

Talon81: /* Effect of Relations on Trade */ grammatical

===The Equipment Market===
This section will describe the ins and outs of purchasing equipment and its wider economical effect within Apocalypse.

==General==
Equipment is one of the most important features of Apocalypse; sending an un-equipped agent into combat is suicide, whereas having the right equipment can see you winning battles against the odds. A variety of Organisations within the cityscape are willing to sell you weapons, armour, armaments and various enhancements for your army of agents or your fleet of craft. Their willingness to trade with you, however, depends on your actions throughout the game.

==Effect of Relations on Trade==
Various Organisations within Apocalypse are responsible for the manufacture and retail of numerous pieces of equipment. Your relationship with these organisations determines the availability of these items. If relations with a particular organisation are unfriendly, your supply of the items they produce will be reduced- if you aren't cut-off completely.

To prevent this from happening, avoid raiding structures belonging to any company that provides items you need. Common examples are Megapol and Marsec. Also, when tending to Infestations, try not to cause too much collateral damage as this will affect relations with the owners of the building. It may be a good idea to leave your HE equipment at home.

==Supply & Demand==
The market in Apocalypse changes with the level of demand for each item. In practice, this means that if you buy all the available ammo for a particular weapon one week, its price will rise the next. If you do not purchase the same item for a week after, the price will drop. If you sell a lot of the item, the price will drop even more. (Though you wouldn't want to do this simply to drop the price.)

Note that the prices of items will not fall below certain levels, accurately reflectiong minimum cost of production. These levels depend on the item in question.

When selling items that you have manufactured in your workshops, the same principle applies. If you sell lots of one item in one week its value will drop, sometimes instantly. Manufactured items regain thier value more slowly than other items, especially if they are commercially available from another company, such as cargo modules. However, you can manipulate the price by buying up anything on the open market.

Trade (Apocalypse)

2009-10-21T00:20:54Z

Talon81: /* Effect of Relations on Trade */ spelling

===The Equipment Market===
This section will describe the ins and outs of purchasing equipment and its wider economical effect within Apocalypse.

==General==
Equipment is one of the most important features of Apocalypse; sending an un-equipped agent into combat is suicide, whereas having the right equipment can see you winning battles against the odds. A variety of Organisations within the cityscape are willing to sell you weapons, armour, armaments and various enhancements for your army of agents or your fleet of craft. Their willingness to trade with you, however, depends on your actions throughout the game.

==Effect of Relations on Trade==
Various Organisations within Apocalypse are responsible for the manufacture and retail of numerous pieces of equipment. Your relationship with these organisations determines the availability of these items. If relations with a particular organisation are unfriendly, your supply of the items they produce will be reduced-if you aren't cut-off completely.

To prevent this from happening, avoid raiding structures belonging to any company that provides items you need. Common examples are Megapol and Marsec. Also when attending Infestations, try not to cause too much collateral damage as this will affect relations with the owners of the building. It may be a good idea to leave your HE equipment at home.

==Supply & Demand==
The market in Apocalypse changes with the level of demand for each item. In practice, this means that if you buy all the available ammo for a particular weapon one week, its price will rise the next. If you do not purchase the same item for a week after, the price will drop. If you sell a lot of the item, the price will drop even more. (Though you wouldn't want to do this simply to drop the price.)

Note that the prices of items will not fall below certain levels, accurately reflectiong minimum cost of production. These levels depend on the item in question.

When selling items that you have manufactured in your workshops, the same principle applies. If you sell lots of one item in one week its value will drop, sometimes instantly. Manufactured items regain thier value more slowly than other items, especially if they are commercially available from another company, such as cargo modules. However, you can manipulate the price by buying up anything on the open market.

Trade (Apocalypse)

2009-10-21T00:19:46Z

Talon81: spelling error

===The Equipment Market===
This section will describe the ins and outs of purchasing equipment and its wider economical effect within Apocalypse.

==General==
Equipment is one of the most important features of Apocalypse; sending an un-equipped agent into combat is suicide, whereas having the right equipment can see you winning battles against the odds. A variety of Organisations within the cityscape are willing to sell you weapons, armour, armaments and various enhancements for your army of agents or your fleet of craft. Their willingness to trade with you, however, depends on your actions throughout the game.

==Effect of Relations on Trade==
Various Organisations within Apocalypse are responsible for the manufacture and retail of numerous pieces of equipment. Your relationship with these organisations determines the avilability of these items. If relations with a particular organisation are unfriendly, your supply of the items they produce will be reduced-if you aren't cut-off completely.

To prevent this from happening, avoid raiding structures belonging to any company that provides items you need. Common examples are Megapol and Marsec. Also when attending Infestations, try not to cause too much collateral damage as this will affect relations with the owners of the building. It may be a good idea to leave your HE equipment at home.

==Supply & Demand==
The market in Apocalypse changes with the level of demand for each item. In practice, this means that if you buy all the available ammo for a particular weapon one week, its price will rise the next. If you do not purchase the same item for a week after, the price will drop. If you sell a lot of the item, the price will drop even more. (Though you wouldn't want to do this simply to drop the price.)

Note that the prices of items will not fall below certain levels, accurately reflectiong minimum cost of production. These levels depend on the item in question.

When selling items that you have manufactured in your workshops, the same principle applies. If you sell lots of one item in one week its value will drop, sometimes instantly. Manufactured items regain thier value more slowly than other items, especially if they are commercially available from another company, such as cargo modules. However, you can manipulate the price by buying up anything on the open market.

Mega-Primus

2009-10-20T20:58:25Z

Talon81: spelling error

= A Tourist's Guide To Mega Primus =

Our Greetings to you, Visitor:

The City which you are about to enter, Mega Primus, is the primary Bastion of Mankind after emerging victorious from three seemingly hopeless wars against a despicable race of gene-manipulating, sinister Alien Empire. Yet hope survives, and mercy flourishes in its wake as well. We have extended our mercy and friendship to those who chose to side with us, and as you see, you will encounter these integrated citizens resembling Sectoids of the First Alien War.

The city features the finest technology and comfort throughout the Sol System, salvaged from the ancient Alien Empire who also seems to have begotten Our species, and the treacherous alien pirates who misused and looted their ruins to wage war on Us. The result is that We are finally sitting on the zenith of our history, seeing the entire contents of Our mysterious past in the blink of an eye. We travel around floating on the efficient and safe People Tubes. With the courtesy of the Transtellar corporation, who profit profoundly from the bountiful trading routes of our home, we revel in our Nanotechnological luxuries and Sensovision, students let school information flow into their minds freely and without effort, all adapted from the psychic coding and nanotech-construction technology of our enemies, we can even fly on hover vehicles we could not have dreamt of 40 years before! Obviously, Earth-born technology was insufficent to apply mass-hover project, so We justly claimed it from the filth who dared touch our blood and earth. And Our thanks go to the glorious soldiers of X-Com, men and women of legends unmatched even in Our dank and filthy Middle Ages. Men and Women who rose amongst the pile of skulls of the dead, Men and Women who carried the Illuminating light of Freedom, Justice and Equality to the masses, Enlightening Us through war, deceit, and heroism.

We do not wish to bore you with Our glorious history, as the Space Liner approaches the Space Port, and a massive Jungle of grass, glass and gleaming metal with its limitless bounties, pleasures and power awaits you.

Once again, Welcome!

The Thirteen Most Enlightened Senators of Mega-Primus of ''Novus Ordo Seclorum''

== Trade ==

Various Corporations have their industries in monopoly, and thus make humongous profits surpassing the power of the Government. Mega-Primus industry produces extremely high-quality products and exports them in high prices, whereas cheaply buying elerium from mining colonies of Mars, the Asteroid Belt and even the far-away Frontier, and exploiting them doubly by selling expensive materials, an Imperialist's finest dream-city.

== Firms, Companies, Collectives ==

Mega-Primus, formerly known as Toronto, is a completely self-sustaining, locked entity, and probably the only completely safe place on Earth in the wake of the destruction of T'leth. Nothing is wasted here. Every piece of scrap, every waste product is recycled and put back to good use. Of course, there is a trade with colonies on Mars and beyond, where Mega-Primus sells high quality goods in exchange for raw materials and Elerium.

Most of the city is maintained by various corporations and organizations. A good X-COM commander should familiarize himself with these entities, as they, unlike the general populace, are well aware of X-COM's presence in the city, and aren't held back by laws or moral obligations. It is possible to have both friends and foes among denizens of the city - but it is impossible to keep up good relations with everyone. However, all of them must be watched for signs of alien infiltration - and some are more susceptible to it than others.

Below is a list of these corporations, along with short descriptions and suggestions.

* Aliens

Not an organization per se, the new Alien threat to the city is vastly different from what we have faced before. They are once again technologically superior to us. They've been proven aggressive when their infiltration attempts were discovered, and as such X-COM is allowed to and is obligated to eliminate this new threat by any means neccessary.

* [[Cult of Sirius]]

A cult of Alien-worshipping freaks, these zealots have built up a surprisingly strong presence in the city. While the size and power of the Cult has apparently diminished since 2040s, they are still hostile to X-COM, and have reportedly amassed a small army, as well as a stockpile of top-notch weaponry in the city to assist their Alien "friends" in their nefarious deeds. Raiding their temples can both cripple their influence and provide X-COM with nice equipment.

* [[Cyberweb]]

The high-tech Cyberweb corporation provides the city with many artificial intelligence devices and systems. They do not manufacture outlawed androids, but provide control systems for various robots and automated services for the city.

* [[Diablo]]

A fanatical and violent gang with a base of operations in the slums outside the city limits. They've pioneered the use of crude yet efficient incendiary grenades, and are feuding with Psyke. Their trust is however easy to earn by attacking Psyke.

* [[Energen]]

Without the highly efficient fusion power plants and electricity infrastructure the city of Mega Primus would grind to quick, violent halt. Energen maintains and oversees these crucial facilities.

* [[Evonet]]

The cleaners of the city, Evonet is responsible for recycling and sewage treatment. The giant recyclotoriums are owned and run by Evonet. There is recycled material in everything in the city and without Evonet garbage and waste would be a serious problem. Evonet also produces foodstuffs from recycled materials.

* [[Extropians]]

The Extropian philosophy is basically a faith in a bright technological future - a brave new world free of disease, pollution, old age and dull aesthetics. They pioneered the city regulations governing the future-retro styling of the architecture and vehicles. They have strong support from Solmine, Marsec and the larger corporations.

* [[General Metro]]

General Metro is the manufacturer of the engines for city's road vehicles, as well as Fusion PowerFuel. Obviously, it's a good idea to have them as friends, else your mighty fleets will turn into scrap metal.

* [[Government]]

While it may seem somewhat odd and shadowy to us, the Government is still the highest authority in the city. Protecting it from Alien inflitration and attacks is a top priority for us. The Government maintains hope that X-COM will be able to deal with the alien threat quietly and before the next election, and as such given it powers comparable to that of Megapol. However, abusing those powers is highly unrecommended, as Government will also be X-COM's primary sponsor - and any questionable actions will reduce the size of that paycheck at the end of the week.

* [[Grav Ball League]]

The fast-paced, highly exiting Grav Ball game and stadiums are run by Grav Ball League. A favourite past-time of many citizens, Grav Ball League has a lucrative deal with Sensovision who broadcast games to those citizens, who are too busy to or otherwise cannot attend live events.

* [[Lifetree]]

Highly efficient psionic methods used in education of young citizens is handled by Lifetree. Schools and universities of Lifetree keep the citizens educated and civilized later in life.

* [[Marsec]]

A megacorporation that stretches from Earth to the Frontier, MARs SECurity is a powerful manufacturer of the best of today's military equipment. Although they have some competition in the inferior-but-cheaper Megapol products, Marsec still outweighs its competitor by holding virtual monopoly on powerful combat vehicles, plasma, psionic and heavy weaponry, as well as Elerium-powered flying armor. It is a very bad idea to mess with Marsec.

* [[Megapol]]

MEGA-Primus POLice is more than just a security force. It is also a goverment-sponsored arms manufacturer. Megapol makes its own equipment and vehicles, and sustains itself by exporting some of it. Megapol has its hands full with the rampant crime syndicates in the city, and as such is able to provide only token support to X-COM, however Megapol patrol vehicles won't hesitate to assist X-COM in dealing with the alien ships. Megapol's market presence includes laser weaponry, heavy body armor, grenades and small arms. Megapol stations are extremely well-defended and the police troops are well-trained and heavily armed, so getting into their bad books will probably be mean the end of X-COM.

* [[Mutant Alliance]]

A semi-legal political entity that is fighting against the prejudice against the human/sectoid hybrids, relics from the First Alien War. Supporting the Mutant Alliance can bring X-COM psionically gifted recruits.

* [[Nanotech]]

Specializing in nanotechnology, the medical and pharmaceutical industries rely on Nanotech for many products. If you are ever treated with a first-aid kit ( or given any medical attention ) you can thank Nanotech.

* [[Nutrivend]]

A key food supplier, Nutrivend manages the efficient hydroponic farms, food processing plants and shops of the city and keeps all citizens well-fed.

* [[Osiron]]

The wealthiest crime syndicate in the city, Osiron is something in between a gang and a legitimate corporation. Osiron is significantly better equipped and organized than other criminal organizations, and can be a formidable opponent.

* [[Psyke]]

A declining criminal gang, Psyke is still a major thorn in Government's side due to their development of illegal, addictive and highly dangerous Psiclone implant. They are at constant war with Diablo, and attacking one will win you friendship of another. And you didn't see it here, but psiclones are worth quite a lot on the black market...

* [[S.E.L.F.]]

The Sentient Engine Liberation Front is a political entity, much alike to the Mutant Alliance, which fights for the rights of the outlawed androids. Androids can be highly efficient shock troops, so good relations with S.E.L.F. are a huge bonus.

* [[Sanctuary Clinic]]

Hospitals, pharmaceutical plants and the procreation parks are run by Sanctuary Clinic. Longeviety, health and procreation is on their shoulders and without these crucial services the city wouldn't last long.

* [[Sensovision]]

The entertainment industry entered a new phase with the advent of Psionic projectors. Actors connected to Psionic sensors can record their thoughts and experiences in any environment. The recorded patterns are edited into 'Sensovision'experiences and replayed at 'Sensodromes' where many people can connect to Psionic receivers. The receiver allows people to see, hear, feel and smell what the actor experienced. Sensoviosion actors are wealthy celebrities and the Sensovision corporation is now selling the expensive receiver sets into peoples homes. The only competition comes from the addictive and illegal Psionic implant known as Psiclone, which is supplied by Psyke.

* [[Solmine]]

Off-planet mining operations are conducted by Solmine and the prized Elerium-115 not found on Earth is their main product. Solmine and Marsec work closely together to ensure the security of the mining colonies.

* [[Superdynamics]]

Superdynamics is an engine manufacturer, specializing in engines for flyers. Since flyers get to see most of the action, it would be wise to outfit them with the best stuff there is - a reason enough to try to keep Superdynamics friendly.

* [[Synthemesh]]

Synthemesh employs many designers to keep generating the latest fashions which fuel consumer demand. The manufacturing plants produce mostly consumer durables, but the corporation also controls a fleet of construction vehicles which are used to build or repair the city infrastructure.

* [[Technocrats]]

Politically the Technocrat philosophy is really no different to the Extropians, except they are a little less colorful and more skeptical of technological solutions to social problems. They believe in a structured and ordered society which rigidly adheres to laws and punishes corruption. They draw most support from the smaller corporations and the populations of the mining colonies.

* [[Transtellar]]

An interstellar shipping corporation. Don't let their space liners fool you - they also have the monopoly on all transport inside the city. Transtellar is very susceptible to Alien infiltration (according to Megapol), and is very nervous about any military activity in its borders. They are also VERY touchy about damage to the people tubes. You know, the ones that come crashing to the ground every time their is a battle in city limits. It will probably be the hardest corporation to keep happy, but not doing so can cripple X-COM's market activity - and that equals bankruptcy.

* [[X-Com (Apocalypse)|X-Com]]

That's us. A shadowy paramilitary organization that in the breaks between taking over the city should also try to chase off the aliens.

== Base Locations ==

The Government offers X-Com discreet locations such as abandoned warehouses and slums, and provided the base is in latter location, it is unlikely that the base is going to be attacked by Alien forces easily (Although the structural integrity of these badly undermaintained structures is very questionable).

The bases have preset corridors, and facilities can be constructed into these empty spaces, and it is forbidden to fund additional excavations.

When needed, the Government can be contacted to give an additional base, provided the funds are at your disposal.

The newest development in base facilities are base defenses: Security Stations, riddled with plasma turrets. A few of those at important chokepoints will be enough to cripple any assault on your base, Alien or human alike.

Mega-Primus

2009-10-20T20:14:28Z

Talon81: spelling error

= A Tourist's Guide To Mega Primus =

Our Greetings to you, Visitor:

The City which you are about to enter, Mega Primus, is the primary Bastion of Mankind after emerging victorious from three seemingly hopeless wars against a despicable race of gene-manipulating, sinister Alien Empire. Yet hope survives, and mercy flourishes in its wake as well. We have extended our mercy and friendship to those who chose to side with us, and as you see, you will encounter these integrated citizens resembling Sectoids of the First Alien War.

The city features the finest technology and comfort throughout the Sol System, salvaged from the ancient Alien Empire who also seems to have begotten Our species, and the treacherous alien pirates who misused and looted their ruins to wage war on Us. The result is that We are finally sitting on the zenith of our history, seeing the entire contents of Our mysterious past in the blink of an eye. We travel around floating on the efficient and safe People Tubes. With the courtesy of the Transtellar corporation, who profit profoundly from the bountiful trading routes of our home, we revel in our Nanotechnological luxuries and Sensovision, students let school information flow into their minds freely and without effort, all adapted from the psychic coding and nanotech-construction technology of our enemies, we can even fly on hover vehicles we could not have dreamt of 40 years before! Obviously, Earth-born technology was insufficent to apply mass-hover project, so We justly claimed it from the filth who dared touch our blood and earth. And Our thanks go to the glorious soldiers of X-Com, men and women of legends unmatched even in Our dank and filthy Middle Ages. Men and Women who rose amongst the pile of skulls of the dead, Men and Women who carried the Illuminating light of Freedom, Justice and Equality to the masses, Enlightening Us through war, deceit, and heroism.

We do not wish to bore you with Our glorious history, as the Space Liner approaches the Space Port, and a massive Jungle of grass, glass and gleaming metal with its limitless bounties, pleasures and power awaits you.

Once again, Welcome!

The Thirteen Most Enlightened Senators of Mega-Primus of ''Novus Ordo Seclorum''

== Trade ==

Various Corporations have their industries in monopoly, and thus make humongous profits surpassing the power of the Government. Mega-Primus industry produces extremely high-quality products and exports them in high prices, whereas cheaply buying elerium from mining colonies of Mars, the Asteroid Belt and even the far-away Frontier, and exploiting them doubly by selling expensive materials, an Imperialist's finest dream-city.

== Firms, Companies, Collectives ==

Mega-Primus, formerly known as Toronto, is a completely self-sustaining, locked entity, and probably the only completely safe place on Earth in the wake of the destruction of T'leth. Nothing is wasted here. Every piece of scrap, every waste product is recycled and put back to good use. Of course, there is a trade with colonies on Mars and beyond, where Mega-Primus sells high quality goods in exchange for raw materials and Elerium.

Most of the city is maintained by various corporations and organizations. A good X-COM commander should familiarize himself with these entities, as they, unlike the general populace, are well aware of X-COM's presence in the city, and aren't held back by laws or moral obligations. It is possible to have both friends and foes among denizens of the city - but it is impossible to keep up good relations with everyone. However, all of them must be watched for signs of alien infiltration - and some are more susceptible to it than others.

Below is a list of these corporations, along with short descriptions and suggestions.

* Aliens

Not an organization per se, the new Alien threat to the city is vastly different from what we have faced before. They are once again technologically superior to us. They've been proven aggressive when their infiltration attempts were discovered, and as such X-COM is allowed to and is obligated to eliminate this new threat by any means neccessary.

* [[Cult of Sirius]]

A cult of Alien-worshipping freaks, these zealots have built up a surprisingly strong presence in the city. While the size and power of the Cult has apparently diminished since 2040s, they are still hostile to X-COM, and have reportedly amassed a small army, as well as a stockpile of top-notch weaponry in the city to assist their Alien "friends" in their nefarious deeds. Raiding their temples can both cripple their influence and provide X-COM with nice equipment.

* [[Cyberweb]]

The high-tech Cyberweb corporation provides the city with many artificial intelligence devices and systems. They do not manufacture outlawed androids, but provide control systems for various robots and automated services for the city.

* [[Diablo]]

A fanatical and violent gang with a base of operations in the slums outside the city limits. They've pioneered the use of crude yet efficient incendiary grenades, and are feuding with Psyke. Their trust is however easy to earn by attacking Psyke.

* [[Energen]]

Without the highly efficient fusion power plants and electricity infrastructure the city of Mega Primus would grind to quick, violent halt. Energen maintains and oversees these crucial facilities.

* [[Evonet]]

The cleaners of the city, Evonet is responsible for recycling and sewage treatment. The giant recyclotoriums are owned and run by Evonet. There is recycled material in everything in the city and without Evonet garbage and waste would be a serious problem. Evonet also produces foodstuffs from recycled materials.

* [[Extropians]]

The Extropian philosophy is basically a faith in a bright technological future - a brave new world free of disease, pollution, old age and dull aesthetics. They pioneered the city regulations governing the future-retro styling of the architecture and vehicles. They have strong support from Solmine, Marsec and the larger corporations.

* [[General Metro]]

General Metro is the manufacturer of the engines for city's road vehicles, as well as Fusion PowerFuel. Obviously, it's a good idea to have them as friends, else your mighty fleets will turn into scrap metal.

* [[Government]]

While it may seem somewhat odd and shadowy to us, the Government is still the highest authority in the city. Protecting it from Alien inflitration and attacks is a top priority for us. The Government maintains hope that X-COM will be able to deal with the alien threat quietly and before the next election, and as such given it powers comparable to that of Megapol. However, abusing those powers is highly unrecommended, as Government will also be X-COM's primary sponsor - and any questionable actions will reduce the size of that paycheck at the end of the week.

* [[Grav Ball League]]

The fast-paced, highly exiting Grav Ball game and stadiums are run by Grav Ball League. A favourite past-time of many citizens, Grav Ball League has a lucrative deal with Sensovision who broadcast games to those citizens, who are too busy to or otherwise cannot attend live events.

* [[Lifetree]]

Highly efficient psionic methods used in education of young citizens is handled by Lifetree. Schools and universities of Lifetree keep the citizens educated and civilized later in life.

* [[Marsec]]

A megacorporation that stretches from Earth to the Frontier, MARs SECurity is a powerful manufacturer of the best of today's military equipment. Although they have some competition in the inferior-but-cheaper Megapol products, Marsec still outweighs its competitor by holding virtual monopoly on powerful combat vehicles, plasma, psionic and heavy weaponry, as well as Elerium-powered flying armor. It is a very bad idea to mess with Marsec.

* [[Megapol]]

MEGA-Primus POLice is more than just a security force. It is also a goverment-sponsored arms manufacturer. Megapol makes its own equipment and vehicles, and sustains itself by exporting some of it. Megapol has its hands full with the rampant crime syndicates in the city, and as such is able to provide only token support to X-COM, however Megapol patrol vehicles won't hesitate to assist X-COM in dealing with the alien ships. Megapol's market presence includes laser weaponry, heavy body armor, grenades and small arms. Megapol stations are extremely well-defended and the police troops are well-trained and heavily armed, so getting into their bad books will probably be mean the end of X-COM.

* [[Mutant Alliance]]

A semi-legal political entity that is fighting against the prejudice against the human/sectoid hybrids, relics from the First Alien War. Supporting the Mutant Alliance can bring X-COM psionically gifted recruits.

* [[Nanotech]]

Specializing in nanotechnology, the medical and pharmaceutical industries rely on Nanotech for many products. If you are ever treated with a first-aid kit ( or given any medical attention ) you can thank Nanotech.

* [[Nutrivend]]

A key food supplier, Nutrivend manages the efficient hydroponic farms, food processing plants and shops of the city and keeps all citizens well-fed.

* [[Osiron]]

The wealthiest crime syndicate in the city, Osiron is something in between a gang and a legitimate corporation. Osiron is significantly better equipped and organized that other criminal organizations, and can be a formidable opponent.

* [[Psyke]]

A declining criminal gang, Psyke is still a major thorn in Government's side due to their development of illegal, addictive and highly dangerous Psiclone implant. They are at constant war with Diablo, and attacking one will win you friendship of another. And you didn't see it here, but psiclones are worth quite a lot on the black market...

* [[S.E.L.F.]]

The Sentient Engine Liberation Front is a political entity, much alike to the Mutant Alliance, which fights for the rights of the outlawed androids. Androids can be highly efficient shock troops, so good relations with S.E.L.F. are a huge bonus.

* [[Sanctuary Clinic]]

Hospitals, pharmaceutical plants and the procreation parks are run by Sanctuary Clinic. Longeviety, health and procreation is on their shoulders and without these crucial services the city wouldn't last long.

* [[Sensovision]]

The entertainment industry entered a new phase with the advent of Psionic projectors. Actors connected to Psionic sensors can record their thoughts and experiences in any environment. The recorded patterns are edited into 'Sensovision'experiences and replayed at 'Sensodromes' where many people can connect to Psionic receivers. The receiver allows people to see, hear, feel and smell what the actor experienced. Sensoviosion actors are wealthy celebrities and the Sensovision corporation is now selling the expensive receiver sets into peoples homes. The only competition comes from the addictive and illegal Psionic implant known as Psiclone, which is supplied by Psyke.

* [[Solmine]]

Off-planet mining operations are conducted by Solmine and the prized Elerium-115 not found on Earth is their main product. Solmine and Marsec work closely together to ensure the security of the mining colonies.

* [[Superdynamics]]

Superdynamics is an engine manufacturer, specializing in engines for flyers. Since flyers get to see most of the action, it would be wise to outfit them with the best stuff there is - a reason enough to try to keep Superdynamics friendly.

* [[Synthemesh]]

Synthemesh employs many designers to keep generating the latest fashions which fuel consumer demand. The manufacturing plants produce mostly consumer durables, but the corporation also controls a fleet of construction vehicles which are used to build or repair the city infrastructure.

* [[Technocrats]]

Politically the Technocrat philosophy is really no different to the Extropians, except they are a little less colorful and more skeptical of technological solutions to social problems. They believe in a structured and ordered society which rigidly adheres to laws and punishes corruption. They draw most support from the smaller corporations and the populations of the mining colonies.

* [[Transtellar]]

An interstellar shipping corporation. Don't let their space liners fool you - they also have the monopoly on all transport inside the city. Transtellar is very susceptible to Alien infiltration (according to Megapol), and is very nervous about any military activity in its borders. They are also VERY touchy about damage to the people tubes. You know, the ones that come crashing to the ground every time their is a battle in city limits. It will probably be the hardest corporation to keep happy, but not doing so can cripple X-COM's market activity - and that equals bankruptcy.

* [[X-Com (Apocalypse)|X-Com]]

That's us. A shadowy paramilitary organization that in the breaks between taking over the city should also try to chase off the aliens.

== Base Locations ==

The Government offers X-Com discreet locations such as abandoned warehouses and slums, and provided the base is in latter location, it is unlikely that the base is going to be attacked by Alien forces easily (Although the structural integrity of these badly undermaintained structures is very questionable).

The bases have preset corridors, and facilities can be constructed into these empty spaces, and it is forbidden to fund additional excavations.

When needed, the Government can be contacted to give an additional base, provided the funds are at your disposal.

The newest development in base facilities are base defenses: Security Stations, riddled with plasma turrets. A few of those at important chokepoints will be enough to cripple any assault on your base, Alien or human alike.

User talk:Seb76

2009-05-22T21:19:57Z

Talon81: /* Keyboard Support */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)
:Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J'ordos]] 12:58, 26 April 2009 (EDT)
::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Replace the batch file that runs xcomutil. Make it so the loader will call an outside program at certian points. Add a section to the config file that will allow the user to pick a program to be run.
[Utilities]
Run Utilities=0|1
Run before battle="xcomutil ..."
Run after battle ="xcomutil ..."
Run before base screen="xcomutil ..."

* Allow scrolling the map with the keyboard. "WASD" as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.

* Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.

* Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

Well, since it has been a little while now, and nobody has said anything, let me be the first. Thank you for the shortcuts on the geoscape. As I mentioned before, I had the shortcuts on battlescape on, but personally I never used them because it is not timed. But the geoscape, being that there is no pause, I have found a lot of use in shortcuts. Works perfectly for me, too. Secondly, the obdata editing feature is fantastic. If only it worked on accuracy, too....
Thanks again, my friend. --[[User:Talon81|Talon81]] 17:19, 22 May 2009 (EDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

<i>Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)</i>

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

== Initial Alien Bases ==

OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)

By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)
:Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)

Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)

:OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)

Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)

== Won't work on my rig Vista+CE version ==

Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.

My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.

* http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG
* http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG
--[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)
:Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):

[[Image:Dxwnd.png]]

[[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)

Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?

http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)

[edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.

:I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:
:[[Image:Scale2x.png]]

:When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)

::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?
:I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)
:Edit: version updated with support for HQ4x (in 1280x800). Feedback appreciated... [[User:Seb76|Seb76]] 09:55, 3 May 2009 (EDT)

The above version works perfectly on my PC but only through DXWmd. I'd also like to note that using DXWnd eliminates fast speed issues in Battlescape for some reason. I'm really excited Seb is pulling this off. <3
:Uploaded a new version, you need to add a "HQ4x=1" line under the "Mod" section to enable it. [[User:Seb76|Seb76]] 15:36, 6 May 2009 (EDT)

Works perfect without the use of DXWnd, but there's some sort of frameskip feeling. Great work, this is getting better and better. :-)

==Heavy laser mod==
My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction. [[User:SaintD:SaintD]]

:Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)
:Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)

::I tried it. The new modes now work, but Snap Mode is still missing from my HL. Also it's not clear the difference between burst and full auto since they both have the same accuracy and TU cost.--[[User:SaintD|SaintD]] 19:25, 29 April 2009 (EDT)

::: Hmmm, on mine the burst and full auto have different accuracies (80% and 60%, respectively); and they fire 5 and 8 rounds, also respectively. I believe the snap shot was taken out on purpose to coincide with the idea of the heavy laser as being more suited to being a support weapon. Of course the last part is conjecture on my part, but I am pretty certain it is not supposed to be there. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)

I am not the original poster in this heading, and I have not had the same problems with the heavy laser that others had (only one I had was about the Range Based Acc not affecting full auto), so I cannot confirm whether this patch has solved that. But I will tell you what you probably already know: everything is fuzzy, kinda like [ Mok's 2xSaI]. It is also a little bit jumpy. Due to that, I can't take advantage of the Funky Fire fix, or any other future fix, unless I am willing to deal with the fuzziness, or unless you create 2 runs; 1 with the Heavy Laser fix, and one without. --[[User:Talon81|Talon81]] 13:42, 28 April 2009 (EDT)
:Hum, I'm not sure I understand. What has the fuzziness to do with the HL fix? [[User:Seb76|Seb76]] 14:15, 28 April 2009 (EDT)

Wow, to think I almost didnt bother to post because I was sure you would already be aware of it. As soon as I updated your loader from 6 April (TFTD door fix) to 26 April (funky fire fix), everything got fuzzy. After that, I tried the update without funky fire (HL fix). Still fuzzy. Then I rolled back to the previous one (Initial Alien Base fix). No more fuzzy. I even went back to HL fix, then back again to Alien Base fix. Same deal. I will try using it on a fresh X-Com install without my other patches. But yeah, you should seriously install the patch I linked to in my above post. Will only take a minute to try. Looks VERY much like it (I know that many people have the fuzzy problem with that patch). --[[User:Talon81|Talon81]] 02:17, 29 April 2009 (EDT)

OK, it is indeed still fuzzy on a fresher copy of X-Com. It is not a genuine fresh install as I no longer have the disk, it is just the original files copied on my computer in another location. Furthermore, I forgot to mention there is also slight video garble (yes, even with the garble fix on) at the bottom of the menu screens. That in itself is not a problem as it is not throughout the game, and is only a few pixels in height. I can't wait to see if anyone else has these problems or if its just me. --[[User:Talon81|Talon81]] 02:27, 29 April 2009 (EDT)
:I have a crash with Mok's patch so I cannot check the problem. By fuzzy you mean something like the image is bilinearly filtered and all smoothed? [[User:Seb76|Seb76]] 17:20, 29 April 2009 (EDT)

I am a total programming/graphics newb, so I don't know if that is a good description or not. The UFO's for example, instead of being crosses, are blurbs that slightly change shape as they fly, and everything has softer transitions that make it look like it is done with pastels or something. I can tell you I tried to take a screen capture but it did not reflect the screen as it appears in game. In any case, unless other people have this same problem, I would not worry about it for my sake. If it is something you want to tackle anyway, just tell me what I can do to help you. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)
:Hum, are youe using the "dev" version instead of the official one? It features a scale2x filter that craps the image up.[[User:Seb76|Seb76]] 14:40, 30 April 2009 (EDT)

Not sure what you mean by "dev" version, but I am guessing you are referring to my version of CE. I do not know for sure, because it has been years since I got it, but I am guessing the answer is yes because mine runs in full screen without any mods. --[[User:Talon81|Talon81]] 12:22, 1 May 2009 (EDT)

Your newest version seems to have gotten rid of my problem. --[[User:Talon81|Talon81]] 12:32, 1 May 2009 (EDT)
:That's great ;-) By dev I was refering to the "dev" version of the loader linked on this page. It is an experimental version that uses scale2x with 640x400 resolution. [[User:Seb76|Seb76]] 12:53, 1 May 2009 (EDT)

User talk:Spike

2009-05-21T00:59:48Z

Talon81: /* Rocket Launcher Firepower Incorrect */

== Message Board ==

----

By any chance, have you taken another look at [[User talk:Bomb Bloke#Rated Accuracy Vs Angle Range |my talk page]] since your return?

Yes yes, I'm lazy and should really be able to interpret the data myself... But I can only really get as far as saying "that's not a linear distribution" and then my lack of understanding re what all the trig functions are for leaves me stranded. :/

- [[User:Bomb Bloke|Bomb Bloke]] 09:20, 10 April 2009 (EDT)

: Sorry what with starting a new job, moving, Easter, I've been a bit busy. Did you say you still had the original data? You sent me it in an Access database, is that right? It all seems a long time ago! [[User:Spike|Spike]] 16:28, 14 April 2009 (EDT)

I don't remember sending you the data specifically (I certainly haven't done so within the last year), but you can find it all linked on my talk page now. - [[User:Bomb Bloke|Bomb Bloke]] 22:31, 14 April 2009 (EDT)

== Apocalypse Blog QA ==

Uncle NKF to the rescue!

Don't ever unload troops at the mission site. To select which agents go into a mission, just highlight them before picking the attack or investigate button or click on the vehicle name to select them all. Get into this habit - always.

The reason why will become incredibly apparent if you play long enough to do an alien dimension building. The moment you complete the mission, the alien building will collapse and your ship will take off automatically (as per standard practice). However, the kicker is that you'll never be able to land at the building site again. This will result in forever stranding any troops that did not get killed by the building crashing down around them.

----

Alien's won't attack a dead body on purpose, though HE explosions caused by nearby combat will certainly destroy them. Watch where you are fighting. Also some enemies tend to pick up anything that's not bolted down, and may even carelessly wander towards one of the area exit pads. It happens - so be vigilant!

----

Dual-Wield does penalise your accuracy, and depending on some weapons, will slow you down considerably. The only reason to dual weild is as you say: to increase volume of fire. If you're like me and like close range combat (you'll find a lot of this in some buildings), then you want to get out as much firepower as you can because the enemy will have just as much of an advantage at such a close range as you do (and there's often more of them than you or they have one-hit big-bang weapons like the Poppers!). Out in the open, single weapons with aimed shots get better results - until you are so accurate that you don't even feel the penalty.

The game's super weapons are easy enough to be effective without dual-wielding as they're ramped up to be the best weapons available. In fact, most people make do with just one devestator or toxigun and cloak combo exclusively.

----

Apocalypse uses the volume of ''successful hits'' to determine accuracy improvements. The M4000 just gets lots of hits in, while the laser sniper rifle may hit a few times. By the way, aimed + dual M4000 garners more accuracy for a slightly slower fire rate than full-auto, allowing you to not waste as much ammo. Not as accurate as one M4000 on aimed or as fast as dual M4k's on full auto.

Plasma gun ammo is scarce at first, but you do have the option of attacking your enemies like the Cult of Sirius and win some off their fallen brethren. In fact, a lot of items that don't get released until a week or two in can be won off raiding enemy organizations. Better to get a good start than try to hobble along. I'd recommend <strike>stealing</strike> borrowing a power sword too.

The Autocannon with AP shells is one of the most powerful non-explosive ranged weapons you can buy. Stronger than the plasma gun and the ammo is easier to obtain. I'd actually recommend only carrying 1 HE and 1 Incendiary clip and carry AP as your primary clips. Beside, you don't want to do too much property damage with the HE rounds (companies don't mind the burning corpses of civilians - they could go hostile towards X-Com if you track too much dirt on their carpets). The HE and In clips are for special uses, like blasting brainsuckers off if you're on your own, or to wipe out hyperworm mobs. Incendiary can be break up tight mobs of enemies, etc. The AC will however be very slow in turn based - so if that's what you play then it may not suit you very well.

----

Psi is a long term investment in Apocalypse. You only earn 3 times your base Psi stats. Hence humans will only ever be useful for low level simple attacks like probes. Hybrids will be your core psi users. Even then they may not be able to do much at the start. They need plenty of uninterrupted practice time in the psi lab before their skills pay off (when I say uninterrupted, I mean: no health loss when the clock ticks over midnight).

Psi may not be immediately useful, but they come into their own once they've built up their stats and can easily strip enemy anthropods or human guards of their disrupter shields in a flash while setting all of their carried grenades to explode on impact with the ground and dropping them.

The only time I've ever got a neutral organization hostile towards me when doing psi practice was when one of my psi troopers mind controlled a gangster then made him jump off the building. When he hit the ground, the gangster was still under my psi trooper's control. The loss in health was attributed to X-COM, and they started shooting. However, if my psi trooper had broken the psi link before the gangster hit the ground, the gangster would've eventually died of critical wounds (or the impact), and the psi trooper would've been free to roam about the map as if nothing happened. A morbid way of killing neutrals and not getting blamed for it.

Stun attacks will have the same effect as you'd get with stun gas or a stun grapple (marvelous weapon by the way - bounces of shields but still great for conserving ammo).

Psi attacks require line of sight. Breaking line of sight breaks the link.

Yes, psi attacks expend Psi Energy, a rechargeable resource. In turn based, psi attacks are generally a one time expense. In real-time, you are charged by the attack attempt. If successful, you'll start paying maintenance costs for as long as you maintain the psi link. You can break the link by going out of line of sight or readying another psi attack. Check the mind bender's information panel for the psi energy bar. Stun and panic for example require you to maintain the link long enough for stun increase or morale loss to take place. Probe lets you access the enemy information any time you want as long as the probe is in effect. Mind control lets you control the unit for as long as you want, but is also the most expensive in costs and maintenance. To make the best use of it, try not to spend any maintenance costs at all. Pause the game, control the enemy, go to their inventory and wreak as much a havoc as you can (for example: arm grenade. Right click grenade, then 'drop' the grenade). Once done, break the MC link and let time run and watch the fireworks.

-[[User:NKF|NKF]] 00:47, 16 October 2008 (CDT)

Dual Wield is useless in Turn Based. And when it comes to the M4000, I play turn based! Switch to autofire, and you only spend 1 TU per shot! Wildly inaccurate? Then sneak in ninja style and shoot everyone at point blank! OWNAGE! Note: Might need grenades for when you round the corner thinking there's only 1 guy and find there's half the Cult of Sirius hiding in the room.
One of my favourite Dual Wields in Apocalypse is Autocannon with HE ammo, autofire, and Marsec Flying Armor. Only to be used when collateral damage is not an issue. Or in the case of COS raids, collateral damage is preferred!
Of course, in real life, dual wielding large weapons like that will lead to such a loss in aiming control that you are very likely to shoot yourself in the hands.

= Realistic UFO Economics an Oxymoron? =

... Trying to form "realistic" economics in UFO defense is just ridiculous. Capturing one intact Medium Scout should realistically give enough cash to outfit an entire platoon of elite soldiers with all the best equipment money can buy. The power source+Elerium should rightfully be worth enough to buy a fleet of Interceptors. Instead, it gives $250k+$250k... not even enough to rent 1 interceptor for 1 month! [[User:Jasonred|Jasonred]] 08:01, 28 February 2009 (CST)

Yeah you're right about realistic UFO economics. :) But we do try. It's still good to try to smooth out the more flagrantly illogical aspects, and to try and level out the game balance. Removing Exploits goes a long way to making the economic aspects of the game better. For improving realism, I think one of the best things we came up with - working with Hobbes - is the idea that X-Com has a fixed-price "tarrif" for all the alien loot it hands over to the Council, established in the X-Com Constitution. This explains why there is no "free market" in the prices of alien items, because as you say, the prices of certain items ought to be astronomical. The other 'hard problem' in UFO economics is one that you highlighted in a recent post - why aren't the resources of the whole world harnessed, budgets in the billions etc. This is harder to explain away, you need a mixture of reasons/excuses. Some of the more useful excuses are - need for secrecy keeps the operation small scale (and as you also recently pointed out, the aliens seem to 'conspire' to keep the conflict small-scale); Earth governments are playing a 'double game' and don't want to risk offending the aliens by funding X-Com heavily, in case X-Com loses and the aliens punish them for supporting X-Com; Earth governments are not convinced that the Alien threat is real. (Obviously they can easily be convinced the Aliens are real, and are violent, but are they really a 'threat' to governments, or can deals be done - in a way this is like the 'double game' argument.) [[User:Spike|Spike]] 08:51, 28 February 2009 (CST)

==Weapon Analysis==

While I'm sure I was wondering about something. When you do Weapon Analysis for HE, I'm guessing you figure a GZ attack against the Under Armor. However, do you also factor in that Large units take nearly 4x damage from an HE attack, since they get hit on every square they occupy? [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:40, 1 March 2009 (CST)

: Indeed I do. I calculate the other 3 squares of GZ+1 effect in some detail, including getting the averages right (which as you know is slightly tricky). One thing I don't calculate is the effects of any near misses. So the figures I give should be taken as a minimum. In practice, HE effectiveness will be somewhat higher due to the near misses - but by how much? It depends on a lot of factors, some I don't know and some that are highly variable (terrain density etc). [[User:Spike|Spike]] 03:55, 2 March 2009 (CST)

Hi Spike, to quote you from your user page:

<table width="75%" {{StdCenterTable}}><tr><td align="left">One more problem with modelling Near Misses: the benefit of lucky near misses - whatever its value - is inversely proportional to overall accuracy. A perfect shooter gets exactly zero benefit from near misses. Which raises an interesting possibility. Maybe the "near miss benefit" could be estimated using a repeated experiments with a logger and a shooter with Firing Accuracy=0. Any damage done to the target would be due to a lucky near miss. This would be the other limiting case - the opposite of the perfect shooter. Then extrapolate between those two extremes to find a "near miss benefit" for that weapon as some function of {TA, range].</td></tr></table>
You bring up some interesting ideas on near misses. But wouldn't the benefits of 0% accuracy (leading to unintended splash damage) be negated by the probability of the soldier shooting himself? I would think that would be a major consideration when taking stuff like this into account. I should also mention that a soldier with max firing accuracy (125%) can pinpoint where shots should hit, thus the shooter intentionally doesn't aim for one target but the center of a group of targets thus creating a "near miss benefit" scenario. What do you think about this? --[[User:Zombie|Zombie]] 12:45, 2 March 2009 (CST)

---

Great points Zombie. On the soldier shooting himself, I was wondering if we could just assume, as a simplication, that 'bad misses' (friendly fire casualties, including self-inflicted damage) even out with 'good misses' (lucky near misses). That would be much simpler! I have no idea if it's true though. Certainly if doing this logger exercise, you would want to distinguish damage done to self vs damage done to target. Actually, it's not really adequate to just 'net out' friendly damage vs target damage. After all, we expect weapons to do more damage to the enemy than to ourselves! So you might want to subtract 2, 3, 4... 10 times the friendly damage from the 'target' damage when determining the 'net benefit' from inaccurate fire.

It's a good point about the marksman firing at a midpoint, and of course that's a tactic we probably all try to use from time to time. In fact it's often frustrating when the game won't let you target a certain optimum point just because there's no object or creature there. These situations are slightly easier to model mathematically - though still cumbersome - because with a super-marksman you know exactly where the shell is going to land. The bit I really can't get my head around in the normal case (average accuracty) is the probability of all the different squares where the round might end up. I know there is some experimentatal data around with error angles but... I guess I'm trying to talk myself into the view that the terrain features are more important than the error angles, therefore it's not worth doing all the heavy math to figure out the effect of the error angles. :)

For the time being I'm probably just going to add a Note to my weapon rankings tables saying "Does not consider the beneficial or harmful effects of misses, near-misses, etc".

[[User:Spike|Spike]] 14:51, 2 March 2009 (CST)

:Stuff like this is always fun to ponder and debate I think. It brings up a lot of good ideas/tactics too. I was just thinking about the second part of your reply a little. For the sake of simplification, I think we should just ignore terrain for the time being. Yes, it plays a role (sometimes huge), but it eliminates quite a few variables to arrive at some sort of conclusion. What would you think about a testing scenario where a soldier with 0% FA (standing on flat level ground) fires at a static object (such as a soldier who can't be hurt)? I'm thinking about using Bomb Bloke's numerical tileset as the substituted desert terrain and then firing about 100 or so rounds and looking at the overall damage done to the terrain by inspecting the numbers. Then you could see any potential "hot zones" where shots may hit more often for example, or even just concentrate on the normal damage area of the weapon and look for hot zones in there. Might be an interesting trial to run. Your thoughts? --[[User:Zombie|Zombie]] 15:22, 2 March 2009 (CST)

I think that sounds great! It would be great to build up a 2D (or even 3D) histogram of where the shots landed. Tweak an autocannon so it has 250 rounds for ease. Work it from a standard range of say 10 or 20. It would also be interesting to see the results at an accuracy of 50%. From data like that you could definitely get some kind of rule of thumb to estimate the good and bad effects of misses. Cool! [[User:Spike|Spike]] 15:39, 2 March 2009 (CST)

===Rocket Launcher Firepower Incorrect===
Hi Spike, on the [[Firepower Tables]] it seems the Rocket Launcher is incorrectly computed. This might have been fixed in the alien specific firepower tables, point blank, etc, I don't yet know (and I dont have an xls viewer at the moment, either). However, at skirmish range, when the Launcher is 45%, 75% TU for snap and aimed, respectively, and 55% and 115% on accuracy, how can aimed fire have more than twice the firepower of snap? I ran the numbers and both aimed and snap were run at 75% TU usage. Furthermore, damage on aimed, small and large rockets, is exactly 75% of the actual average. The damages should read 46 and 58 for small rockets and 61 and 77 for large. --[[User:Talon81|Talon81]] 04:29, 15 May 2009 (EDT)

I bet I know why, talon. It's cause the Rocket Launcher can only fire once per turn, on snap. And once per turn, on aimed. Tadaa... [[User:Jasonred|Jasonred]] 14:00, 15 May 2009 (EDT)

: That cannot be the cause because it takes 45% of TUs to fire snap (therefore can fire twice). Secondly, it SHOULD not be the cause because even if it could only fire once, that is something to apply to the Sustained Rates chart, and not the Instantaneous Rates chart. On the Instantaneous Rates chart, it is figured as if you could use every TU. --[[User:Talon81|Talon81]] 14:17, 16 May 2009 (EDT)

:: You *DO* know that the Rocket Launcher has a max ammo of 1, and therefore it CANNOT fire twice in 1 round? ... to fire twice per round requires 149 TU minimum. 67 to fire snap, 15 to reload, 67 to fire again. ... also, corrected your link. Maybe you can view it now. ... I think this belongs to the firepower table discussion page, not here, anyhow. BTW, after careul consideration, I think you are right... depending on definition of Instantaneous Rate. [[User:Jasonred|Jasonred]] 14:51, 20 May 2009 (EDT)

::: You guys have figured it out and the Rate of Fire calculation I just put in to the Talk page is wrong, or rather incomplete (I'll go back and change it). Actually, what I do is I cap the RoF at the ammo capacity of the weapon - I don't attempt to calculate sustained fire rates <i>including reloading</i>. But I think Talon81 has a point, to be consistent, for the "instantaneous" rates I should probably ignore that cap. There may be other errors as well, thanks for keeping me on my toes guys. [[User:Spike|Spike]] 15:43, 20 May 2009 (EDT)

:::: Thanks for the link fix, Jason. Yeah, for some reason I wasn't thinking about the reloading issue. However, taking that into account would come up with different numbers (obviously) than the ones that were there. While certainly it is not fair to ignore the need to reload (especially on the sustained rates table), it is also not fair to ignore that it can be reloaded (especially on the instantaneous rates table). Long story short, I wanted Spike to know about it and correct me where I was wrong, without alerting everybody that stopped by the firepower page, and now Spike has been gracious enough to answer. --[[User:Talon81|Talon81]] 20:59, 20 May 2009 (EDT)

== Large Units and Fire ==

If I'd remembered earlier I would've piped up about this, but I recall years ago when I set up a savegame for Zombie to test damage done to sectopod quarters, I physically split a sectopod into its various quarters by moving its individual unitpos segment coordinates to different locations around the map. Blasting one quarterpod with incendiary rounds set fire to all the others, even though they weren't in the same locality. This referring to the unit sticky fire, not the ground fire. Can't remember if it uses the same "apply this effect to the next four segments" rule that messed up the mind control of large units in TFTD though. -[[User:NKF|NKF]] 02:20, 16 March 2009 (EDT)

User talk:Spike

2009-05-16T18:20:15Z

Talon81: /* Rocket Launcher Firepower Incorrect */

== Message Board ==

----

By any chance, have you taken another look at [[User talk:Bomb Bloke#Rated Accuracy Vs Angle Range |my talk page]] since your return?

Yes yes, I'm lazy and should really be able to interpret the data myself... But I can only really get as far as saying "that's not a linear distribution" and then my lack of understanding re what all the trig functions are for leaves me stranded. :/

- [[User:Bomb Bloke|Bomb Bloke]] 09:20, 10 April 2009 (EDT)

: Sorry what with starting a new job, moving, Easter, I've been a bit busy. Did you say you still had the original data? You sent me it in an Access database, is that right? It all seems a long time ago! [[User:Spike|Spike]] 16:28, 14 April 2009 (EDT)

I don't remember sending you the data specifically (I certainly haven't done so within the last year), but you can find it all linked on my talk page now. - [[User:Bomb Bloke|Bomb Bloke]] 22:31, 14 April 2009 (EDT)

== Apocalypse Blog QA ==

Uncle NKF to the rescue!

Don't ever unload troops at the mission site. To select which agents go into a mission, just highlight them before picking the attack or investigate button or click on the vehicle name to select them all. Get into this habit - always.

The reason why will become incredibly apparent if you play long enough to do an alien dimension building. The moment you complete the mission, the alien building will collapse and your ship will take off automatically (as per standard practice). However, the kicker is that you'll never be able to land at the building site again. This will result in forever stranding any troops that did not get killed by the building crashing down around them.

----

Alien's won't attack a dead body on purpose, though HE explosions caused by nearby combat will certainly destroy them. Watch where you are fighting. Also some enemies tend to pick up anything that's not bolted down, and may even carelessly wander towards one of the area exit pads. It happens - so be vigilant!

----

Dual-Wield does penalise your accuracy, and depending on some weapons, will slow you down considerably. The only reason to dual weild is as you say: to increase volume of fire. If you're like me and like close range combat (you'll find a lot of this in some buildings), then you want to get out as much firepower as you can because the enemy will have just as much of an advantage at such a close range as you do (and there's often more of them than you or they have one-hit big-bang weapons like the Poppers!). Out in the open, single weapons with aimed shots get better results - until you are so accurate that you don't even feel the penalty.

The game's super weapons are easy enough to be effective without dual-wielding as they're ramped up to be the best weapons available. In fact, most people make do with just one devestator or toxigun and cloak combo exclusively.

----

Apocalypse uses the volume of ''successful hits'' to determine accuracy improvements. The M4000 just gets lots of hits in, while the laser sniper rifle may hit a few times. By the way, aimed + dual M4000 garners more accuracy for a slightly slower fire rate than full-auto, allowing you to not waste as much ammo. Not as accurate as one M4000 on aimed or as fast as dual M4k's on full auto.

Plasma gun ammo is scarce at first, but you do have the option of attacking your enemies like the Cult of Sirius and win some off their fallen brethren. In fact, a lot of items that don't get released until a week or two in can be won off raiding enemy organizations. Better to get a good start than try to hobble along. I'd recommend <strike>stealing</strike> borrowing a power sword too.

The Autocannon with AP shells is one of the most powerful non-explosive ranged weapons you can buy. Stronger than the plasma gun and the ammo is easier to obtain. I'd actually recommend only carrying 1 HE and 1 Incendiary clip and carry AP as your primary clips. Beside, you don't want to do too much property damage with the HE rounds (companies don't mind the burning corpses of civilians - they could go hostile towards X-Com if you track too much dirt on their carpets). The HE and In clips are for special uses, like blasting brainsuckers off if you're on your own, or to wipe out hyperworm mobs. Incendiary can be break up tight mobs of enemies, etc. The AC will however be very slow in turn based - so if that's what you play then it may not suit you very well.

----

Psi is a long term investment in Apocalypse. You only earn 3 times your base Psi stats. Hence humans will only ever be useful for low level simple attacks like probes. Hybrids will be your core psi users. Even then they may not be able to do much at the start. They need plenty of uninterrupted practice time in the psi lab before their skills pay off (when I say uninterrupted, I mean: no health loss when the clock ticks over midnight).

Psi may not be immediately useful, but they come into their own once they've built up their stats and can easily strip enemy anthropods or human guards of their disrupter shields in a flash while setting all of their carried grenades to explode on impact with the ground and dropping them.

The only time I've ever got a neutral organization hostile towards me when doing psi practice was when one of my psi troopers mind controlled a gangster then made him jump off the building. When he hit the ground, the gangster was still under my psi trooper's control. The loss in health was attributed to X-COM, and they started shooting. However, if my psi trooper had broken the psi link before the gangster hit the ground, the gangster would've eventually died of critical wounds (or the impact), and the psi trooper would've been free to roam about the map as if nothing happened. A morbid way of killing neutrals and not getting blamed for it.

Stun attacks will have the same effect as you'd get with stun gas or a stun grapple (marvelous weapon by the way - bounces of shields but still great for conserving ammo).

Psi attacks require line of sight. Breaking line of sight breaks the link.

Yes, psi attacks expend Psi Energy, a rechargeable resource. In turn based, psi attacks are generally a one time expense. In real-time, you are charged by the attack attempt. If successful, you'll start paying maintenance costs for as long as you maintain the psi link. You can break the link by going out of line of sight or readying another psi attack. Check the mind bender's information panel for the psi energy bar. Stun and panic for example require you to maintain the link long enough for stun increase or morale loss to take place. Probe lets you access the enemy information any time you want as long as the probe is in effect. Mind control lets you control the unit for as long as you want, but is also the most expensive in costs and maintenance. To make the best use of it, try not to spend any maintenance costs at all. Pause the game, control the enemy, go to their inventory and wreak as much a havoc as you can (for example: arm grenade. Right click grenade, then 'drop' the grenade). Once done, break the MC link and let time run and watch the fireworks.

-[[User:NKF|NKF]] 00:47, 16 October 2008 (CDT)

Dual Wield is useless in Turn Based. And when it comes to the M4000, I play turn based! Switch to autofire, and you only spend 1 TU per shot! Wildly inaccurate? Then sneak in ninja style and shoot everyone at point blank! OWNAGE! Note: Might need grenades for when you round the corner thinking there's only 1 guy and find there's half the Cult of Sirius hiding in the room.
One of my favourite Dual Wields in Apocalypse is Autocannon with HE ammo, autofire, and Marsec Flying Armor. Only to be used when collateral damage is not an issue. Or in the case of COS raids, collateral damage is preferred!
Of course, in real life, dual wielding large weapons like that will lead to such a loss in aiming control that you are very likely to shoot yourself in the hands.

= Realistic UFO Economics an Oxymoron? =

... Trying to form "realistic" economics in UFO defense is just ridiculous. Capturing one intact Medium Scout should realistically give enough cash to outfit an entire platoon of elite soldiers with all the best equipment money can buy. The power source+Elerium should rightfully be worth enough to buy a fleet of Interceptors. Instead, it gives $250k+$250k... not even enough to rent 1 interceptor for 1 month! [[User:Jasonred|Jasonred]] 08:01, 28 February 2009 (CST)

Yeah you're right about realistic UFO economics. :) But we do try. It's still good to try to smooth out the more flagrantly illogical aspects, and to try and level out the game balance. Removing Exploits goes a long way to making the economic aspects of the game better. For improving realism, I think one of the best things we came up with - working with Hobbes - is the idea that X-Com has a fixed-price "tarrif" for all the alien loot it hands over to the Council, established in the X-Com Constitution. This explains why there is no "free market" in the prices of alien items, because as you say, the prices of certain items ought to be astronomical. The other 'hard problem' in UFO economics is one that you highlighted in a recent post - why aren't the resources of the whole world harnessed, budgets in the billions etc. This is harder to explain away, you need a mixture of reasons/excuses. Some of the more useful excuses are - need for secrecy keeps the operation small scale (and as you also recently pointed out, the aliens seem to 'conspire' to keep the conflict small-scale); Earth governments are playing a 'double game' and don't want to risk offending the aliens by funding X-Com heavily, in case X-Com loses and the aliens punish them for supporting X-Com; Earth governments are not convinced that the Alien threat is real. (Obviously they can easily be convinced the Aliens are real, and are violent, but are they really a 'threat' to governments, or can deals be done - in a way this is like the 'double game' argument.) [[User:Spike|Spike]] 08:51, 28 February 2009 (CST)

==Weapon Analysis==

While I'm sure I was wondering about something. When you do Weapon Analysis for HE, I'm guessing you figure a GZ attack against the Under Armor. However, do you also factor in that Large units take nearly 4x damage from an HE attack, since they get hit on every square they occupy? [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:40, 1 March 2009 (CST)

: Indeed I do. I calculate the other 3 squares of GZ+1 effect in some detail, including getting the averages right (which as you know is slightly tricky). One thing I don't calculate is the effects of any near misses. So the figures I give should be taken as a minimum. In practice, HE effectiveness will be somewhat higher due to the near misses - but by how much? It depends on a lot of factors, some I don't know and some that are highly variable (terrain density etc). [[User:Spike|Spike]] 03:55, 2 March 2009 (CST)

Hi Spike, to quote you from your user page:

<table width="75%" {{StdCenterTable}}><tr><td align="left">One more problem with modelling Near Misses: the benefit of lucky near misses - whatever its value - is inversely proportional to overall accuracy. A perfect shooter gets exactly zero benefit from near misses. Which raises an interesting possibility. Maybe the "near miss benefit" could be estimated using a repeated experiments with a logger and a shooter with Firing Accuracy=0. Any damage done to the target would be due to a lucky near miss. This would be the other limiting case - the opposite of the perfect shooter. Then extrapolate between those two extremes to find a "near miss benefit" for that weapon as some function of {TA, range].</td></tr></table>
You bring up some interesting ideas on near misses. But wouldn't the benefits of 0% accuracy (leading to unintended splash damage) be negated by the probability of the soldier shooting himself? I would think that would be a major consideration when taking stuff like this into account. I should also mention that a soldier with max firing accuracy (125%) can pinpoint where shots should hit, thus the shooter intentionally doesn't aim for one target but the center of a group of targets thus creating a "near miss benefit" scenario. What do you think about this? --[[User:Zombie|Zombie]] 12:45, 2 March 2009 (CST)

---

Great points Zombie. On the soldier shooting himself, I was wondering if we could just assume, as a simplication, that 'bad misses' (friendly fire casualties, including self-inflicted damage) even out with 'good misses' (lucky near misses). That would be much simpler! I have no idea if it's true though. Certainly if doing this logger exercise, you would want to distinguish damage done to self vs damage done to target. Actually, it's not really adequate to just 'net out' friendly damage vs target damage. After all, we expect weapons to do more damage to the enemy than to ourselves! So you might want to subtract 2, 3, 4... 10 times the friendly damage from the 'target' damage when determining the 'net benefit' from inaccurate fire.

It's a good point about the marksman firing at a midpoint, and of course that's a tactic we probably all try to use from time to time. In fact it's often frustrating when the game won't let you target a certain optimum point just because there's no object or creature there. These situations are slightly easier to model mathematically - though still cumbersome - because with a super-marksman you know exactly where the shell is going to land. The bit I really can't get my head around in the normal case (average accuracty) is the probability of all the different squares where the round might end up. I know there is some experimentatal data around with error angles but... I guess I'm trying to talk myself into the view that the terrain features are more important than the error angles, therefore it's not worth doing all the heavy math to figure out the effect of the error angles. :)

For the time being I'm probably just going to add a Note to my weapon rankings tables saying "Does not consider the beneficial or harmful effects of misses, near-misses, etc".

[[User:Spike|Spike]] 14:51, 2 March 2009 (CST)

:Stuff like this is always fun to ponder and debate I think. It brings up a lot of good ideas/tactics too. I was just thinking about the second part of your reply a little. For the sake of simplification, I think we should just ignore terrain for the time being. Yes, it plays a role (sometimes huge), but it eliminates quite a few variables to arrive at some sort of conclusion. What would you think about a testing scenario where a soldier with 0% FA (standing on flat level ground) fires at a static object (such as a soldier who can't be hurt)? I'm thinking about using Bomb Bloke's numerical tileset as the substituted desert terrain and then firing about 100 or so rounds and looking at the overall damage done to the terrain by inspecting the numbers. Then you could see any potential "hot zones" where shots may hit more often for example, or even just concentrate on the normal damage area of the weapon and look for hot zones in there. Might be an interesting trial to run. Your thoughts? --[[User:Zombie|Zombie]] 15:22, 2 March 2009 (CST)

I think that sounds great! It would be great to build up a 2D (or even 3D) histogram of where the shots landed. Tweak an autocannon so it has 250 rounds for ease. Work it from a standard range of say 10 or 20. It would also be interesting to see the results at an accuracy of 50%. From data like that you could definitely get some kind of rule of thumb to estimate the good and bad effects of misses. Cool! [[User:Spike|Spike]] 15:39, 2 March 2009 (CST)

===Rocket Launcher Firepower Incorrect===
Hi Spike, on the [[title=Firepower_Tables|Firepower Tables]] it seems the Rocket Launcher is incorrectly computed. This might have been fixed in the alien specific firepower tables, point blank, etc, I don't yet know (and I dont have an xls viewer at the moment, either). However, at skirmish range, when the Launcher is 45%, 75% TU for snap and aimed, respectively, and 55% and 115% on accuracy, how can aimed fire have more than twice the firepower of snap? I ran the numbers and both aimed and snap were run at 75% TU usage. Furthermore, damage on aimed, small and large rockets, is exactly 75% of the actual average. The damages should read 46 and 58 for small rockets and 61 and 77 for large. --[[User:Talon81|Talon81]] 04:29, 15 May 2009 (EDT)

I bet I know why, talon. It's cause the Rocket Launcher can only fire once per turn, on snap. And once per turn, on aimed. Tadaa... [[User:Jasonred|Jasonred]] 14:00, 15 May 2009 (EDT)

: That cannot be the cause because it takes 45% of TUs to fire snap (therefore can fire twice). Secondly, it SHOULD not be the cause because even if it could only fire once, that is something to apply to the Sustained Rates chart, and not the Instantaneous Rates chart. On the Instantaneous Rates chart, it is figured as if you could use every TU. --[[User:Talon81|Talon81]] 14:17, 16 May 2009 (EDT)

== Large Units and Fire ==

If I'd remembered earlier I would've piped up about this, but I recall years ago when I set up a savegame for Zombie to test damage done to sectopod quarters, I physically split a sectopod into its various quarters by moving its individual unitpos segment coordinates to different locations around the map. Blasting one quarterpod with incendiary rounds set fire to all the others, even though they weren't in the same locality. This referring to the unit sticky fire, not the ground fire. Can't remember if it uses the same "apply this effect to the next four segments" rule that messed up the mind control of large units in TFTD though. -[[User:NKF|NKF]] 02:20, 16 March 2009 (EDT)

User talk:Spike

2009-05-16T18:17:03Z

Talon81: /* Rocket Launcher Firepower Incorrect */

== Message Board ==

----

By any chance, have you taken another look at [[User talk:Bomb Bloke#Rated Accuracy Vs Angle Range |my talk page]] since your return?

Yes yes, I'm lazy and should really be able to interpret the data myself... But I can only really get as far as saying "that's not a linear distribution" and then my lack of understanding re what all the trig functions are for leaves me stranded. :/

- [[User:Bomb Bloke|Bomb Bloke]] 09:20, 10 April 2009 (EDT)

: Sorry what with starting a new job, moving, Easter, I've been a bit busy. Did you say you still had the original data? You sent me it in an Access database, is that right? It all seems a long time ago! [[User:Spike|Spike]] 16:28, 14 April 2009 (EDT)

I don't remember sending you the data specifically (I certainly haven't done so within the last year), but you can find it all linked on my talk page now. - [[User:Bomb Bloke|Bomb Bloke]] 22:31, 14 April 2009 (EDT)

== Apocalypse Blog QA ==

Uncle NKF to the rescue!

Don't ever unload troops at the mission site. To select which agents go into a mission, just highlight them before picking the attack or investigate button or click on the vehicle name to select them all. Get into this habit - always.

The reason why will become incredibly apparent if you play long enough to do an alien dimension building. The moment you complete the mission, the alien building will collapse and your ship will take off automatically (as per standard practice). However, the kicker is that you'll never be able to land at the building site again. This will result in forever stranding any troops that did not get killed by the building crashing down around them.

----

Alien's won't attack a dead body on purpose, though HE explosions caused by nearby combat will certainly destroy them. Watch where you are fighting. Also some enemies tend to pick up anything that's not bolted down, and may even carelessly wander towards one of the area exit pads. It happens - so be vigilant!

----

Dual-Wield does penalise your accuracy, and depending on some weapons, will slow you down considerably. The only reason to dual weild is as you say: to increase volume of fire. If you're like me and like close range combat (you'll find a lot of this in some buildings), then you want to get out as much firepower as you can because the enemy will have just as much of an advantage at such a close range as you do (and there's often more of them than you or they have one-hit big-bang weapons like the Poppers!). Out in the open, single weapons with aimed shots get better results - until you are so accurate that you don't even feel the penalty.

The game's super weapons are easy enough to be effective without dual-wielding as they're ramped up to be the best weapons available. In fact, most people make do with just one devestator or toxigun and cloak combo exclusively.

----

Apocalypse uses the volume of ''successful hits'' to determine accuracy improvements. The M4000 just gets lots of hits in, while the laser sniper rifle may hit a few times. By the way, aimed + dual M4000 garners more accuracy for a slightly slower fire rate than full-auto, allowing you to not waste as much ammo. Not as accurate as one M4000 on aimed or as fast as dual M4k's on full auto.

Plasma gun ammo is scarce at first, but you do have the option of attacking your enemies like the Cult of Sirius and win some off their fallen brethren. In fact, a lot of items that don't get released until a week or two in can be won off raiding enemy organizations. Better to get a good start than try to hobble along. I'd recommend <strike>stealing</strike> borrowing a power sword too.

The Autocannon with AP shells is one of the most powerful non-explosive ranged weapons you can buy. Stronger than the plasma gun and the ammo is easier to obtain. I'd actually recommend only carrying 1 HE and 1 Incendiary clip and carry AP as your primary clips. Beside, you don't want to do too much property damage with the HE rounds (companies don't mind the burning corpses of civilians - they could go hostile towards X-Com if you track too much dirt on their carpets). The HE and In clips are for special uses, like blasting brainsuckers off if you're on your own, or to wipe out hyperworm mobs. Incendiary can be break up tight mobs of enemies, etc. The AC will however be very slow in turn based - so if that's what you play then it may not suit you very well.

----

Psi is a long term investment in Apocalypse. You only earn 3 times your base Psi stats. Hence humans will only ever be useful for low level simple attacks like probes. Hybrids will be your core psi users. Even then they may not be able to do much at the start. They need plenty of uninterrupted practice time in the psi lab before their skills pay off (when I say uninterrupted, I mean: no health loss when the clock ticks over midnight).

Psi may not be immediately useful, but they come into their own once they've built up their stats and can easily strip enemy anthropods or human guards of their disrupter shields in a flash while setting all of their carried grenades to explode on impact with the ground and dropping them.

The only time I've ever got a neutral organization hostile towards me when doing psi practice was when one of my psi troopers mind controlled a gangster then made him jump off the building. When he hit the ground, the gangster was still under my psi trooper's control. The loss in health was attributed to X-COM, and they started shooting. However, if my psi trooper had broken the psi link before the gangster hit the ground, the gangster would've eventually died of critical wounds (or the impact), and the psi trooper would've been free to roam about the map as if nothing happened. A morbid way of killing neutrals and not getting blamed for it.

Stun attacks will have the same effect as you'd get with stun gas or a stun grapple (marvelous weapon by the way - bounces of shields but still great for conserving ammo).

Psi attacks require line of sight. Breaking line of sight breaks the link.

Yes, psi attacks expend Psi Energy, a rechargeable resource. In turn based, psi attacks are generally a one time expense. In real-time, you are charged by the attack attempt. If successful, you'll start paying maintenance costs for as long as you maintain the psi link. You can break the link by going out of line of sight or readying another psi attack. Check the mind bender's information panel for the psi energy bar. Stun and panic for example require you to maintain the link long enough for stun increase or morale loss to take place. Probe lets you access the enemy information any time you want as long as the probe is in effect. Mind control lets you control the unit for as long as you want, but is also the most expensive in costs and maintenance. To make the best use of it, try not to spend any maintenance costs at all. Pause the game, control the enemy, go to their inventory and wreak as much a havoc as you can (for example: arm grenade. Right click grenade, then 'drop' the grenade). Once done, break the MC link and let time run and watch the fireworks.

-[[User:NKF|NKF]] 00:47, 16 October 2008 (CDT)

Dual Wield is useless in Turn Based. And when it comes to the M4000, I play turn based! Switch to autofire, and you only spend 1 TU per shot! Wildly inaccurate? Then sneak in ninja style and shoot everyone at point blank! OWNAGE! Note: Might need grenades for when you round the corner thinking there's only 1 guy and find there's half the Cult of Sirius hiding in the room.
One of my favourite Dual Wields in Apocalypse is Autocannon with HE ammo, autofire, and Marsec Flying Armor. Only to be used when collateral damage is not an issue. Or in the case of COS raids, collateral damage is preferred!
Of course, in real life, dual wielding large weapons like that will lead to such a loss in aiming control that you are very likely to shoot yourself in the hands.

= Realistic UFO Economics an Oxymoron? =

... Trying to form "realistic" economics in UFO defense is just ridiculous. Capturing one intact Medium Scout should realistically give enough cash to outfit an entire platoon of elite soldiers with all the best equipment money can buy. The power source+Elerium should rightfully be worth enough to buy a fleet of Interceptors. Instead, it gives $250k+$250k... not even enough to rent 1 interceptor for 1 month! [[User:Jasonred|Jasonred]] 08:01, 28 February 2009 (CST)

Yeah you're right about realistic UFO economics. :) But we do try. It's still good to try to smooth out the more flagrantly illogical aspects, and to try and level out the game balance. Removing Exploits goes a long way to making the economic aspects of the game better. For improving realism, I think one of the best things we came up with - working with Hobbes - is the idea that X-Com has a fixed-price "tarrif" for all the alien loot it hands over to the Council, established in the X-Com Constitution. This explains why there is no "free market" in the prices of alien items, because as you say, the prices of certain items ought to be astronomical. The other 'hard problem' in UFO economics is one that you highlighted in a recent post - why aren't the resources of the whole world harnessed, budgets in the billions etc. This is harder to explain away, you need a mixture of reasons/excuses. Some of the more useful excuses are - need for secrecy keeps the operation small scale (and as you also recently pointed out, the aliens seem to 'conspire' to keep the conflict small-scale); Earth governments are playing a 'double game' and don't want to risk offending the aliens by funding X-Com heavily, in case X-Com loses and the aliens punish them for supporting X-Com; Earth governments are not convinced that the Alien threat is real. (Obviously they can easily be convinced the Aliens are real, and are violent, but are they really a 'threat' to governments, or can deals be done - in a way this is like the 'double game' argument.) [[User:Spike|Spike]] 08:51, 28 February 2009 (CST)

==Weapon Analysis==

While I'm sure I was wondering about something. When you do Weapon Analysis for HE, I'm guessing you figure a GZ attack against the Under Armor. However, do you also factor in that Large units take nearly 4x damage from an HE attack, since they get hit on every square they occupy? [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:40, 1 March 2009 (CST)

: Indeed I do. I calculate the other 3 squares of GZ+1 effect in some detail, including getting the averages right (which as you know is slightly tricky). One thing I don't calculate is the effects of any near misses. So the figures I give should be taken as a minimum. In practice, HE effectiveness will be somewhat higher due to the near misses - but by how much? It depends on a lot of factors, some I don't know and some that are highly variable (terrain density etc). [[User:Spike|Spike]] 03:55, 2 March 2009 (CST)

Hi Spike, to quote you from your user page:

<table width="75%" {{StdCenterTable}}><tr><td align="left">One more problem with modelling Near Misses: the benefit of lucky near misses - whatever its value - is inversely proportional to overall accuracy. A perfect shooter gets exactly zero benefit from near misses. Which raises an interesting possibility. Maybe the "near miss benefit" could be estimated using a repeated experiments with a logger and a shooter with Firing Accuracy=0. Any damage done to the target would be due to a lucky near miss. This would be the other limiting case - the opposite of the perfect shooter. Then extrapolate between those two extremes to find a "near miss benefit" for that weapon as some function of {TA, range].</td></tr></table>
You bring up some interesting ideas on near misses. But wouldn't the benefits of 0% accuracy (leading to unintended splash damage) be negated by the probability of the soldier shooting himself? I would think that would be a major consideration when taking stuff like this into account. I should also mention that a soldier with max firing accuracy (125%) can pinpoint where shots should hit, thus the shooter intentionally doesn't aim for one target but the center of a group of targets thus creating a "near miss benefit" scenario. What do you think about this? --[[User:Zombie|Zombie]] 12:45, 2 March 2009 (CST)

---

Great points Zombie. On the soldier shooting himself, I was wondering if we could just assume, as a simplication, that 'bad misses' (friendly fire casualties, including self-inflicted damage) even out with 'good misses' (lucky near misses). That would be much simpler! I have no idea if it's true though. Certainly if doing this logger exercise, you would want to distinguish damage done to self vs damage done to target. Actually, it's not really adequate to just 'net out' friendly damage vs target damage. After all, we expect weapons to do more damage to the enemy than to ourselves! So you might want to subtract 2, 3, 4... 10 times the friendly damage from the 'target' damage when determining the 'net benefit' from inaccurate fire.

It's a good point about the marksman firing at a midpoint, and of course that's a tactic we probably all try to use from time to time. In fact it's often frustrating when the game won't let you target a certain optimum point just because there's no object or creature there. These situations are slightly easier to model mathematically - though still cumbersome - because with a super-marksman you know exactly where the shell is going to land. The bit I really can't get my head around in the normal case (average accuracty) is the probability of all the different squares where the round might end up. I know there is some experimentatal data around with error angles but... I guess I'm trying to talk myself into the view that the terrain features are more important than the error angles, therefore it's not worth doing all the heavy math to figure out the effect of the error angles. :)

For the time being I'm probably just going to add a Note to my weapon rankings tables saying "Does not consider the beneficial or harmful effects of misses, near-misses, etc".

[[User:Spike|Spike]] 14:51, 2 March 2009 (CST)

:Stuff like this is always fun to ponder and debate I think. It brings up a lot of good ideas/tactics too. I was just thinking about the second part of your reply a little. For the sake of simplification, I think we should just ignore terrain for the time being. Yes, it plays a role (sometimes huge), but it eliminates quite a few variables to arrive at some sort of conclusion. What would you think about a testing scenario where a soldier with 0% FA (standing on flat level ground) fires at a static object (such as a soldier who can't be hurt)? I'm thinking about using Bomb Bloke's numerical tileset as the substituted desert terrain and then firing about 100 or so rounds and looking at the overall damage done to the terrain by inspecting the numbers. Then you could see any potential "hot zones" where shots may hit more often for example, or even just concentrate on the normal damage area of the weapon and look for hot zones in there. Might be an interesting trial to run. Your thoughts? --[[User:Zombie|Zombie]] 15:22, 2 March 2009 (CST)

I think that sounds great! It would be great to build up a 2D (or even 3D) histogram of where the shots landed. Tweak an autocannon so it has 250 rounds for ease. Work it from a standard range of say 10 or 20. It would also be interesting to see the results at an accuracy of 50%. From data like that you could definitely get some kind of rule of thumb to estimate the good and bad effects of misses. Cool! [[User:Spike|Spike]] 15:39, 2 March 2009 (CST)

===Rocket Launcher Firepower Incorrect===
Hi Spike, on the [[title=Firepower_Tables|Firepower Tables]] it seems the Rocket Launcher is incorrectly computed. This might have been fixed in the alien specific firepower tables, point blank, etc, I don't yet know (and I dont have an xls viewer at the moment, either). However, at skirmish range, when the Launcher is 45%, 75% TU for snap and aimed, respectively, and 55% and 115% on accuracy, how can aimed fire have more than twice the firepower of snap? I ran the numbers and both aimed and snap were run at 75% TU usage. Furthermore, damage on aimed, small and large rockets, is exactly 75% of the actual average. The damages should read 46 and 58 for small rockets and 61 and 77 for large. --[[User:Talon81|Talon81]] 04:29, 15 May 2009 (EDT)

I bet I know why, talon. It's cause the Rocket Launcher can only fire once per turn, on snap. And once per turn, on aimed. Tadaa... [[User:Jasonred|Jasonred]] 14:00, 15 May 2009 (EDT)

: That very well may be the cause, but that is something to apply to the "sustained rates" chart, and not the Instantaneous Rates chart. On the Instantaneous Rates chart, it is figured as if you could use every TU. --[[User:Talon81|Talon81]] 14:17, 16 May 2009 (EDT)

== Large Units and Fire ==

If I'd remembered earlier I would've piped up about this, but I recall years ago when I set up a savegame for Zombie to test damage done to sectopod quarters, I physically split a sectopod into its various quarters by moving its individual unitpos segment coordinates to different locations around the map. Blasting one quarterpod with incendiary rounds set fire to all the others, even though they weren't in the same locality. This referring to the unit sticky fire, not the ground fire. Can't remember if it uses the same "apply this effect to the next four segments" rule that messed up the mind control of large units in TFTD though. -[[User:NKF|NKF]] 02:20, 16 March 2009 (EDT)

User talk:Spike

2009-05-15T08:29:33Z

Talon81: /* Weapon Analysis */

== Message Board ==

----

By any chance, have you taken another look at [[User talk:Bomb Bloke#Rated Accuracy Vs Angle Range |my talk page]] since your return?

Yes yes, I'm lazy and should really be able to interpret the data myself... But I can only really get as far as saying "that's not a linear distribution" and then my lack of understanding re what all the trig functions are for leaves me stranded. :/

- [[User:Bomb Bloke|Bomb Bloke]] 09:20, 10 April 2009 (EDT)

: Sorry what with starting a new job, moving, Easter, I've been a bit busy. Did you say you still had the original data? You sent me it in an Access database, is that right? It all seems a long time ago! [[User:Spike|Spike]] 16:28, 14 April 2009 (EDT)

I don't remember sending you the data specifically (I certainly haven't done so within the last year), but you can find it all linked on my talk page now. - [[User:Bomb Bloke|Bomb Bloke]] 22:31, 14 April 2009 (EDT)

== Apocalypse Blog QA ==

Uncle NKF to the rescue!

Don't ever unload troops at the mission site. To select which agents go into a mission, just highlight them before picking the attack or investigate button or click on the vehicle name to select them all. Get into this habit - always.

The reason why will become incredibly apparent if you play long enough to do an alien dimension building. The moment you complete the mission, the alien building will collapse and your ship will take off automatically (as per standard practice). However, the kicker is that you'll never be able to land at the building site again. This will result in forever stranding any troops that did not get killed by the building crashing down around them.

----

Alien's won't attack a dead body on purpose, though HE explosions caused by nearby combat will certainly destroy them. Watch where you are fighting. Also some enemies tend to pick up anything that's not bolted down, and may even carelessly wander towards one of the area exit pads. It happens - so be vigilant!

----

Dual-Wield does penalise your accuracy, and depending on some weapons, will slow you down considerably. The only reason to dual weild is as you say: to increase volume of fire. If you're like me and like close range combat (you'll find a lot of this in some buildings), then you want to get out as much firepower as you can because the enemy will have just as much of an advantage at such a close range as you do (and there's often more of them than you or they have one-hit big-bang weapons like the Poppers!). Out in the open, single weapons with aimed shots get better results - until you are so accurate that you don't even feel the penalty.

The game's super weapons are easy enough to be effective without dual-wielding as they're ramped up to be the best weapons available. In fact, most people make do with just one devestator or toxigun and cloak combo exclusively.

----

Apocalypse uses the volume of ''successful hits'' to determine accuracy improvements. The M4000 just gets lots of hits in, while the laser sniper rifle may hit a few times. By the way, aimed + dual M4000 garners more accuracy for a slightly slower fire rate than full-auto, allowing you to not waste as much ammo. Not as accurate as one M4000 on aimed or as fast as dual M4k's on full auto.

Plasma gun ammo is scarce at first, but you do have the option of attacking your enemies like the Cult of Sirius and win some off their fallen brethren. In fact, a lot of items that don't get released until a week or two in can be won off raiding enemy organizations. Better to get a good start than try to hobble along. I'd recommend <strike>stealing</strike> borrowing a power sword too.

The Autocannon with AP shells is one of the most powerful non-explosive ranged weapons you can buy. Stronger than the plasma gun and the ammo is easier to obtain. I'd actually recommend only carrying 1 HE and 1 Incendiary clip and carry AP as your primary clips. Beside, you don't want to do too much property damage with the HE rounds (companies don't mind the burning corpses of civilians - they could go hostile towards X-Com if you track too much dirt on their carpets). The HE and In clips are for special uses, like blasting brainsuckers off if you're on your own, or to wipe out hyperworm mobs. Incendiary can be break up tight mobs of enemies, etc. The AC will however be very slow in turn based - so if that's what you play then it may not suit you very well.

----

Psi is a long term investment in Apocalypse. You only earn 3 times your base Psi stats. Hence humans will only ever be useful for low level simple attacks like probes. Hybrids will be your core psi users. Even then they may not be able to do much at the start. They need plenty of uninterrupted practice time in the psi lab before their skills pay off (when I say uninterrupted, I mean: no health loss when the clock ticks over midnight).

Psi may not be immediately useful, but they come into their own once they've built up their stats and can easily strip enemy anthropods or human guards of their disrupter shields in a flash while setting all of their carried grenades to explode on impact with the ground and dropping them.

The only time I've ever got a neutral organization hostile towards me when doing psi practice was when one of my psi troopers mind controlled a gangster then made him jump off the building. When he hit the ground, the gangster was still under my psi trooper's control. The loss in health was attributed to X-COM, and they started shooting. However, if my psi trooper had broken the psi link before the gangster hit the ground, the gangster would've eventually died of critical wounds (or the impact), and the psi trooper would've been free to roam about the map as if nothing happened. A morbid way of killing neutrals and not getting blamed for it.

Stun attacks will have the same effect as you'd get with stun gas or a stun grapple (marvelous weapon by the way - bounces of shields but still great for conserving ammo).

Psi attacks require line of sight. Breaking line of sight breaks the link.

Yes, psi attacks expend Psi Energy, a rechargeable resource. In turn based, psi attacks are generally a one time expense. In real-time, you are charged by the attack attempt. If successful, you'll start paying maintenance costs for as long as you maintain the psi link. You can break the link by going out of line of sight or readying another psi attack. Check the mind bender's information panel for the psi energy bar. Stun and panic for example require you to maintain the link long enough for stun increase or morale loss to take place. Probe lets you access the enemy information any time you want as long as the probe is in effect. Mind control lets you control the unit for as long as you want, but is also the most expensive in costs and maintenance. To make the best use of it, try not to spend any maintenance costs at all. Pause the game, control the enemy, go to their inventory and wreak as much a havoc as you can (for example: arm grenade. Right click grenade, then 'drop' the grenade). Once done, break the MC link and let time run and watch the fireworks.

-[[User:NKF|NKF]] 00:47, 16 October 2008 (CDT)

Dual Wield is useless in Turn Based. And when it comes to the M4000, I play turn based! Switch to autofire, and you only spend 1 TU per shot! Wildly inaccurate? Then sneak in ninja style and shoot everyone at point blank! OWNAGE! Note: Might need grenades for when you round the corner thinking there's only 1 guy and find there's half the Cult of Sirius hiding in the room.
One of my favourite Dual Wields in Apocalypse is Autocannon with HE ammo, autofire, and Marsec Flying Armor. Only to be used when collateral damage is not an issue. Or in the case of COS raids, collateral damage is preferred!
Of course, in real life, dual wielding large weapons like that will lead to such a loss in aiming control that you are very likely to shoot yourself in the hands.

= Realistic UFO Economics an Oxymoron? =

... Trying to form "realistic" economics in UFO defense is just ridiculous. Capturing one intact Medium Scout should realistically give enough cash to outfit an entire platoon of elite soldiers with all the best equipment money can buy. The power source+Elerium should rightfully be worth enough to buy a fleet of Interceptors. Instead, it gives $250k+$250k... not even enough to rent 1 interceptor for 1 month! [[User:Jasonred|Jasonred]] 08:01, 28 February 2009 (CST)

Yeah you're right about realistic UFO economics. :) But we do try. It's still good to try to smooth out the more flagrantly illogical aspects, and to try and level out the game balance. Removing Exploits goes a long way to making the economic aspects of the game better. For improving realism, I think one of the best things we came up with - working with Hobbes - is the idea that X-Com has a fixed-price "tarrif" for all the alien loot it hands over to the Council, established in the X-Com Constitution. This explains why there is no "free market" in the prices of alien items, because as you say, the prices of certain items ought to be astronomical. The other 'hard problem' in UFO economics is one that you highlighted in a recent post - why aren't the resources of the whole world harnessed, budgets in the billions etc. This is harder to explain away, you need a mixture of reasons/excuses. Some of the more useful excuses are - need for secrecy keeps the operation small scale (and as you also recently pointed out, the aliens seem to 'conspire' to keep the conflict small-scale); Earth governments are playing a 'double game' and don't want to risk offending the aliens by funding X-Com heavily, in case X-Com loses and the aliens punish them for supporting X-Com; Earth governments are not convinced that the Alien threat is real. (Obviously they can easily be convinced the Aliens are real, and are violent, but are they really a 'threat' to governments, or can deals be done - in a way this is like the 'double game' argument.) [[User:Spike|Spike]] 08:51, 28 February 2009 (CST)

==Weapon Analysis==

While I'm sure I was wondering about something. When you do Weapon Analysis for HE, I'm guessing you figure a GZ attack against the Under Armor. However, do you also factor in that Large units take nearly 4x damage from an HE attack, since they get hit on every square they occupy? [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:40, 1 March 2009 (CST)

: Indeed I do. I calculate the other 3 squares of GZ+1 effect in some detail, including getting the averages right (which as you know is slightly tricky). One thing I don't calculate is the effects of any near misses. So the figures I give should be taken as a minimum. In practice, HE effectiveness will be somewhat higher due to the near misses - but by how much? It depends on a lot of factors, some I don't know and some that are highly variable (terrain density etc). [[User:Spike|Spike]] 03:55, 2 March 2009 (CST)

Hi Spike, to quote you from your user page:

<table width="75%" {{StdCenterTable}}><tr><td align="left">One more problem with modelling Near Misses: the benefit of lucky near misses - whatever its value - is inversely proportional to overall accuracy. A perfect shooter gets exactly zero benefit from near misses. Which raises an interesting possibility. Maybe the "near miss benefit" could be estimated using a repeated experiments with a logger and a shooter with Firing Accuracy=0. Any damage done to the target would be due to a lucky near miss. This would be the other limiting case - the opposite of the perfect shooter. Then extrapolate between those two extremes to find a "near miss benefit" for that weapon as some function of {TA, range].</td></tr></table>
You bring up some interesting ideas on near misses. But wouldn't the benefits of 0% accuracy (leading to unintended splash damage) be negated by the probability of the soldier shooting himself? I would think that would be a major consideration when taking stuff like this into account. I should also mention that a soldier with max firing accuracy (125%) can pinpoint where shots should hit, thus the shooter intentionally doesn't aim for one target but the center of a group of targets thus creating a "near miss benefit" scenario. What do you think about this? --[[User:Zombie|Zombie]] 12:45, 2 March 2009 (CST)

---

Great points Zombie. On the soldier shooting himself, I was wondering if we could just assume, as a simplication, that 'bad misses' (friendly fire casualties, including self-inflicted damage) even out with 'good misses' (lucky near misses). That would be much simpler! I have no idea if it's true though. Certainly if doing this logger exercise, you would want to distinguish damage done to self vs damage done to target. Actually, it's not really adequate to just 'net out' friendly damage vs target damage. After all, we expect weapons to do more damage to the enemy than to ourselves! So you might want to subtract 2, 3, 4... 10 times the friendly damage from the 'target' damage when determining the 'net benefit' from inaccurate fire.

It's a good point about the marksman firing at a midpoint, and of course that's a tactic we probably all try to use from time to time. In fact it's often frustrating when the game won't let you target a certain optimum point just because there's no object or creature there. These situations are slightly easier to model mathematically - though still cumbersome - because with a super-marksman you know exactly where the shell is going to land. The bit I really can't get my head around in the normal case (average accuracty) is the probability of all the different squares where the round might end up. I know there is some experimentatal data around with error angles but... I guess I'm trying to talk myself into the view that the terrain features are more important than the error angles, therefore it's not worth doing all the heavy math to figure out the effect of the error angles. :)

For the time being I'm probably just going to add a Note to my weapon rankings tables saying "Does not consider the beneficial or harmful effects of misses, near-misses, etc".

[[User:Spike|Spike]] 14:51, 2 March 2009 (CST)

:Stuff like this is always fun to ponder and debate I think. It brings up a lot of good ideas/tactics too. I was just thinking about the second part of your reply a little. For the sake of simplification, I think we should just ignore terrain for the time being. Yes, it plays a role (sometimes huge), but it eliminates quite a few variables to arrive at some sort of conclusion. What would you think about a testing scenario where a soldier with 0% FA (standing on flat level ground) fires at a static object (such as a soldier who can't be hurt)? I'm thinking about using Bomb Bloke's numerical tileset as the substituted desert terrain and then firing about 100 or so rounds and looking at the overall damage done to the terrain by inspecting the numbers. Then you could see any potential "hot zones" where shots may hit more often for example, or even just concentrate on the normal damage area of the weapon and look for hot zones in there. Might be an interesting trial to run. Your thoughts? --[[User:Zombie|Zombie]] 15:22, 2 March 2009 (CST)

I think that sounds great! It would be great to build up a 2D (or even 3D) histogram of where the shots landed. Tweak an autocannon so it has 250 rounds for ease. Work it from a standard range of say 10 or 20. It would also be interesting to see the results at an accuracy of 50%. From data like that you could definitely get some kind of rule of thumb to estimate the good and bad effects of misses. Cool! [[User:Spike|Spike]] 15:39, 2 March 2009 (CST)

===Rocket Launcher Firepower Incorrect===
Hi Spike, on the [[title=Firepower_Tables|Firepower Tables]] it seems the Rocket Launcher is incorrectly computed. This might have been fixed in the alien specific firepower tables, point blank, etc, I don't yet know (and I dont have an xls viewer at the moment, either). However, at skirmish range, when the Launcher is 45%, 75% TU for snap and aimed, respectively, and 55% and 115% on accuracy, how can aimed fire have more than twice the firepower of snap? I ran the numbers and both aimed and snap were run at 75% TU usage. Furthermore, damage on aimed, small and large rockets, is exactly 75% of the actual average. The damages should read 46 and 58 for small rockets and 61 and 77 for large. --[[User:Talon81|Talon81]] 04:29, 15 May 2009 (EDT)

== Large Units and Fire ==

If I'd remembered earlier I would've piped up about this, but I recall years ago when I set up a savegame for Zombie to test damage done to sectopod quarters, I physically split a sectopod into its various quarters by moving its individual unitpos segment coordinates to different locations around the map. Blasting one quarterpod with incendiary rounds set fire to all the others, even though they weren't in the same locality. This referring to the unit sticky fire, not the ground fire. Can't remember if it uses the same "apply this effect to the next four segments" rule that messed up the mind control of large units in TFTD though. -[[User:NKF|NKF]] 02:20, 16 March 2009 (EDT)

Heavy Cannon vs Auto Cannon

2009-05-06T16:25:21Z

Talon81:

*The Heavy Cannon in general has 50% better firepower (effective damage per turn) than the AutoCannon against lightly armoured targets. This advantage increases further against more heavily armoured targets.
*The HC is significantly cheaper to own and operate than the AutoCannon - around half price.
*HC is superior in reaction fire (snap fire) firepower.
*Generally the HC has the best first-shot-kill probability - very important when aliens can reaction fire with plasma weapons on Auto against lightly armoured troops!
*Heavy Cannon is the best starting sniper weapon vs well armoured targets. The Pistol is better, but only against lightly armoured targets. The HC is superior to all others in this regard, even the Laser Pistol. It is only beaten when the Laser Rifle appears.
*HC generally has much greater terrain-clearing capabilities than AC (both AP and HE). HC will tend to destroy objects that the AC would not. However, the AC on Auto-Fire will cover a greater area destruction.
*The HC can step up to tackling Mutons, with some degree of success. HC-AP has double the Autocannon's effective firepower against Mutons, and HE (the best round vs Mutons) is 20-40% more powerful (20% vs AC auto, 40% vs AC snap).
*AC-HE or AC-AP on auto is so inaccurate as to be barely more effective than snap shot. HC snap fire is much more effective than AC snap or auto.
:Actually, auto fire with the AC is just as effective as snap fire with the HC until you get past (roughly) 20 spaces from your target (see [[title=Firing_Accuracy_Testing#Test1: Benchmark|Firing Accuracy Testing]]). The firepower ratings given on the [[title=Firepower_Tables|firepower table]] are most accurate at that range. So, anything closer than 20 spaces is going to actually give a benefit to the AC on auto fire.
*However in the rare cases where AC-HE auto can be used without regard to accuracy (point blank range in Power Armour, or short range with targets against a strong wall), total firepower is about 60% higher than HC-HE.
*Similiar to the walls, HEIGHT makes Autocannnons with HE much more powerful. Shooting from higher ground/ Flying Armor will turn an Autocannon with HE into an extremely deadly weapon.However, it has the side-effect of destroying a lot of precious alien equipment, when an enemy dies from the first shot, drops his equipment and corpse, and the 2nd shot wipes out all the bounty.
:*Actually, since plasma weapons(the most valuable alien items) are [[Explosions#Object_Destruction|difficult to destroy]], this isn't as big an issue as it may seem, since the Auto Cannon can do 44 damage at ground zero, a dead on hit on the killed alien will still leave its primary weapon, since damage vs. objects is not randomized. At one space away, the Blaster Launcher will also survive. However, the body, any grenades, and any spare clips will be destroyed unless your soldier botches the shot by 3 squares or more(2 squares for the body.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:19, 16 February 2009 (CST)
*The main advantages the Auto Cannon has over the HC are its 2.33 times greater ammo capacity.
*Conversely the main downside of the HC is the 6-rd ammo limitation, and its implications for Encumbrance, total ammo capacity, diversity of ammo types per soldier, inventory slots used, and use of the 80-item limit. For small squads (eg 6 man) this will lead to Weight/Encumbrance problems carrying enough ammo to finish the mission. For large squads (14 man) this is less of a problem but still puts quite a strain on the 80-item limit.
* The AutoCannon has definite specialist roles where it is superior to the HC, such as illuminating with IC. AC-HE on auto can also be more effective for mass clearance of deep (but light) cover.

*If using the Incendiary Exploit, the Autocannon gains relative to the HC, as it can fire more rounds (doing fire damage to multiple units each time), and arguably it can make more effective use of the limited number of map squares that can be on fire, due to its smaller burst radius.

*The biggest drawback to all heavy weapons is weight restrictions or the resulting TU penalty from encumbrance. For the HC 81% of starting rookies can carry it (unencumbered) with 1 extra clip, 52% with 2 extra clips and 24% with 3 extra clips. (The first clip of any weapon, usually AP, is loaded automatically and "weight free" during the Equip Troops phase, unless you change or unload it ). As for the Auto-Cannon, 81% can carry it with 1 more clip, 57% with 2 more clips and 33% with 3 more clips.

Note:

"Firepower" as used here is defined as "average armour-adjusted damage delivered on target per unit of time".

Research

2009-05-03T06:31:16Z

Talon81:

'''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]] technology, [[armour]], [[Base Facilities|base facilities]], interception and transport [[craft]], 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 [[Alien Research#Cydonia or Bust|winning the game]].

== Research Costs ==

You start the game with one [[Laboratory]] and 10 Scientists. You will want to add 40 additional Scientists when space and money permit, so as to unlock new technology as soon as possible. This is expensive: 40 Scientists have a hiring cost of $2.4 million (and a monthly salary of $1.2 million), and require the addition of a new [[Living Quarters]], at a cost of $400,000.

An additional Laboratory, Living Quarters, and 50 Scientists (for a total of 100) is recommended when you can cobble together an additional $4.2 million, so as to unlock all useful alien technologies within the first few months of the game.

Many of the game's most important research topics require the capture of certain specific live aliens, so it is recommended you start building an [[Alien Containment]] at the very beginning of the game. As few as three aliens need to be captured and researched to ultimately unlock all the critical research topics which are dependent on alien captives. See [[#The Minimum Three|The Minimum Three]] for more details.

== Initial Research Projects ==

You are given [[Weapons#Laser_Technology|Laser Weapons]], [[Medi-Kit]]s, and [[Motion Scanner]]s as research topics at the beginning of the game. Every subsequent research topic becomes available by completing a previous research topic, or by capturing new technology found on the battlefield. You cannot research any given alien item until you have a sample of it in your possession.

Alien artifacts from the battlefield cannot be [[manufacture]]d or used (or even thrown!) by your soldiers until they have been fully researched. In fact, you start the game unable to manufacture any items until you have completed your first research topics.

X-COM commanders differ on which technologies are best researched first, although the initial three topics are all good choices. [[Laser Rifle]]s are an enormous improvement over standard armaments, particularly against [[Cyberdisc]]s, the toughest early foe. Laser weapons are reasonably powerful and do not require ammunition, making them useful for the duration of the game.

[[Medi-Kit]]s are rapidly researched and of great utility, especially once your soldiers are outfitted with armor. [[Personal Armor|Armor]] technology is also a high priority, although it is relatively time-consuming to research and subsequently manufacture.

[[Motion Scanner]]s can help you pinpoint the location of your foes, and are the most profitable item that can be manufactured in the early game. (See [[Manufacturing Profitability]].)

After your first [[UFO Ground Assault|combats]], advanced alien weapons become available for research. [[Heavy Plasma]], [[Small Launcher]], and [[Blaster Launcher]] (if you can find one) are all popular early research choices.

Commanders who wish to supplement their incomes by manufacturing profitable items should research [[Laser Cannon]]s early on, as they are the most profitable production item in the entire game.

Once you manage to capture an alien [[Navigator (Alien Rank)|Navigator]], you should research it as soon as possible, as the [[Hyper-wave Decoder]] it unlocks is an invaluable technology. Researching a psionically-enabled alien (a psionic [[Sectoid]], which means either a [[Leader (Alien Rank)|Leader]] or [[Commander (Alien Rank)|Commander]] or any [[Ethereal]]) should also be a top priority, as [[psionics]] becomes an enormous factor as the game progresses.

== The Minimum Three ==

You only need to capture three live aliens to unlock the research topics that will allow you complete the game. These three aliens are, in the following order:

#Any ''random alien''
#Any ''Leader or Commander''
#Any ''Commander''

By studying these three aliens, you can unlock the end-game mission [[Alien Research#Cydonia or Bust|Cydonia or Bust]]. These same three aliens can be used to unlock all additional technologies dependent on alien captives by altering the list as follows:

;[[Hyper-wave Decoder]]
: Substitute "any ''random alien''" with "any ''Navigator''"

;[[Psionic Laboratory]]
: Make sure your captured Leader or Commander is [[Sectoid]] or [[Ethereal]]

Thus, to unlock all technology that matters, you only need to research:

#Any ''Navigator''
#''Sectoid or Ethereal Leader/Commander''
#Any ''Commander''

Studying any alien (including the above three) can also produce a variety of [[UFOpaedia]] entries, such as alien species information, UFO stats, and alien mission types, which also adds to your [[scoring#Research|score]]. See [[#Researching aliens|Researching Aliens]] for more details.

The minimum alien artifacts needed for research to win the game are:

#UFO Power Source
#UFO Navigation
#Alien Alloys
#Elerium-115.

The absolute minimum amount of Elerium-115 needed will vary depending on whether you found 2 UFO Power Sources or had to manufacture one. (you need 2 to build an Avenger)(It costs 16 Elerium to build a power source)
You also need 12 Elerium to fuel the Avenger, UNLESS you take advantage of an exploit which allows you to fly an aircraft with 0 fuel.
Since Elerium is found pods of 50 units each, you only need to capture 1 single pod of elerium.

== How To Capture Live Aliens ==

Capturing the above three aliens, especially early on in the game, can be difficult. However, [[Mind Probe]]s can make it much easier to single out specific aliens, and once you get [[Small Launcher]]s, things are pretty easy. Be sure to build an [[Alien Containment]] at the beginning of the game, and don't bother to capture any aliens alive until it's built.

Using [[Stun Rod]]s is tricky, except when you can sneak up on an alien from behind. However, sending a swarm of rookies with Stun Rods into a UFO can be worth it in order to capture that first Navigator. Don't attempt this if there are multiple aliens facing your soldiers -- you will get shot to pieces.

If you spot an alien with a Small Launcher, you can often get him to knock himself out by walking up to him point-blank and letting him shoot you next turn.

Occasionally you will simply get lucky -- conventional weapons can deal a small amount of stun along with a lot of conventional damage. Current opinion and testing shows that aliens may be immune to [[stun]] due to smoke inhalation.

When an alien is [[unconscious]], you can see what rank it is by standing over it and picking it up. Bring the most desired aliens back to the transport and have a sentry with a Stun Rod watch over them in case they wake up again. If your Containment is getting full, any undesired aliens can be killed while unconscious using any form of [[grenade]] or HE ammunition.

== Research Tips ==
In principle, doubling the number of scientists means you get the results in half the time. In reality, because of rounding errors, it is better to run several small projects in parallel. The again, small projects may take a long time to complete. Don't be shy of pooling your entire workforce on a single project if you want to get quick results.

Scientists at different bases cannot pool their efforts: if you have two bases work on the same project, it will take as long to complete as if you had only base working on it. If possible, you should build all your laboratories at a single base to allow all your scientists to focus on one project at a time.

You cannot begin researching any alien technology unless you have a sample of it on base. However, once you begin research, you do not need to keep the sample on hand. If you begin every project as soon as it becomes available to you, you can sell off all alien items (including alien corpses) which you do not wish to keep around. (You can also transfer aliens to another base's Containment unit after you have begun researching them.) You do not need to assign any scientists to a project to begin it: only assign your scientists to whichever project you wish to complete next.

If you build two labs and hire 100 scientists as soon as you can afford it, you can research all the most desirable alien technologies within 7-8 months (by July or August). With three labs and 150 scientists, you can research all the best stuff by June or so. More scientists than this will not appreciably speed your progress.

== Popular Research Sequences ==

Research time is given in total Scientist days and average days needed for one Laboratory (50 Scientists). Two Laboratories (100 Scientists) will take approximately half as long. The listed times are averages: actual research times will take between 0.5 and 1.5 times as long (see [[#Research time: notes|Research time: notes]] for more details).

A <tt>-></tt> before an entry signifies the total time required to complete that project. For example, Laser Pistol requires Laser Weapons (50 days) + Laser Pistol (100 days); <tt>-></tt>Laser Pistol is 150 days.

<big>'''Laser Pistol'''</big>

An option which should not be overlooked. Researched extremely quickly, 53% more damaging than than a basic [[Rifle]], one-handed, fastest rate of fire of any weapon (good for scouts), can be manufactured for [[Manufacturing Profitability|profit]]. Good for covering the span before you get [[Laser Rifle]]s or [[Heavy Plasma]]s they remain useful for the entire game. Laser Pistols are an excellent secondary weapon to attach to your belt in case you run out of ammo, [[Morale#Panicking_and_Berserking|forced to drop your main weapon]], or want to [[Reaction Training|train reactions]].

Laser Weapons 50 1.0 day
[[Laser Pistol]] 100 2.0 days
'''Total: 150 3.0 days'''

<big>'''Laser Rifle'''</big>

Respectable damage, no ammo required. A good alternative to [[Heavy Plasma]] for some of your troops.

->Laser Pistol 150 3.0 days
[[Laser Rifle]] 300 6.0 days
'''Total: 450 9.0 days'''

''or'' '''Laser Pistol + 6.0 days'''

<big>'''Laser Cannon'''</big>

A poor Craft weapon, but the most [[Manufacturing Profitability|profitable]] item in the game. Completing this research topic also permits you to build [[Tank/Laser Cannon]]s, which have a much more powerful weapon than Cannon and Rocket tanks, and are effective against several dangerous units, particularly [[Sectopod]]s.

->Laser Rifle 450 9.0 days
[[Heavy Laser]] 460 9.2 days
[[Laser Cannon]] 420 8.4 days
'''Total: 1330 26.6 days'''

''or'' '''Laser Rifle + 17.6 days'''

<big>'''Small Launcher'''</big>

Small Launchers make capturing aliens a snap, and have surprisingly broad tactical use. One stun bomb can knock out several weak aliens at once, and unlike explosives, they are safe to use in confined quarters. Furthermore, stun bombs do not damage equipment, making for potentially higher [[UFO Recovery Values]]. Stun bombs are also quite effective against 4-space terror units (Reapers, Cyberdiscs, and Sectopods) due to each square taking partial damage from the stun blast.

[[Small Launcher]] 550 11.0 days
[[Stun Bomb]] 180 3.6 days
'''Total: 730 14.6 days'''

<big>'''Heavy Plasma'''</big>

Just about the best weapon in the game. There's a reason why every alien eventually carries one of these.

[[Heavy Plasma]] 800 16.0 days
Heavy Plasma Clip 400 8.0 days
'''Total: 1200 24.0 days'''

<big>'''Plasma Beam'''</big>

The best Craft weapon, 100% effective against everything except [[Battleship]]s.

->Heavy Plasma 1200 24.0 days
[[Plasma Beam]] 660 13.2 days
'''Total: 1860 37.2 days'''

''or'' '''Heavy Plasma + 13.2 days'''

<big>'''Blaster Launcher'''</big>

When you absolutely, positively, have to kill every alien in the room. Accept no substitute.

[[Blaster Launcher]] 900 18.0 days
[[Blaster Bomb]] 300 6.0 days
'''Total: 1200 24.0 days'''

<big>'''Fusion Ball Launcher'''</big>

Useful against [[Battleship]]s when using multiple crafts; use Plasma Beam otherwise.

->Blaster Launcher 1200 24.0 days
[[Fusion Ball Launcher]] 880 17.6 days
'''Total: 2080 41.6 days'''

''or'' '''Blaster Launcher + 17.6 days'''

<big>'''Fusion Ball Defences'''</big>

The most compact base defense facility besides the [[Mind Shield]] -- although a proper [[Base Layout Strategy|base layout strategy]] is probably better still.
Due to a weird programming logic, once aliens have discovered your base, they MUST launch a ground attack. If the first battleship is blown up by air defences, they will just send another... and another... and another... ad infinitum. Furthermore, these appear to STACK, so you can end up watching the the base defense screen several times a month a month and getting sick of it. Making Fusion Ball Defences and Grav Shield ultimately useless.

->Fusion Ball Launcher 2080 41.6 days
[[Fusion Ball Defences|Fusion Defence]] 800 16.0 days
'''Total: 2880 57.6 days'''

''or'' '''Fusion Ball Launcher + 16.0 days'''

<big>'''Personal Armor'''</big>

Wearing this, you might actually survive a shot or two. But don't press your luck.

[[Alien Alloys]] 400 8.0 days
[[Personal Armor]] 180 3.6 days
'''Total: 580 11.6 days'''

<big>'''Power Suit'''</big>

You might survive a shot or three.

->Personal Armor 580 11.6 days
[[Elerium-115]] 450 9.0 days
[[UFO Power Source]] 450 9.0 days
[[Power Suit]] 205 4.1 days
'''Total: 1685 33.7 days'''

''or'' '''Personal Armor + 22.1 days'''

<big>'''Flying Suit'''</big>

A shot or three plus much greater visibility and mobility.

->Power Suit 1685 33.7 days
[[UFO Navigation]] 450 9.0 days
[[Flying Suit]] 330 6.6 days
'''Total: 2465 49.3 days'''

''or'' '''Power Suit + 15.6 days'''

<big>'''Firestorm'''</big>

Your first UFO. Unfortunately, a standard [[Interceptor]] armed with [[Plasma Beam]]s can often do just as well. This technology may be most desirable as part of the path to unlock Hovertanks.

Alien Alloys 400 8.0 days
Elerium-115 450 9.0 days
UFO Power Source 450 9.0 days
UFO Navigation 450 9.0 days
UFO Construction 450 9.0 days
[[Firestorm|New Fighter Craft]] 600 12.0 days
'''Total: 2800 56.0 days'''

However, there is high overlap between UFO technology and armor technology. Commanders will almost always research [[Power Suit]]s or [[Flying Suit]]s before embarking on UFO construction:

->Flying Suit 2465 49.3 days
UFO Construction 450 9.0 days
New Fighter Craft 600 12.0 days
'''Total: 3515 70.3 days'''

''or'' '''Flying Suit + 21.0 days'''

<big>'''Lightning'''</big>

A craft with unique properties -- but most prefer an [[Avenger]].

->Firestorm ''(via Flying Suit)'' 3515 70.3 days
[[Lightning|New Fighter-Transporter]] 700 14.0 days
'''Total: 4215 84.3 days'''

''or'' '''Firestorm + 14.0 days'''

<big>'''Avenger'''</big>

They don't call it the Ultimate Craft for nothing. Two or three Avengers plus a handful of Interceptors can give you complete air superiority over Terra. It also allows you to bring twice the manpower into battle than you could before. What's not to like?

->Lighting 4215 84.3 days
[[Avenger|Ultimate Craft]] 900 18.0 days
'''Total: 5115 102.3 days'''

''or'' '''Lightning + 18.0 days'''
''or'' '''Flying Suit + 32.0 days'''

<big>'''Grav Shield'''</big>

Combined with several [[Fusion Ball Defences]], a Grav Shield will make your base impervious to alien invasion. However, a [[Mind Shield]] and/or a secure [[Base Layout Strategy|base layout]] is a quite viable alternative. Immediately shooting down scout UFOs on [[Alien Missions#Alien Retaliation|Alien Retaliation]] missions will also prevent most attacks.
Due to a weird programming logic, once aliens have discovered your base, they MUST launch a ground attack. If the first battleship is blown up by air defences, they will just send another... and another... and another... ad infinitum. Furthermore, these appear to STACK, so you can end up watching the the base defense screen several times a month a month and getting sick of it. Making Fusion Ball Defences and Grav Shield ultimately useless.

->Lightning 4215 84.3 days
[[Grav Shield]] 930 18.6 days
'''Total: 5145 102.9 days'''

''or'' '''Lightning + 18.6 days'''

<big>'''Hovertank/Plasma'''</big>

A popular (and expendable) scout. Immune to Psi attacks, like all tanks. Produceable immediately after the completion of Firestorm and Plasma Beam research topics. Apparently, v1.0 has a bug where it is immediately available for construction after researching Plasma Beam, Elerium and Alien Alloys. In that case, you don't need the Firestorm topic.

->Firestorm 3515 70.3 days
->Plasma Beam 1860 37.2 days
'''Total: 5375 107.5 days'''

<big>'''Hovertank/Launcher'''</big>

In the field, it's less popular than the Plasma Hovertank due to the expense of its ammunition, which also does less damage than the man-portable [[Blaster Launcher]]. For base defense, the free Hovertank/Launcher ammo that is granted to you to protect the base turns this tank into the ultimate expendable defensive unit. It can be built immediately after the completion of the Firestorm and Fusion Ball Launcher research topics.

->Firestorm 3515 70.3 days
->Fusion Ball Launcher 2080 41.6 days
'''Total: 5595 111.9 days'''

<big>'''Psionic Laboratory'''</big>

Once you get [[psionics]], the aliens' days are numbered. It's tricky catching a Sectoid Leader or Ethereal, but the sooner you can, the better. With a psi lab you can separate the wheat from the chaff.

Any live psionic alien 192 3.84 days
[[Psionic Laboratory]] 420 8.4 days
'''Total: 612 12.24 days'''

<big>'''Psi-Amp'''</big>

Barely useful when [[Psionic Skill]] is low, but way too useful when it's high. A transport full of Psi soldiers is as scary to the aliens as the [[Ethereal]]s were at first to you.

->Psionic Laboratory 420 12.24 days
[[Psi-Amp]] 500 10.0 days
'''Total: 920 22.24 days'''

''or'' '''Psionic Laboratory + 10.0 days'''

<big>'''Mind Shield'''</big>

With a single Mind Shield at each base, the aliens will keep attempting [[Alien Missions#Alien Retaliation|Alien Retaliation]] missions, but most of them time, they'll zig-zag around, unable to find your base. Shooting down any Retaliation scout you see in addition will ensure that they almost never mount an attack on your base.

->Psionic Laboratory 420 12.24 days
[[Mind Shield]] 360 7.2 days
'''Total: 780 19.44 days'''

''or'' '''Psionic Laboratory + 7.2 days'''

<big>'''Hyper-Wave Decoder'''</big>

One of the most important technologies of the game. Build one at each base you own and you will be able to see just about every alien craft that enters the Earth's atmosphere. Every craft you intercept will please your funding nations, and can be worth millions in [[UFO Recovery Values|salvage value]]. A Hyper-Wave Decoder is your meal ticket: grab an alien Navigator the first chance you get.

Any live alien Navigator 192 3.86 days
[[Hyper-wave Decoder]] 670 13.4 days
'''Total: 862 17.26 days'''

<big>'''Cydonia'''</big>

Your final mission. Win it, and you are a savior; lose it, and humanity dies. You have to perform the research in this particular order, so don't forget to research The Martian Solution before you interrogate your first Commander, or else you'll have to capture another one. The same goes for your first Leader -- but if it's a Sectoid, research it immediately: the [[Psionic Laboratory]] is your absolute top priority. Once you get Psi soldiers, you can capture another Leader without much trouble at all.

In addition to completing these research topics, you must have an [[Avenger]] built before you can travel to [[Cydonia]]. The Avenger can be researched and built at any time, independent of the Cydonia-specific research topics. None of these topics are useful aside from unlocking Cydonia, so you can save most of it until you're ready to complete the game.

Any live alien 192 3.84 days
[[Alien Research|Alien Origins]] 300 6.0 days
Any live Leader 192 3.84 days
[[Alien Research|The Martian Solution]] 500 10.0 days
Any live Commander 192 3.84 days
[[Alien Research|Cydonia or Bust]] 600 12.0 days
'''Total: 1976 39.52 days'''
''plus''
->Avenger 5115 102.3 days
'''Total: 7091 141.82 days'''

<big>'''Stand-alone technologies'''</big>

In addition to the above research sequences, there are four useful technologies which have no research "dependencies" and can be studied directly. Medi-kits and Motion Scanners are two of the initially-available research topics (described [[#Initial research projects|above]]). Alien Grenades are a substantial improvement over the standard X-COM grenade, packing almost as much punch as a High Explosive, but far easier to carry and throw. Mind Probes can show alien rank and stats (useful for singling out Leaders and Commanders), although their usefulness is dwarfed by that of the Psi-Amp.

[[Medi-Kit]] '''210 4.2 days'''
[[Motion Scanner]] '''180 3.6 days'''
[[Alien Grenade]] '''200 4.0 days'''
[[Mind Probe]] '''600 12.0 days'''

= Technical Details =

== Research Trees ==

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.

== Researching Aliens ==

Researching live aliens will provide a variety of information. The type of information revealed is usually dependent on the alien's rank (or type).

Here is an overview of the research each alien type can produce:

*Any Live Alien: [[Alien Research#Alien Origins|Alien Origins]] and information on its own species
*Alien [[Soldier (Alien Rank)|Soldier]] or [[Terrorist (Alien Rank)|Terrorist]]: Nothing, beyond information on its own species
*Alien [[Medic (Alien Rank)|Medic]]: information on other [[#Alien species|alien species]]
*Alien [[Navigator (Alien Rank)|Navigator]]: [[#Alien missions|Alien missions]] and [[Hyper-wave Decoder]]
*Alien [[Engineer (Alien Rank)|Engineer]]: [[#Alien ships|Alien ships]]
*Alien [[Leader (Alien Rank)|Leader]] (or Commander): [[Alien Research#The Martian Solution|The Martian Solution]]
*Alien [[Commander (Alien Rank)|Commander]]: [[Alien Research#Cydonia or Bust|Cydonia or Bust]]
*Sectoid Leader or Commander, or any Ethereal: [[Psionic Laboratory]]

Researching a live alien will produce a "live alien" entry and can sometimes produce other [[UFOpaedia]] entries or even unlock new research topics, as detailed above. The first live alien of any type you study will unlock the [[Alien Research#Alien Origins|Alien Origins]] topic. Researching an alien will often produce no new UFOpaedia entries, if everything that could be learned from that alien type has already been discovered.

Most of the UFOpaedia entries generated by studying live aliens are of no intrinsic value, although sometimes they will provide insight into in-game alien behavior or characteristics. Sometimes the information provided is misleading. If nothing else, though, they are fun to read.

Each [[#Alien species|alien species]] (including autopsies), [[#Alien missions|alien mission]], or [[#Alien ships|alien ship]] entry added to the UFOpaedia will earn the player 50 points.

=== Alien Types ===

There are 29 different alien race/rank combos in the game:

*Sectoid Soldier, Medic, Navigator, Engineer, Leader, or Commander
*Snakeman Soldier, Navigator, Engineer, Leader, or Commander
*Ethereal Soldier, Leader, or Commander
*Muton Soldier, Navigator, or Engineer
*Floater Soldier, Medic, Navigator, Engineer, Leader, or Commander
*Celatid Terrorist
*Silacoid Terrorist
*Chryssalid Terrorist
*Reaper Terrorist
*Sectopod Terrorist
*Cyberdisc Terrorist

One does not need to capture all of the alien-rank combinations to produce every possible UFOpaedia entry in the game. Enough Medics, Navigators, and Engineers of any sort will eventually fill out your UFOpaedia completely (although you must study at least one Leader and Commander, as [[#The Minimum Three|detailed above]]).

=== Alien Missions ===

These UFOpaedia entries will be generated by researching alien Navigators. Captured Navigators may give information on mission types other than the type they were engaged in when captured.

*[[Alien Missions#Alien Research|Alien Research]]
*[[Alien Missions#Alien Harvest|Alien Harvest]]
*[[Alien Missions#Alien Abduction|Alien Abduction]]
*[[Alien Missions#Alien Infiltration|Alien Infiltration]]
*[[Alien Missions#Alien Base|Alien Base]]
*[[Alien Missions#Alien Terror|Alien Terror]]
*[[Alien Missions#Alien Retaliation|Alien Retaliation]]
*[[Alien Missions#Alien Supply|Alien Supply]]

=== Alien Ships ===

These UFOpaedia entries will be generated by researching alien Engineers. They do not unlock any technologies, but they do give detailed information about the performance characteristics of each ship, which can help players tailor their [[UFO_Interception|interception]] strategies. Captured Engineers may give information on ship types other than the type they were found on.

*[[Small Scout]]
*[[Medium Scout]]
*[[Large Scout]]
*[[Abductor]]
*[[Harvester]]
*[[Supply ship|Supply Ship]]
*[[Terror ship|Terror Ship]]
*[[Battleship]]

=== Alien Species ===

Studying any captive alien will produce a "live alien" [[UFOpaedia]] entry on that species, unless that entry already exists. Researching an alien corpse will produce an "Alien Autopsy" UFOpaedia entry on its species.

Researching alien Medics can produce "live alien" and Autopsy entries on species other than their own. (However, if the entry on live [[Ethereal]]s is produced in this manner it will not unlock the [[Psionic Laboratory]] research topic -- you must still study a psionic alien directly.)

There are 11 different alien species in the game, and 11 different Live and Autopsy entries can be generated. (Zombies can be thought of as a 12th alien species, although neither a corpse nor live specimen can ever be collected, and a UFOpaedia entry can never be generated on them.)

The two robotic units (Sectopods and Cyberdiscs) cannot be captured alive or studied directly. To generate a live alien UFOpaedia entry on them, you must research alien Medics of any other species.

*[[Sectoid]]
*[[Snakeman]]
*[[Ethereal]]
*[[Muton]]
*[[Floater]]
*[[Celatid]]
*[[Silacoid]]
*[[Chryssalid]]
*[[Reaper]]
*[[Sectopod]]
*[[Cyberdisc]]

== Research Time ==

The following is a list of all research topics in the game. Values taken from [[RESEARCH.DAT]].

=== Sorted alphabetically ===

{| {{StdCenterTable}} width="50%"
|- {{StdDescTable_Heading}}
! Man Days !! One Lab !! Research Project
|-
|400 || 8 ||align="left"| Alien Alloys
|-
|180 || 3.6 ||align="left"| Alien Corpses (each -- 11 different types)
|-
|150 || 3 ||align="left"| Alien Entertainment
|-
|150 || 3 ||align="left"| Alien Food
|-
|200 || 4 ||align="left"| Alien Grenade
|-
|300 || 6 ||align="left"| Alien Origins
|-
|150 || 3 ||align="left"| Alien Reproduction*
|-
|150 || 3 ||align="left"| Alien Surgery
|-
|300 || 6 ||align="left"| Blaster Bomb
|-
|900 || 18 ||align="left"| Blaster Launcher
|-
|600 || 12 ||align="left"| Cydonia or Bust
|-
|450 || 9 ||align="left"| Elerium-115
|-
|150 || 3 ||align="left"| Examination Room
|-
|330 || 6.6 ||align="left"| Flying Suit
|-
|800 || 16 ||align="left"| Fusion Defenses
|-
|880 || 17.6||align="left"| Fusion Missile (Fusion Ball & Launcher)
|-
|930 || 18.6||align="left"| Grav Shield
|-
|460 || 9.2 ||align="left"| Heavy Laser
|-
|800 || 16 ||align="left"| Heavy Plasma
|-
|400 || 8 ||align="left"| Heavy Plasma Clip
|-
|670 || 13.4||align="left"| Hyper-Wave Decoder
|-
|420 || 8.4 ||align="left"| Laser Cannon
|-
|510 || 10.2||align="left"| Laser Defenses
|-
|100 || 2 ||align="left"| Laser Pistol
|-
|300 || 6 ||align="left"| Laser Rifle
|-
|50 || 1 ||align="left"| Laser Weapons
|-
|192 || 3.84||align="left"| Live Aliens (except Terrorists and Sectoid Commander) (22 types)
|-
|190 || 3.8 ||align="left"| Live Sectoid Commander (go figure)
|-
|170 || 3.4 ||align="left"| Live Terrorists (4 types -- Reaper, Chryssalid, Silacoid, Celatid)
|-
|210 || 4.2 ||align="left"| Medi-Kit
|-
|600 || 12 ||align="left"| Mind Probe
|-
|360 || 7.2 ||align="left"| Mind Shield
|-
|180 || 3.6 ||align="left"| Motion Scanner
|-
|600 || 12 ||align="left"| New Fighter Craft (Firestorm)
|-
|700 || 14 ||align="left"| New Fighter-Transporter (Lightning)
|-
|180 || 3.6 ||align="left"| Personal Armor
|-
|660 || 13.2||align="left"| Plasma Beam
|-
|620 || 12.4||align="left"| Plasma Defenses
|-
|600 || 12 ||align="left"| Plasma Pistol
|-
|400 || 8 ||align="left"| Plasma Pistol Clip
|-
|700 || 14 ||align="left"| Plasma Rifle
|-
|400 || 8 ||align="left"| Plasma Rifle Clip
|-
|205 || 4.1 ||align="left"| Power Suit
|-
|500 || 10 ||align="left"| Psi-Amp
|-
|420 || 8.4 ||align="left"| Psi-Lab
|-
|550 || 11 ||align="left"| Small Launcher
|-
|180 || 3.6 ||align="left"| Stun Bomb
|-
|500 || 10 ||align="left"| The Martian Solution
|-
|450 || 9 ||align="left"| UFO Construction
|-
|450 || 9 ||align="left"| UFO Navigation
|-
|450 || 9 ||align="left"| UFO Power Source
|-
|900 || 18 ||align="left"| Ultimate Craft (Avenger)
|}

<nowiki>*</nowiki> Alien Reproduction is not ordinarily researchable unless you use an editor to add one your General Stores.

=== Sorted By Days Needed ===
{| {{StdCenterTable}} width="50%"
|- {{StdDescTable_Heading}}
!Man Days !! One Lab!! Research Project
|-
|50 || 1 ||align="left"| Laser Weapons
|-
|100 || 2 ||align="left"| Laser Pistol
|-
|150 || 3 ||align="left"| Alien Entertainment
|-
|150 || 3 ||align="left"| Alien Food
|-
|150 || 3 ||align="left"| Alien Reproduction
|-
|150 || 3 ||align="left"| Alien Surgery
|-
|150 || 3 ||align="left"| Examination Room
|-
|170 || 3.4 ||align="left"| Live Terrorists (4 types -- Reaper, Chryssalid, Silacoid, Celatid)
|-
|180 || 3.6 ||align="left"| Alien Corpses (each -- 11 different types)
|-
|180 || 3.6 ||align="left"| Motion Scanner
|-
|180 || 3.6 ||align="left"| Personal Armor
|-
|180 || 3.6 ||align="left"| Stun Bomb
|-
|190 || 3.8 ||align="left"| Live Sectoid Commander (go figure)
|-
|192 || 3.84||align="left"| Live Aliens (except Terrorists and Sectoid Commander) (22 types)
|-
|200 || 4 ||align="left"| Alien Grenade
|-
|205 || 4.1 ||align="left"| Power Suit
|-
|210 || 4.2 ||align="left"| Medi-Kit
|-
|300 || 6 ||align="left"| Alien Origins
|-
|300 || 6 ||align="left"| Blaster Bomb
|-
|300 || 6 ||align="left"| Laser Rifle
|-
|330 || 6.6 ||align="left"| Flying Suit
|-
|360 || 7.2 ||align="left"| Mind Shield
|-
|400 || 8 ||align="left"| Alien Alloys
|-
|400 || 8 ||align="left"| Heavy Plasma Clip
|-
|400 || 8 ||align="left"| Plasma Pistol Clip
|-
|400 || 8 ||align="left"| Plasma Rifle Clip
|-
|420 || 8.4 ||align="left"| Laser Cannon
|-
|420 || 8.4 ||align="left"| Psi-Lab
|-
|450 || 9 ||align="left"| Elerium-115
|-
|450 || 9 ||align="left"| UFO Construction
|-
|450 || 9 ||align="left"| UFO Navigation
|-
|450 || 9 ||align="left"| UFO Power Source
|-
|460 || 9.2 ||align="left"| Heavy Laser
|-
|500 || 10 ||align="left"| Psi-Amp
|-
|500 || 10 ||align="left"| The Martian Solution
|-
|510 || 10.2||align="left"| Laser Defenses
|-
|550 || 11 ||align="left"| Small Launcher
|-
|600 || 12 ||align="left"| Cydonia or Bust
|-
|600 || 12 ||align="left"| Mind Probe
|-
|600 || 12 ||align="left"| New Fighter Craft (Firestorm)
|-
|600 || 12 ||align="left"| Plasma Pistol
|-
|620 || 12.4||align="left"| Plasma Defenses
|-
|660 || 13.2||align="left"| Craft Plasma Beam
|-
|670 || 13.4||align="left"| Hyper-Wave Decoder
|-
|700 || 14 ||align="left"| New Fighter-Transporter (Lightning)
|-
|700 || 14 ||align="left"| Plasma Rifle
|-
|800 || 16 ||align="left"| Fusion Defenses
|-
|800 || 16 ||align="left"| Heavy Plasma
|-
|880 || 17.6||align="left"| Fusion Missile (Fusion Ball & Launcher)
|-
|900 || 18 ||align="left"| Blaster Launcher
|-
|900 || 18 ||align="left"| Ultimate Craft (Avenger)
|-
|930 || 18.6||align="left"| Grav Shield
|}
=== Research Time Notes ===

*'''One Lab''' is the number of Days divided by 50. This shows how quickly one lab full of 50 scientists needs to complete the Project, on average. Two labs full of scientists would need half this time on average, etc.
*This single check per day also means they will take a minimum of one day, except in special circumstances. Decimals are still shown for the '''One Lab''' column, however, so you can project to multiple labs and/or see where time is lost or gained by truncation (read on).
*The numbers shown in the tables are '''averages'''. In actuality, the time may differ by +- 50%. Laser Weapons may take anything from 25 to 75 man days, on average it's 50.
* Projects only progress and check completion '''at midnight''', so what scientists are doing – whether traveling between bases, on different projects or sitting in the coffee room unassigned – during the entire rest of the day is irrelevant. All that matters is what (if any) projects they are on at midnight.
* Each midnight, the game subtracts the number of man days according to how many men you have assigned to that project; the project is done when the counter reaches zero. If a project will require 31 man days and you have 10 scientists assigned, it will take four days to complete. By then you have spent (10 Scientists * 4 days = 40 man days) and effectively wasted nine. On the last day, you could withdraw nine scientists from the project; or you could have started it with only eight to begin with and still have researched it in four days. However, as there is no way of knowing how much time a project will really need, it's inevitable that a few man days will be wasted on every project.
* The efficiency increases as the number of scientists on a project decreases. If you run several projects in parallel, you'll waste fewer man days overall. In the extreme case, you'd assign only one scientist on every project and would be sure that not a single man day will be lost; however, it would also take months or even years to get anything done. You decide.
* Actually, all that matters is the last day; so you could at first assign many scientists and, once you feel that the project approaches conclusion, remove most of them. But without cheating, there's no way of telling.

==Research Progress==

The Progress part of the current Research screen will give you an idea of how things are going, but you will have to know how to read the information it is giving you.
<br>
<br>
<big>'''Unknown Progress'''</big>

The first part of understanding the progress report is knowing why a project has an Unknown progress. This happens whenever a project has more than 2/3rds of its '''average''' research time left. Examples:

* Laser Weapons average 50 Man Days (MDs), so if you have 34 or more MDs left then it will be listed as Unknown
* Psi Amps average 500 MDs, so if you have 334 or more MDs left then it will be listed as Unknown

Clearly this indicates an immediate fact that can be helpful (especially if you want to do some cheating), that if you create a project and assign even just one scientist to it and don't get Unknown, then you just got a good roll for the time required (more accurately, in the top 16.7% of possible results, or 1 in 6 projects). Let's walk through an example:
* Say a project has an '''average''' time of 120 MDs. Thus, it's roll can actually be 60 to 180 MDs.
* If you get the best possible roll - 60 MDs - the project is at 50% ''relative to the '''average''' time'' of 120 MDs. 50% is greater than a third, so it will not be at Unknown.
* The break-even point for a 120-average-MDs project would be a roll of 80 MDs. At 80, the algorithm thinks, "ok, 80 more MDs are needed; 120-80='''40''' MDs are gone, which is one third of 120 MDs. So it's not Unknown status any more."
* This range of 60 to 80 MDs is only one-sixth of the possible rolls for a 120 day project (60 to 180 MDs). Thus, you have to get in the top sixth of rolls to not see Unknown.
<br>
<big>'''Known Progress'''</big>

Okay, so eventually your project gets out of Unknown status due to the industrious sweat of your scientists and the progress of time (or alternately a bit of reloading of saves). Now we get back an actual progress rating of Poor, Average, Good or Excellent, and we need to understand what they mean.

Actual Progress ratings are related again to the average project durations for the item being researched, but this time as we know it is related to the number of scientists on the project. So simply divide the number of assigned scientists by average project research time and convert to a percentage:

Scientists assigned / Average ManDays required * 100 = Progress Rating

{| {{StdDescTable}} width="25%"
| {{StdDescTable Heading}} | Named Rating
| {{StdDescTable Heading}} | Progress Rating
|-
| Excellent || 26+
|-
| Good || 14 to <26
|-
| Average || 8 to <14
|-
| Poor || >0 to <8
|-
| None || 0
|}

Note the progress rating is equivalent to the percentage progress you would make if you happen to roll exactly average when starting a project, so an average Excellent project will be at most 4 days to complete (26%*4), but you have to factor in the random element - i.e., that you actually have a target of somewhere between 50% and 150%, so the range if you are just inside Excellent is 2-6 days, for example.

So to show against our previous examples, once they are not unknown:

*Laser Weapons have an average project time of 50, so 0 gives None, 1 to 3 gives Poor, 4 to 6 gives Average, 7 to 12 gives Good, and 13 or more gives Excellent
*Psi Amps have an average project time of 500, so 0 gives None, 1 to 39 gives Poor, 40 to 69 gives Average, 70 to 129 gives Good, and 130 or more gives Excellent

Note that the actual time left is not included in this calculation, so once it is out of unknown the progress seen on screen will only change if you change the number of scientists assigned.

We can also deduce the range of maximum times left from the ratings as well, although unknown and poor have too high a range to be meaningful really (although you can divide the values shown by the number of scientists you have assigned, and reduce it proportionality if you have a project shorter than Grav Shield).

{| {{StdDescTable}} width="25%"
| {{StdDescTable Heading}} | Named Rating
| {{StdDescTable Heading}} | Days Left
|-
| Excellent || 1 to 3
|-
| Good || 1 to 5
|-
| Average || 1 to 9
|-
| Poor || 1 to 620
|-
| Unknown || 1 to 1395
|-
| None || Infinite
|}

Notes: For Unknown 1395 is the worst roll on Grav Shield, and you might only have 1 man doing it, but on the other end for Laser Weapons you could have 34 Man Days left, but easily have that many scientists on it to complete it next midnight. For Poor it covers from a large range like Unknown, but you must have completed 2/3rds of it, so again for the highest average project time Grav Shield we get 930*(2/3), or 620. For long projects like Grav Shield you can be rated poor while having up to 74 scientists assigned due to their average time to complete being so high.

Of course really the only important thing here is that we are not seeing Unknown, at that point you know that you only have 2/3rds or less left, so at that point you can work it out more accurately just by: 66.7%/Progress Rating = Max Days left (round all fractions up). If you just started the project (or have never assigned anyone to it) you also know it is at least 50%, so 50%/Progress Rating = Min Days left at that point.

== Total Research Time ==

The total time needed to research all technologies is 21,215 days, plus another 576 to research [[#The Minimum Three|The Minimum Three]], plus another 6,500 or so to add every alien [[#Alien species|species]], [[#Alien ships|ship type]], and [[#Alien missions|mission type]] entry to the [[UFOpaedia]] (about 28,300 days total).

This can be compared against the total time needed for 1 Scientist, 50 Scientists (1 lab), 100 (2 labs), and so on. Numbers were composed by taking the average of the integer-truncated min and max for each project, then summing these together for all projects:

'''Note: the following figures are based on an earlier (incomplete) list of research topics. The specific numbers are no longer correct, although the "efficiency" figures are likely to be similar.'''

''Scientists
<u>1</u> <u>50</u> <u>100</u> <u>150</u> <u>200</u> <u>250</u> <u>300</u> <u>350</u> <u>400</u> <u>450</u> <u>500</u>
Days 20215 391 190 125 94 75 67 58 56 52 49
Months 663 12.82 6.23 4.10 3.08 2.46 2.20 1.89 1.84 1.69 1.61
Efficiency -- +3% +6% +8% +8% +8% +1% +0% -10% -13% -17%

"Months" are considered to be 30.5 days long.

'''Efficiency''' shows how much time is gained or lost versus a pure case with absolutely no integer truncation or 1-day minima (see Notes). As can be seen, it is maximal around 3-5 labs, then starts dropping and keeps dropping.

Note that going from 3 labs to 4 only saves you about a month -- which is about how long it takes to set up the lab! In practice, 2-3 labs are quite sufficient to acquire all alien technologies in a reasonable time frame.

[[Category:Data tables]]

User talk:Seb76

2009-05-01T16:32:21Z

Talon81: /* Heavy laser mod */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)
:Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J'ordos]] 12:58, 26 April 2009 (EDT)
::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Replace the batch file that runs xcomutil. Make it so the loader will call an outside program at certian points. Add a section to the config file that will allow the user to pick a program to be run.
[Utilities]
Run Utilities=0|1
Run before battle="xcomutil ..."
Run after battle ="xcomutil ..."
Run before base screen="xcomutil ..."

* Allow scrolling the map with the keyboard. "WASD" as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.

* Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.

* Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

<i>Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)</i>

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

== Initial Alien Bases ==

OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)

By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)
:Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)

Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)

:OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)

Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)

== Won't work on my rig Vista+CE version ==

Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.

My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.

* http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG
* http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG
--[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)
:Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):

[[Image:Dxwnd.png]]

[[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)

Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?

http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)

[edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.

:I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:
:[[Image:Scale2x.png]]

:When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)

::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?
:I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)

==Heavy laser mod==
My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction. [[User:SaintD:SaintD]]

:Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)
:Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)

::I tried it. The new modes now work, but Snap Mode is still missing from my HL. Also it's not clear the difference between burst and full auto since they both have the same accuracy and TU cost.--[[User:SaintD|SaintD]] 19:25, 29 April 2009 (EDT)

::: Hmmm, on mine the burst and full auto have different accuracies (80% and 60%, respectively); and they fire 5 and 8 rounds, also respectively. I believe the snap shot was taken out on purpose to coincide with the idea of the heavy laser as being more suited to being a support weapon. Of course the last part is conjecture on my part, but I am pretty certain it is not supposed to be there. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)

I am not the original poster in this heading, and I have not had the same problems with the heavy laser that others had (only one I had was about the Range Based Acc not affecting full auto), so I cannot confirm whether this patch has solved that. But I will tell you what you probably already know: everything is fuzzy, kinda like [ Mok's 2xSaI]. It is also a little bit jumpy. Due to that, I can't take advantage of the Funky Fire fix, or any other future fix, unless I am willing to deal with the fuzziness, or unless you create 2 runs; 1 with the Heavy Laser fix, and one without. --[[User:Talon81|Talon81]] 13:42, 28 April 2009 (EDT)
:Hum, I'm not sure I understand. What has the fuzziness to do with the HL fix? [[User:Seb76|Seb76]] 14:15, 28 April 2009 (EDT)

Wow, to think I almost didnt bother to post because I was sure you would already be aware of it. As soon as I updated your loader from 6 April (TFTD door fix) to 26 April (funky fire fix), everything got fuzzy. After that, I tried the update without funky fire (HL fix). Still fuzzy. Then I rolled back to the previous one (Initial Alien Base fix). No more fuzzy. I even went back to HL fix, then back again to Alien Base fix. Same deal. I will try using it on a fresh X-Com install without my other patches. But yeah, you should seriously install the patch I linked to in my above post. Will only take a minute to try. Looks VERY much like it (I know that many people have the fuzzy problem with that patch). --[[User:Talon81|Talon81]] 02:17, 29 April 2009 (EDT)

OK, it is indeed still fuzzy on a fresher copy of X-Com. It is not a genuine fresh install as I no longer have the disk, it is just the original files copied on my computer in another location. Furthermore, I forgot to mention there is also slight video garble (yes, even with the garble fix on) at the bottom of the menu screens. That in itself is not a problem as it is not throughout the game, and is only a few pixels in height. I can't wait to see if anyone else has these problems or if its just me. --[[User:Talon81|Talon81]] 02:27, 29 April 2009 (EDT)
:I have a crash with Mok's patch so I cannot check the problem. By fuzzy you mean something like the image is bilinearly filtered and all smoothed? [[User:Seb76|Seb76]] 17:20, 29 April 2009 (EDT)

I am a total programming/graphics newb, so I don't know if that is a good description or not. The UFO's for example, instead of being crosses, are blurbs that slightly change shape as they fly, and everything has softer transitions that make it look like it is done with pastels or something. I can tell you I tried to take a screen capture but it did not reflect the screen as it appears in game. In any case, unless other people have this same problem, I would not worry about it for my sake. If it is something you want to tackle anyway, just tell me what I can do to help you. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)
:Hum, are youe using the "dev" version instead of the official one? It features a scale2x filter that craps the image up.[[User:Seb76|Seb76]] 14:40, 30 April 2009 (EDT)

Not sure what you mean by "dev" version, but I am guessing you are referring to my version of CE. I do not know for sure, because it has been years since I got it, but I am guessing the answer is yes because mine runs in full screen without any mods. --[[User:Talon81|Talon81]] 12:22, 1 May 2009 (EDT)

Your newest version seems to have gotten rid of my problem. --[[User:Talon81|Talon81]] 12:32, 1 May 2009 (EDT)

User talk:Seb76

2009-05-01T16:22:56Z

Talon81: /* Heavy laser mod */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)
:Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J'ordos]] 12:58, 26 April 2009 (EDT)
::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Replace the batch file that runs xcomutil. Make it so the loader will call an outside program at certian points. Add a section to the config file that will allow the user to pick a program to be run.
[Utilities]
Run Utilities=0|1
Run before battle="xcomutil ..."
Run after battle ="xcomutil ..."
Run before base screen="xcomutil ..."

* Allow scrolling the map with the keyboard. "WASD" as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.

* Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.

* Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

<i>Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)</i>

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

== Initial Alien Bases ==

OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)

By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)
:Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)

Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)

:OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)

Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)

== Won't work on my rig Vista+CE version ==

Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.

My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.

* http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG
* http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG
--[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)
:Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):

[[Image:Dxwnd.png]]

[[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)

Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?

http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)

[edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.

:I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:
:[[Image:Scale2x.png]]

:When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)

::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?
:I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)

==Heavy laser mod==
My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction. [[User:SaintD:SaintD]]

:Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)
:Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)

::I tried it. The new modes now work, but Snap Mode is still missing from my HL. Also it's not clear the difference between burst and full auto since they both have the same accuracy and TU cost.--[[User:SaintD|SaintD]] 19:25, 29 April 2009 (EDT)

::: Hmmm, on mine the burst and full auto have different accuracies (80% and 60%, respectively); and they fire 5 and 8 rounds, also respectively. I believe the snap shot was taken out on purpose to coincide with the idea of the heavy laser as being more suited to being a support weapon. Of course the last part is conjecture on my part, but I am pretty certain it is not supposed to be there. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)

I am not the original poster in this heading, and I have not had the same problems with the heavy laser that others had (only one I had was about the Range Based Acc not affecting full auto), so I cannot confirm whether this patch has solved that. But I will tell you what you probably already know: everything is fuzzy, kinda like [ Mok's 2xSaI]. It is also a little bit jumpy. Due to that, I can't take advantage of the Funky Fire fix, or any other future fix, unless I am willing to deal with the fuzziness, or unless you create 2 runs; 1 with the Heavy Laser fix, and one without. --[[User:Talon81|Talon81]] 13:42, 28 April 2009 (EDT)
:Hum, I'm not sure I understand. What has the fuzziness to do with the HL fix? [[User:Seb76|Seb76]] 14:15, 28 April 2009 (EDT)

Wow, to think I almost didnt bother to post because I was sure you would already be aware of it. As soon as I updated your loader from 6 April (TFTD door fix) to 26 April (funky fire fix), everything got fuzzy. After that, I tried the update without funky fire (HL fix). Still fuzzy. Then I rolled back to the previous one (Initial Alien Base fix). No more fuzzy. I even went back to HL fix, then back again to Alien Base fix. Same deal. I will try using it on a fresh X-Com install without my other patches. But yeah, you should seriously install the patch I linked to in my above post. Will only take a minute to try. Looks VERY much like it (I know that many people have the fuzzy problem with that patch). --[[User:Talon81|Talon81]] 02:17, 29 April 2009 (EDT)

OK, it is indeed still fuzzy on a fresher copy of X-Com. It is not a genuine fresh install as I no longer have the disk, it is just the original files copied on my computer in another location. Furthermore, I forgot to mention there is also slight video garble (yes, even with the garble fix on) at the bottom of the menu screens. That in itself is not a problem as it is not throughout the game, and is only a few pixels in height. I can't wait to see if anyone else has these problems or if its just me. --[[User:Talon81|Talon81]] 02:27, 29 April 2009 (EDT)
:I have a crash with Mok's patch so I cannot check the problem. By fuzzy you mean something like the image is bilinearly filtered and all smoothed? [[User:Seb76|Seb76]] 17:20, 29 April 2009 (EDT)

I am a total programming/graphics newb, so I don't know if that is a good description or not. The UFO's for example, instead of being crosses, are blurbs that slightly change shape as they fly, and everything has softer transitions that make it look like it is done with pastels or something. I can tell you I tried to take a screen capture but it did not reflect the screen as it appears in game. In any case, unless other people have this same problem, I would not worry about it for my sake. If it is something you want to tackle anyway, just tell me what I can do to help you. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)
:Hum, are youe using the "dev" version instead of the official one? It features a scale2x filter that craps the image up.[[User:Seb76|Seb76]] 14:40, 30 April 2009 (EDT)

Not sure what you mean by "dev" version, but I am guessing you are referring to my version of CE. I do not know for sure, because it has been years since I got it, but I am guessing the answer is yes because mine runs in full screen without any mods. --[[User:Talon81|Talon81]] 12:22, 1 May 2009 (EDT)

User talk:Seb76

2009-04-30T03:51:27Z

Talon81: /* Heavy laser mod */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)
:Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J'ordos]] 12:58, 26 April 2009 (EDT)
::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Allow scrolling the map with the keyboard. "WASD" as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.

* Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.

* Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

<i>Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)</i>

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

== Initial Alien Bases ==

OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)

By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)
:Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)

Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)

:OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)

Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)

== Won't work on my rig Vista+CE version ==

Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.

My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.

* http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG
* http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG
--[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)
:Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):

[[Image:Dxwnd.png]]

[[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)

Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?

http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)

[edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.

:I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:
:[[Image:Scale2x.png]]

:When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)

::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?
:I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)

==Heavy laser mod==
My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction. [[User:SaintD:SaintD]]

:Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)
:Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)

::I tried it. The new modes now work, but Snap Mode is still missing from my HL. Also it's not clear the difference between burst and full auto since they both have the same accuracy and TU cost.--[[User:SaintD|SaintD]] 19:25, 29 April 2009 (EDT)

::: Hmmm, on mine the burst and full auto have different accuracies (80% and 60%, respectively); and they fire 5 and 8 rounds, also respectively. I believe the snap shot was taken out on purpose to coincide with the idea of the heavy laser as being more suited to being a support weapon. Of course the last part is conjecture on my part, but I am pretty certain it is not supposed to be there. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)

I am not the original poster in this heading, and I have not had the same problems with the heavy laser that others had (only one I had was about the Range Based Acc not affecting full auto), so I cannot confirm whether this patch has solved that. But I will tell you what you probably already know: everything is fuzzy, kinda like [ Mok's 2xSaI]. It is also a little bit jumpy. Due to that, I can't take advantage of the Funky Fire fix, or any other future fix, unless I am willing to deal with the fuzziness, or unless you create 2 runs; 1 with the Heavy Laser fix, and one without. --[[User:Talon81|Talon81]] 13:42, 28 April 2009 (EDT)
:Hum, I'm not sure I understand. What has the fuzziness to do with the HL fix? [[User:Seb76|Seb76]] 14:15, 28 April 2009 (EDT)

Wow, to think I almost didnt bother to post because I was sure you would already be aware of it. As soon as I updated your loader from 6 April (TFTD door fix) to 26 April (funky fire fix), everything got fuzzy. After that, I tried the update without funky fire (HL fix). Still fuzzy. Then I rolled back to the previous one (Initial Alien Base fix). No more fuzzy. I even went back to HL fix, then back again to Alien Base fix. Same deal. I will try using it on a fresh X-Com install without my other patches. But yeah, you should seriously install the patch I linked to in my above post. Will only take a minute to try. Looks VERY much like it (I know that many people have the fuzzy problem with that patch). --[[User:Talon81|Talon81]] 02:17, 29 April 2009 (EDT)

OK, it is indeed still fuzzy on a fresher copy of X-Com. It is not a genuine fresh install as I no longer have the disk, it is just the original files copied on my computer in another location. Furthermore, I forgot to mention there is also slight video garble (yes, even with the garble fix on) at the bottom of the menu screens. That in itself is not a problem as it is not throughout the game, and is only a few pixels in height. I can't wait to see if anyone else has these problems or if its just me. --[[User:Talon81|Talon81]] 02:27, 29 April 2009 (EDT)
:I have a crash with Mok's patch so I cannot check the problem. By fuzzy you mean something like the image is bilinearly filtered and all smoothed? [[User:Seb76|Seb76]] 17:20, 29 April 2009 (EDT)

I am a total programming/graphics newb, so I don't know if that is a good description or not. The UFO's for example, instead of being crosses, are blurbs that slightly change shape as they fly, and everything has softer transitions that make it look like it is done with pastels or something. I can tell you I tried to take a screen capture but it did not reflect the screen as it appears in game. In any case, unless other people have this same problem, I would not worry about it for my sake. If it is something you want to tackle anyway, just tell me what I can do to help you. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)

User talk:Seb76

2009-04-29T06:27:10Z

Talon81: /* Heavy laser mod */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)
:Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J'ordos]] 12:58, 26 April 2009 (EDT)
::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Allow scrolling the map with the keyboard. "WASD" as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.

* Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.

* Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

<i>Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)</i>

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

== Initial Alien Bases ==

OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)

By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)
:Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)

Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)

:OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)

Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)

== Won't work on my rig Vista+CE version ==

Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.

My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.

* http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG
* http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG
--[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)
:Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):

[[Image:Dxwnd.png]]

[[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)

Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?

http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)

[edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.

:I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:
:[[Image:Scale2x.png]]

:When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)

::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?
:I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)

==Heavy laser mod==
My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction.
:Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)
:Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)

I am not the original poster in this heading, and I have not had the same problems with the heavy laser that others had (only one I had was about the Range Based Acc not affecting full auto), so I cannot confirm whether this patch has solved that. But I will tell you what you probably already know: everything is fuzzy, kinda like [http://www.strategycore.co.uk/files/index.php?dlid=474 Mok's 2xSaI]. It is also a little bit jumpy. Due to that, I can't take advantage of the Funky Fire fix, or any other future fix, unless I am willing to deal with the fuzziness, or unless you create 2 runs; 1 with the Heavy Laser fix, and one without. --[[User:Talon81|Talon81]] 13:42, 28 April 2009 (EDT)
:Hum, I'm not sure I understand. What has the fuzziness to do with the HL fix? [[User:Seb76|Seb76]] 14:15, 28 April 2009 (EDT)

Wow, to think I almost didnt bother to post because I was sure you would already be aware of it. As soon as I updated your loader from 6 April (TFTD door fix) to 26 April (funky fire fix), everything got fuzzy. After that, I tried the update without funky fire (HL fix). Still fuzzy. Then I rolled back to the previous one (Initial Alien Base fix). No more fuzzy. I even went back to HL fix, then back again to Alien Base fix. Same deal. I will try using it on a fresh X-Com install without my other patches. But yeah, you should seriously install the patch I linked to in my above post. Will only take a minute to try. Looks VERY much like it (I know that many people have the fuzzy problem with that patch). --[[User:Talon81|Talon81]] 02:17, 29 April 2009 (EDT)

OK, it is indeed still fuzzy on a fresher copy of X-Com. It is not a genuine fresh install as I no longer have the disk, it is just the original files copied on my computer in another location. Furthermore, I forgot to mention there is also slight video garble (yes, even with the garble fix on) at the bottom of the menu screens. That in itself is not a problem as it is not throughout the game, and is only a few pixels in height. I can't wait to see if anyone else has these problems or if its just me. --[[User:Talon81|Talon81]] 02:27, 29 April 2009 (EDT)

User talk:Seb76

2009-04-29T06:17:20Z

Talon81: /* Heavy laser mod */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)
:Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J'ordos]] 12:58, 26 April 2009 (EDT)
::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Allow scrolling the map with the keyboard. "WASD" as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.

* Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.

* Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

<i>Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)</i>

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

== Initial Alien Bases ==

OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)

By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)
:Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)

Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)

:OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)

Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)

== Won't work on my rig Vista+CE version ==

Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.

My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.

* http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG
* http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG
--[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)
:Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):

[[Image:Dxwnd.png]]

[[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)

Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?

http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)

[edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.

:I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:
:[[Image:Scale2x.png]]

:When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)

::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?
:I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)

==Heavy laser mod==
My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction.
:Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)
:Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)

I am not the original poster in this heading, and I have not had the same problems with the heavy laser that others had (only one I had was about the Range Based Acc not affecting full auto), so I cannot confirm whether this patch has solved that. But I will tell you what you probably already know: everything is fuzzy, kinda like [http://www.strategycore.co.uk/files/index.php?dlid=474 Mok's 2xSaI]. It is also a little bit jumpy. Due to that, I can't take advantage of the Funky Fire fix, or any other future fix, unless I am willing to deal with the fuzziness, or unless you create 2 runs; 1 with the Heavy Laser fix, and one without. --[[User:Talon81|Talon81]] 13:42, 28 April 2009 (EDT)
:Hum, I'm not sure I understand. What has the fuzziness to do with the HL fix? [[User:Seb76|Seb76]] 14:15, 28 April 2009 (EDT)

Wow, to think I almost didnt bother to post because I was sure you would already be aware of it. As soon as I updated your loader from 6 April (TFTD door fix) to 26 April (funky fire fix), everything got fuzzy. After that, I tried the update without funky fire (HL fix). Still fuzzy. Then I rolled back to the previous one (Initial Alien Base fix). No more fuzzy. I even went back to HL fix, then back again to Alien Base fix. Same deal. I will try using it on a fresh X-Com install without my other patches. But yeah, you should seriously install the patch I linked to in my above post. Will only take a minute to try. Looks VERY much like it (I know that many people have the fuzzy problem with that patch). --[[User:Talon81|Talon81]] 02:17, 29 April 2009 (EDT)

User talk:Seb76

2009-04-28T17:44:25Z

Talon81: /* Heavy laser mod */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)
:Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J'ordos]] 12:58, 26 April 2009 (EDT)
::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Allow scrolling the map with the keyboard. "WASD" as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.

* Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.

* Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

<i>Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)</i>

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

== Initial Alien Bases ==

OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)

By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)
:Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)

Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)

:OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)

Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)

== Won't work on my rig Vista+CE version ==

Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.

My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.

* http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG
* http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG
--[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)
:Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):

[[Image:Dxwnd.png]]

[[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)

Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?

http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)

[edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.

:I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:
:[[Image:Scale2x.png]]

:When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)

::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?
:I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)

==Heavy laser mod==
My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction.
:Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)
:Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)

I am not the original poster in this heading, and I have not had the same problems with the heavy laser that others had (only one I had was about the Range Based Acc not affecting full auto), so I cannot confirm whether this patch has solved that. But I will tell you what you probably already know: everything is fuzzy, kinda like [http://www.strategycore.co.uk/files/index.php?dlid=474 Mok's 2xSaI]. It is also a little bit jumpy. Due to that, I can't take advantage of the Funky Fire fix, or any other future fix, unless I am willing to deal with the fuzziness, or unless you create 2 runs; 1 with the Heavy Laser fix, and one without. --[[User:Talon81|Talon81]] 13:42, 28 April 2009 (EDT)

User talk:Seb76

2009-04-28T17:42:49Z

Talon81: /* Heavy laser mod */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)
:Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J'ordos]] 12:58, 26 April 2009 (EDT)
::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Allow scrolling the map with the keyboard. "WASD" as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.

* Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.

* Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

<i>Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)</i>

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

== Initial Alien Bases ==

OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)

By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)
:Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)

Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)

:OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)

Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)

== Won't work on my rig Vista+CE version ==

Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.

My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.

* http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG
* http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG
--[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)
:Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):

[[Image:Dxwnd.png]]

[[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)

Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?

http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)

[edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.

:I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:
:[[Image:Scale2x.png]]

:When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)

::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?
:I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)

==Heavy laser mod==
My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction.
:Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)
:Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)

I am not the original poster in this heading, and I have not had the same problems with the heavy laser that others had (only one I had was about the Range Based Acc not affecting full auto), so I cannot confirm whether this patch has solved that. But I will tell you what you probably already know: everything is fuzzy, kinda like [[http://www.strategycore.co.uk/files/index.php?dlid=474|Mok's 2xSaI]]. It is also a little bit jumpy. Due to that, I can't take advantage of the Funky Fire fix, or any other future fix, unless I am willing to deal with the fuzziness, or unless you create 2 runs; 1 with the Heavy Laser fix, and one without. --[[User:Talon81|Talon81]] 13:42, 28 April 2009 (EDT)

User talk:Seb76

2009-04-28T17:34:31Z

Talon81: /* Initial Alien Bases */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)
:Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J'ordos]] 12:58, 26 April 2009 (EDT)
::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Allow scrolling the map with the keyboard. "WASD" as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.

* Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.

* Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

<i>Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)</i>

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

== Initial Alien Bases ==

OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)

By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)
:Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)

Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)

:OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)

Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)

== Won't work on my rig Vista+CE version ==

Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.

My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.

* http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG
* http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG
--[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)
:Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):

[[Image:Dxwnd.png]]

[[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)

Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?

http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)

[edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.

:I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:
:[[Image:Scale2x.png]]

:When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)

::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?
:I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)

==Heavy laser mod==
My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction.
:Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)
:Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)

User talk:Seb76

2009-04-25T00:16:18Z

Talon81: /* Initial Alien Bases */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

<i>Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)</i>

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

== Initial Alien Bases ==

OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)

By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)
:Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)

Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)

== Won't work on my rig Vista+CE version ==

Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.

My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.

* http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG
* http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG
--[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)
:Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):

[[Image:Dxwnd.png]]

[[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)

Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?

http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)

[edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.

:I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:
:[[Image:Scale2x.png]]

:When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)

::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?

==Heavy laser mod==
My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction.
:Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)

User talk:Seb76

2009-04-24T17:13:49Z

Talon81: /* Initial Alien Bases */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

<i>Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)</i>

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

== Initial Alien Bases ==

OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)

By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)

== Won't work on my rig Vista+CE version ==

Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.

My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.

* http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG
* http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG
--[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)
:Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):

[[Image:Dxwnd.png]]

[[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)

Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?

http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)

[edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.

:I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:
:[[Image:Scale2x.png]]

:When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)

::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?

==Heavy laser mod==
My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction.
:Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)

User talk:Jasonred

2009-04-22T06:27:32Z

Talon81: /* Time-Efficient Corridor Build */

AARGH!!! I've been forgetting to log in whenever I edit!!!

Those 218.111s are all mine, AFAIK. my server seems to give me slightly different IPs each time. huh.

==Posting on talk pages==

Jasonred: Please sign your posts on talk pages or informal discussion pages by putting tildes (~) after your post! 3 will add your linked name, four will also timestamp the edit. I'm about to use four tildes here. [[User:Arrow Quivershaft|Arrow Quivershaft]] 23:46, 26 February 2009 (CST)

: More on the signature. I know it's easy enough to forget to type in the quadruple tildes, but you might find it easier to use the toolbar to add your signature and timestamp as an alternative. It's the second to last icon above the text edit box. It just makes submitting to a talk page a two-click process rather than clicking directly on submit. Just pointing that out if you hadn't noticed it yet.

: Oh, and the toolbar's also a quick way to add the bold and italic formatting to any text selection as an alternative to emphasizing text with all capitals (which are probably best left for acronyms). -[[User:NKF|NKF]] 02:57, 9 April 2009 (EDT)

== Posting on main (non-Talk) pages ==

Hi Jason

Glad to have you back with us and making lots of contributions. You have a lot of game experience to share so that is very good. Some more points on the protocol for posting though:

The main pages are meant to be articles, not discussions. So on the main pages we don't add a signature. I made this mistake myself when I was first posting. So: Talk pages, add your signature; Non-Talk pages, don't add a signature.

Also, as the main pages are meant to read as articles, they shouldn't have comments or discussion really. They should present a single view. So if you have a comment, question, or difference of opinion it's best to raise it on the Talk page rather than the main article. Then we can have a bit of a discussion about it, come to agreement, and change the main page in a way that reflects some kind of consensus.

Cheers,
Spike
[[User:Spike|Spike]] 06:17, 28 February 2009 (CST)

And while a bit of humour or speculation is ok on main articles - as long is it's clearly speculation - imaginative fiction should not be on the main pages. We try to keep the main pages 'canonical'. :)

[[User:Spike|Spike]] 13:32, 10 March 2009 (CDT)

: Some literary license has been taken in places when we first started out the wiki, but we're now trying to make sure the core articles aren't too fictitious in content. Alas, even though I wrote the description for the HTL, I feel a great need to reduce it a bit to bring it back in line - particularly with the second to last paragraph. It was only included as it was often a comment TFTD players would jokingly mentioned in their posts in various message boards I've been to. -[[User:NKF|NKF]] 13:46, 10 March 2009 (CDT)

== Speed Run timescale ==

Hi Jason. Is the Speed Run record measured in real time or game time? I guess it must be real time, you couldn't get to Cydonia in an hour of game time. Doing it in an hour of real time is unbelievably impressive. [[User:Spike|Spike]] 07:28, 8 March 2009 (CDT)

:Yeah, that seems to be in real time. I agree that it's impressive; I can complete a full run of 1-Mission X-COM in a few hours, but just over an hour is...wow. [[User:Arrow Quivershaft|Arrow Quivershaft]] 07:39, 8 March 2009 (CDT)

:: You can't even research laser weapons in 1 hour real time... actually, your skyranger can't even complete an intercept in 1 hour game time, methinks... [[User:Jasonred|Jasonred]] 09:47, 8 March 2009 (CDT)

: You're entirely right about game time, but in real time, thanks to the time acceleration buttons, it IS possible to get to March in less than 20 minutes. [[User:Arrow Quivershaft|Arrow Quivershaft]] 17:09, 8 March 2009 (CDT)

==Theories about battle time==

Sorry about this; I can't edit the [[Talk:Time Units]], so I had to move this here. [[User:Arrow Quivershaft|Arrow Quivershaft]] 16:56, 16 March 2009 (EDT)

: I find that if I get the server error, copy your edits onto the clipboard (or in my case, I make doubly sure and paste it into an editpad window), navigate to another page, then go back to the page you were going to edit and edit it again and paste your work back into it. Seems to work fine that way. Not sure what's causing it. -[[User:NKF|NKF]] 00:27, 17 March 2009 (EDT)

The most outlandish theory is that Time CEASES TO EXIST within a battlefield... the Elerium has affected space time itself, preventing units from escaping, outside interference, etc etc. While some poo-poo this theory, it would be noted that all tactical mission will end at the exact same time that they began, on the clock. Even a 900 turn long siege and hunt-n-seek on the battlescape will not even take 1 second to transpire in the rest of the world. This is very important to know, for the commander who is busy trying to juggle multiple intercepts and ground missions. (as compared to Jagged Alliance, where events do occur in real time, and a engagement which takes hours will eat many hours of daylight) [[User:Jasonred|Jasonred]]

: The point about how Battlescape time doesn't translate across to Geoscape time is valid and worth noting somewhere, but perhaps it's not completely relevant for the Time Unit section. Not entirely sure where it could go though. Perhaps the Geoscape overview section? -[[User:NKF|NKF]] 00:27, 17 March 2009 (EDT)

== Unconscious kills ==

Good question. The article ([[Unconscious#Notes]]) points out that unconscious kills don't show up on the victory screen. It's a good guess they don't count for [[Experience]] either. [[User:Spike|Spike]] 10:16, 5 April 2009 (EDT)

They definitely don't in Xcom... I'm specifically asking about TFTD. [[User:Jasonred|Jasonred]] 10:33, 5 April 2009 (EDT)

: Usually those sort of things are identical as the game engines are identical, with a very small number of known bug fixes (or attempted fixes) in TFTD. I suggest you just test it and let us know! [[User:Spike|Spike]] 17:16, 5 April 2009 (EDT)

== Capital Letters (aka Shouting) ==

Please make an effort to limit the use of all capital letters. This is considered to be shouting, and is bad netiquette too. FOR EXAMPLE, THIS IS SHOUTING. Except in very rare circumstances, emphasizing text in an article with all caps is in bad practice. Using '''bold''' text is a little better as it doesn't have any negative connotations associated with it, but it shouldn't be happening in every contribution and on every page either. Just look at any normal book for what I mean. Rarely do you see any type of formatted (bold, italics, colored or otherwise) text within. This is an online encyclopedia and should read like one. --[[User:Zombie|Zombie]] 08:59, 8 April 2009 (EDT)

== Personal pronouns, and stuff ==

On similar matter, I do have one thing I've been meaning to say:

When adding to any of the main articles, remember that may be many writers. Be careful when putting in personal pronouns ("I"), opinions or anecdotes. They should be avoided or perhaps rewritten to better fit into the article.

A few exceptions include articles that are in the brainstorming phase (aka - it's just a discussion between members), or pages that clearly belong to you (like your talk pages or your own guides). Thanks to the disclaimer I added, we can also add our own opinions to the various articles in the weapon analysis page. I felt we needed some place on the wiki where we could put a variety of personal opinions and discussions for others to consider, as I find that it is a good mental exercise to see how different things work for different people - but to leave it up to the reader to decide how to use the information. Great way to pick up ideas that you would probably never have thought of before.

I'm mainly mentioning this for both your benefit as well as the rest of us, because I know you are (or probably were) tired of some of us constantly revising your edits.

One other thing, I hadn't really taken notice of this until recently, but I discovered that you've deleted some of my recent edits (mainly some paragraphs in the talk pages - and I think some damage table I drafted up, but I can't remember which. I'll have to backtrack a bit to track it down). It is quite a strange sensation for me when I'm reading through a talk pages only to find something I'm sure I put in is no longer there, but can't remember what it was. This is mainly a reminder to check that the Wiki doesn't complain about edit conflicts - as this happens a lot when we've got sharp bursts of activity like we've been having over the past week. -[[User:NKF|NKF]] 02:48, 9 April 2009 (EDT)

... I doubt I deleted a damage table... which page? The history will show what I did.

Though I have had some horrible incidents where I am editting a page at the same time as someone else, and something terrible happens.
Are you sure it was me?

: Found it - battleship page. Looks like we may have been editing the page at the same time. Had a table to show the min-max number of shots it takes the battleship's weapon to blow up one of your ships. Basically converted your earlier analysis into table form. A few other minor edits went missing too, but no worries. Good thing the wiki keeps short histories. -[[User:NKF|NKF]] 00:36, 10 April 2009 (EDT)

== Time-Efficient Corridor Build ==

hi, I noticed you edited the article to represent the possibility of the build working better when rotated. Actually, because this was a build from a progression of thoughts, I hadnt really thought of rotating this exact build. I had analyzed that thought when it was a little different, and I NEEDED to have the hangars down low. Anyway, kudos on catching that. However, after analyzing further, here is the way I understand it:
Rotating it 90 degrees counter-clockwise would seal the (currently) bottom-right two general stores.
Rotating it 180 degrees would seal the one 2nd to the right.
Both of these would prevent any human spawning points from reaching alien ones without blasting the walls. Rotating it 90 degrees clockwise would seem to be the only viable solution, as it would only seal off the labs, workshops, and special facilities (mind, psi, containment, and/or hyperwave, depending on how they get arranged). Living Quarters and General Stores would be fine. Please let me know what you think of this (I'm watching this page if you wanna respond here). --[[User:Talon81|Talon81]] 20 April 2009

: Well, basically the disjoint bug can be mostly overcome through pre-planned rotation and rearrangement, but Xcomutil just makes life so much easier overall... now all we need is a mod that fixes the green screen of doom bug! [[User:Jasonred|Jasonred]] 03:03, 21 April 2009 (EDT)

Well, I know that the disjoint bug can be overcome in MOST builds through rotation, but as I said, this build seems to have only one way. And while of course there are utilities to overcome it entirely, I am trying to account for those who do not use them. Personally though, I find [[User:Seb76|Seb76's]] loader to be FAR superior to Xcomutil. --[[User:Talon81|Talon81]] 02:27, 22 April 2009 (EDT)

User talk:Jasonred

2009-04-20T23:56:29Z

Talon81: New section: Time-Efficient Corridor Build

Talk:Base Layout Strategy

2009-04-20T17:53:49Z

Talon81: New section: Time-Efficient Corridor Build

Ethereal (or anyone) - See my new Floor Plan section. Feel free to standardize wording.

Traditionally I have not fought base battles, preferring to down the Retaliatory battleship first. However, I may give it a go just for the fun of a change.

What do you think of the concept of a Small Radar next to the Access Lift, with either a General Stores "past" it, or a Large Radar? The Small Radar keeps aliens "in the open"; the Stores can then be used as you suggest, and/or wouldn't a Large Radar be better than a Hyperwave, because more soldiers can fit in the ground-level room of it (plus come in its "back door" with impunity)?

Of course, the Hyperwave and the Stores are much more viable for actual base usage.

Some thoughts ---[[User:MikeTheRed|MikeTheRed]] 17:11, 14 June 2006 (PDT)

----

Build time is one of the biggest factors in base construction. When I build a new base, I want a Hyper-Wave Decoder there as quickly as possible. (If it's before I've unlocked that tech, I guess a Small Radar is a good start -- although I usually manage to get Hyper-Wave before I have funds I want to allocate for a second base.)

Because of this, I'll build a Hangar below the Access Lift and a Hyper-Wave above it. If I'm patient, I'll put a General Stores (10 days build time) above it first, then the Hyper-Wave, to give the "scout post" a little separation from the Lift. I suppose a Small radar in place of the General Stores would work well too -- if not better -- although it's more expensive and not useful like the Stores would be.

The one drawback with the "perfect" design is that you have to wait until each module is built before you can attach the next one, since it's all crammed against one wall. But Hangar+Stores then Hyperwave then Living Quarters gets you a functional base pretty fast.

--[[User:Ethereal Cereal|Ethereal Cereal]] 19:10, 14 June 2006 (PDT)

----

True, build time can be a real problem. I've been playing with "bridges" with something cheap (like a Storeroom) from the Access Lift (or wherever) to link to other areas, so the base can expand faster. (Storerooms are both cheap and fast.) Then later I will take out or replace the bridge, depending on where/what it was. If you're really challenging yourself with tough conditions though, you may not have the extra cash, esp. early on.

I had not seen that "extra arm" design - good thinking!

I would think that with a Small Radar above the Lift (instead of Hyperwave in your design), one (not two) extra blank spaces (next to the Small Radar) would be enough. Unless tons of aliens come through at once, too many to stop in one turn... I have yet to do a base defense in my current Superhuman game. How likely is it that many enemies will try to come through in one turn? The cyberdisc could be a real problem, too.

I see now why you once said you were playing with smoke. Having smoke right outside your scout door seems like it might work really well, or to its side, blocking visualization of your shooters around the sides of the scout room. In fact, one might ''not'' want a Large Radar (back to my early thought) then, because a smaller scout room would give your shooters on the side more room to aim.

I notice you put your hangars on the south side of the base. Does it matter if one has them across the north side instead? (With Access Lift to far left.)

---[[User:MikeTheRed|MikeTheRed]] 22:34, 14 June 2006 (PDT)

----

Friends, check my [[user_talk:NKF|user talk]] page and head down to the Total Randomness section. Right at the bottom. Easy to find.

I was fiddling with wiki templates and trying to see how parameterized wiki templates worked - and probably failing in the process. Anyway, our wiki's settings for the parameters seem somewhat limited, but there's enough functionality to put together a parameterized grid of sorts.

Would it be an idea to reuse what I've done here but to use X-Com base module images instead? With such a contraption, you can design any 6 by 6 module base to your hearts content and not have to take screenshots every time you want to discuss a possible base layout.

- [[User:NKF|NKF]]

----

I hope you don't mind me taking the liberty, but I've swapped your images with the game sprites, and I reckon the result looks pretty good (I've got your thumbnails backed up should you want them replaced). :)

- [[User:Bomb_Bloke|Bomb Bloke]]

-----

No, actually, that's pretty good. We'll stick to them. Good job Bomb Bloke.

I'll have to rename or make a copy of the template and slap together some documentation for it. Can anyone suggest a good easy-to-remember name I can call it? Base Kit? Base Maker? Base Mapper?

I'll hang on to the previous images for a little later. I have the originals, so that's fine. They were originally there just to show a top-down floorpan of the base (lower level), so you could design it and then see where all the doors are and how you can move through the base.

Anyway, post-it note... now bed.

- [[User:NKF|NKF]]

----

Mike: I don't know if it matters if the hangars are north or south -- the base disjoint bug might come into play with small modules put on the southern border, but I don't know, I've never even encountered it.

Bomb Bloke & NKF: Wow, with Bloke's graphics, your base template does look quite good.

--[[User:Ethereal Cereal|Ethereal Cereal]] 10:29, 15 June 2006 (PDT)

----

Ditto that, now the "test kit" is more a full fledged "base design kit"! I may use it to plan my own. Thanks, NKF and BB! ---[[User:MikeTheRed|MikeTheRed]] 15:42, 15 June 2006 (PDT)

----

Going with NKF's original name of "UFO Base Kit" (or UBK for short), I've made a [[UFO_Base_Kit|seperate page for it]]. It's linked on the main page.

I've also incorporated it in place of these images on the [[Base_Layout_Strategy|BLS]] page:

Note that these images have their own Tool Text. The UBK doesn't support that.

- [[User:Bomb_Bloke|Bomb Bloke]]

----
Images removed in preparation of deletion. --[[User:Zombie|Zombie]] 23:39, 29 June 2006 (PDT)

==Non destructible==
Should there be a note somewhere at the top that if you do build the access lift chokepoint style base then to ensure the adjacent base facility isn't destructible? I am not sure of the exact list of what modules are and arent, so won't comment directly unless I come across the list at some point and remember this. --[[User:Sfnhltb|Sfnhltb]] 12:58, 5 March 2007 (PST)

== main page needs a lot of work ==

Base design for the starter base vs bases afterwards are different enough I think they need separate pages.
Additionally a lot of content should be re-written:
*split into 2 pages, one for the starter base and one for bases afterwards
*Discussion comments shouldn't be on the main page (even though I added to them.)
*Needs better integration with [[Base Management]]
*[[Known_Bugs#Base Construction Bugs|All the base bugs]] influence base construction but are not mentioned
*Build time so far has been ignored. Important because a base needs to be useful '''before''' it is ''finished'' --[[User:Brunpal|Brunpal]] 23:19, 28 November 2007 (PST)

----

Consider this build I've named "''Hit the Ground Running''":

<center>
{|
|-
|
{{UBK|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|stores|dirt|dirt|dirt|dirt|=
|dirt|lift|small_radar|dirt|dirt|dirt|=
|hangar1|hangar2|dirt|dirt|dirt|dirt|=
|hangar3|hangar4|dirt|dirt|dirt|dirt|=}}
|
|
|
|
{{UBK|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|quarters|dirt|dirt|dirt|dirt|=
|hyperwave|stores|workshop|dirt|dirt|dirt|=
|dirt|lift|small_radar|dirt|dirt|dirt|=
|hangar1|hangar2|dirt|dirt|dirt|dirt|=
|hangar3|hangar4|dirt|dirt|dirt|dirt|=}}
|
|
|
|
{{UBK|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|quarters|dirt|dirt|dirt|dirt|=
|hyperwave|stores|workshop|dirt|dirt|dirt|=
|dirt|lift|small_radar|dirt|dirt|dirt|=
|hangar1|hangar2|hangar1|hangar2|dirt|dirt|=
|hangar3|hangar4|hangar3|hangar4|dirt|dirt|=}}
|
|
|
|
{{UBK|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|quarters|dirt|dirt|dirt|dirt|=
|hyperwave|stores|workshop|dirt|dirt|dirt|=
|dirt|lift|small_radar|dirt|dirt|dirt|=
|hangar1|hangar2|hangar1|hangar2|dirt|dirt|=
|hangar3|hangar4|hangar3|hangar4|dirt|dirt|=}}
|}
</center>

<center>
{|
|-
|
{{UBK|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|quarters|dirt|dirt|dirt|dirt|=
|hyperwave|stores|workshop|dirt|dirt|dirt|=
|dirt|lift|small_radar|dirt|dirt|dirt|=
|hangar1|hangar2|hangar1|hangar2|dirt|dirt|=
|hangar3|hangar4|hangar3|hangar4|dirt|dirt|=}}
|
|
|
|{{UBK|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|quarters|dirt|dirt|dirt|dirt|=
|hyperwave|stores|workshop|dirt|dirt|dirt|=
|dirt|lift|dirt|dirt|dirt|dirt|=
|hangar1|hangar2|hangar1|hangar2|dirt|dirt|=
|hangar3|hangar4|hangar3|hangar4|dirt|dirt|=}}
|}
</center>

----

=== Base Day 0 ===
:*All under construction

===Base Day 10===
:sm radar -2 days left
:hanger -2 days left
:quarters started -16 days left
:HWD started -26 days left
:workshop started -32 days left
Complete:
*Storage
::Transfer from primary base's surplus stores here

===Base Day 12===
:hanger -8 days left
:quarters -14 days left
:HWD -24 days left
:2nd hanger started -20 days left
:workshop -30 days left
Complete:
*Storage
*sm radar

===Base Day 20===
:quarters -6 days left
:HWD -16 days left
:2nd hanger -12 days left
:workshop -22 days left
Complete:
*Storage
*sm radar
*hanger #1
::transfer/purchase intercept craft

===Base Day 26===
:HWD -10 days left
:2nd hanger -6 days left
:workshop -16 days left
Complete:
*Storage
*sm radar
*hanger #1
*quarters
::3 empty spaces for whatever you want next to the quarters

===Base Day 36===
:workshop -6 days left
Complete:
*Storage
*sm radar
*hanger #1
*hanger #2 (finished 4 days ago)
*quarters
*HWD
::small radar is obsolete and destroyed to make chokepoint. Now paying for dirt

----

Or better still, take advantage of the phantom radar. When you start to build the HWD, decomission the small radar then build the HWD on top of it. But that's making use of an unintended exploit so isn't really kosher.

I suppose you could build the secondary hangar over it like so:

{{UBK|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|workshop|quarters|dirt|dirt|dirt|dirt|=
|hyperwave|stores|dirt|dirt|dirt|dirt|=
|dirt|lift|hangar1|hangar2|dirt|dirt|=
|hangar1|hangar2|hangar3|hangar4|dirt|dirt|=
|hangar3|hangar4|dirt|dirt|dirt|dirt|=}}

This unfortunately means that you'll have to move the workshop to the other side, and since it is forced to wait for the quarters to be built, it'll start up a lot later.

In the end I guess the speed at which your base gets built will depend on how you want to juggle your priorities. I see a few common priorities that need consideration when constructing a secondary base. These are:

# Radar coverage
# Base Garrison
# A hangar - absolute minimum
# Bells and Whistles - Basically all the optional upgrades like the HWD (if replacing), Mind shield, labs, workshops, extra hangars, etc.

The first three are generally the most important for any simple base setup with intercept/ground assault capabilities.

The bells and whistles are all desireable but don't need to be obtained right away if you already have similar operations elsewhere (say your main base).

One unusual alternative I'd like to propose is to completely ignore the one-chokepoint base construction and turn it into a plaza. Have all your facilities built around the first hangar, so your troops can enter it from all directions.

{{UBK|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|dirt|quarters|dirt|dirt|dirt|=
|dirt|dirt|hangar1|hangar2|workshop|dirt|=
|hyperwave|lift|hangar3|hangar4|dirt|dirt|=
|hangar1|hangar2|dirt|stores|dirt|dirt|=
|hangar3|hangar4|dirt|dirt|dirt|dirt|=
}}

The original radar is replaced by the second quadrant of the lower left hangar. Basically you start off with a radar and a hangar, then once the hangar is built, the stores and quarters and workshop all start off at the same time. The HWD is built off the side, and once it's done, the original radar is plucked out and the second hangar goes in.

Note, I did not intentionally isolate the various modules to all corners of the hangar. They just ended up that way - some connected side modules might be useful too.

To be honest, while I've used this setup to great effect in the past, this is a bit riskier and the setup would actually work a lot better with a single hangar base - which would in effect mimic the game's original main base setup, but with the positions swapped!

Also, since there are no stores to begin with, the interceptor that arrives at this base would have to be armed with plasma beams or laser cannons.

Still, speed building a base for functionality seems like an interesting exercise.

- [[User:NKF|NKF]] 23:30, 29 November 2007 (PST)

:In your base above "hit the ground running", wouldn't it be better to start the hanger in the middle of the bottom two rows? That way you can build two hangers afterwards on either side of the first once its built. I do this for the main reason of providing spawn spots for aliens (inside the three hangers) and because I use lightning, firestorm, interceptor at each base. Xcom2 I don't use barracuda because of "too Deep" messages. ie:

NO:
{{UBK|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|lift|dirt|dirt|dirt|dirt|=
|hangar1|hangar2|dirt|dirt|dirt|dirt|=
|hangar3|hangar4|dirt|dirt|dirt|dirt|=
}}

YES:
{{UBK|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|dirt|lift|dirt|dirt|dirt|=
|dirt|dirt|hangar1|hangar2|dirt|dirt|=
|dirt|dirt|hangar3|hangar4|dirt|dirt|=
}}

[[User:EsTeR|EsTeR]]

== Secondary base + Base disjoint bug ==

I can't check it right now, but wouldn't design below be useful?

<center>{{UBK|=
|quarters|quarters|quarters|quarters|workshop|workshop|=
|stores|dirt|quarters|quarters|workshop|workshop|=
|hyperwave|dirt|stores|mind|workshop|psi|=
|lift|dirt|dirt|dirt|dirt|psi|=
|hangar1|hangar2|hangar1|hangar2|hangar1|hangar2|=
|hangar3|hangar4|hangar3|hangar4|hangar3|hangar4|=}}</center>

There's additional facility in the 4th row. I suppose that due to base disjoint bug, it would be disconnected from other modules. If itsn't stores, or quarters, no units should spawn there.
The benfits are one extra facility, and base gets protection from destroying facilities in access lift choke point.

Did anyone try this? Would it work?

[[User:Mchl|Mchl]] 04:28, 1 June 2008 (PDT)

:I've not tried it myself, but there are a few issues I see.

:1, the choke point set up through the Access Lift is negated, allowing aliens to attack from both ends.

:2, the Psi Lab actually has TEN spawn points, 7 on the lower level and 3 above. , as detailed [[ExploitsE#Base_Defence_Mission_Spawning_Issues|here]]. It's true that they are human priority spawns, and with that many hangars the aliens won't need human spawn points, but you risk no guys spawning in that area, allowing the aliens to come in from both ends and tear your troops apart.

:3, Certain Facilities are hardened against and cannot be destroyed during a Base Defense mission, no matter how much you smash them up. These facilities are the [[Hangar]], the [[Access Lift]], the [[General Stores]], and the [[Living Quarters]]. If they entire line of the choke point hallway is made of such buildings, the risk of the base being destroyed is negated as well. Here is what my bases often look like.

<center>{{UBK|=
|stores|quarters|quarters|quarters|workshop|workshop|=
|stores|dirt|quarters|quarters|workshop|workshop|=
|stores|dirt|stores|mind|workshop|psi|=
|lift|hyperwave|dirt|dirt|dirt|dirt|=
|hangar1|hangar2|hangar1|hangar2|hangar1|hangar2|=
|hangar3|hangar4|hangar3|hangar4|hangar3|hangar4|=}}</center>

:Everything after the Living Quarters in the top row and second column will change depending on base needs and function. (General Stores are used to form the path up because they build fast and offer some defense and hiding places during attack in better fashion than Living Quarters. And you need them anyways.) The hyperwave decoder being to the right of the Access Lift allows early radar without having to have it be in the choke point and since the choke is so long anyways the effect is minimal. (It also should be noted that many bases, especially ones with nearby support, those housing [[Avenger]]s, or those not serving as a soldier dispatch, can get away with only having two hangars.) Hope this helps! [[User:Arrow Quivershaft|Arrow Quivershaft]] 08:18, 1 June 2008 (PDT)

I put a PSI-lab there just because it was in the line above in the template I copied from the article. (This also why there's HWD next to lift instead of any reinforced facility. It's just copied from main article.

My point is: will the facility I added be the subject to the base disjoint bug or not? I must get some way to play X-COM under Ubuntu to check it... :P [[User:Mchl|Mchl]] 09:36, 1 June 2008 (PDT)

:Ahh...sorry, didn't understand what you were asking. Your answer is that yes, the Psi lab should indeed benefit from the Base Disjoint Bug under normal circumstances. However, many of the popular enhancers for X-COM(including XcomUtil) work around the Base Disjoint Bug and then it no longer would work. [[User:Arrow Quivershaft|Arrow Quivershaft]] 09:40, 1 June 2008 (PDT)

::Thanks. I'll give it a life fire testing next time I lay my hands on X-COM. Never used XcomUtil... If anything, I hack the game myself ;) [[User:Mchl|Mchl]] 09:50, 1 June 2008 (PDT)

If you go with the original idea, one good connecting facility would be the small radar. Few if any units will ever spawn in that section. I like two access points into the hangar area myself for pincer attacks, but it does look like a creative way to use the bug.

With all the code digging that's been going on lately, I'm sure it's only a matter of time before the off-by-one loop and inner loop error that's causing the base disjoint bug will be tracked down and rectified for good. - [[User:NKF|NKF]] 14:04, 1 June 2008 (PDT)

:As a quick note on Mchl's strategy of using that extra bit of space...keep in mind that any units that spawn in that one extra module will be completely isolated, with no way to escape for the battle. Unless someone inside has a Blaster Launcher and Bombs, or a few Heavy Plasma clips, or someone outside can come to provide such evacuation. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:20, 1 June 2008 (PDT)

<div style="float:right; padding-left:5px;">{{UBK|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|stores|dirt|dirt|dirt|dirt|dirt|=
|lift|dirt|dirt|dirt|quarters|stores|=
|hangar1|hangar2|hangar1|hangar2|hangar1|hangar2|=
|hangar3|hangar4|hangar3|hangar4|hangar3|hangar4|=}}</div>

The solution to those isolated modules is (as we all should know) placing a module next to it. So in the example on the right, placing a facility like the Living Quarters next to the General Stores will allow soldiers to get to the other part of the base. Could also put a low-spawn module in place of the LQ's (like one of the radars) which would create a secondary choke point of sorts.

I'd just like to mention that even though the hangars are at the bottom, the base disjoint bug is still present as the lower pass-through is blocked off. In some cases this is a good thing as it restricts movement through a single connection and allows you to clear each hangar one at a time. --[[User:Zombie|Zombie]] 21:40, 5 November 2008 (CST) <br clear="all">
:Thinking of it, I never got any feedback for the [[User:Seb76#Base_Disjoint_Bug|fix]] I made. Does it fail for some base layouts? [[User:Seb76|Seb76]] 14:21, 6 November 2008 (CST)

By the way Mchl, if you install the Steam versions of XCOM, which run under dosbox, they will run just as easily under Ubuntu dosbox. If fact you can run them under Ubuntu dosbox pointing to the directory on the /host filesystem where Steam installed them. Same goes for TFTD and Apocalypse - they all run under Ubuntu. [[User:Spike|Spike]] 13:42, 9 November 2008 (CST)

== Discussion transplanted from article page ==

- [[User:tequilachef|tequilachef]]: Remember that the Aliens need enough spawn points when attacking your base. If they do not have enough they will use X-Com spawn points, which makes the carefully planned choke point practically useless since you will be ambushed from inside your own living quarters and general stores. Three hangars and the access lift are enough to cover every possible attacking alien force. Therefore I think the two beforementioned base layouts are practically useless!

: I belive that one hangar and one access lift can provide more than enough spawn points for an invasion fleet. I do it all the time and there aren't any spillovers. I couldn't find any reference anywhere on the wiki, but a section that discusses the nuances of the spawn nodes would be interesting, and perhaps even note the spawn nodes in the individual base map blocks. - [[User:NKF|NKF]]

::For a fairly detailed monologue about alien spawn points per module and how alien spawning is determined, please see [[ExploitsE#Base_Defence_Mission_Spawning_Issues|Base_Defence_Mission_Spawning_Issues]]. According to this, you have 23 alien spawn tiles with one Hangar and the Access Lift. According to the deployment chart for Alien Retaliation missions, the only time you'll have more than 23 aliens dispatched to try and smoke you out is in Superhuman, and even then, the most you can go over is 5, making 2 Hangars and the Access Lift sufficient to fully spawn any Alien Retaliation. My greater concern would be the location of the HWD; that's a module that can be destroyed during a heated Alien Retaliation Mission, and if you lose it, the whole base is demolished. Also, because of it's central staircase, it will prevent you from firing any weapon but Blaster Bombs down the hallway behind the choke point. It would be wiser to have Living Quarters or General Stores along that entire choke line, since such a module cannot be demolished, it also serves as a high-priority spawn point for your troopers, and the open central area allows you to nuke the aliens from far away. Finally, those two bases seem like they would have 50 or 100 soldiers each(based on the number of Psi Labs), at which point a full complement of 28 aliens is outnumbered nearly 4-to-1 and can be defeated through attrition alone if needed. Even assuming a squad of 100 psissies and 22 Ethereals(the six Sectopods can't use psi), you've still got 56 soldiers to kill things with, since each Ethereal can MC only twice per turn. -[[User:Arrow Quivershaft|Arrow Quivershaft]]

:::Interesting point, Arrow. [[Battleship#Alien_Deployment|Superhuman Battleships]] have 22-28 crew, with the variability coming from 0-2 extra terrorists and 0-4 extra soldiers. FWIW, this is like rolling a 3-sided die (0-2) and 5 sided one (0-5), with a 20% chance there will be 22-23 aliens (1/15 + 2/15), or 27-28 (same odds), for that matter. The average is 25, or 2 aliens outside the Lift and Hangar, if you only have one Hangar. -[[User:MikeTheRed|MikeTheRed]] 18:09, 30 July 2008 (PDT)

::I should note a small error in that. Due to program constraints, you can never have more than 40 soldiers spawn(and tanks count as 4 soldiers). Still, how someone could lose a fight in a defense-oriented base when commanding 40 soldiers with Laser Rifles is beyond me. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:24, 30 July 2008 (PDT)

: The above two base designs are still useless. While it has a long choke point it is not practical. You can only build next to finished structures. Therefore it will take 55 days before the first soldier can start defending it. (Days: HWD-26, stores-10, LQ-16, 3 for soldier delivery) Placing the Access Lift next to a wall while keeping it a choke point means that there are only 2 spaces to place structure. Removing structure means later you will be paying for dirt. Furthermore I'm not convinced that an extended choke past the lift +1 tile is useful. Too many guys end up spending a long time hoofing it to a spot they can be useful.--[[User:Brunpal|Brunpal]] 19:19, 28 November 2007 (PST)

:: That's true in theory, Brunpal, but you can build temporary facilities like Stores to "bridge a gap", then remove them. Yes, you'll wind up [[Base_Facilities#Facility_Maintenance_Cost_Bug|paying for dirt]], but that will only matter in a self-imposed cash-crunch scenario. -[[User:MikeTheRed|MikeTheRed]] 15:31, 7 December 2007 (PST)

<center>{{UBK|=
|workshop|dirt|hangar1|hangar2|hangar1|hangar2|=
|stores|dirt|hangar3|hangar4|hangar3|hangar4|=
|stores|lab|dirt|lift|hangar1|hangar2|=
|stores|stores|stores|stores|hangar3|hangar4|=
|stores|stores|stores|stores|large_radar|quarters|=
|stores|stores|stores|stores|quarters|quarters|=}}
</center>

The following base is built on the theory that the best way to defeat the aliens is to turn the alien spawn-points into a salient. The nature of this defense allows for surrounding the initial enemy spawn point on 3 sides, allowing for crossfire to cut the aliens down to size.

== Time-Efficient Corridor Build ==

If anyone has any feedback or comments on it, I am eager to hear it.--[[User:Talon81|Talon81]] 13:53, 20 April 2009 (EDT)

Base Layout Strategy

2009-04-20T17:50:48Z

Talon81: /* Time-Efficient Corridor Build */

Your base will, at some point, be raided by angry aliens looking for revenge for all those UFO's you've taken out. Unlike most places you'll have to fight, you have control over the layout of your base, so design it wisely.

The key point for base defensibility is to minimize the number of points of entry. Aliens usually come down into your base through hangars and the access lift (although they can emerge on other locations - see the last comment on [[Base_Defense#Bugs]]). If you group your hangars with the access lift, then build only one module connecting to this part of your base, that module becomes a choke point for base defense. A long chain of rooms becomes a long choke point ripe for mining with Proximity Grenades and other dirty tricks. This way, you can line up all your units against one point of entry instead of having to spread them out to cover four or five.

The access lift is always the first unit built, so it becomes the obvious candidate for this single point of entry. Place it on the grid so you leave enough room to build hangars on one side of the lift, and everything else on the other side. I'd recommend building a General Stores on the lift opposite the hangar. A general stores is needed for any base, and it gets completed quickly. Once the general stores are completed, build all new facilities (except hangars, of course) off of that.

==Overhauling the Starter Base==

At higher difficulty levels, alien retaliation can often come MUCH sooner than you might be ready for-- before you have base defenses built, and before you have powerful weapons to arm your troops with. Considering that the access lift and all hangars serve as entry points for the invaders, the starter base has all the defensive virtues of a screen door:
<center>{{UBK|=
|dirt|dirt|hangar1|hangar2|dirt|dirt|=
|dirt|dirt|hangar3|hangar4|dirt|dirt|=
|dirt|dirt|lift|quarters|dirt|dirt|=
|dirt|small_radar|stores|lab|workshop|dirt|=
|hangar1|hangar2|dirt|dirt|hangar1|hangar2|=
|hangar3|hangar4|dirt|dirt|hangar3|hangar4|=}}</center>
The hangars and lift are distributed as widely as possible through the base, giving the aliens a wealth of breach points and enabling them to assault any defenders from all sides.

With this in mind, I recommend a partial rebuild of your initial base ASAP. Build two hangars next to the topmost hangar to replace the lower two, and a living quarters down between the two lower existing hangars to replace the one next to the access lift. Place any other new modules on the lower half of the screen, where they will not touch the lift or the new hangars.

As the new living quarters and hangar are completed, dismantle the old ones. It should now look something like:
<center>{{UBK|=
|hangar1|hangar2|hangar1|hangar2|hangar1|hangar2|=
|hangar3|hangar4|hangar3|hangar4|hangar3|hangar4|=
|dirt|dirt|lift|dirt|dirt|dirt|=
|large_radar|small_radar|stores|lab|workshop|dirt|=
|dirt|dirt|quarters|containment|dirt|dirt|=
|dirt|dirt|dirt|dirt|dirt|dirt|=}}</center>
Of course, place any other new facilities with a mind to preserving the new choke-point at the grav lift (i.e., nothing adjacent to the top hangars.) This layout isn't as fortified as many new-build bases can be, but it's a good compromise between defendability (one choke-point at the lift), available space, expedience (it converts from the standard layout in minimal time), and, especially, cost. It only costs the price of two hangars and a living quarters ($800,000) to overhaul your base this way-- a cost that can be covered by the proceeds from, say, one small landed UFO. It does however accrue base [[maintenance costs]] of $720,000 per month due to a [[Known Bugs#Paying For Dirt|bug]].

===Variations===

The previous example was a one chokepoint base that is easy to defend, however it is by no means the only way to build the base. Don't be afraid to try different variations of the base to suit the strategy that you intend use.

If you want to attack the aliens from two sides, the simple addition of an extra module can modify the one-chokepoint base into a two-chokepoint base. For example:

<center>{{UBK|=
|hangar1|hangar2|hangar1|hangar2|hangar1|hangar2|=
|hangar3|hangar4|hangar3|hangar4|hangar3|hangar4|=
|dirt|dirt|lift|dirt|small_radar|dirt|=
|large_radar|small_radar|stores|lab|workshop|dirt|=
|dirt|dirt|quarters|containment|dirt|dirt|=
|dirt|dirt|dirt|dirt|dirt|dirt|=}}</center>

The above base is designed to work like the popular defendable base layout, but also provides a second access point into the hangars. Although this means you have to spread your soldiers out to cover both points, so do the aliens.

With this example in particular, the small radar module provides an empty hallway. If you like to use rockets, this one access point gives you a clear shot into the hangars. A few well placed rockets can cut down the opposition considerably.

If you really like to use rockets but can only handle aliens entering the map through one entry point, consider the following variation.

<center>{{UBK|=
|hangar1|hangar2|hangar1|hangar2|hangar1|hangar2|=
|hangar3|hangar4|hangar3|hangar4|hangar3|hangar4|=
|dirt|dirt|lift|dirt|small_radar|dirt|=
|large_radar|small_radar|dirt|lab|workshop|dirt|=
|dirt|containment|quarters|stores|dirt|dirt|=
|dirt|dirt|dirt|dirt|dirt|dirt|=}}</center>

It may take a while to re-order the base in this manner from the starting setup, but the end result provides you with a clear firing corridor into the hangars with plenty of cubbyholes to hide in. All of the aliens will have to funnel through the small radar module, which is an open space with no place for the aliens to hide.

One disadvantage of this base however is that if the workshop suffers too much structural damage, all facilities past the small radar will be destroyed as they'll be disconnected from the access lift.

No matter what layout you eventually use, remember that the more complicated it is the longer it may take to construct and the more money it will cost. The last example requires moving a module that was already present in the default base. i.e. the general stores.

== Secondary Base Design ==

With your second and subsequent bases, you can build it securely right from the beginning. The most secure design uses the Access Lift as a choke point between the hangars and the rest of the base, as pictured above, but puts it to the side, out of the way, and also adds a long corridor between the Access Lift and the rest of the base:
<center>{{UBK|=
|quarters|quarters|quarters|quarters|workshop|workshop|=
|stores|dirt|quarters|quarters|workshop|workshop|=
|hyperwave|dirt|stores|mind|workshop|psi|=
|lift|dirt|dirt|dirt|dirt|dirt|=
|hangar1|hangar2|hangar1|hangar2|hangar1|hangar2|=
|hangar3|hangar4|hangar3|hangar4|hangar3|hangar4|=}}</center>

The exact facilities built are up to the individual player, although a hyper-wave decoder, stores, and living quarters are generally the most important facilities to build first. Even if you don't plan on stationing any X-Com [[craft]] at the base, you should also build at least one hangar (where aliens will spawn preferentially during a [[Base Defense]] mission) to prevent them from spawning deeper inside the base.

Be sure not to put the Access Lift on the southern or eastern borders of the map to avoid the [[Known Bugs#Base Disjoint Bug|base disjoint bug]].

If three hangars are not needed, additional base facilities can be added, as long as they are not placed adjacent to the hangars:
<center>
{|
|-
|
{{UBK|=
|quarters|quarters|quarters|quarters|workshop|workshop|=
|stores|dirt|quarters|quarters|workshop|workshop|=
|hyperwave|dirt|stores|mind|workshop|psi|=
|lift|dirt|dirt|dirt|psi|psi|=
|hangar1|hangar2|hangar1|hangar2|dirt|psi|=
|hangar3|hangar4|hangar3|hangar4|dirt|psi|=}}
|
|
|
|
{{UBK|=
|quarters|quarters|quarters|quarters|workshop|workshop|=
|stores|dirt|quarters|quarters|workshop|workshop|=
|hyperwave|dirt|stores|mind|workshop|psi|=
|lift|dirt|quarters|psi|psi|psi|=
|hangar1|hangar2|dirt|psi|psi|psi|=
|hangar3|hangar4|dirt|psi|psi|psi|=}}
|}
</center>

The design with only one hangar, however, runs the risk of having aliens spawn in areas other than the hangars and access lift, as one hangar plus one access lift only provide (15 + 8 = 23) alien spawn points, and a [[Battleship]] on Superhuman difficulty can carry between 22 and 28 aliens. Especially troubling is the fact that Terror Units have the lowest alien spawn priority and thus are most likely to show up in your base. This might result in some [[Chryssalid|particularly]] [[Sectopod|nasty]] units spawning behind your lines, quickly turning an otherwise easy Base Defense into a nightmare!

=== Accelerated build ===

One drawback of the above design is that it takes 52 days before all the facilities in the "choke line" are completed and the base is fully defensible against invasion. The following variant moves the Hyper-Wave Decoder to the right of the access lift, allowing the decoder, one hangar, and stores plus quarters to all be complete within 26 days.

Moving the hyperwave out of the choke line also makes it less likely to be destroyed by a stray blaster bomb. In the above designs, if the hyperwave gets destroyed, all modules beyond it will be destroyed as well. (Living quarters and stores are immune to destruction.)

<center>
{|
|-
|
{{UBK|=
|quarters|quarters|quarters|quarters|workshop|workshop|=
|quarters|dirt|quarters|quarters|workshop|workshop|=
|stores|dirt|stores|mind|workshop|psi|=
|lift|hyperwave|dirt|dirt|dirt|dirt|=
|hangar1|hangar2|hangar1|hangar2|hangar1|hangar2|=
|hangar3|hangar4|hangar3|hangar4|hangar3|hangar4|=}}
|
|
|
|
{{UBK|=
|quarters|quarters|quarters|quarters|workshop|workshop|=
|quarters|dirt|quarters|quarters|workshop|workshop|=
|stores|dirt|stores|mind|workshop|psi|=
|lift|hyperwave|dirt|dirt|psi|psi|=
|hangar1|hangar2|hangar1|hangar2|dirt|psi|=
|hangar3|hangar4|hangar3|hangar4|dirt|psi|=}}
|}
</center>

=== Time-Efficient Corridor Build ===

The following designs are an attempt to greatly speed up build times without sacrificing much (if any) defensibility. The base on the left is an example of how to start a new base if you don't yet have a Hyperwave Decoder. This would get you 2 Hangars, a General Stores, Radar, and Living Quarters by day 26. You can of course skip the Large Radar if you have already researched Hyperwave (in which case you would no doubt place the Hyperwave above your first Stores).

The base on the right is a complete version of this base. Notice that the General Stores above the Access Lift is the only facility that has been removed if you did not build the Radar, so if you are [[Known Bugs#Paying For Dirt|paying for dirt]], you will not suffer greatly. This build has only 5 wasted spaces, which is less than any other defensible build using 3 Hangars. If you really want the extra corridor space, you can skip the bottom-most Living Quarters. The corridor is, of course, indestructible, as it is done with General Stores. As a warning, if you have not eliminated the [[Known Bugs#Base Disjoint Bug|base disjoint bug]], you will find your soldiers sealed off from the aliens. Furthermore, if you expect to be attacked within a short period of time, you may not yet have swapped your choke point from the Access Lift to the General Stores on the left.

Lastly, the base on the right is an alternative 2 Hangar build.

<center>
{|
|-
|
{{UBK|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|dirt|dirt|stores|hangar1|hangar2|=
|dirt|dirt|large_radar|lift|hangar3|hangar4|=
|dirt|dirt|hangar1|hangar2|dirt|dirt|=
|dirt|dirt|hangar3|hangar4|dirt|dirt|=}}
|
|
|
|
{{UBK|=
|workshop|workshop|workshop|containment|hyperwave|mind|=
|workshop|quarters|lab|psi|dirt|dirt|=
|quarters|quarters|quarters|dirt|hangar1|hangar2|=
|stores|quarters|dirt|lift|hangar3|hangar4|=
|stores|dirt|hangar1|hangar2|hangar1|hangar2|=
|stores|stores|hangar3|hangar4|hangar3|hangar4|=}}
|
|
|
|
{{UBK|=
|workshop|workshop|workshop|containment|hyperwave|mind|=
|workshop|quarters|lab|psi|psi|psi|=
|quarters|quarters|quarters|dirt|psi|psi|=
|stores|quarters|dirt|lift|dirt|dirt|=
|stores|dirt|hangar1|hangar2|hangar1|hangar2|=
|stores|stores|hangar3|hangar4|hangar3|hangar4|=}}
|}
</center>

If you have a program to overhaul your starter base, the base on the bottom left is what I recommend. The picture on the right shows a good choice for immediate additions to it. You would of course want to add another Living Quarters if finances permit (don't forget to staff your Laboratory or Workshops).

<center>
{|
|-
|
{{UBK|=
|dirt|dirt|workshop|dirt|dirt|dirt|=
|dirt|dirt|lab|dirt|dirt|dirt|=
|dirt|dirt|quarters|small_radar|hangar1|hangar2|=
|dirt|dirt|dirt|lift|hangar3|hangar4|=
|dirt|dirt|hangar1|hangar2|hangar1|hangar2|=
|dirt|stores|hangar3|hangar4|hangar3|hangar4|=}}
|
|
|
|
{{UBK|=
|dirt|lab|workshop|containment|dirt|dirt|=
|dirt|dirt|lab|large_radar|dirt|dirt|=
|dirt|quarters|quarters|small_radar|hangar1|hangar2|=
|dirt|dirt|dirt|lift|hangar3|hangar4|=
|dirt|dirt|hangar1|hangar2|hangar1|hangar2|=
|stores|stores|hangar3|hangar4|hangar3|hangar4|=}}
|}
</center>

== Corner ambush build ==

<center>{{UBK|=
|quarters|workshop|workshop|quarters|quarters|stores|=
|quarters|psi|workshop|workshop|quarters|stores|=
|hyperwave|psi|stores|mind|dirt|stores|=
|dirt|dirt|workshop|dirt|dirt|stores|=
|hangar1|hangar2|dirt|hangar1|hangar2|stores|=
|hangar3|hangar4|lift|hangar3|hangar4|dirt|=}}</center>

I decided to put a little variety into my base defences. I like this pattern because i get to ambush the aliens as they turn the corner of the first general stores. Let THEM see how it feels getting whacked at blind corners!
Also, notice how that fights will only occur in or near indestructible modules. Too many exploding cyberdisks convinced me to do this.

The fact that the corridor is 5 units long is SIGNIFICANT. (the prior designs are actually only 3 modules long, because aliens spawn in the access lift, which has also has doors which block LOS and fired shots) Because alien sight is 20 squares. 5 modules is 45 tiles.This means that I can in fact keep 6 units (3 standing, 3 kneeling) at the north end of the North East corner module. I place scouts/spotters with a motion detectors in the rooms and round the corners of the corridor of general stores. The spotters pop out diagonally for mutual surprise, then hide again. Then the 6 snipers at the end of the corridor shoot down the corridor killing enemies in it. 45 tile distance means that no alien can turn the corner and walk far enough down the corridor to spot and shoot at my snipers in 1 turn.

== Missile Defence Module Build ==

<center>{{UBK|=
|stores|quarters|workshop|workshop|quarters|quarters|=
|stores|quarters|psi|workshop|workshop|quarters|=
|stores|dirt|psi|stores|mind|hyperwave|=
|stores|dirt|dirt|workshop|dirt|dirt|=
|missile|hangar1|hangar2|dirt|hangar1|hangar2|=
|dirt|hangar3|hangar4|lift|hangar3|hangar4|=}}</center>

This build takes advantage of the missile defences unique structure to force aliens to enter from the right, take a big detour, then exit to the north. This will likely severely hamper enemy blaster bomb efforts. However, by the same token, this is very likely to wind up causing your missile defences module to get blown up by blaster bombs, which will disconnect the rest of your base from your elevator, and make you lose most of your base. Be warned.

==Floor Plan Comparison==
Here's a comparison of the '''ground floor''' plans for X-COM base modules, in case it helps you design your base. For images, follow the links or see [[Xcom_and_Alien_Bases#XCom_Base|X-COM Base Module Images]]:

*'''3-wide "central plus sign" corridors:
** 1-wide doors along NW to SE path: [[Living Quarters]], [[Laboratory]], [[Workshop]]
** 1-wide doors along SW to NE path: [[Alien Containment]], [[Psionic Laboratory]]
** 2-wide doors along SW to NE path: [[General Stores]]

*'''Central room:
** 1 1-wide door, 2-wide corridors: [[Laser Defences]] (SW door), [[Plasma Defences]] (SE door), [[Fusion Ball Defences]] (NE door)
** 2 1-wide doors, 2-wide corridors: [[Large Radar System]] (SW & NE doors)
** 2 1-wide doors, 3-wide corridors: [[Grav Shield]], [[Hyper-wave Decoder]], [[Mind Shield]] (all have SW & SE doors)

*'''Unique modules:
**Wide open ground floor: [[Small Radar System]]
** "P" design of [[Missile Defences]] - no ground level doors; can force particular paths
** [[Hangar]]
** [[Access Lift]]

Most modules have a fairly open second story, with the exception of [[Missile Defences]], [[General Stores]], [[Alien Containment]], and the [[Psionic Laboratory]]. Still, half of the rest have a fair amount of clutter that might hide aliens.

==Notes==
*Corridors attaching to the right topside of a hangar (on the grid, the east side of the north wall) corner come through a ground-level hangar door. Corridors attaching anywhere else don't get a door. See picture at [[X-Com_Base_Terrain]].
*The ideal case is to have your choke point aligned vertically on the base grid, lined with general stores. The general stores have large, doublewide doors that open out onto the vertical corridor. These doors will give your your troops and tanks cover, and let them pop out to make attacks at will.
*It is also desirable to have a base facility containing a door directly facing the Access Lift (such as the Hyper-wave Decoder). A scout can pop out at the beginning of a turn and spot units coming down the corridor without risk of being shot due to the [[reaction fire triggers#mutual_surprise|"mutual surprise" rule]]. Other units with indirect-fire weapons (grenades and blaster launchers) can then safely attack the spotted alien(s). Direct-fire weapons can also be safely used if a thick-enough [[Smoke Grenade|smoke cover]] is present.
*Troops will spawn primarily in the Living Quarters and General Stores . Tanks will spawn mostly in the General Stores. You might want to cluster these units around your choke-point so your units will be where you need them.
*When constructing a base, be very careful that you avoid the [[Known Bugs#Base Disjoint Bug|Base Disjoint Bug]] where modules along the right and lower edges of the map can get sealed off. Improper placement will often end up forcing you to cut through the very tough walls and dirt blocks with heavy plasmas or tank lasers. However, with proper placement of modules, the sealed off walls can be very advantageous in controlling the flow of aliens. [[XcomUtil]] users cannot take advantage of this as the setup tool for this utility automatically rips out the walls.
*You can (and should) keep the poorly positioned rooms of your starter base up until the battleship is closing in. You can dismantle rooms instantly as long as they are unused. Since maintenance costs are buggy and listed values are always wrong, you are always better off keeping a room even if it is unused... at least up until the point the aliens arrive or you need the room.

==See Also==
*[[Base Management]]
*[[Base Defense]]
*[[Base Defense Measures]]
*[[X-Com Base Terrain]]

Base Layout Strategy

2009-04-20T17:47:08Z

Talon81:

Your base will, at some point, be raided by angry aliens looking for revenge for all those UFO's you've taken out. Unlike most places you'll have to fight, you have control over the layout of your base, so design it wisely.

The key point for base defensibility is to minimize the number of points of entry. Aliens usually come down into your base through hangars and the access lift (although they can emerge on other locations - see the last comment on [[Base_Defense#Bugs]]). If you group your hangars with the access lift, then build only one module connecting to this part of your base, that module becomes a choke point for base defense. A long chain of rooms becomes a long choke point ripe for mining with Proximity Grenades and other dirty tricks. This way, you can line up all your units against one point of entry instead of having to spread them out to cover four or five.

The access lift is always the first unit built, so it becomes the obvious candidate for this single point of entry. Place it on the grid so you leave enough room to build hangars on one side of the lift, and everything else on the other side. I'd recommend building a General Stores on the lift opposite the hangar. A general stores is needed for any base, and it gets completed quickly. Once the general stores are completed, build all new facilities (except hangars, of course) off of that.

==Overhauling the Starter Base==

At higher difficulty levels, alien retaliation can often come MUCH sooner than you might be ready for-- before you have base defenses built, and before you have powerful weapons to arm your troops with. Considering that the access lift and all hangars serve as entry points for the invaders, the starter base has all the defensive virtues of a screen door:
<center>{{UBK|=
|dirt|dirt|hangar1|hangar2|dirt|dirt|=
|dirt|dirt|hangar3|hangar4|dirt|dirt|=
|dirt|dirt|lift|quarters|dirt|dirt|=
|dirt|small_radar|stores|lab|workshop|dirt|=
|hangar1|hangar2|dirt|dirt|hangar1|hangar2|=
|hangar3|hangar4|dirt|dirt|hangar3|hangar4|=}}</center>
The hangars and lift are distributed as widely as possible through the base, giving the aliens a wealth of breach points and enabling them to assault any defenders from all sides.

With this in mind, I recommend a partial rebuild of your initial base ASAP. Build two hangars next to the topmost hangar to replace the lower two, and a living quarters down between the two lower existing hangars to replace the one next to the access lift. Place any other new modules on the lower half of the screen, where they will not touch the lift or the new hangars.

As the new living quarters and hangar are completed, dismantle the old ones. It should now look something like:
<center>{{UBK|=
|hangar1|hangar2|hangar1|hangar2|hangar1|hangar2|=
|hangar3|hangar4|hangar3|hangar4|hangar3|hangar4|=
|dirt|dirt|lift|dirt|dirt|dirt|=
|large_radar|small_radar|stores|lab|workshop|dirt|=
|dirt|dirt|quarters|containment|dirt|dirt|=
|dirt|dirt|dirt|dirt|dirt|dirt|=}}</center>
Of course, place any other new facilities with a mind to preserving the new choke-point at the grav lift (i.e., nothing adjacent to the top hangars.) This layout isn't as fortified as many new-build bases can be, but it's a good compromise between defendability (one choke-point at the lift), available space, expedience (it converts from the standard layout in minimal time), and, especially, cost. It only costs the price of two hangars and a living quarters ($800,000) to overhaul your base this way-- a cost that can be covered by the proceeds from, say, one small landed UFO. It does however accrue base [[maintenance costs]] of $720,000 per month due to a [[Known Bugs#Paying For Dirt|bug]].

===Variations===

The previous example was a one chokepoint base that is easy to defend, however it is by no means the only way to build the base. Don't be afraid to try different variations of the base to suit the strategy that you intend use.

If you want to attack the aliens from two sides, the simple addition of an extra module can modify the one-chokepoint base into a two-chokepoint base. For example:

<center>{{UBK|=
|hangar1|hangar2|hangar1|hangar2|hangar1|hangar2|=
|hangar3|hangar4|hangar3|hangar4|hangar3|hangar4|=
|dirt|dirt|lift|dirt|small_radar|dirt|=
|large_radar|small_radar|stores|lab|workshop|dirt|=
|dirt|dirt|quarters|containment|dirt|dirt|=
|dirt|dirt|dirt|dirt|dirt|dirt|=}}</center>

The above base is designed to work like the popular defendable base layout, but also provides a second access point into the hangars. Although this means you have to spread your soldiers out to cover both points, so do the aliens.

With this example in particular, the small radar module provides an empty hallway. If you like to use rockets, this one access point gives you a clear shot into the hangars. A few well placed rockets can cut down the opposition considerably.

If you really like to use rockets but can only handle aliens entering the map through one entry point, consider the following variation.

<center>{{UBK|=
|hangar1|hangar2|hangar1|hangar2|hangar1|hangar2|=
|hangar3|hangar4|hangar3|hangar4|hangar3|hangar4|=
|dirt|dirt|lift|dirt|small_radar|dirt|=
|large_radar|small_radar|dirt|lab|workshop|dirt|=
|dirt|containment|quarters|stores|dirt|dirt|=
|dirt|dirt|dirt|dirt|dirt|dirt|=}}</center>

It may take a while to re-order the base in this manner from the starting setup, but the end result provides you with a clear firing corridor into the hangars with plenty of cubbyholes to hide in. All of the aliens will have to funnel through the small radar module, which is an open space with no place for the aliens to hide.

One disadvantage of this base however is that if the workshop suffers too much structural damage, all facilities past the small radar will be destroyed as they'll be disconnected from the access lift.

No matter what layout you eventually use, remember that the more complicated it is the longer it may take to construct and the more money it will cost. The last example requires moving a module that was already present in the default base. i.e. the general stores.

== Secondary Base Design ==

With your second and subsequent bases, you can build it securely right from the beginning. The most secure design uses the Access Lift as a choke point between the hangars and the rest of the base, as pictured above, but puts it to the side, out of the way, and also adds a long corridor between the Access Lift and the rest of the base:
<center>{{UBK|=
|quarters|quarters|quarters|quarters|workshop|workshop|=
|stores|dirt|quarters|quarters|workshop|workshop|=
|hyperwave|dirt|stores|mind|workshop|psi|=
|lift|dirt|dirt|dirt|dirt|dirt|=
|hangar1|hangar2|hangar1|hangar2|hangar1|hangar2|=
|hangar3|hangar4|hangar3|hangar4|hangar3|hangar4|=}}</center>

The exact facilities built are up to the individual player, although a hyper-wave decoder, stores, and living quarters are generally the most important facilities to build first. Even if you don't plan on stationing any X-Com [[craft]] at the base, you should also build at least one hangar (where aliens will spawn preferentially during a [[Base Defense]] mission) to prevent them from spawning deeper inside the base.

Be sure not to put the Access Lift on the southern or eastern borders of the map to avoid the [[Known Bugs#Base Disjoint Bug|base disjoint bug]].

If three hangars are not needed, additional base facilities can be added, as long as they are not placed adjacent to the hangars:
<center>
{|
|-
|
{{UBK|=
|quarters|quarters|quarters|quarters|workshop|workshop|=
|stores|dirt|quarters|quarters|workshop|workshop|=
|hyperwave|dirt|stores|mind|workshop|psi|=
|lift|dirt|dirt|dirt|psi|psi|=
|hangar1|hangar2|hangar1|hangar2|dirt|psi|=
|hangar3|hangar4|hangar3|hangar4|dirt|psi|=}}
|
|
|
|
{{UBK|=
|quarters|quarters|quarters|quarters|workshop|workshop|=
|stores|dirt|quarters|quarters|workshop|workshop|=
|hyperwave|dirt|stores|mind|workshop|psi|=
|lift|dirt|quarters|psi|psi|psi|=
|hangar1|hangar2|dirt|psi|psi|psi|=
|hangar3|hangar4|dirt|psi|psi|psi|=}}
|}
</center>

The design with only one hangar, however, runs the risk of having aliens spawn in areas other than the hangars and access lift, as one hangar plus one access lift only provide (15 + 8 = 23) alien spawn points, and a [[Battleship]] on Superhuman difficulty can carry between 22 and 28 aliens. Especially troubling is the fact that Terror Units have the lowest alien spawn priority and thus are most likely to show up in your base. This might result in some [[Chryssalid|particularly]] [[Sectopod|nasty]] units spawning behind your lines, quickly turning an otherwise easy Base Defense into a nightmare!

=== Accelerated build ===

One drawback of the above design is that it takes 52 days before all the facilities in the "choke line" are completed and the base is fully defensible against invasion. The following variant moves the Hyper-Wave Decoder to the right of the access lift, allowing the decoder, one hangar, and stores plus quarters to all be complete within 26 days.

Moving the hyperwave out of the choke line also makes it less likely to be destroyed by a stray blaster bomb. In the above designs, if the hyperwave gets destroyed, all modules beyond it will be destroyed as well. (Living quarters and stores are immune to destruction.)

<center>
{|
|-
|
{{UBK|=
|quarters|quarters|quarters|quarters|workshop|workshop|=
|quarters|dirt|quarters|quarters|workshop|workshop|=
|stores|dirt|stores|mind|workshop|psi|=
|lift|hyperwave|dirt|dirt|dirt|dirt|=
|hangar1|hangar2|hangar1|hangar2|hangar1|hangar2|=
|hangar3|hangar4|hangar3|hangar4|hangar3|hangar4|=}}
|
|
|
|
{{UBK|=
|quarters|quarters|quarters|quarters|workshop|workshop|=
|quarters|dirt|quarters|quarters|workshop|workshop|=
|stores|dirt|stores|mind|workshop|psi|=
|lift|hyperwave|dirt|dirt|psi|psi|=
|hangar1|hangar2|hangar1|hangar2|dirt|psi|=
|hangar3|hangar4|hangar3|hangar4|dirt|psi|=}}
|}
</center>

=== Time-Efficient Corridor Build ===

The following designs are an attempt to greatly speed up build times without sacrificing much (if any) defensibility. The base on the left is an example of how to start a new base if you don't yet have a Hyperwave Decoder. This would get you 2 Hangars, a General Stores, Radar, and Living Quarters by day 26. You can of course skip the Large Radar if you have already researched Hyperwave (in which case you would no doubt place the Hyperwave above your first Stores).

The base on the right is a complete version of this base. Notice that the general stores above the Access Lift is the only facility that has been removed if you did not build the radar, so if you are [[Known Bugs#Paying For Dirt|paying for dirt]], you will not suffer greatly. This build has only 5 wasted spaces, which is less than any other defensible build using 3 Hangars. If you really want the extra corridor space, you can skip the bottom-most Living Quarters. The corridor is, of course, indestructible, as it is done with General Stores. As a warning, if you have not eliminated the [[Known Bugs#Base Disjoint Bug|base disjoint bug]], you will find your soldiers sealed off from the aliens. Furthermore, if you expect to be attacked within a short period of time, you may not yet have swapped your choke point from the Access Lift to the General Stores on the left.

Lastly, the base on the right is an alternative 2 Hangar build.

<center>
{|
|-
|
{{UBK|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|dirt|dirt|stores|hangar1|hangar2|=
|dirt|dirt|large_radar|lift|hangar3|hangar4|=
|dirt|dirt|hangar1|hangar2|dirt|dirt|=
|dirt|dirt|hangar3|hangar4|dirt|dirt|=}}
|
|
|
|
{{UBK|=
|workshop|workshop|workshop|containment|hyperwave|mind|=
|workshop|quarters|lab|psi|dirt|dirt|=
|quarters|quarters|quarters|dirt|hangar1|hangar2|=
|stores|quarters|dirt|lift|hangar3|hangar4|=
|stores|dirt|hangar1|hangar2|hangar1|hangar2|=
|stores|stores|hangar3|hangar4|hangar3|hangar4|=}}
|
|
|
|
{{UBK|=
|workshop|workshop|workshop|containment|hyperwave|mind|=
|workshop|quarters|lab|psi|psi|psi|=
|quarters|quarters|quarters|dirt|psi|psi|=
|stores|quarters|dirt|lift|dirt|dirt|=
|stores|dirt|hangar1|hangar2|hangar1|hangar2|=
|stores|stores|hangar3|hangar4|hangar3|hangar4|=}}
|}
</center>

If you have a program to overhaul your starter base, the base on the bottom left is what I recommend. The picture on the right shows a good choice for immediate additions to it. You would of course want to add another Living Quarters if finances permit (don't forget to staff your Laboratory or Workshops).

<center>
{|
|-
|
{{UBK|=
|dirt|dirt|workshop|dirt|dirt|dirt|=
|dirt|dirt|lab|dirt|dirt|dirt|=
|dirt|dirt|quarters|small_radar|hangar1|hangar2|=
|dirt|dirt|dirt|lift|hangar3|hangar4|=
|dirt|dirt|hangar1|hangar2|hangar1|hangar2|=
|dirt|stores|hangar3|hangar4|hangar3|hangar4|=}}
|
|
|
|
{{UBK|=
|dirt|lab|workshop|containment|dirt|dirt|=
|dirt|dirt|lab|large_radar|dirt|dirt|=
|dirt|quarters|quarters|small_radar|hangar1|hangar2|=
|dirt|dirt|dirt|lift|hangar3|hangar4|=
|dirt|dirt|hangar1|hangar2|hangar1|hangar2|=
|stores|stores|hangar3|hangar4|hangar3|hangar4|=}}
|}
</center>

== Corner ambush build ==

<center>{{UBK|=
|quarters|workshop|workshop|quarters|quarters|stores|=
|quarters|psi|workshop|workshop|quarters|stores|=
|hyperwave|psi|stores|mind|dirt|stores|=
|dirt|dirt|workshop|dirt|dirt|stores|=
|hangar1|hangar2|dirt|hangar1|hangar2|stores|=
|hangar3|hangar4|lift|hangar3|hangar4|dirt|=}}</center>

I decided to put a little variety into my base defences. I like this pattern because i get to ambush the aliens as they turn the corner of the first general stores. Let THEM see how it feels getting whacked at blind corners!
Also, notice how that fights will only occur in or near indestructible modules. Too many exploding cyberdisks convinced me to do this.

The fact that the corridor is 5 units long is SIGNIFICANT. (the prior designs are actually only 3 modules long, because aliens spawn in the access lift, which has also has doors which block LOS and fired shots) Because alien sight is 20 squares. 5 modules is 45 tiles.This means that I can in fact keep 6 units (3 standing, 3 kneeling) at the north end of the North East corner module. I place scouts/spotters with a motion detectors in the rooms and round the corners of the corridor of general stores. The spotters pop out diagonally for mutual surprise, then hide again. Then the 6 snipers at the end of the corridor shoot down the corridor killing enemies in it. 45 tile distance means that no alien can turn the corner and walk far enough down the corridor to spot and shoot at my snipers in 1 turn.

== Missile Defence Module Build ==

<center>{{UBK|=
|stores|quarters|workshop|workshop|quarters|quarters|=
|stores|quarters|psi|workshop|workshop|quarters|=
|stores|dirt|psi|stores|mind|hyperwave|=
|stores|dirt|dirt|workshop|dirt|dirt|=
|missile|hangar1|hangar2|dirt|hangar1|hangar2|=
|dirt|hangar3|hangar4|lift|hangar3|hangar4|=}}</center>

This build takes advantage of the missile defences unique structure to force aliens to enter from the right, take a big detour, then exit to the north. This will likely severely hamper enemy blaster bomb efforts. However, by the same token, this is very likely to wind up causing your missile defences module to get blown up by blaster bombs, which will disconnect the rest of your base from your elevator, and make you lose most of your base. Be warned.

==Floor Plan Comparison==
Here's a comparison of the '''ground floor''' plans for X-COM base modules, in case it helps you design your base. For images, follow the links or see [[Xcom_and_Alien_Bases#XCom_Base|X-COM Base Module Images]]:

*'''3-wide "central plus sign" corridors:
** 1-wide doors along NW to SE path: [[Living Quarters]], [[Laboratory]], [[Workshop]]
** 1-wide doors along SW to NE path: [[Alien Containment]], [[Psionic Laboratory]]
** 2-wide doors along SW to NE path: [[General Stores]]

*'''Central room:
** 1 1-wide door, 2-wide corridors: [[Laser Defences]] (SW door), [[Plasma Defences]] (SE door), [[Fusion Ball Defences]] (NE door)
** 2 1-wide doors, 2-wide corridors: [[Large Radar System]] (SW & NE doors)
** 2 1-wide doors, 3-wide corridors: [[Grav Shield]], [[Hyper-wave Decoder]], [[Mind Shield]] (all have SW & SE doors)

*'''Unique modules:
**Wide open ground floor: [[Small Radar System]]
** "P" design of [[Missile Defences]] - no ground level doors; can force particular paths
** [[Hangar]]
** [[Access Lift]]

Most modules have a fairly open second story, with the exception of [[Missile Defences]], [[General Stores]], [[Alien Containment]], and the [[Psionic Laboratory]]. Still, half of the rest have a fair amount of clutter that might hide aliens.

==Notes==
*Corridors attaching to the right topside of a hangar (on the grid, the east side of the north wall) corner come through a ground-level hangar door. Corridors attaching anywhere else don't get a door. See picture at [[X-Com_Base_Terrain]].
*The ideal case is to have your choke point aligned vertically on the base grid, lined with general stores. The general stores have large, doublewide doors that open out onto the vertical corridor. These doors will give your your troops and tanks cover, and let them pop out to make attacks at will.
*It is also desirable to have a base facility containing a door directly facing the Access Lift (such as the Hyper-wave Decoder). A scout can pop out at the beginning of a turn and spot units coming down the corridor without risk of being shot due to the [[reaction fire triggers#mutual_surprise|"mutual surprise" rule]]. Other units with indirect-fire weapons (grenades and blaster launchers) can then safely attack the spotted alien(s). Direct-fire weapons can also be safely used if a thick-enough [[Smoke Grenade|smoke cover]] is present.
*Troops will spawn primarily in the Living Quarters and General Stores . Tanks will spawn mostly in the General Stores. You might want to cluster these units around your choke-point so your units will be where you need them.
*When constructing a base, be very careful that you avoid the [[Known Bugs#Base Disjoint Bug|Base Disjoint Bug]] where modules along the right and lower edges of the map can get sealed off. Improper placement will often end up forcing you to cut through the very tough walls and dirt blocks with heavy plasmas or tank lasers. However, with proper placement of modules, the sealed off walls can be very advantageous in controlling the flow of aliens. [[XcomUtil]] users cannot take advantage of this as the setup tool for this utility automatically rips out the walls.
*You can (and should) keep the poorly positioned rooms of your starter base up until the battleship is closing in. You can dismantle rooms instantly as long as they are unused. Since maintenance costs are buggy and listed values are always wrong, you are always better off keeping a room even if it is unused... at least up until the point the aliens arrive or you need the room.

==See Also==
*[[Base Management]]
*[[Base Defense]]
*[[Base Defense Measures]]
*[[X-Com Base Terrain]]

Base Layout Strategy

2009-04-20T17:27:46Z

Talon81: added new base designs

Your base will, at some point, be raided by angry aliens looking for revenge for all those UFO's you've taken out. Unlike most places you'll have to fight, you have control over the layout of your base, so design it wisely.

The key point for base defensibility is to minimize the number of points of entry. Aliens usually come down into your base through hangars and the access lift (although they can emerge on other locations - see the last comment on [[Base_Defense#Bugs]]). If you group your hangars with the access lift, then build only one module connecting to this part of your base, that module becomes a choke point for base defense. A long chain of rooms becomes a long choke point ripe for mining with Proximity Grenades and other dirty tricks. This way, you can line up all your units against one point of entry instead of having to spread them out to cover four or five.

The access lift is always the first unit built, so it becomes the obvious candidate for this single point of entry. Place it on the grid so you leave enough room to build hangars on one side of the lift, and everything else on the other side. I'd recommend building a General Stores on the lift opposite the hangar. A general stores is needed for any base, and it gets completed quickly. Once the general stores are completed, build all new facilities (except hangars, of course) off of that.

==Overhauling the Starter Base==

At higher difficulty levels, alien retaliation can often come MUCH sooner than you might be ready for-- before you have base defenses built, and before you have powerful weapons to arm your troops with. Considering that the access lift and all hangars serve as entry points for the invaders, the starter base has all the defensive virtues of a screen door:
<center>{{UBK|=
|dirt|dirt|hangar1|hangar2|dirt|dirt|=
|dirt|dirt|hangar3|hangar4|dirt|dirt|=
|dirt|dirt|lift|quarters|dirt|dirt|=
|dirt|small_radar|stores|lab|workshop|dirt|=
|hangar1|hangar2|dirt|dirt|hangar1|hangar2|=
|hangar3|hangar4|dirt|dirt|hangar3|hangar4|=}}</center>
The hangars and lift are distributed as widely as possible through the base, giving the aliens a wealth of breach points and enabling them to assault any defenders from all sides.

With this in mind, I recommend a partial rebuild of your initial base ASAP. Build two hangars next to the topmost hangar to replace the lower two, and a living quarters down between the two lower existing hangars to replace the one next to the access lift. Place any other new modules on the lower half of the screen, where they will not touch the lift or the new hangars.

As the new living quarters and hangar are completed, dismantle the old ones. It should now look something like:
<center>{{UBK|=
|hangar1|hangar2|hangar1|hangar2|hangar1|hangar2|=
|hangar3|hangar4|hangar3|hangar4|hangar3|hangar4|=
|dirt|dirt|lift|dirt|dirt|dirt|=
|large_radar|small_radar|stores|lab|workshop|dirt|=
|dirt|dirt|quarters|containment|dirt|dirt|=
|dirt|dirt|dirt|dirt|dirt|dirt|=}}</center>
Of course, place any other new facilities with a mind to preserving the new choke-point at the grav lift (i.e., nothing adjacent to the top hangars.) This layout isn't as fortified as many new-build bases can be, but it's a good compromise between defendability (one choke-point at the lift), available space, expedience (it converts from the standard layout in minimal time), and, especially, cost. It only costs the price of two hangars and a living quarters ($800,000) to overhaul your base this way-- a cost that can be covered by the proceeds from, say, one small landed UFO. It does however accrue base [[maintenance costs]] of $720,000 per month due to a [[Known Bugs#Paying For Dirt|bug]].

===Variations===

The previous example was a one chokepoint base that is easy to defend, however it is by no means the only way to build the base. Don't be afraid to try different variations of the base to suit the strategy that you intend use.

If you want to attack the aliens from two sides, the simple addition of an extra module can modify the one-chokepoint base into a two-chokepoint base. For example:

<center>{{UBK|=
|hangar1|hangar2|hangar1|hangar2|hangar1|hangar2|=
|hangar3|hangar4|hangar3|hangar4|hangar3|hangar4|=
|dirt|dirt|lift|dirt|small_radar|dirt|=
|large_radar|small_radar|stores|lab|workshop|dirt|=
|dirt|dirt|quarters|containment|dirt|dirt|=
|dirt|dirt|dirt|dirt|dirt|dirt|=}}</center>

The above base is designed to work like the popular defendable base layout, but also provides a second access point into the hangars. Although this means you have to spread your soldiers out to cover both points, so do the aliens.

With this example in particular, the small radar module provides an empty hallway. If you like to use rockets, this one access point gives you a clear shot into the hangars. A few well placed rockets can cut down the opposition considerably.

If you really like to use rockets but can only handle aliens entering the map through one entry point, consider the following variation.

<center>{{UBK|=
|hangar1|hangar2|hangar1|hangar2|hangar1|hangar2|=
|hangar3|hangar4|hangar3|hangar4|hangar3|hangar4|=
|dirt|dirt|lift|dirt|small_radar|dirt|=
|large_radar|small_radar|dirt|lab|workshop|dirt|=
|dirt|containment|quarters|stores|dirt|dirt|=
|dirt|dirt|dirt|dirt|dirt|dirt|=}}</center>

It may take a while to re-order the base in this manner from the starting setup, but the end result provides you with a clear firing corridor into the hangars with plenty of cubbyholes to hide in. All of the aliens will have to funnel through the small radar module, which is an open space with no place for the aliens to hide.

One disadvantage of this base however is that if the workshop suffers too much structural damage, all facilities past the small radar will be destroyed as they'll be disconnected from the access lift.

No matter what layout you eventually use, remember that the more complicated it is the longer it may take to construct and the more money it will cost. The last example requires moving a module that was already present in the default base. i.e. the general stores.

== Secondary Base Design ==

With your second and subsequent bases, you can build it securely right from the beginning. The most secure design uses the Access Lift as a choke point between the hangars and the rest of the base, as pictured above, but puts it to the side, out of the way, and also adds a long corridor between the Access Lift and the rest of the base:
<center>{{UBK|=
|quarters|quarters|quarters|quarters|workshop|workshop|=
|stores|dirt|quarters|quarters|workshop|workshop|=
|hyperwave|dirt|stores|mind|workshop|psi|=
|lift|dirt|dirt|dirt|dirt|dirt|=
|hangar1|hangar2|hangar1|hangar2|hangar1|hangar2|=
|hangar3|hangar4|hangar3|hangar4|hangar3|hangar4|=}}</center>

The exact facilities built are up to the individual player, although a hyper-wave decoder, stores, and living quarters are generally the most important facilities to build first. Even if you don't plan on stationing any X-Com [[craft]] at the base, you should also build at least one hangar (where aliens will spawn preferentially during a [[Base Defense]] mission) to prevent them from spawning deeper inside the base.

Be sure not to put the Access Lift on the southern or eastern borders of the map to avoid the [[Known Bugs#Base Disjoint Bug|base disjoint bug]].

If three hangars are not needed, additional base facilities can be added, as long as they are not placed adjacent to the hangars:
<center>
{|
|-
|
{{UBK|=
|quarters|quarters|quarters|quarters|workshop|workshop|=
|stores|dirt|quarters|quarters|workshop|workshop|=
|hyperwave|dirt|stores|mind|workshop|psi|=
|lift|dirt|dirt|dirt|psi|psi|=
|hangar1|hangar2|hangar1|hangar2|dirt|psi|=
|hangar3|hangar4|hangar3|hangar4|dirt|psi|=}}
|
|
|
|
{{UBK|=
|quarters|quarters|quarters|quarters|workshop|workshop|=
|stores|dirt|quarters|quarters|workshop|workshop|=
|hyperwave|dirt|stores|mind|workshop|psi|=
|lift|dirt|quarters|psi|psi|psi|=
|hangar1|hangar2|dirt|psi|psi|psi|=
|hangar3|hangar4|dirt|psi|psi|psi|=}}
|}
</center>

The design with only one hangar, however, runs the risk of having aliens spawn in areas other than the hangars and access lift, as one hangar plus one access lift only provide (15 + 8 = 23) alien spawn points, and a [[Battleship]] on Superhuman difficulty can carry between 22 and 28 aliens. Especially troubling is the fact that Terror Units have the lowest alien spawn priority and thus are most likely to show up in your base. This might result in some [[Chryssalid|particularly]] [[Sectopod|nasty]] units spawning behind your lines, quickly turning an otherwise easy Base Defense into a nightmare!

=== Accelerated build ===

One drawback of the above design is that it takes 52 days before all the facilities in the "choke line" are completed and the base is fully defensible against invasion. The following variant moves the Hyper-Wave Decoder to the right of the access lift, allowing the decoder, one hangar, and stores plus quarters to all be complete within 26 days.

Moving the hyperwave out of the choke line also makes it less likely to be destroyed by a stray blaster bomb. In the above designs, if the hyperwave gets destroyed, all modules beyond it will be destroyed as well. (Living quarters and stores are immune to destruction.)

<center>
{|
|-
|
{{UBK|=
|quarters|quarters|quarters|quarters|workshop|workshop|=
|quarters|dirt|quarters|quarters|workshop|workshop|=
|stores|dirt|stores|mind|workshop|psi|=
|lift|hyperwave|dirt|dirt|dirt|dirt|=
|hangar1|hangar2|hangar1|hangar2|hangar1|hangar2|=
|hangar3|hangar4|hangar3|hangar4|hangar3|hangar4|=}}
|
|
|
|
{{UBK|=
|quarters|quarters|quarters|quarters|workshop|workshop|=
|quarters|dirt|quarters|quarters|workshop|workshop|=
|stores|dirt|stores|mind|workshop|psi|=
|lift|hyperwave|dirt|dirt|psi|psi|=
|hangar1|hangar2|hangar1|hangar2|dirt|psi|=
|hangar3|hangar4|hangar3|hangar4|dirt|psi|=}}
|}
</center>

=== Time-Efficient Corridor Build ===

The following designs are an attempt to greatly speed up build times without sacrificing much (if any) defensibility. The picture on the left is an example of how to start a new base if you don't yet have a Hyperwave Decoder. This would get you 2 Hangars, a General Stores, Radar, and Living Quarters by day 26. You can of course skip the Large Radar if you have already researched Hyperwave(in which case you would no doubt place the Hyperwave above your first Stores). The picture on the right is a complete version of this base. Notice that the general stores above the Access Lift is the only facility that has been removed, so if you are [[Known Bugs#Paying For Dirt|paying for dirt]], you will not suffer greatly. This build has only 5 wasted spaces, which is less than any other defensible build using 3 Hangars. If you really want the extra corridor space, you can skip the bottom-most Living Quarters. The corridor is, of course, indestructible, as it is done with General Stores. As a warning, if you have not eliminated the [[Known Bugs#Base Disjoint Bug|base disjoint bug]], you will find your soldiers sealed off from the aliens.
<center>
{|
|-
|
{{UBK|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|dirt|dirt|dirt|dirt|dirt|=
|dirt|dirt|dirt|stores|hangar1|hangar2|=
|dirt|dirt|large_radar|lift|hangar3|hangar4|=
|dirt|dirt|hangar1|hangar2|dirt|dirt|=
|dirt|dirt|hangar3|hangar4|dirt|dirt|=}}
|
|
|
|
{{UBK|=
|workshop|workshop|workshop|containment|hyperwave|mind|=
|workshop|quarters|lab|psi|dirt|dirt|=
|quarters|quarters|quarters|dirt|hangar1|hangar2|=
|stores|quarters|dirt|lift|hangar3|hangar4|=
|stores|dirt|hangar1|hangar2|hangar1|hangar2|=
|stores|stores|hangar3|hangar4|hangar3|hangar4|=}}
|}
</center>

If you have a program to overhaul your starter base, the base on the bottom left is what I recommend. The picture on the right shows a good choice for immediate additions to it. You would of course want to add another Living Quarters if finances permit (don't forget to staff your Laboratory or Workshops).

<center>
{|
|-
|
{{UBK|=
|dirt|dirt|workshop|dirt|dirt|dirt|=
|dirt|dirt|lab|dirt|dirt|dirt|=
|dirt|dirt|quarters|small_radar|hangar1|hangar2|=
|dirt|dirt|dirt|lift|hangar3|hangar4|=
|dirt|dirt|hangar1|hangar2|hangar1|hangar2|=
|dirt|stores|hangar3|hangar4|hangar3|hangar4|=}}
|
|
|
|
{{UBK|=
|dirt|lab|workshop|containment|dirt|dirt|=
|dirt|dirt|lab|large_radar|dirt|dirt|=
|dirt|quarters|quarters|small_radar|hangar1|hangar2|=
|dirt|dirt|dirt|lift|hangar3|hangar4|=
|dirt|dirt|hangar1|hangar2|hangar1|hangar2|=
|stores|stores|hangar3|hangar4|hangar3|hangar4|=}}
|}
</center>

== Corner ambush build ==

<center>{{UBK|=
|quarters|workshop|workshop|quarters|quarters|stores|=
|quarters|psi|workshop|workshop|quarters|stores|=
|hyperwave|psi|stores|mind|dirt|stores|=
|dirt|dirt|workshop|dirt|dirt|stores|=
|hangar1|hangar2|dirt|hangar1|hangar2|stores|=
|hangar3|hangar4|lift|hangar3|hangar4|dirt|=}}</center>

I decided to put a little variety into my base defences. I like this pattern because i get to ambush the aliens as they turn the corner of the first general stores. Let THEM see how it feels getting whacked at blind corners!
Also, notice how that fights will only occur in or near indestructible modules. Too many exploding cyberdisks convinced me to do this.

The fact that the corridor is 5 units long is SIGNIFICANT. (the prior designs are actually only 3 modules long, because aliens spawn in the access lift, which has also has doors which block LOS and fired shots) Because alien sight is 20 squares. 5 modules is 45 tiles.This means that I can in fact keep 6 units (3 standing, 3 kneeling) at the north end of the North East corner module. I place scouts/spotters with a motion detectors in the rooms and round the corners of the corridor of general stores. The spotters pop out diagonally for mutual surprise, then hide again. Then the 6 snipers at the end of the corridor shoot down the corridor killing enemies in it. 45 tile distance means that no alien can turn the corner and walk far enough down the corridor to spot and shoot at my snipers in 1 turn.

== Missile Defence Module Build ==

<center>{{UBK|=
|stores|quarters|workshop|workshop|quarters|quarters|=
|stores|quarters|psi|workshop|workshop|quarters|=
|stores|dirt|psi|stores|mind|hyperwave|=
|stores|dirt|dirt|workshop|dirt|dirt|=
|missile|hangar1|hangar2|dirt|hangar1|hangar2|=
|dirt|hangar3|hangar4|lift|hangar3|hangar4|=}}</center>

This build takes advantage of the missile defences unique structure to force aliens to enter from the right, take a big detour, then exit to the north. This will likely severely hamper enemy blaster bomb efforts. However, by the same token, this is very likely to wind up causing your missile defences module to get blown up by blaster bombs, which will disconnect the rest of your base from your elevator, and make you lose most of your base. Be warned.

==Floor Plan Comparison==
Here's a comparison of the '''ground floor''' plans for X-COM base modules, in case it helps you design your base. For images, follow the links or see [[Xcom_and_Alien_Bases#XCom_Base|X-COM Base Module Images]]:

*'''3-wide "central plus sign" corridors:
** 1-wide doors along NW to SE path: [[Living Quarters]], [[Laboratory]], [[Workshop]]
** 1-wide doors along SW to NE path: [[Alien Containment]], [[Psionic Laboratory]]
** 2-wide doors along SW to NE path: [[General Stores]]

*'''Central room:
** 1 1-wide door, 2-wide corridors: [[Laser Defences]] (SW door), [[Plasma Defences]] (SE door), [[Fusion Ball Defences]] (NE door)
** 2 1-wide doors, 2-wide corridors: [[Large Radar System]] (SW & NE doors)
** 2 1-wide doors, 3-wide corridors: [[Grav Shield]], [[Hyper-wave Decoder]], [[Mind Shield]] (all have SW & SE doors)

*'''Unique modules:
**Wide open ground floor: [[Small Radar System]]
** "P" design of [[Missile Defences]] - no ground level doors; can force particular paths
** [[Hangar]]
** [[Access Lift]]

Most modules have a fairly open second story, with the exception of [[Missile Defences]], [[General Stores]], [[Alien Containment]], and the [[Psionic Laboratory]]. Still, half of the rest have a fair amount of clutter that might hide aliens.

==Notes==
*Corridors attaching to the right topside of a hangar (on the grid, the east side of the north wall) corner come through a ground-level hangar door. Corridors attaching anywhere else don't get a door. See picture at [[X-Com_Base_Terrain]].
*The ideal case is to have your choke point aligned vertically on the base grid, lined with general stores. The general stores have large, doublewide doors that open out onto the vertical corridor. These doors will give your your troops and tanks cover, and let them pop out to make attacks at will.
*It is also desirable to have a base facility containing a door directly facing the Access Lift (such as the Hyper-wave Decoder). A scout can pop out at the beginning of a turn and spot units coming down the corridor without risk of being shot due to the [[reaction fire triggers#mutual_surprise|"mutual surprise" rule]]. Other units with indirect-fire weapons (grenades and blaster launchers) can then safely attack the spotted alien(s). Direct-fire weapons can also be safely used if a thick-enough [[Smoke Grenade|smoke cover]] is present.
*Troops will spawn primarily in the Living Quarters and General Stores . Tanks will spawn mostly in the General Stores. You might want to cluster these units around your choke-point so your units will be where you need them.
*When constructing a base, be very careful that you avoid the [[Known Bugs#Base Disjoint Bug|Base Disjoint Bug]] where modules along the right and lower edges of the map can get sealed off. Improper placement will often end up forcing you to cut through the very tough walls and dirt blocks with heavy plasmas or tank lasers. However, with proper placement of modules, the sealed off walls can be very advantageous in controlling the flow of aliens. [[XcomUtil]] users cannot take advantage of this as the setup tool for this utility automatically rips out the walls.
*You can (and should) keep the poorly positioned rooms of your starter base up until the battleship is closing in. You can dismantle rooms instantly as long as they are unused. Since maintenance costs are buggy and listed values are always wrong, you are always better off keeping a room even if it is unused... at least up until the point the aliens arrive or you need the room.

==See Also==
*[[Base Management]]
*[[Base Defense]]
*[[Base Defense Measures]]
*[[X-Com Base Terrain]]

User talk:Seb76

2009-04-19T19:23:48Z

Talon81: New section: Initial Alien Bases

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

<i>Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)</i>

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

== Initial Alien Bases ==

OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)

User talk:Seb76

2009-04-19T19:18:01Z

Talon81: /* Heavy Laser Mod */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

<i>Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)</i>

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

User talk:Seb76

2009-04-19T19:16:22Z

Talon81: /* Heavy Laser Mod */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw.

== Wish List please please please ==

=== New and Outstanding Requests ===

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

<i>Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)</i>

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

User talk:Seb76

2009-04-14T10:02:22Z

Talon81: /* TFTD Door problem */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

<i>Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)</i>

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

User talk:Seb76

2009-04-14T10:01:03Z

Talon81: /* Heavy Laser Mod */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

<i>Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)</i>

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again.
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)

Talon81

User talk:Seb76

2009-04-11T06:49:11Z

Talon81: /* TFTD Door problem */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

<i>Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)</i>

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again.
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)

Talon81

User talk:Seb76

2009-04-06T08:24:28Z

Talon81: New section: TFTD Door problem

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

==== Incendiary Bug ====

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

:: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

==== See Also ====

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

=== Completed Items - Thanks Seb! ===

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control?

Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!
:I think this is a known issue with LOS, not sure though
I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

<i>Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)</i>

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again.