https://www.ufopaedia.org/api.php?action=feedcontributions&user=Spike&feedformat=atom
UFOpaedia - User contributions [en]
2024-03-29T14:13:29Z
User contributions
MediaWiki 1.35.4
https://www.ufopaedia.org/index.php?title=TFTDextender&diff=72349
TFTDextender
2016-06-13T19:10:44Z
<p>Spike: /* Installation */ Steam instructions</p>
<hr />
<div>[[File:Cthulhu_rising.jpg|500px|right|Base to Lt. Cmdr. Solomon: Say Again... What do you see?]]<br />
=[[:file:TFTDextender.zip|File: TFTDextender]]=<br />
<br />
This is a conversion of Seb76's UFOloader. Xusilak released a prototype, called TFTDloader, that offered players the ability to run the CE, or Gold, version without video problems in September 2010. He made a lot of notations on various subroutines and variables used throughout the executable. In March of 2012, Kyrub released an updated version called TFTD Extender, which had limited functionality. When he became unable to continue development on his project, Tycho released another version called TFTDextender, which was based on Xusilak's original code and had more functionality than Kyrub's version. Almost all applicable fixes and mods that were made for UFO Extender have been successfully imported and new mods and fixes specifically for this game have been added since the initial version. Version 1.02 was released in June, 2013.<br />
<br />
The extender patches the program in memory, '''it does not modify the executable'''. The advantage is that it won't change the file on disk so there is little risk of destroying your game installation (still, it is wise to do a backup of your game folder before using this). It also means that any data mods that one may wish to use should not conflict. Of course, if your computer stops responding and starts chanting verses in an inhuman language, I don't take any responsability...<br />
<br />
Some changes are recorded in a game's save files so be aware of this fact when you change options and wonder why some changes don't work on games already in progress. Changes will require you to restart the loader to have them take effect. <br />
<br />
:Feel free to contact me with any questions and please don't hesistate to report any problem you encounter with this, I'll try to help you fix it. [[User:Morgan525|Tycho]]<br />
:You can also reach me through the StrategyCore forum for TFTD Extender[http://www.strategycore.co.uk/forums/topic/9867-tftd-extender/], where also I am called "Tycho".<br />
<br />
<br />
==Installation==<br />
<br />
:NOTE: This program only works with the Windows version of ''Terror from the Deep'' (usually referred to as the Collector's Edition (CE) or the Gold Edition). '''It is not compatible with the DOS version nor will it run through DOSbox''' as the memory handling and offsets are different.<br />
<br />
*You'll need the MS VC2008 runtime to use TFTDextender. You can get it [http://www.microsoft.com/en-us/download/details.aspx?id=29] here.<br />
*If you want to use the mp3 patch, you need to have Windows Media Player installed. '''This is not necessary starting with version 1.07'''<br />
*Download the latest full version and latest patch by clicking on the title above to get to the file section.<br />
*Extract the contents to your TFTD folder where the "Terror from the Deep.exe" file is located. <br />
::-You need a program able extract zip files.<br />
::-Extract the full version first and then the patch. Click "Yes" to overwrite the current file.<br />
*Use a simple text editor (like MS notepad) to open TFTDextender.INI and enable the options you wish, usually by changing the number on the entry line to 1. <br />
::-Look at this page or refer to ExtenderINIref.txt in the TFTD game directory for exact details on each option.<br />
*To run the game with the extender, use "TFTDextender.exe" and not the usual game executable. <br />
::-The program looks for the file named "Terror from the Deep.exe" but this can be changed by editing the line under the section marked [Loader] at the beginning of the TFTDextender.INI file. ''(enabled in version 1.6).''<br />
*If you have a Steam installation, locate the TFTD game folder and install there. Instead of running via Steam, just run TFTDExtender directly from that folder.<br />
<br />
==FAQs==<br />
''Why don't I have music after installing the Extender?''<br />
:The CE version uses midi files for the soundtrack. Some digital downloads are missing the midi music in the SOUND folder. They are provided here: [[File:TFTDmidi.zip]]<br />
<br />
''Problems with mp3 playing: Crash or no sound''<br />
: This is usually a codec problem with the OS music player. See this discussion on how to isolate and resolve this. [http://forums.steampowered.com/forums/showpost.php?p=33138727&postcount=272]<br />
: Starting with version 1.07, a new way to play music has been implemented so mp3 playback should work despite codecs.<br />
<br />
''When I run the Extender, I have problems loading or I get garbled graphics.''<br />
:The initial settings in the INI are very basic since user preferences and systems are so varied. It is up to the users to configure the INI file to their needs. Some graphic cards have a problem with the initial video settings and require D3D to be enabled. Others may need to disable even the basic settings if they intend to use another mod program, such as XcomUtil.<br />
<br />
''I get a crash message as soon as I run the Extender.''<br />
: (1)This can be caused by not having the video options configured correctly. Try enabling D3D in the INI.<br />
: (2)Disable the option to skip the intro movie, especially if you are using a split executable such as with xcomutil.<br />
<br />
''TFTD Extender and XcomUtil: Crash/errors when leaving Geoscape/starting a battle''<br />
: Kyrub identified a problem with the way XcomUtil splits the executable. Bomb_bloke wrote an updated splitter: see this discussion [http://www.strategycore.co.uk/forums/topic/10103-tftdxcomutil-error-message/#entry119265].<br />
: There now is an option in the INI to disable error messages.<br />
<br />
''The game crashes as soon as I choose to go to T'leth.''<br />
: There is a problem with some movie files with some digital downloads of the game. Bomb Bloke wrote a set of dummy files which will let the CE version continue to the final battle. Check out this article[http://www.strategycore.co.uk/forums/topic/3404-cant-finish-the-game/#entry58766].<br />
<br />
== Some Disclaimers==<br />
:'''Extender and modified game executables''': These may work together but there is no guarentee. Some heavily modify the binary and trying to patch on top of it will produce unexpected data corruption or crash the game. Even splitting the executable, such as done by XComUtil, causes problems.<br />
:'''DAT file mod requests''': DAT files modifications are not done because there are already lots of them and various data editors available to do them for yourself. This rule allows all data mods to keep working with the loader (that is why some xcomutil features should still work, as long as they are those only based on resource modifications). ''Any bug fix that requires a change to some resource data in order to compensate for the fix, will have an option to exclude the data change so that any player changes will not be overwritten.''<br />
<br />
==TFTDextender INI references==<br />
===Bug Fixes===<br />
<br />
:''By default most bug fixes are already enabled; there is a section in the INI for bug fixes in case you want to disable a fix. A complete list of these fixes are listed in the file, TFTDbugReference.txt. To disable a fix, simply open this file and copy the appropriate line to the [Bug Fix] section of the INI.<br />
''<br />
*Music Change Freeze: try to prevent the freeze that happens ingame when the MIDI music changes (experimental) ['''Not enabled''' by default]<br />
*Sensor Stacking: Fix the bug where having more than one sonar for each type is useless. When enabled, each standard sonar has a 10% probability<br />
*Base Facility Dismantle-Construction Crash: fix the crash that may happen after you delete a facility under construction.<br />
*Collectors Edition Blaster Bomb Bug: fix problems with setting vertical waypoints<br />
*Proximity Grenades: fix lost armed state when reloading a game<br />
*Proximity Grenades Experience: give experience to the thrower, not the victim...<br />
*Transfered Crafts Refueled: fix the "Fuel dump on transfer" bug<br />
*Zrbite-fueled Craft Bug: fix the bug which causes Zrbite fueled crafts to return to base when their fuel level is 50%<br />
*Corpses Don't Teleport: The corpse for an unconscious unit that was moved and later killed by an explosion will not spawn where the unit originally went unconscious. {version 105p1}<br />
*Door Jam: fix the opened sliding doors not closing after a reload<br />
*Personnel Overflow: fix the overflow that occurs when there are 256 engineers/scientists present in a base. Values are topped at 255 now<br />
*Funky Fire: only apply fire damage at the end of turn. Also doubles fire damage to compensate<br />
*Hostile Civilians: fix civilians becoming hostile after being mind controlled<br />
*BioDrone Melee Attack Fix: Assigns a value to melee accuracy allowing the melee attack to be effective<br />
*FixSounds: Zombies sound like any other bipedal units when walking. The "pop" at the end of many sound effects has been eliminated.<br />
*No Underwater Weapons Fire on Land: prevents underwater-only weapons from making reaction shots or shooting when a soldier is bezerk.<br />
*Tech Tree Impasses Resolved: You won't need to have a sub_contruction item in inventory before completing research on the Transmission Resolver, nor a MC reader before finishing MC Lab. Both can be researched when one is found just like other artifacts.<br />
*Coelacanth/Gauss Ammo Fix:all ammo problems related to unequiping one from a craft or after combat are fixed. Its only prerequisite is Gauss Cannon (same as the laser tank in EU).<br />
*Hallucinoid Range Attack Fix: Gives the Hallucinoid a stunning ranged ''area'' attack as per the Ufopaedia description - making this alien much more dangerous.<br />
*P.W.T. Launcher Production Fix: P.W.T. launcher production will now correctly consume 1 plastic for the first item produced.<br />
*Better chance to get a Cargo Ship Terror Mission rather than only Cruise Liners.<br />
*Soldiers will not go MIA if they are MCed when mission ends successfully.<br />
*Deep One attack no longer resembles the Celatid Spit.<br />
*Bio-Drone no longer burns the ground like the Silacoid.<br />
*Fixed the problem that allowed the player to assign too many technicians to a manufacturing project. Now the same as ''Enemy Unknown''.<br />
*Fixed the damage on the Displacer's sonic oscillator. ''The in-game UFOpaedia stated that the displacer did 130 damage but the value in the exectuable was only 110.<br />
*Any MCed unit will have the MCed effect removed and its proper faction restored when it is rendered unconscious.<br />
*Clips loaded into weapons that are left on the battlefield during an abort will not be given to the player.<br />
*Weight issues with clips that are in weapons have been fixed.<br />
*Craft Gauss Cannon's max ammo increased to 100 and base rearm rate increased to 50 rounds per hour.<br />
*The area of effect for the Thermal Shok Bomb has been reduce to closer match the radius of Enemy Unknown's Stun Bomb.<br />
*PWT Ammo for all weapons has had their production requirements changed to a more logical correlation to the damage they do. Sell value reflects the changes. [new games only]<br />
*Aqua Plastic Armor uses the correct damage modifiers.<br />
*Aliens with no weapons will not crash the game after throwing their last grenade.<br />
*Aliens attempting to attack a base location will not crash the game.<br />
*Large Units are affected only once by the same explosion.<br />
*All parts of a large unit are correctly controlled if Molecular Control is successful.<br />
*Tentacults hatched from Molecular Controlled zombies will not be assigned to the X-COM side. <br />
*SWS/Harpoon Bolts and SWS/Gauss Cannon Rounds will not take up space in base inventory.<br />
*Large Units with range attacks do not go berserk.<br />
*Aliens can now use their melee weapons.<br />
*Tentacults have a lower strength and Lobstermen's is higher.<br />
*Units immune to fire with only a few hit points cannot be killed by fire.<br />
*SWS present for base defence missions will get their ammo from base stores. (No free ammo.)<br />
<br />
===Loader===<br />
*'''Executable''': The name of the game executable that the Extender will use.<br />
*'''Debug Messages''': Used to enable or disable the error messages that are displayed when the Extender encounters a problem. With this enabled, the game will simply exit to the desktop when an error occurs. Set to 1 to stop the messages.<br />
<br />
===Video===<br />
* '''Video Pitch''': This fixes the garbled video seen when you first start the game. It is similar to f0dder's loader. This is enabled by default.<br />
* '''HQ4x''': raise the resolution of the game and applies some filtering. It is quite CPU intensive though...<br />
* '''D3D''': replace DirectDraw calls with Direct3D9. It sets the monitor to its default resolution and uses D3D to stretch the image on screen. It may also fix the speed issues if your video driver is configured properly.<br />
: ''These settings are exclusive of each other: Some work together while others will override the previous level: [initial] video pitch -> HQ4x -> D3D -> D3D&HQ4x [highest scaling].''<br />
:'' If the initial '''Video Pitch''' option doesn't seem to work, use the D3D option.''<br />
* '''D3D Windowed''': run the game in a window. The first two numbers are the Y and X positions on the screen for where to place the box. The second two numbers are the size of the window in height and width. 0 0 600 800 should place a 800x600 window in the top left corner.<br />
* '''Always On Top''': force the window in the foreground.<br />
* '''Clip Cursor''': prevent the cursor from going outside the window. It has two modes:<br />
**Level 1: Tactical only. In the battlescape the mouse is restrained to the window but not in the Geoscape.<br />
**Level 2: Constant. Mouse is restrained in both Battlescape and Geoscape. <br />
:<br />
'''These options only apply when you run the game in full screen mode:'''<br />
* '''Scale Mouse''': attempts to keep the cursor from running off screen when using HQ4x and/or D3D. Useful when not running a windowed game. ''Try this if you start the game and your mouse doesn't seem to work or there is no cursor on the screen.''<br />
* '''Screen Ratio''': adds black bars to keep aspect ratio on non 16/10 monitors (based on patch from mikawo) You can set "Screen Ratio" to correct your aspect ratio. Some common settings are 1.33333 or 1.66666. <br />
: ''I believe the ratio is the width/height but factor that 16/10 is the default of 1: 16/10 [320x200, 640x400, 1280x800, 1440x900] would be 1. 4/3 ratio [640x480, 1024x768, 1440x1080] is 0.833333. 16/9 should be 1.11111. Using these values for Screen Ratio seems to give the correct aspect ratio when compared to DOSBox results.'' <br />
:<br />
'''Other Video options that work in either windowed or full-screen:'''<br />
*'''Slow the Clock''': Slow the passage of time in the Geoscape. The passage of time will match the option chosen in the right menu by the player but the clock will increment in smaller units at a faster rate. ''At the 5 sec rate, the clock will increment in seconds but 5 seconds of game time will pass for every second of real time. '' (available with version 1.061)<br />
*'''Slow Battlescape Animation Speed''': All animations in the battlescape can be slowed down. User can fine tune the degree from only 2x up to 15x slower. 3~5x is recommended to start with.<br />
* '''Max FPS''': limit the framerate for the ones that cannot get vsync working. Not as smooth as vsync limited, but better than nothing (only works with D3D or Video Pitch enabled). Can help to slow the game, similar to lowering cycles per second. Defaulted to 70. <br />
* '''Skip Intro''': bypasses the Microprose logo video and initial movie when you start the game.<br />
* '''Force Language''': automatically selects the appropriate language for you.<br />
<br />
===Mods===<br />
* '''Know Thy Enemy''': Damage on weapons is capped until humans learn the location of vital areas of each alien race. ''Damaged is capped at average weapon strength with a small chance of a "lucky shot" that bypasses the cap limit. Explosion and Thermal damage is not affected.''<br />
* '''Start With Alternate Tech Tree''': choose the level of change to apply to the research tree when you <u>start a NEW game</u>. (the higher the number the more changes are applied.)<br />
**=1: The need for a live Deep One to research Ion Armor is removed.<br />
**=2: The vibroblade can be researched when found but a calcinite autopsy is required for thermic lance.<br />
**=3: The prerequisites for armors have been reordered or changed. Aqua plastics can be researched when found. The prerequisite for Ion Armor is '''not''' a live Deep One but <u>more logical</u>. (Hint:all armors' prerequisites follow the same idea.)<br />
:Each level stacks upon or replaces the previous set of changes.<br />
:''Note: Some changes will be stored in the game's saved files and cannot be altered again except by editing these files directly. There could be some issues with the availability of certain research topics if one changes the option for a game already in progress.''<br />
* '''Different Colony Races''': More variety of alien races on stage 1 and the alien race in stage 2 corresponds to the race of the supply craft.<br />
* '''Small Colony Size''': The size of stage 2 of a colony is reduced to the same area as a base in Enemy Unknown.<br />
* '''Single Stage Ship Missions''': Ship sites will be complete after the first stage. <br />
* '''Smaller USO Battle Maps''': The map size is reduced to be the same as those in Enemy Unknown.<br />
* '''Increase Sea Floor Terrain Variety''': Enabling this will increase the chances of different environments being generated in random USO recovery missions.<br />
* '''All Torpedos At Start''': Replaces the craft gas cannons and ammo with D.U.P launchers on your subs and torpedoes in your base stores, as if you manually did this at the beginning of game without the wasted time.<br />
* '''Improve Rearm Rate of Ajax''': The number of rounds loaded onto a craft each cycle is increased from 1/hour to 2/hour.<br />
* '''Show Money''': Shrinks the clock in the date/time panel on the main geoscape screen, and adds a funds display above it. It is useful for examining remaining funds during manufacturing projects, while waiting for time to pass.<br />
* '''Block Can't Intercept Messages''' [<s>'''Block Intercept Over Land Message, Block Mission Too Deep Message'''</s>]: Blocks the pop-up notifications that you cannot intercept an alien sub. ''An Xcraft will pursue and automatically engage a USO once it reaches water. A Barracuda will hover over or chase a very deep sub until it reaches a shallower depth. Only a Triton will receive the "Mission too deep" message and automatically return to base.''<br />
* '''Crafts Always Ready''': Craft can be launched before damage, ammo, or fuel are completely restored.<br />
:''(v1.06)''<br />
:''=1: Craft can be launched in any condition.''<br />
:''=2: Damaged craft are grounded.''<br />
* '''Manual Interception Fire Mode''': Subs will not fall back after taking damage or expending all their ammo. This overcomes the issue of the last shot always missing.[http://www.ufopaedia.org/index.php?title=Known_Bugs#Interceptions:_Last_Shot_Always_Misses]<br />
* '''USO Responds to Interception''': Alien subs will react to being attacked. <br />
* '''True Cautious Mode''': Subs with two equal weapons will only fire one weapon at a time and the stance imparts a penalty to alien attacks.<br />
* '''De-equip Craft''': Provides the option on the craft armament screen.<br />
[[file:X2deequip.JPG|center|400px]]<br />
* '''Reorder Soldiers In Crafts''': <br />
[[file:X2reorder.JPG|center|400px]]<br />
:If you hold the mouse button for more than 200ms when clicking, the soldier will be moved to the top/bottom of the list. Now you can force rookies on the front line... It also enables you to check the soldier's stats by clicking on his name.<br />
* '''Auto sell''': allows the player to activate an automatic production and automatic selling mode in manufacturing by pressing the down arrow button to reduce the quantity of desired items below zero:<br />
**Autosell mode: In this mode, production will never cease unless resources become unavailable, and all produced items will be immediately sold. <br />
**Autoproduce mode: This functions in the same way as autosell, but the results will not be sold, merely stockpiled forever.<br />
: Caution should be used with this mode, as it can drain resources quickly.<br />
::::[[file:X2autosell.JPG|400px|Autosell]] [[file:X2autoproduce.JPG|405px|Autoproduce]]<br />
* '''Improved Gauss Tank''': Aqua Plastic becomes a prerequisite and part of the production requirements but the armor gets a significant boost. <br />
[[File:X2ImpGaussTank.JPG|center|400px|Improved Gauss Tank]]<br />
* '''Improved Detector''': The particle disturbance sensor will be upgraded after research on M.C. Reader is finished. Its radius of detection is doubled and will detect all units in range. <br />
::''Our recent research on the alien scanning device has allowed us an excellent opportunity. We can devise improved detectors that will emit a small pulse and triangulate on any alien implants that respond. You should be able to determine the general direction and range.'' <br />
* '''Remove Background Land Sound''': The background sound of land sites is poor quality for today's sound systems and annoying. This option blocks it.<br />
* '''Alien Bleeding''': Aliens can suffer fatal wounds as well.<br />
* '''No Alien Freak Out Messages''': The player will receive no notice that alien units have suffered morale problems.<br />
* '''More Reaction Fire''': Aliens and Aquanauts will react to targets turning in place as well as movement or attacks.<br />
* '''Hot Grenades''': Grenade timers will continue to countdown even when held.<br />
* '''Alien Inventory''': Gain direct access to an alien's inventory screen after it has been brought under your control.<br />
* '''No Blaster Bomb Drift''': disable the randomness applied to blaster bomb (Power Wave Torpedoes) trajectories between waypoints. It'll solve drifting issues experienced with the blaster launcher, and also make aliens even more deadly with that weapon since their hard coded accuracy of 55% won't affect their shots anymore.<br />
* '''All Items Usable On Land''': Removes all restrictions on items so they may be used anywhere. Magnetic Ion Armor flies on land.<br />
* '''Smaller Stun Blast''': the area of effect for the thermal bomb is reduced.<br />
[[File:Stun_blast_radius.GIF|center|Compare area of effect for Stun Blast]]<br />
* '''Modified Loadouts for Aquatoid''': For those who wonder how a small aquatoid can carry a sonic cannon. This mod will replace their cannons with sonic rifles or pistols, depending upon the rank of the unit. Other weapons are not affected.<br />
<br />
===Equipment===<br />
* '''Show Stats''': Displays several of the important soldiers' stats on the right to help you decide how to equip them. MC stats will be displayed when they become available. The rank icon is part of TFTD, unlike ''Enemy Unknown''.<br />
[[file:X2liststats.JPG|center|400px]]<br />
* '''Show Grenade State''': Grenades that have been armed now have [primed] added to their name.<br />
* '''Save Equipment''': Will automatically reequip each aquanaut with their last weapon load-out, if possible, at the beginning of any mission. New soldiers will receive a minimal set of weapon and ammo to start with. <br />
** ''Auto Flares'': automatically equip flares (if available in the craft) during night missions (only works with Save Equipment).<br />
:<br />
'''Localization strings''': add the following strings to the end of the equipment section and change the text between the "=" and ">" to match your particular language. English is the default. (''available with version 1.05p3''). Examples are for English:<br />
:Weight=Weight><br />
:Accuracy=Accur><br />
:Reaction=React><br />
:Psi Strength=P.Str><br />
:Psi Skill=P.Skill><br />
<br />
===Enhanced Tactical AI===<br />
This feature makes the aliens slightly more aggressive. Melee Terror Units are less indecisive when attacking. Player can choose the distances (in tiles) that aliens will attempt to use auto-fire and snap shots. Aliens will make targeted shots for ranges beyond snap shot. A scaled-down version of Kyrub's AI model. ''Thanks to Kyrub for providing the data point information.''<br />
: ''Apply'': Set to 1 to enable this feature.<br />
<br />
===Ranged Based Accuracy===<br />
This modifies the accuracy based on the distance from the target. The accuracy decreases linearly (2% per tile) when shooting beyond the limit of the firing mode:<br />
: ''Apply'': Set to 1 to enable this feature.<br />
: ''Minimum Efficiency'': The efficiency will not decrease beyond this limit for range. [-50% = 25+ tiles]<br />
*auto shot: 8 tiles<br />
*snap shot: 16 tiles<br />
*aimed shot: no penalty<br />
:''These initial values complement the Tactical AI ranges.''<br />
<br />
===Line of Fire Check for M.C.===<br />
Soldiers with MC ability and items that utilized MC will require the individual soldier have LOS to use the item as selected by the player.<br />
* Mind Control=0<br />
* Panic=0<br />
* MC Reader=0<br />
: Change any option to 1 to enable the feature.<br />
<br />
===Alternate Initial Base Layout===<br />
Allows the player to rearrange, add, or remove any module to the initial base at the start of a game.<br />
: ''Apply'': Set to 1 to enable this feature.<br />
Possible modules [use this notation in the INI]:<br />
*AirLock <br />
*LivingQuarters<br />
*Laboratory <br />
*Workshop<br />
*[StdSonar] Standard Sonar <br />
*[WideSonar] Wide Array Sonar <br />
*TorpedoDefense <br />
*GeneralStores<br />
*AlienContainment <br />
*GaussDefense<br />
*SonicDefense <br />
*[PWTDefence] Power Wave Torpedo Defense <br />
*[BombShield] Bombardment Shield <br />
*[MCShield] Molecular Control Shield <br />
*[MCLab] Molecular Control Laboratory <br />
*[TransRes] Transmission Resolver <br />
*SubPenTL <br />
*SubPenTR<br />
*SubPenBL <br />
*SubPenBR<br />
*Empty<br />
<br />
===OBDATA.DAT===<br />
Change the value of some OBDATA.DAT settings on the fly. To change a value, add a line "itemname setting=value" (without the quotes).<br />
: ''Apply'': Set to 1 to enable this feature.<br />
<br />
Available settings:<br />
*Damage <br />
*Resistance (to explosions)<br />
*Weight<br />
*Damage Type<br />
*Auto accuracy<br />
*Snap accuracy<br />
*Aimed accuracy<br />
*Auto TUs<br />
*Snap TUs<br />
*Aimed TUs<br />
*Size (clip size)<br />
<br />
For Size, Damage and Damage Type, you usually want to modify the relevant clip object, not the weapon object (exceptions - melee weapons, XComUtil-modified infinite-ammo Gauss weapons). <br />
Item names are case insensitive and available at [[OBDATA.DAT (TFTD)]].<br />
<br />
=== Music ===<br />
: ''Apply'': Set to 1 to enable this feature.<br />
: '''Source''': choose which option by removing the ";" from the front of the line of your choice and adding a ";" to the beginning of the other line that you wish to disable.<br />
: '''CD Drive''': change to the drive letter of your CD/DVD ROM drive. (if applicable)<br />
: '''MP3''': You should create a folder labeled "MP3" in the same folder as your TFTD executable.<br />
<br />
==== PSX CD ====<br />
If you have the PSX version of the game, you should be able to enjoy the CD music with this patch. (experimental)<br />
<br />
==== MP3 Music ====<br />
If you have mp3 music files available for the game, you can use them instead of the default MIDI ones (see the INI file for examples).<br />
[[:file:TerrorFromTheDeepSoundtrackMP3.zip | Terror From The Deep Soundtrack]]<br />
<br />
=== Caps ===<br />
You can raise the maximum value that the soldiers' stats may increase in the course of gaining experience from combat.<br />
: ''Apply'': Set to 1 to enable.<br />
<br />
=== ShortCuts ===<br />
: ''Apply'': Set to 1 to enable BattleScape or GeoScape shortcuts.<br />
<br />
==== Geoscape key mapping ====<br />
*UpArrow: Rotate Up<br />
*DownArrow: Rotate Down<br />
*LeftArrow: Rotate Left<br />
*RighArrow: Rotate Right<br />
*MouseWheelUp: Zoom In<br />
*MouseWheelDown: Zoom Out<br />
*1: Geo Speed1<br />
*2: Geo Speed2<br />
*3: Geo Speed3<br />
*4: Geo Speed4<br />
*5: Geo Speed5<br />
*6: Geo Speed6<br />
*MouseMiddle: Intercept<br />
*B: Bases<br />
*G: Graphs<br />
*U: Ufopaedia<br />
*Escape: Options<br />
*F: Fundings<br />
<br />
==== Battlescape key mapping ====<br />
*UpArrow: unit goes up<br />
*DownArrow: unit goes down<br />
*LeftArrow: left menu<br />
*RightArrow: right menu<br />
*Return: end of turn<br />
*Escape: options menu<br />
*BackSpace: go to next unit, remove current from the queue<br />
*Tab: go to next unit<br />
*Space: go to inventory<br />
*PageUp: view goes up one level<br />
*PageDown: view goes down one level<br />
*1: reserve mode off<br />
*2: reserve mode snap<br />
*3: reserve mode auto<br />
*4: reserve mode aimed<br />
<br />
==== Key names ====<br />
Standard keys (A, 2, etc) are indicated as-is, the following "special" keynames are available (case insensitive):<br />
{|<br />
|<br />
*Back<br />
*BackSpace<br />
*Back Space<br />
*Tab<br />
*Clear<br />
*Return<br />
*Enter<br />
*Shift<br />
*Control<br />
*Menu<br />
|<br />
*Pause<br />
*Escape<br />
*Space<br />
*Prior<br />
*PageUp<br />
*Next<br />
*PageDown<br />
*End<br />
*Home<br />
*Left<br />
|<br />
*Up<br />
*Right<br />
*Down<br />
*Print<br />
*Insert<br />
*Delete<br />
*Num0<br />
*Numpad0<br />
*Num1<br />
*Numpad1<br />
|<br />
*Num2<br />
*Numpad2<br />
*Num3<br />
*Numpad3<br />
*Num4<br />
*Numpad4<br />
*Num5<br />
*Numpad5<br />
*Num6<br />
*Numpad6<br />
|<br />
*Num7<br />
*Numpad7<br />
*Num8<br />
*Numpad8<br />
*Num9<br />
*Numpad9<br />
*Multiply<br />
*Add<br />
*Separator<br />
*Subtract<br />
|<br />
*Decimal<br />
*Divide<br />
*F1<br />
*F2<br />
*F3<br />
*F4<br />
*F5<br />
*F6<br />
*F7<br />
*F8<br />
|<br />
*F9<br />
*F10<br />
*F11<br />
*F12<br />
*MouseMiddle<br />
*MouseWheelUp<br />
*MouseWheelDown<br />
*MouseWheelLeft<br />
*MouseWheelRight<br />
|}<br />
<br />
If you need a key not listed here and you know its VK_* code, you can specify it with it's hex value (e.g. 0x90 for num lock)<br />
<br />
The implementation is rather messy, expect side effects and report them...<br />
<br />
[[Category:TFTD]]</div>
Spike
https://www.ufopaedia.org/index.php?title=Sub_Armaments&diff=72346
Sub Armaments
2016-06-12T23:46:04Z
<p>Spike: /* Effect Of Target Size */</p>
<hr />
<div>X-COM flying subs would be useless if they had no means of neutralising enemy [[Alien Subs]]. To this end, there are a number of craft armaments, or craft weapons, that you can be fit to interception craft for use in combat. Some of these weapons are immediately available to you to purchase, others have to be researched and manufactured in your workshops.<br />
<br />
The weapons systems that can be purchased throughout the course of your conflict with the alien menace are:<br />
<br />
*[[Craft Gas Cannon]]<br />
*[[AJAX]]<br />
*[[D.U.P. Head]]<br />
<br />
The weapons that can be manufactured after you have researched them are:<br />
<br />
*[[Gauss Cannon]]<br />
*[[Sonic Oscillator]]<br />
*[[P.W.T. Cannon]]<br />
<br />
<br />
==Quick Comparison Table==<br />
<br />
<br />
<table {{StdCenterTable}} class="sortable"><br />
<tr {{StdDescTable_Heading}}><br />
<th width="150" align="left">Armament</th><br />
<th width="90">Max<br>Damage (Dm)</th><br />
<th width="120">Range (km) (R)</th><br />
<th width="100">Accuracy (A)</th><br />
<th width="160">Official<br>Reload<br>Time (gs) (RTo)</th><br />
<th width="100">Actual<br>Reload<br>Time (gs) (RTa)</th><br />
<th width="80">Shots</th><br />
<th width="80">Official<br>Firepower<br>(D&times;A/RTo)</th><br />
<th width="80">Actual<br>Firepower<br>(D&times;A/RTa)</th><br />
<th width="80">Payload<br>(Da&times;S&times;A)</th><br />
</tr><br />
<tr><td align="left">Craft Gas Cannon</td><td>15</td><td>8</td><td>25%</td><td>3</td><td>3</td><td>200</td><td>0.94</td><td>0.94</td><td>562.5</td></tr><br />
<tr><td align="left">AJAX Cau</td><td>60</td><td>32</td><td>70%</td><td>17</td><td>48</td><td>6</td><td>1.85</td><td>0.66</td><td>189</td></tr><br />
<tr><td align="left">AJAX Std</td><td>60</td><td>32</td><td>70%</td><td>17</td><td>36</td><td>6</td><td>1.85</td><td>0.88</td><td>189</td></tr><br />
<tr><td align="left">AJAX Agg</td><td>60</td><td>32</td><td>70%</td><td>17</td><td>24</td><td>6</td><td>1.85</td><td>1.31</td><td>189</td></tr><br />
<tr><td align="left">D.U.P. Head Cau</td><td>110</td><td>50</td><td>80%</td><td>21</td><td>72</td><td>3</td><td>3.14</td><td>0.92</td><td>198</td></tr><br />
<tr><td align="left">D.U.P. Head Std</td><td>110</td><td>50</td><td>80%</td><td>21</td><td>54</td><td>3</td><td>3.14</td><td>1.22</td><td>198</td></tr><br />
<tr><td align="left">D.U.P. Head Agg</td><td>110</td><td>50</td><td>80%</td><td>21</td><td>36</td><td>3</td><td>3.14</td><td>1.83</td><td>198</td></tr><br />
<tr><td align="left">Gauss Cannon</td><td>90</td><td>20</td><td>35%</td><td>4</td><td>18</td><td>50</td><td>5.91</td><td>1.31</td><td>1181.25</td></tr><br />
<tr><td align="left">Sonic Oscillator</td><td>150</td><td>55</td><td>50%</td><td>5</td><td>18</td><td>100</td><td>11.25</td><td>3.13</td><td>5625</td></tr><br />
<tr><td align="left">P.W.T. Cannon Cau</td><td>200</td><td>60</td><td>100%</td><td>28</td><td>48</td><td>2</td><td>5.36</td><td>3.13</td><td>300</td></tr><br />
<tr><td align="left">P.W.T. Cannon Std</td><td>200</td><td>60</td><td>100%</td><td>28</td><td>36</td><td>2</td><td>5.36</td><td>4.17</td><td>300</td></tr><br />
<tr><td align="left">P.W.T. Cannon Agg</td><td>200</td><td>60</td><td>100%</td><td>28</td><td>24</td><td>2</td><td>5.36</td><td>6.25</td><td>300</td></tr><br />
</table><br />
<br />
As a general guide to the available weapons, 75km is the standoff range you first get the dogfight screen. If a weapon has close to 70km range the weapon will start firing soon after you press cautious attack, where weapons with around 30km range will require you to close in quite a lot. These ranges are also shown graphically on the interception screen.<br />
<br />
See [[Alien Subs#Weapons vs. Alien Submarines|Weapons vs. Alien Subs]] for advice on which armaments to use against which Alien Subs. <br />
<br />
'''Note that the Official Reload Times are incorrect.''' This is despite the fact that the Official values appear at points in the executable code, as well as in the in game UFOPedia. The 'Actual' values above have been verified by research, and also match the 'Actual' values in UFO Enemy Unknown.<br />
<br />
===Effect Of Target Size===<br />
<br />
The hit probability formula is normalised for Medium UFOs/USOs. Accuracy is lower than normal against Small craft and higher than normal for Large and even higher for Very Large craft. But because actual hit probability can't exceed 100%, there will be a relative firepower & payload advantage (compared to what is stated above) conveyed to inaccurate weapons vs larger targets. So against larger targets, lower base-accuracy weapons (eg cannons) will be more effective, relative to higher base-accuracy weapons (eg missiles), than is shown above. For smaller targets the linear relationships should still hold so the relationships above will be valid, although the absolute rates of firepower and of payload will be lower.<br />
<br />
==See Also==<br />
{{Subs Navbar}}<br />
<br />
[[Category:TFTD]]</div>
Spike
https://www.ufopaedia.org/index.php?title=Sub_Armaments&diff=72345
Sub Armaments
2016-06-12T23:44:54Z
<p>Spike: /* Quick Comparison Table */ Effect Of Target Size</p>
<hr />
<div>X-COM flying subs would be useless if they had no means of neutralising enemy [[Alien Subs]]. To this end, there are a number of craft armaments, or craft weapons, that you can be fit to interception craft for use in combat. Some of these weapons are immediately available to you to purchase, others have to be researched and manufactured in your workshops.<br />
<br />
The weapons systems that can be purchased throughout the course of your conflict with the alien menace are:<br />
<br />
*[[Craft Gas Cannon]]<br />
*[[AJAX]]<br />
*[[D.U.P. Head]]<br />
<br />
The weapons that can be manufactured after you have researched them are:<br />
<br />
*[[Gauss Cannon]]<br />
*[[Sonic Oscillator]]<br />
*[[P.W.T. Cannon]]<br />
<br />
<br />
==Quick Comparison Table==<br />
<br />
<br />
<table {{StdCenterTable}} class="sortable"><br />
<tr {{StdDescTable_Heading}}><br />
<th width="150" align="left">Armament</th><br />
<th width="90">Max<br>Damage (Dm)</th><br />
<th width="120">Range (km) (R)</th><br />
<th width="100">Accuracy (A)</th><br />
<th width="160">Official<br>Reload<br>Time (gs) (RTo)</th><br />
<th width="100">Actual<br>Reload<br>Time (gs) (RTa)</th><br />
<th width="80">Shots</th><br />
<th width="80">Official<br>Firepower<br>(D&times;A/RTo)</th><br />
<th width="80">Actual<br>Firepower<br>(D&times;A/RTa)</th><br />
<th width="80">Payload<br>(Da&times;S&times;A)</th><br />
</tr><br />
<tr><td align="left">Craft Gas Cannon</td><td>15</td><td>8</td><td>25%</td><td>3</td><td>3</td><td>200</td><td>0.94</td><td>0.94</td><td>562.5</td></tr><br />
<tr><td align="left">AJAX Cau</td><td>60</td><td>32</td><td>70%</td><td>17</td><td>48</td><td>6</td><td>1.85</td><td>0.66</td><td>189</td></tr><br />
<tr><td align="left">AJAX Std</td><td>60</td><td>32</td><td>70%</td><td>17</td><td>36</td><td>6</td><td>1.85</td><td>0.88</td><td>189</td></tr><br />
<tr><td align="left">AJAX Agg</td><td>60</td><td>32</td><td>70%</td><td>17</td><td>24</td><td>6</td><td>1.85</td><td>1.31</td><td>189</td></tr><br />
<tr><td align="left">D.U.P. Head Cau</td><td>110</td><td>50</td><td>80%</td><td>21</td><td>72</td><td>3</td><td>3.14</td><td>0.92</td><td>198</td></tr><br />
<tr><td align="left">D.U.P. Head Std</td><td>110</td><td>50</td><td>80%</td><td>21</td><td>54</td><td>3</td><td>3.14</td><td>1.22</td><td>198</td></tr><br />
<tr><td align="left">D.U.P. Head Agg</td><td>110</td><td>50</td><td>80%</td><td>21</td><td>36</td><td>3</td><td>3.14</td><td>1.83</td><td>198</td></tr><br />
<tr><td align="left">Gauss Cannon</td><td>90</td><td>20</td><td>35%</td><td>4</td><td>18</td><td>50</td><td>5.91</td><td>1.31</td><td>1181.25</td></tr><br />
<tr><td align="left">Sonic Oscillator</td><td>150</td><td>55</td><td>50%</td><td>5</td><td>18</td><td>100</td><td>11.25</td><td>3.13</td><td>5625</td></tr><br />
<tr><td align="left">P.W.T. Cannon Cau</td><td>200</td><td>60</td><td>100%</td><td>28</td><td>48</td><td>2</td><td>5.36</td><td>3.13</td><td>300</td></tr><br />
<tr><td align="left">P.W.T. Cannon Std</td><td>200</td><td>60</td><td>100%</td><td>28</td><td>36</td><td>2</td><td>5.36</td><td>4.17</td><td>300</td></tr><br />
<tr><td align="left">P.W.T. Cannon Agg</td><td>200</td><td>60</td><td>100%</td><td>28</td><td>24</td><td>2</td><td>5.36</td><td>6.25</td><td>300</td></tr><br />
</table><br />
<br />
As a general guide to the available weapons, 75km is the standoff range you first get the dogfight screen. If a weapon has close to 70km range the weapon will start firing soon after you press cautious attack, where weapons with around 30km range will require you to close in quite a lot. These ranges are also shown graphically on the interception screen.<br />
<br />
See [[Alien Subs#Weapons vs. Alien Submarines|Weapons vs. Alien Subs]] for advice on which armaments to use against which Alien Subs. <br />
<br />
'''Note that the Official Reload Times are incorrect.''' This is despite the fact that the Official values appear at points in the executable code, as well as in the in game UFOPedia. The 'Actual' values above have been verified by research, and also match the 'Actual' values in UFO Enemy Unknown.<br />
<br />
===Effect Of Target Size===<br />
<br />
The hit probability formula is normalised for Medium UFOs/USOs. But because actual hit probability can't exceed 100%, there will be a relative firepower & payload advantage (compared to what is stated above) conveyed to inaccurate weapons vs larger targets. So against larger targets, lower base-accuracy weapons (eg cannons) will be more effective, relative to higher base-accuracy weapons (eg missiles), than is shown above. For smaller targets the linear relationships should still hold so the relationships above will be valid, although the absolute rates of firepower and of payload will be lower.<br />
<br />
==See Also==<br />
{{Subs Navbar}}<br />
<br />
[[Category:TFTD]]</div>
Spike
https://www.ufopaedia.org/index.php?title=XCOM_News&diff=72343
XCOM News
2016-06-11T13:05:29Z
<p>Spike: added weekend offer</p>
<hr />
<div>This is the Ufopaedia.org news page where relevant news and site messages will appear. When this page is transcluded into other pages, only the new news items should appear there. Everything else will only display on this page. <br />
<br />
== News ==<br />
<onlyinclude><br />
<div style="padding-left:10px;"><br />
====<span style ="color:#49BCB5;">XCOM 2 Arrives!</span>====<br />
''' June 11th, 2016'''<br />
:* Steam have a one third off weekend special on XCOM 2 this weekend. <br />
<br clear="all"><br />
[[File:XCOM2_Sectopod.png|240px|thumb|XCOM 2 Arrives]]<br />
''' February 4th, 2016'''<br />
:* It is now possible to start the preload of XCOM 2 through Steam (~24.6 Gb download). Firaxis has already [http://steamcommunity.com/games/268500/announcements/detail/843665914362353836 announced] the release schedule for the different regions and has made available the ingame characters of the Development team for use in XCOM 2's Character Pool. Several reviews have been already released on the major gaming sites - some spoilers might be included on those, read at your own risk. Good luck commanders. <br />
<br clear="all"><br />
[[File:XCOM 2 Retaliation.png|240px|thumb|XCOM 2 - Join Us Or Become Them]]<br />
''' December 12th, 2015'''<br />
:* The Official [[XCOM2|XCOM 2]] "Retaliation" trailer has been released. You can check the video [https://www.youtube.com/watch?v=j0qHZG1-rEg here] and for more ingame action, you can check Beaglerush's XCOM 2 gameplay videos: [https://www.youtube.com/watch?v=I9vG-N0ILB0 War Hand], [https://www.youtube.com/watch?v=JT_0gsOmsQE Blacksite] and [https://www.youtube.com/watch?v=5X1Tfx_TM38&feature=youtu.be Legendary War Hand]. XCOM 2 will be released on February 5th, 2016. <br />
[[File:XCOM 2 Soldier Customization.png|240px|thumb|Soldier Customization]]<br />
''' September 10th, 2015'''<br />
:* [[XCOM2]] has been made available for pre-order on Steam in addition to XCOM: Enemy Unknown being free to play for all users until 10am PT on Sunday, September 13 with a 75% discount for anyone who purchases the game during the same period. This discount also applies to all downloadable content. Like the Elite Soldier Pack that came with pre-orders of Enemy Unknown, XCOM2 pre-orders come with the Resistance Warrior Pack which has more soldier customization options.[http://xcom.com/news/xcom-enemy-unknown-is-free-to-play-on-steam-this-weekend]<br />
<br />
'''August 7th, 2015'''<br />
:* Firaxis has released new [https://www.youtube.com/watch?v=lj42i7f1nj0&feature=youtu.be footage] of the upcoming [[XCOM2]] game, with a focus on the Avenger, the mobile base used by XCOM to fight the ADVENT forces. Highlights include a tour through the base facilities and XCOM's Chief Engineer and Scientist, as well as a display of the soldier customization and the strategic layer.<br />
<br clear="all"><br />
<br />
====OpenTFTD Beta Released====<br />
[[File:OpenTFTD1.png|240px|thumb|OpenTFTD]]<br />
'''August 4th, 2015'''<br />
:* The developers of [[OpenXcom]] have released the first Nightly (a.k.a. beta version) of [http://openxcom.org/ OpenTFTD], an open source reimplementation of [[TFTD|XCOM: Terror From The Deep]]. OpenTFTD comes included with the engine of regular OpenXcom and requires a copy of the original TFTD game to play.<br />
<br clear="all"><br />
====XCOM 2 Gameplay Video Released====<br />
'''June 16th, 2015'''<br />
:* Firaxis has released the first [https://www.youtube.com/watch?v=AzAKyj-KK-E&t=2m22s video] of XCOM 2 gameplay during the E3 2015 conference. The footage features a tactical mission where XCOM troops have to blow up an Advent target and it shows several enemies, including the Advent units of Soldier, Captain, Turret and MEC, as well as the Viper and the evolved Muton Berserker. The video also shows the new concealment/ambush mechanic, as well as a Gremlin hacking a turret and the Skyranger retrieval. It is also possible to see Officer [[Bradford (EU2012)|Bradford]] ordering XCOM troops into action and a glimpse of the world under the alien occupation.<br />
<br />
====XCOM2 confirmed!==== <br />
'''June 1st, 2015'''<br />
:* 2K and Firaxis have confirmed today on the XCOM official website [[http://xcom.com/]] the upcoming sequel to XCOM: Enemy Unknown. [[XCOM2]] takes place 20 years after the events of the remake, where the aliens have taken over Earth and the remains of XCOM are waging a guerrilla war against the extraterrestrials. The game will feature new soldier classes, the return of the [[Snakemen]] along with other new aliens, procedure generated (random) maps, and will be exclusive to the PC with specific features for mod development. More features will be revealed soon on IGN [http://ca.ign.com/articles/2015/06/01/xcom-2-announced-ign-first].<br />
'''May 29th, 2015'''<br />
:* Two clues at the Advent website have a series of letters that when combined produce "VIGILO CONFIDO", or the motto of Enemy Unknown 2012. It seems that a new XCOM game is under development and more details should be announced later. <br />
'''May 27th, 2015'''<br />
:* 2K has released yesterday a link to a site that presents an alternate reality company called [http://www.adventfuture.org/ Advent Administration]. Its contents have triggered speculation on the 2K official forums and Xcom subreddit that it is related to a new upcoming XCOM announcement. The site contains a rotating globe, pictures depicting a XCOM: Apocalypse style city, one of which seems to contain artwork already present on XCOM: Enemy Unknown, and a downloadable .pdf file uses a font called 'XCOM-Regular'. The site also appears to be under some sort of hacking by an unknown party, with its contents being replaced by phrases such as 'we are still watching'. While all of this is merely circumstantial evidence, 2K is expected to announce a major title on the next E3 Conference in 3 weeks so keep tuned for further details. <br />
<br />
</onlyinclude><br />
<br />
== Archived News == <br />
<br />
'''October 21st, 2014'''<br />
:* Firaxis has released video footage of the two panels dedicated to XCOM: Enemy Unknown during the company's 2014 community convention, which took place last month. The panels were called ''Designing the Soldiers in XCOM'', which was presented by Game Designer Ananda Gupta, and ''The Artwork of XCOM'', by Art Director Greg Foertsch. The Firaxicon videos are available at Firaxis's Youtube [https://www.youtube.com/playlist?list=PL-lTq9LJCHpRP88U3dngU2P6GhJ8KqEjP channel]. <br />
'''October 16th, 2014'''<br />
:* Steam announced that XCOM: Enemy Unknown can be played for free this weekend, starting today and until next Sunday. For more details check Steam's [http://store.steampowered.com/news/14681/ announcement]. <br />
<br />
'''August 5th, 2014'''<br />
:* Fantasy Flight Games announced that they'll be publishing ''XCOM: The Board Game'' on the last quarter of 2014. The tabletop board game is based on [[Enemy Unknown (2012)|XCOM: Enemy Unknown]] and can be played from 1-4 players, which take the individual roles of XCOM Commander, Chief Scientist, Central Officer and Squad Leader, with the help of an app companion to determine the moves of the alien forces. For more details check the publisher's [http://www.fantasyflightgames.com/edge_news.asp?eidn=4972 page], and yes, the game comes included with plastic figures representing all soldier classes, as well as the Interceptors and UFOs. Cost is presented as $59.95 for this game and it will be available for preview at the publisher's booth on Gen Con Indy 2014. <br />
'''June 13th, 2014'''<br />
:* [[OpenXcom]] has just completed its release 1.0 version, available for free at [http://openxcom.org/ openxcom.org]. If you're looking to spice up the original [[X-COM|UFO: Enemy Unknown]] game, then check out this revamped open source clone version, developed by [[User:SupSuper|SupSuper]] and a bunch of X-COM enthusiasts. For more details about OpenXcom, see this [https://www.youtube.com/watch?v=GL2x-Sz9Oa8 presentation]. <br />
'''May 29th, 2014'''<br />
:*Feral Interactive has [http://www.feralinteractive.com/en/news/424/ announced] that they will release XCOM: Enemy Unknown as their first game for Linux this summer, using the Ubuntu 14.04 version and through SteamPlay. <br />
'''May 17th, 2014'''<br />
:*[https://www.youtube.com/watch?v=qsHppXrgP0I YCOM: Enemy Unlikely] - Another remake of the XCOM series, YCOM: Enemy Unlikely is a demake of XCOM: Enemy Unknown, with a bit of hilarity added. The video contains a link on its description to download and play the game. <br />
'''April 29th, 2014'''<br />
:*[http://xcomrl.blogspot.pt/ X@COM] - playable alpha demo. X@COM, or XCOM Rogue-like, is a current fan project that aims to replicate the original UFO: Enemy Unknown using only ASCII characters. They're aiming to finish the project by 2015 and they have a current playable alpha version that can be downloaded for playing. <br />
'''March 9th, 2014'''<br />
:*[http://www.kotaku.com.au/2014/03/x-coms-design-document-had-just-12-pages/ Kokatu] magazine has published an article about the creation of the original [[X-COM|UFO: Enemy Unknown]] which includes a [http://www.gdcvault.com/play/1017808/Classic-Game-Postmortem-X-COM link] to last year's video presentation made by its creator, Julian Gollop, about the original game's design process.<br />
'''March 4th, 2014'''<br />
:*XCOM: Complete Edition released for PC and Mac. Includes all of the DLCs released so far, including the Elite Soldier Pack, Slingshot and Enemy Within. <br />
'''February 7th, 2014'''<br />
:*[[XCOM: Enemy Within DLC (EU2012)|XCOM: Enemy Within]] has won the Best Strategy/Simulation Game of the Year 2013 DICE awards. For a list of winners see [http://www.interactive.org/news/17th_annual_dice_awards_winners.asp].<br />
'''February 4th, 2014'''<br />
:*2K Games is preparing the release a complete edition of [[Enemy Unknown (2012)|XCOM: Enemy Unknown]] on March 4th, according to [http://www.gameinformer.com/b/news/archive/2014/02/03/xcom-and-civilization-v-complete-editions-coming-soon.aspx Gameinformer]. No further details have been released yet about the edition but it's likely that it should include all of the DLCs released so far, such as [[Elite Soldier Pack DLC (EU2012)|Elite Soldier Pack]], [[Slingshot DLC (EU2012)|Slingshot]] and the [[XCOM: Enemy Within DLC (EU2012)|Enemy Within]] expansion.<br />
<br />
==== [[XCOM: Enemy Within DLC (EU2012)|XCOM: Enemy Within]] and [[Hangar 6: R&D DLC (Bureau)|Hangar 6: R&D]] have been released! ====<br />
====XCOM: Enemy Within released====<br />
'''November 15th 2013'''<br />
:*And now it is the rest of the world's turn as Enemy Within receives its international release today. So get on and enjoy the all new features!<br />
'''November 12th 2013'''<br />
:*XCOM Enemy Within is released in America with new features like the new human faction – EXALT, Base Defence and all new maps and council Missions. Enjoy the game and see you on the farm with the crashed UFO.<br />
<br />
==== XCOM: Enemy Within Reviews! ====<br />
'''November 11th 2013'''<br />
:*Several reviews of [[XCOM: Enemy Within DLC (EU2012)|XCOM: Enemy Within]] have been published today. To read/see them, check [http://www.escapistmagazine.com/articles/view/editorials/reviews/10729-XCOM-Enemy-Within-Review Escapist Magazine] ("''All of the fun new toys, however, do work a bit against the game's biggest flaw - after a certain point of advancement, the challenge and satisfaction of snuffing aliens dissipates quickly.''"), [http://www.shacknews.com/article/81977/xcom-enemy-within-video-review Shacknews] ("''Firaxis once again manages to balance XCOM's disparate elements, resulting in a challenging and satisfying experience.''"), [http://uk.ign.com/articles/2013/11/11/xcom-enemy-within-review IGN] ("''Enemy Within is an amazing expansion to a brilliant tactical game.''") and [http://www.strategyinformer.com/pc/xcomenemyunknowntheenemywithin/reviews.html Strategy Informer] ("''I could go on about the virtues of Enemy Within, about how good it was to play through the whole campaign again, but ultimately it’ll come down to two factors: The fact that the ending hasn’t changed a bit, and the fact that, ultimately, you’re still playing the same game.''", and [http://www.youtube.com/watch?v=4mb_RXgIStw Revision3] ("''EW gets a 4 out of 5.''").<br />
<br />
====The Bureau Expansion====<br />
'''November 8th 2013'''<br />
:*[[The Bureau: XCOM Declassified|The Bureau: XCOM Declassified]] gained it first DLC Pack today in the form of [[Hangar 6: R&D DLC (Bureau)|Hangar 6: R&D]] in which the player takes control of DaSilva in an attempt to get to the bottom of a mysterious new infection.<br />
<br />
==== XCOM Base Defense confirmed on EW====<br />
'''October 23th, 2013'''<br />
:*The newest preview videos released ([http://www.escapistmagazine.com/articles/view/editorials/reviews/previews/10679-XCOM-Enemy-Within-Preview-Whole-New-Game here] and [http://www.gamespot.com/videos/base-defense-returns-in-xcom-enemy-within/2300-6415682/ here]) have confirmed the addition of a Base Defense mission to [[XCOM: Enemy Within DLC (EU2012)|XCOM: Enemy Within]], a feature of the original game long called for by players. Check for more details on the Enemy Within page.<br />
<br />
==== EXALT revealed!====<br />
'''October 9th, 2013'''<br />
:*A new faction has been revealed for [[XCOM: Enemy Within DLC (EU2012)|XCOM: Enemy Within]], the upcoming [[Enemy Unknown (2012)|XCOM: Enemy Unknown]] expansion. XCOM's new enemies are called EXALT and they're a secret paramilitary human group that is conspiring to use the alien technology and chaos of the invasion to achieve world domination. More details available at the [[XCOM: Enemy Within DLC (EU2012)|Enemy Within]] page.<br />
<br />
==== XCOM: Enemy Within details announced!====<br />
'''August 21st, 2013'''<br />
:*Producer 2K revealed details about '''XCOM: Enemy Within''', the upcoming expansion to [[Enemy Unknown (2012)|XCOM: Enemy Unknown]]. The main features are the addition of the Meld, a substance that allows you to create a new class (Mech Troopers), with new weapons and abilities or to genetically enhance your soldiers (Gene Mods), along with other features. The release date is November 12th (US) and 15th (rest of the world) and check the full details on the [[XCOM: Enemy Within DLC (EU2012)|XCOM: Enemy Within]] page.<br />
<br />
==== XCOM: Enemy Within will be revealed on August 21st====<br />
'''August 3rd, 2013'''<br />
:*Producer 2K has confirmed that it will reveal during Gamescom 2013 a new DLC for XCOM: Enemy Unknown called [[XCOM: Enemy Within DLC (EU2012)|XCOM: Enemy Within]].<br />
<br />
<br />
==== The Bureau: XCOM Declassified will be released next month====<br />
'''July 18th, 2013'''<br />
:*The upcoming XCOM squad based shooter will be available for sale on stores on August 20th in the US and on the 23rd to the rest of the world. From the available previews/footage it seems the game has been redesigned as a prequel to ''XCOM: Enemy Unknown'', featuring Sectoids, Mutons and even Silacoids.<br />
<br />
==== The Bureau: XCOM Declassified coming soon====<br />
'''May 5th, 2013'''<br />
:*Marin's 2K XCOM squad based shooter should be released soon as '''The Bureau: XCOM Declassified'''. The game was announced three years ago and has been redesigned.<br />
<br />
==== Clash of the Titans: X-COM meets XCOM ==== <br />
'''April 2nd, 2013'''<br />
:*Julian Gollop and Jake Solomon have met for the first time during Game Developers Conference 2013 to be interviewed regarding the original game and the 2012 remake. Check the video of the encounter here: [http://www.youtube.com/watch?v=z8zZsecTRfM].<br />
<br />
==== GDC 2013: Julian Gollop's Postmortem on UFO: Enemy Unknown/XCOM: UFO Defense ====<br />
<br />
'''March 28th, 2013'''<br />
<br />
:*Julian Gollop gave a talk at Games Developers Conference 2013 on the development of the original UFO: Enemy Unknown/XCOM: UFO Defense. An interesting look into the philosophies and source material that went into the making of the game, and also how it nearly failed. <br />
<br />
:: See the video at: http://www.gamespot.com/events/gdc-2013/video.html?sid=6406150<br />
'''March 1st, 2013'''<br />
:*'''Elite Edition for the Mac announced.''' Firaxis have announced that Feral Games are porting XCOM: Enemy Unknown to the OS X and will be released in an Elite Edition. This edition will include the [[Elite Soldier Pack DLC (EU2012)|Elite Soldier Pack]], [[Slingshot DLC (EU2012)|Slingshot]] and [[Second Wave (EU2012)|Second Wave]] DLCs and should be released this spring. <br />
<br />
'''January 8th, 2013'''<br />
:*'''[[Second Wave (EU2012)|Second Wave]] options now available on XCOM: Enemy Unknown.''' The latest patch released today by Firaxis now activates the Second Wave options and makes it available for the game. Despite it being already included but inactive (and playable through mods) the developers had stated that they didn't had time to complete Second Wave before XCOM: Enemy Unknown but it was on their intentions to finish it. It now includes the following [[Info_(EU2012)#Advanced Options|options]] as part of Advanced Gameplay: ''Damage Roulette, New Economy, Not Created Equally, Hidden Potential, Red Fog, Absolutely Critical, The Greater Good, Marathon, Results Driven, High Stakes, Diminishing Returns, More Than Human, Total Loss, War Wariness, E-115'' and ''Alternate Sources''. The [[Patches_(EU2012)#2013-01-08|patch]] also introduces fixes to the teleport bug and adds a new XCOM Hero. <br />
<br />
'''December 4, 2012'''<br />
:* 2K Games has released the first of two DLC packs for all platforms, named ''Slingshot''. The pack features several additional new helmets, 1 new armor decoration and 3 linked Council missions and a special playable soldier named ''Zhang''.<br />
<br />
'''October 23, 2012'''<br />
:* 2K Games has [http://www.2kgames.com/blog/add-on-content-packs-for-xcom-enemy-unknown-coming-soon announced] the first of two DLC packs for all platforms. The first, named ''Slingshot'', will feature 3 new linked Council missions that will focus on a playable character named ''Zhang''.<br />
<br />
'''October 9, 2012'''<br />
:* Eighteen years after the original release of ''UFO: Enemy Unknown'' (or ''XCOM: UFO Defense''), 2K Games has released today in North America ''XCOM: Enemy Unknown'', its remake of the original game, which will be followed by the international release next Friday. XCOM is back!<br />
<br />
''' September 24, 2012 '''<br />
:* Demo is released on '''[http://store.steampowered.com/app/200510/ Steam]'''. It features a tutorial mission, a standard mission and a limited interaction with the Base and Geoscape layer. <br />
<br />
''' August 10, 2012 '''<br />
:* Multiplayer deathmatch revealed for XCOM: Enemy Unknown (2012), mix your own squad of soldiers & aliens and battle online vs other players. <br />
<br />
''' January 5, 2012 '''<br />
:*Publisher 2K Games announces that Firaxis (makers of Civilization) is developing a re-imagining of the original XCOM: Enemy Unknown for release this fall (2012).<br />
<br />
<br />
----<br />
<br />
==== <span style ="color:#49BCB5;">New XCOM FPS Game by 2k Marin</span> ====<br />
:* XCOM FPS has been delayed multiple times, release is late 2013 or 2014 at the earliest.<br />
:* The game will focus on elite U.S. government operatives attempting to prevent a nightmarish invasion of the United States (while dropping the dash in X-COM). See:<br />
:* The [http://www.xcom.com official XCOM] site (only a couple of trailers here)<br />
:* Some criticism of its change in focus ([http://www.destructoid.com/2k-marin-s-22-minute-demonstration-of-xcom-209954.phtml 1], [http://www.destructoid.com/2k-xcom-changed-because-strategy-games-aren-t-modern-205991.phtml 2]), although 2k Marin may be rethinking this<br />
:* [http://forums.2kgames.com/forums/forumdisplay.php?76-XCOM-General-Discussion 2k's XCOM forum], including passionate posts by X-Commies<br />
:* Once slated for March 2012 release, it has now slipped to a later date ([http://www.videogamer.com/xbox360/xcom_2k_marin/news/xcom_release_date_slips_avoids_mass_effect_3.html 1], [http://www.gamespot.com/news/6344515.html?tag=nl.e579 2]).<br />
<br />
----<br />
==== <span style ="color:#49BCB5;">X-COM Packages </span> ====<br />
Now available for less than $15<br />
:*At [http://www.gamersgate.com/index.php?page=product&what=view&sku=DDB-XCOM&via=newly_added&aff=sc GamersGate], [http://store.steampowered.com/sub/964/ Steam] and [http://www.direct2drive.com/2/7614/product/Buy-X-Com-Complete-Bundle-Download Direct2Drive]. (Includes '''UFO''', '''TFTD''', '''Apoc''', '''Int''', and '''Enf''').<br />
<br />
For "reviews", see [[GEOSCAPE.EXE#X-COM_Complete_Packages|this]]. <br />
<br />
<span style ="color:#49BCB5;">'''OFFICIAL'''</span> - [http://kotaku.com/5516654/x+com-is-back NEW X-COM GAME FROM THE DEVELOPERS OF BIOSHOCK 2]<br><br />
Yes, this will come as a shock to all, but 2K Australia and 2K Marin is busily working on a first-person shooter based on the X-COM franchise. More info will presumably become available on the 2010 E3.<br />
<br />
For more information/rumors check 2K's [http://forums.2kgames.com/forums/forumdisplay.php?f=76 X-COM forum].<br />
</div></div>
Spike
https://www.ufopaedia.org/index.php?title=TFTD_Research_Sequences&diff=72334
TFTD Research Sequences
2016-06-09T01:34:19Z
<p>Spike: /* Research Sequences */ query on Sonic Oscillator requirements</p>
<hr />
<div>==Research Sequences==<br />
<br />
<br />
'''Ref Avg TOT.'''<br />
'''--- --- ----'''<br />
'''Gauss sequence'''<br />
0 50 50 Gauss Tech <br />
29 100 150 Gauss Pistol <br />
62 60 210 Gauss Pistol Clip (optional) <br />
30 300 510 Gauss Rifle <br />
63 150 660 Gauss Rifle Clip (optional) <br />
31 460 1120 Heavy Gauss <br />
64 230 1350 Heavy Gauss Clip<br />
32 420 1770 Craft Gauss Cannon (includes: Gauss Cannon Ammo "for free")<br />
(1560 total without optional items)<br />
'''Sonic sequence''' (Do you need all weapons to get Oscillator? Or any one weapon plus its clip?)<br />
8 600 600 Sonic Pistol <br />
9 400 1000 Sonic Pistol Clip<br />
6 700 1700 Blasta Rifle <br />
7 400 2100 Blasta Clip <br />
4 800 2900 Sonic Cannon <br />
5 400 3300 Cannon Power Clip<br />
33 660 3960 Sonic Oscillator (only 1660 total if Sonic Pistol + Clip)<br />
'''Armour sequence (unlocks Subs)'''<br />
50 180 Deep One Corpse <br />
25 400 Aqua Plastics <br />
59 180 Plastic Aqua Armor <br />
17 450 Ion-Beam Accelerator<br />
?? 170 Live Deep One<br />
60 205 Ion Armor <br />
61 330 1915 Mag-Ion Armor (2365 including Magnetic Navigation)<br />
'''Transmission resolver sequence''' <br />
18 450 Magnetic Navigation <br />
41 670 1120 Transmision Resolver<br />
'''MC sequence''' <br />
'''(make sure an MC Reader is in stores when completing MC Lab)'''<br />
?? 170 Live Terrorist<br />
40 420 590 MC Lab <br />
16 600 1190 M.C. Reader<br />
?? 192 1382 Live Tasoth<br />
3 500 1882 M.C. Disruptor <br />
'''Drill sequence'''<br />
49 180 Calcinite Corpse<br />
66 500 680 Vibroblade<br />
46 180 Gill Man Corpse <br />
67 500 1360 Thermic Lance <br />
68 600 1960 Heavy Thermic Lance<br />
'''DPL sequence'''<br />
15 450 Zrbite<br />
10 900 Disruptor Pulse Launcher <br />
11 300 1650 Disruptor Ammo<br />
34 880 2530 ?PWT Cannon?<br />
'''Thermal Shok sequence''' <br />
12 550 Thermal Shock Launcher <br />
13 180 730 Thermal Shock Bomb<br />
'''Sub sequence (needs Mag-Ion Armour, Zrbite, Transm. Res.)'''<br />
=2815<br />
'''Ensure Sub Construction item is owned when pre-reqs are met''' <br />
19 450 Alien Sub Construction<br />
26 600 1050 Manta <br />
27 700 1750 Hammerhead <br />
28 900 2650 Leviathan <br />
<br />
'''Victory sequence''' <br />
56 300 Alien Origins (any live alien) <br />
57 500 Ultimate Threat (live Lobsterman Commander) <br />
58 600 1400 Tleth the alien city (another Lobsterman Commander)<br />
<br />
'''Miscellaneous useful items'''<br />
1 180 Particle Disturbance Sensor <br />
2 210 Medi-Kit <br />
14 200 Sonic Pulser<br />
'''Defence Modules (need relevant offensive tech)''' <br />
35 510 Gauss Defences <br />
36 620 Sonic Defences <br />
37 800 PWT Defences <br />
38 930 Bombardment Shield <br />
39 360 MC Generator<br />
'''SWSs (needs Manta + relevant heavy infantry weapon tech)''' <br />
42 250 Coelacanth/Gauss (why does this need Sub tech when it's a Coelecanth chassis?) <br />
43 430 Displacer/Sonic (needs Sub tech) <br />
44 690 Displacer/PWT (needs Sub tech)<br />
<br />
See Also:<br />
[[TRTBAG|TFTD Research Tree Bug Avoidance Guide]]<br />
<br />
[[Category:Research (TFTD)]]<br />
[[Category:TFTD]]</div>
Spike
https://www.ufopaedia.org/index.php?title=TRTBAG&diff=72333
TRTBAG
2016-06-09T01:14:27Z
<p>Spike: /* v2.1 */ grammar</p>
<hr />
<div>__NOTOC__<br />
= The TFTD Research Tree Bug Avoidance Guide =<br />
<div align = "right" style = "font-size:80%;">A needlessly wordy article by [[User:NKF|NKF]]</div><br />
<br />
__TOC__<br />
<br />
<br clear="all"><br />
<br />
==Foreword== <br />
<br />
<p>The designers of X-Com Terror From The Deep seem to have attempted to make the research process in TFTD much more complicated than its very straightforward predecessor's research tree. They have succeeded in doing this, but have also introduced many glaringly unacceptable errors in the process that can prevent you from completing the game.</p> <br />
<p><br />
Some players may have had the luck of not bumping into any of these errors by picking all the right research at the right time, or have a game that doesn't seem to have these problems. Unfortunately, as the research order in TFTD is non-linear, that is to say you can research anything you've got in any order you want, a lot of us are less fortunate. This guide should help to assist and point out some of the stickier bits. <br />
</p><br />
<br />
<p><br />
Also note that ''this is not a reproduction of the research tree''.<br />
There are many documents in a variety of formats describing the complete research tree on the Internet that you can peruse. This document is merely a supplement. <br />
</p><br />
===Definitions===<br />
The word 'prerequisite' is used quite frequently<br />
throughout this document. As prerequisite is not<br />
an everyday word, here is its definition.<br />
<br />
:;Pre-Requisite: Pre- means 'before', Requisite means something that is required in order to achieve something. In Layman terms and in context with the game: to get this thingy, you need to research or have these other thingies first.<br />
<br clear="all"><br />
=== Spoiler Warning ===<br />
While this may spoil the game if you are new to<br />
it, it is better to be informed than to make a<br />
mistake that is irreversible. The game IS hard,<br />
even for X-Com UFO veterans.<br />
<br />
With the exception of MC technology, this<br />
document discusses a branch of the research tree<br />
that will take you from the very start of the<br />
game all the way to the final chamber in T'Leth. (Well, not exactly, but it'll give you everything you need!) <br />
<br />
<br />
<br />
<br />
== Glitches in the System ==<br />
<br />
There are two major occasions where research can grind to a halt: <br />
<br />
* An alien is required to further research AFTER certain projects are completed<br />
* An object is needed in storage before research is completed<br />
<br />
== Interrogations ==<br />
<br />
A large portion of the research can be cut off by researching an alien in the incorrect sequence. <br />
<br />
For example, in order to open a new research branch, you need to have researched project A and B and then interrogate alien C in order to get new technology D. <br />
If you were to interrogate alien C before completing research on A and B, technology D will not appear for research once you've completed research on A and B. <br />
In order to get D to appear, you must capture another alien and interrogate it again. <br />
<br />
So, as a rule of thumb, if an alien is a prerequisite for any particular tech item, <br />
it is highly recommended that you hold off the completion of the interrogation until<br />
all the prerequisites have been researched.<br />
<br />
== The Deep One Dilemma==<br />
<p><br />
The primary research path at an abstract level looks roughly like so:<br />
<br>&nbsp;<br />
<center><br />
{| cellspacing="3"<br />
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Armour <br />
|| &rarr; <br />
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Subs <br />
|| &rarr; <br />
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | T'Leth<br />
|}<br />
</center><br />
<br><br />
The path for Armour looks roughly like:<br />
<br>&nbsp;<br />
<center><br />
{| cellspacing="3"<br />
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Deep One Corpse<br />
|| &rarr; <br />
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Aqua Plastics<br />
|| &rarr; <br />
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Plastic Aqua Armour<br />
|| &rarr; <br />
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Ion Beam Accelerators<br />
|| &rarr; <br />
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Live Deep One Terrorist<br />
|| &rarr; <br />
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Ion Armour<br />
|| &rarr; <br />
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Magnetic Navigation<br />
|| &rarr; <br />
| style="text-align: center; background: lavender; border: 1px gray solid; width: 80px;" | Mag. Ion Armour<br />
|}<br />
</center><br />
<br><br />
Not all of the technologies need to be reseached in the exact order - with the exception of the live [[Deep One]], which should only be reseached after you have met the other prerequisites for Ion Armour.<br />
<br />
Without Armours you won't get to research advanced subs; without advanced subs you can't reach T'leth and defeat the aliens once and for all.<br />
<br />
You will need a living specimen and a<br />
corpse. In older versions of the game, where you<br />
need a lobsterman navigator to get magnetic<br />
navigation, getting a live Deep One Terrorist is<br />
not that important. However, in TFTD versions<br />
with the v2 update, success hinges on getting a<br />
living Deep One terrorist.<br />
<br />
Deep One Terrorists can be found in most Gill-man<br />
land missions. They do not appear underwater (1),<br />
and are replaced with Xarquids if you shoot down<br />
Gill-Men terror ships.<br />
<br />
:(1) ''you may find some Deep One Terrorists in the second level of T'Leth; however, you may only get there after when you already have the tech they provide.''<br />
</p><br />
<p><br />
Don't worry if you missed them, Gill-Man terror<br />
sites do still appear when it's late in the game,<br />
although they are abundant early in game.<br />
</p><br />
<p><br />
Deep One Terrorists also appear in 'mixed' alien<br />
crew land missions. A mixed crew is made up of a<br />
variety of species, and in terror sites and base<br />
attacks, will be supported by a variety of<br />
land-based terror units, which includes the Deep<br />
One Terrorist as well as the odd Xarquid (which<br />
normally replaces the Deep One Terrorist for<br />
underwater missions).<br />
</p><br />
<p><br />
Just promote a terror site by leaving any ships<br />
on terror missions alone, or encourage the<br />
Gill-Men or 'mixed' crews to attack your base by<br />
shooting some of their USOs down near your base.<br />
You might also want to dismantle your M.C<br />
generator to improve the likelihood of an attack.<br />
</p><br />
<p><br />
Before starting research on the Deep One<br />
Terrorist, refer to the Ion Armour section.<br />
</p><br />
<p><br />
Finally, researching an alien medic and getting<br />
information on the Deep One Terrorist or its<br />
corpse is not the same as researching the real<br />
thing. You will not get any research benefits<br />
from the alien medic's report. Keep this in mind.<br />
</p><br />
<br />
== The Tasoth Commander Trap==<br />
<br />
Note that it is unfortunately difficult to double check the validity of this bug at the present time, so this section has been intentionally left vague for now, but is left for the benefit of the that may experience it. <br />
<br />
Most copies of the game do not recognise the Tasoth Commander as a legal alien (Although the alien/rank combination can still exist) and cannot be researched. If for whatever reason one does somehow appear on your research list, do not complete the research on it until after obtaining a Leviathan and the final mission launch button. Researching it will prevent these topics from being researched through normal means. <br />
<br />
If you're unsure whether you'll face this bug or otherwise, update your game with the v2 patch if you are using the Dos version. The Collectors edition of TFTD is already updated to v2.<br />
<br />
==Required Objects == <br />
=== The MC Reader and Sub Construction samples===<br />
<p><br />
These two items, the MC Reader and the Sub<br />
Construction store item, are special in that they<br />
will only become available for research if and<br />
only if a sample is available in your general<br />
stores before completing research for their<br />
prerequisite technologies.<br />
</p><br />
<p><br />
If you do not have any when completing research<br />
on the last of their required technologies, they<br />
will NOT appear later even after acquiring a few<br />
samples.<br />
</p><br />
<p><br />
For example: If you've done Zrbite and are about<br />
to finish research on the Transmission Resolver,<br />
make sure that you have the 'sub construction'<br />
item in stores before the research on the<br />
Transmission Resolver hits 100%, or vice-versa.<br />
</p><br />
<p><br />
Between the MC Reader and the Sub Construction<br />
store item, the 'sub construction' store item is<br />
required to win the game. The MC Reader is<br />
optional.<br />
</p><br />
<p><br />
Note: This does not apply to Aqua Plastics. You<br />
can research it even without any samples.<br />
</p><br />
<p><br />
Note: If this happens to you and you don't have a suitable save game to revert, you can still rescue your game using a hex editor. Open the file RESEARCH.DAT that resides in the appropriate save game folder and set the byte at the hexadecimal offset 0x1B4 to 1. This will allow you to research Alien Sub Construction. (It will allow you to research it even if you don't have the prerequisite technologies, in fact, but you wouldn't cheat that way, would you?)<br><br />
</p><br />
<p><br />
Note: Another way to combat the research tree bug for Alien Sub Construction is to modify <br />
[http://www.ufopaedia.org/index.php?title=PROJECT.DAT_%28TFTD%29 PROJECT.DAT]. Open the file with a hex editor and set the byte at the hexadecimal offset 0x26 to 01. This will make Alien Sub Construction appear in your research, then all you have to do is assign some scientists and complete it. Note that this bypasses all prerequisites. (tested on TFTD v2 but should also work on other versions)<br />
<br><br />
</p><br />
<p><br />
'''Modify save games at your own risk. You should always create a backup first.'''<br />
</p><br />
<br />
<br><br />
<br />
== Version differences==<br />
<p><br />
There are two versions of TFTD. The original<br />
unpatched version of TFTD and the one with the v2<br />
update.<br />
</p><br />
<p><br />
Players with the Collectors Edition of TFTD have<br />
the version with the v2 patch.<br />
</p><br />
<p><br />
The known changes in the research tree are as<br />
follows:<br />
</p><br />
<p><br />
====Unpatched====<br />
</p><br />
<p><br />
A Lobsterman Navigator is needed to research<br />
Magnetic Navigation<br />
</p><br />
<p><br />
Ion Armour is not required for Magnetic Ion<br />
Armour. All the technologies you need for<br />
Magnetic Ion Armour are Plastic Aqua Armour, Ion<br />
Beam Accelerators and Magnetic Navigation.<br />
</p><br />
<p><br />
====v2====<br />
</p><br />
<p><br />
Magnetic Navigation can be researched as soon as<br />
one is in storage. The lobsterman navigator is<br />
NOT required.<br />
</p><br />
<p><br />
Ion Armour is required for Magnetic Ion Armour.<br />
Magnetic Ion Armour now just requires Magnetic<br />
Navigation and Ion Armour.<br />
</p><br />
<p><br />
Yes, in other words, the v2 patch makes it easier<br />
to get Mag. Ion Armour. However, it also means<br />
that winning the game hinges on your ability to<br />
obtain a live Deep One terrorist AND researching<br />
it in the right order.<br />
</p><br />
<p><br />
If you patch your game and reload a campaign<br />
created before the patch, you might face a few<br />
research problems. It's not that common, but you<br />
might find that you'll have some trouble with<br />
researching the more advanced armour via the V2<br />
method. There should be no problems if you<br />
haven't even started on the Ion Armour or Mag Ion<br />
Armour yet. It's mostly for campaigns where<br />
you're already half-way through researching the<br />
armour.<br />
</p><br />
====v2.1====<br />
Only difference from v2 (per [http://www.strategycore.co.uk/files/index.php?dlid=192 StrategyCore]) is that the MC Reader bug is fixed: it can be researched even if you didn't have a sample when MC Lab was complete. Note that TFTD CE is v2 and does not include this fix.<br />
<br />
= The Good Bit=<br />
The all important good bit gets down to the brass tacks. It's probably why you're here, so dig in! <br />
<br><br />
<br />
=== Alien Sub Components ===<br />
<br />
{| cellpadding="6" cellspacing="0" rules="all" style="border: 1px solid gray; text-align: center; background: #F9F9F9"<br />
|- style="background: lavender; border: 1px gray solid"<br />
! width="15%" | Technology !! width="20%" | Prerequisities !! Notes<br />
|-<br />
| Zrbite || None || style="text-align: left" | A clump of Zrbite can be found underneath an Ion Beam Accelerator unit. If any explosive detonations occur near the IBA unit, it will be destroyed as it is very brittle (or rather, the IBA will blow up).<br />
<br />
You can pick up these clumps, but finding a clump only occurs in unusual circumstances. For example, throwing an unconscious soldier into an IBA and waiting for him or her to wake up. Falling down onto one or walking into one with the walk-through-walls bug.<br />
<br />
Xcomutil users will often find Zrbite clumps lying about when selecting a USO floor map that is not the same as the type of USO you're actually attacking.<br />
|-<br />
| Aqua Plastics || Deep One corpse || style="text-align: left" | You don't need any aqua plastics to research it. You just need the Deep One corpse.<br />
|-<br />
| Ion Beam Accelerators || None || style="text-align: left" | Ion Beam Accelerator units are found in intact alien USOs. Most smaller enemy subs will lose their IBA units if shot down, although some of the IBA units may survive if they're in larger ships.<br />
|-<br />
| Magnetic Navigation || None (TFTD v2) or Lobsterman&nbsp;Navigator (TFTD&nbsp;pre-v2) || style="text-align: left" | In older versions of the game, a Lobsterman Navigator is required to get Magnetic Navigation. Otherwise, it should appear immediately on the research list once one is in storage.<br />
|-<br />
| Transmission Resolver || Magnetic Navigation || style="text-align: left" | &nbsp;<br />
|-<br />
| Sub Construction || Sub Construction (item), Zrbite, Transmission&nbsp;Resolver || style="text-align: left" | Keep at least one 'sub construction' component in storage before completing either of the two prerequisites. If you don't have one when both the prerequisites have been met, you will not get the 'sub construction' tech item, which is required for the advanced submarines<br />
|}<br />
<br><br />
<br />
=== Armour ===<br />
{| cellpadding="6" cellspacing="0" rules="all" style="border: 1px solid gray; text-align: center; background: #F9F9F9"<br />
|- style="background: lavender; border: 1px gray solid"<br />
! width="15%" | Technology !! width="20%" | Prerequisities !! Notes<br />
|-<br />
| Plastic&nbsp;Aqua Armor || Aqua&nbsp;Plastics || style="text-align: left" | Aqua Plastics are obtained from a Deep One corpse. You need not have any actual aqua-plastics in storage to get the Aqua Plastics research item.<br />
|-<br />
| Ion Armour || Ion&nbsp;Beam&nbsp;Accelerators, Plastic&nbsp;Aqua&nbsp;Armour and a&nbsp;Deep&nbsp;One&nbsp;Terrorist || style="text-align: left" | Research the first two prerequisites in any order you wish. However, you MUST research the live Deep One Terrorist LAST. If you researched this alien earlier, you won't get Ion Armour. Capturing another Deep One Terrorist is possible, but there is a small chance that you will not be able to research any more of them.<br />
<br />
This is especially important in versions of TFTD patched with the v2 update, as without Ion Armour, you cannot get Magnetic Ion Armour, which in turn is needed to get the advanced submarines.<br />
|-<br />
| Magnetic&nbsp;Ion Armour<br>(TFTD v2) || Ion&nbsp;Armour, Magnetic&nbsp;Navigation || style="text-align: left" | If you don't know what version of the game you have, the method in which you obtain Mag. Ion Armour will tell you which one it is.<br />
<br />
For versions v2 and up, Magnetic Navigation becomes available the moment you have a sample in storage. Also keep in mind that Ion Armour is compulsory.<br />
|-<br />
| Magnetic&nbsp;Ion Armour<br>(TFTD pre-v2) || Magnetic&nbsp;Navigation, Ion&nbsp;Beam&nbsp;Accelerators || style="text-align: left" | In older versions of TFTD, to get Magnetic Navigation, you need a Lobsterman Navigator. Keep in mind, Ion Armour is not compulsory.<br />
|}<br />
<br><br />
<br />
=== Submarines ===<br />
{| cellpadding="6" cellspacing="0" rules="all" style="border: 1px solid gray; text-align: center; background: #F9F9F9"<br />
|- style="background: lavender; border: 1px gray solid"<br />
! width="15%" | Technology !! width="20%" | Prerequisities !! Notes<br />
|-<br />
| Manta || Magnetic&nbsp;Ion&nbsp;Armour, Sub&nbsp;Construction || style="text-align: left" | Refer to the sub component section for notes on Sub Construction. This submarine allows construction of the more advanced SWS.<br />
|-<br />
| Hammerhead || Manta || &nbsp;<br />
|-<br />
| Leviathan || Hammerhead, Lobsterman&nbsp;Commander || style="text-align: left" | The Lobsterman Commander should be researched after the Hammerhead. Also, for your convenience, don't forget to research 'alien origins' first so that you don't have to capture a third lobsterman commander to win the game.<br />
<br />
If you did not research the commander and the hammerhead in the right order, don't worry, just research another Lobsterman Commander.<br />
<br />
Note (to Hexedit): Open the file RESEARCH.DAT that resides in the appropriate save game folder and set the byte at the hexadecimal offset 0x27A to 1. This will allow you to research The Latest Flying Sub aka Leviathan<br />
|}<br />
<br><br />
<br />
=== Techs to Win the Game ===<br />
{| cellpadding="6" cellspacing="0" rules="all" style="border: 1px solid gray; text-align: center; background: #F9F9F9"<br />
|- style="background: lavender; border: 1px gray solid"<br />
! width="15%" | Technology !! width="20%" | Prerequisities !! Notes<br />
|-<br />
| Alien&nbsp;Origins || Any live alien ||<br />
|-<br />
| The Ultimate Threat || Alien&nbsp;Origins and a&nbsp;Lobsterman&nbsp;Commander || style="text-align: left" | Research the commander last. If you researched the commander before alien origins, don't worry. Just research another commander.<br />
'''* A lobsterman Navigator can also substitute for the commander'''<br />
|-<br />
| T'Leth, the&nbsp;Alien's&nbsp;City || The&nbsp;Ultimate&nbsp;Threat and a&nbsp;Lobsterman&nbsp;Commander (another&nbsp;one) || style="text-align: left" | You need to research another lobsterman commander.<br />
<br />
If you researched the Tasoth commander any time in the past, then you've fallen in to the [[#The Tasoth Commander Trap|Tasoth Commander Trap]] and this very<br />
important tech item will not appear, which means your current campaign has been scuttled and has already sunk all the way to the bottom of the ocean floor. Period.<br />
<br />
If you don't have any saves made before completing research on the Tasoth commander, then your only recourse is to start a new game.<br />
|}<br />
<br><br />
<br />
=== Disruptor Pulse Launcher (optional) ===<br />
<br />
Optional as you do not need the DPL torpedoes to win the game. It's not a serious problem, but is mentioned anyway to ally any concerns about the launchers not appearing for research.<br />
<br />
{| cellpadding="6" cellspacing="0" rules="all" style="border: 1px solid gray; text-align: center; background: #F9F9F9"<br />
|- style="background: lavender; border: 1px gray solid"<br />
! width="15%" | Technology !! width="20%" | Prerequisities !! Notes<br />
|-<br />
| Disruptor&nbsp;Pulse Launcher || Zrbite || style="text-align: left" | As soon as you've researched Zrbite, you can start research on the DPL launcher and its ammo - assuming you had a sample in storage upon completion of the project.<br />
<br />
However, unlike Sub Construction and the Mind Probe, the DPL Launcher has a failsafe. If you did not have any samples upon completion of Zrbite, you will be able to make them appear for research the moment the '''next''' research project is completed.<br />
|}<br />
<br><br />
<br />
=== Molecular Control Technology (optional) ===<br />
<br />
Optional because you don't need MC tech to win the game. But as its research branch has a notable bug, is included as well.<br />
<br />
{| cellpadding="6" cellspacing="0" rules="all" style="border: 1px solid gray; text-align: center; background: #F9F9F9"<br />
|- style="background: lavender; border: 1px gray solid"<br />
! width="15%" | Technology !! width="20%" | Prerequisities !! Notes<br />
|-<br />
| M.C.-LAB || Any Live Terrorist || style="text-align: left" | Either of the two terrorist units will give you the M.C.-Lab.<br />
<br />
Deep One Terrorists generally follow Gill-men and Calcinites associate themselves with Aquatoids. Both aliens can be found in 'mixed' crew land missions.<br />
|-<br />
| MC Reader || MC Reader (item), M.C.-Lab || style="text-align: left" | The MC Reader research item will only become available if research on the M.C.-Lab is completed while an MC Reader is in storage.<br />
<br />
If you miss out on this, you will NOT get the MC Disruptor or the MC Generator for the rest of the campaign.<br />
|-<br />
| MC Disruptor || MC Reader and<br>any live Tasoth || style="text-align: left" | Excluding the Tasoth Commander, of course.<br />
<br />
While the Ufopaedia says it only works underwater, this item will work on land. I believe the text was meant to say that only aquanauts with 'MC implants' can use it, the word 'underwater' seems like a typo that was never removed.<br />
<br />
Again, if you research the live Tasoth before completing the research on M.C. Reader, you will be forced to capture and interrogate another live Tasoth in order to get the M.C. Disruptor technology.<br />
|-<br />
| MC Generator || MC Disruptor || style="text-align: left" | This item will protect your base from being found, but it does not work 100% of the time. Aliens can still attack shielded bases if their scouts are lucky. The magnitude of USOs successfully spotting your base is reduced.<br />
|}<br />
<br><br />
<br />
=== Melee Weapons (optional, but handy) ===<br />
<br />
Vibro Blade research comes from the Calcinite corpse. Once that research is done, if you've autopsied a Gillman corpse by that point (more than likely) you also get to research Thermic Lance. Once Thermic Lance is researched, Heavy Thermic Lance, last in this line, can be researched<br />
<br />
<br />
=== Obligatory Disclaimer Claptrap === <br />
<p><br />
This document will not always be 100% accurate, as the game tends to behave differently for <br />
different players with different computer systems and game editions.<br />
</p><br />
<p><br />
These notes are derived through many controlled tests and observations with the MS-DOS<br />
edition of Terror From The Deep with the TFTDv2 patch. Any noticeable difference between the<br />
patched game and the older versions are noted. Otherwise, these notes are valid for practically<br />
any version of TFTD available on the PC, with the possible exception of TFTD for the Sony Playstation.<br />
</p><br />
<p><br />
TFTD, Terror From The Deep, X-Com, XCOM, et. al.<br />
originally developed by some very fine people. Originally distributed by Microprose. Now? Who knows. <br />
</p><br />
<p><br />
As the purpose of this document is to inform, feel free to distribute any information in this<br />
document as you see fit.<br />
</p><br />
<p><br />
Many thanks for the input and feedback from the<br />
regular posters on the Xcommand and X-Com<br />
Tactical Command forums for assisting in the<br />
preparation of this document. Some indirect<br />
thanks to the fine folks on the alt.games.x-com<br />
Usenet newsgroup as well. Extra bits and pieces here and there picked up from the xcomufo.com forums as well. <br />
</p><br />
<br />
[[Category:Research (TFTD)]]<br />
[[Category:TFTD]]</div>
Spike
https://www.ufopaedia.org/index.php?title=Known_Bugs_(TFTD)&diff=72329
Known Bugs (TFTD)
2016-06-07T15:46:32Z
<p>Spike: /* Craft Bugs */ added 'Medic Cannon'</p>
<hr />
<div>''Note: Since TFTD shares its game engine with X-Com Enemy Unknown, there are many problems that are common to both games. Please track any shared/common bugs under the XCOM-EU list of Known Bugs (link at the bottom of this page). This page is just for TFTD-Specific bugs. ''<br />
<br />
<br />
= List of TFTD-Specific Bugs =<br />
==Artifact Site Glitches==<br />
There is a rarely occurring glitch when winning Artifact Sight missions by killing all aliens. Instead of a normal end screen,the screen will turn black and then resume on one of your soldiers, but with an unmovable cursor. Reloading saves may put you on the geoscape where the game can be played normally apart from when entering Artifact Sites, where you either cannot move your cursor in the equipment screen or the ending screen from the mission when the glitch occurred is shown but the cursor can't be moved. This means you must ignore all Artifact Site missions to continue the game, but as ignoring them results in an immediate -2000 point penalty, you will eventually lose due to being shut down or running out of funds. <br />
<br />
== Research Tree bugs ==<br />
<br />
See the [[TRTBAG|Research Bug Avoidance Guide]] for full discussion. *<br />
<br />
==Alien Glitches==<br />
<br />
* Aliens can't use carried melee weapons (Vibroblades and both types of Thermic Lances), even when they are equipped with them. (This is a game engine bug is present in UFO:EU as well, but it is not relevant to UFO:EU, since in UFO:EU aliens never get equipped with any carried melee weapons.) *<br />
* The [[Bio-Drone]]'s melee attack almost always has no effect, even on unarmoured troops. ([[User:Zombie|Zombie]] has determined the weapon has a base accuracy of 0%, presumably a programming error). This is a serious flaw in the Bio-Drone, as it always uses this attack when Aquanauts are adjacent - especially given that one of the best ways to deal with Bio-Drones is by melee combat. *<br />
* <s>The [[Hallucinoid]]'s ranged attack only works on land, but the Hallucinoid rarely/never appears on land. Presumably this is a programming error and was meant to be the other way round (only works underwater)</s>. The [[Hallucinoid]] is not given a ranged attack of any kind although the in-game description states that it has one. Its melee attack deals normal (lethal) damage although the in-game description says that it is icy, leading the player to believe that it should stun. ''This has been verified by several reliable sources. It does not appear on land unless the game code or data files have been modified.''<br />
* The Deep One attack looks like the Celatid spit / mortar (holdover from UFO). *<br />
* The Bio-Drone leaves a burning trail (holdover from the Silacoid in UFO?). *<br />
<br />
== Mind Control Bugs==<br />
*[[Large units#Large units in TFTD|Large units in TFTD]] suffer from even more bizarre behaviour than in UFO, due to an attempt to fix the old UFO bug.<br />
<br />
== Craft Bugs==<br />
*The floor maps & schematic pictures of the Survey Ship and Escort are swapped with each other in the Battlescape, the Interception window and the UFOPaedia. There is a (partial?) fix for this in [[XcomUtil]]. [[User:Zombie|Zombie]] has provided a [http://www.strategycore.co.uk/files/index.php?dlid=620 fix] that also fixes the routes as well as the maps.<br />
<br />
*The schematic pictures of the Battle Ship and the Fleet Supply Cruiser are also swapped in the UFOPaedia and Intercept window. The floorplan maps on the Battlescape are not affected.<br />
*Troop transports like the [[Triton]] can be blown up quite badly in land maps (rather than being invulnerable as it should be). This somehow doesn't prevent X-COM from flying back using it.<br />
* '''TFTD V1.0''' There is a unit positioning bug when placing 26 men in a Leviathan. This bug is fixed by [[XcomUtil]] (and presumably in later versions of TFTD).<br />
* 'Medic Cannon' - USO being armed with 1/0 weapons, the 'weapon' being 'medic' shown as a purple rank badge with commander's chains. with an ammunition capacity of two, but without any rounds for it. [[User:NKF|NKF]] says "it takes the D.U.P. Head as ammo. The launcher. Not the ammo. I don't know if the performance is the same between glitches, but I've seen this thing destroy a Dreadnaught and left no wreckage. Then at other times it does nothing."<br />
<br />
== X-COM Equipment Glitches ==<br />
* Underwater-only weapons (HydroJet Cannon, Torpedo Launcher, and Disruptor Pulse Launcher, plus the Coelecanth/AquaJet & Displacer/PWT SWS weapons) are able to fire on land during XCOM's reaction-fire phase. This should not be allowed. *<br />
* Coelacanth/Gauss Cannon ammo arming bug(s): The Coelacanth/Gauss does NOT return any remaining ammo to your stores at the end of a mission. In addition, when you assign a Coelacanth/Gauss to a troop transport, 50 Gauss Cannon rounds (used by both Craft and SWS Gauss Cannon) will be immediately deducted. These rounds cannot be refunded by any means. If you change your mind about assigning it, deassign it, and then reassign it, the premium will be deducted yet again from your stores. *<br />
<br />
== Geoscape Bugs ==<br />
* There is a really annoying "Cannot intercept over land" message that repeatedly pops up (often more than once a second) during some pursuits along coastlines. This is probably because the pursuing aircraft is moving rapidly from land areas to sea areas and back again as it flies along a coastline. *<br />
<br />
* When intercepting an Alien Sub that is too deep for an XCom Flying Sub's operating depth, the Sub will report "Mission too deep" and return to base, rather than tracking the Alien Sub until such time as the Alien Sub rises to a depth at which the Sub can intercept. This forces you to take control of the Sub and get it to follow the Alien Sub manually, using Geoscape waypoints. *<br />
<br />
* Alien Subs will sometimes Touch Down on land (e.g. several hundred nm south of the North African coastline). If you respond to these missions with an Assault, they are fought at Shallow depth rather than on land. Geoscape map/terrain data bug maybe? ''Even worse, assaulting these subs may cause your game to crash when it tries to start the battle.''<br />
<br />
* [[Known Bugs#Manufacturing Rate Limit Bug (TFTD)|Manufacturing Rate Limit Bug/Quirk (TFTD)]] - The manufacturing windows allows you to assign more technicians than the limit allowed and provides a quicker estimated time to complete the project than actually occurs. *<br />
<br />
* Craft Gauss Cannon rearm rate. The Craft Gauss Cannon reloads at only 10 rounds per hour. This compares to 99 or 100 rounds per hour for all other cannon weapons in TFTD and EU. This is believed to be a data entry bug when changing the reload rate of the Laser Cannon (99) for the TFTD equivalent Gauss Cannon. The result is that fully reloading a single Gauss Cannon takes 5+1= 6 hours and dual Gauss Cannon 5x2+1= 11 hours. This is slower rearming than any other weapon system apart from AJAX/Stingray (which itself probably represents a design oversight on its rearming rate). *<br />
<br />
* When generating the Geodata.dat outline map for a sunken plane mission, if the game decides to put in a small version of the right wing (PLANE19.MAP or PLANE20.MAP) it will try to place it in Geodata map block 3, 3 (tile x:30 y:30). When verifying if the block is free, the game will mistakenly check Geodata map block 1, 1 (x:10 y:10). If that block is free, it will create the small wing in map block 3, 3 regardless of what was in there. While this is a bug, its effects are quite trivial and players will not necessarily notice anything amiss were it to have taken effect. <br />
:: The more technical explanation is that instead of checking the Geodata.dat map location at 3 * 5 + 3, the game simply checks the map at location 3 + 3. The map width (5) has been omitted.<br />
<br />
== Battlescape Bugs ==<br />
* Strange MCD records (aka the 3d shapes that form the various walls and objects in the game). Due to some strange shapes, there are some locations with various line of sight errors and clipping errors such as a bullet hitting something in mid air when it shouldn't. There are even some cases where walking into a tile is much more tiring than it should be. This is not TFTD specific, but is much more apparent. <br />
<br />
* On ship missions, there are some metal panels on walls. These tend to remain floating in the air even if the wall is destroyed. This is only a visual bug. <br />
<br />
* Multi-stage mission bugs<br />
**Strange effects occur to Aquanauts who were unconscious and/or under Molecular Control at the end of the previous stage of a multi-stage mission. These effects include: the Aquanauts becoming invisible, or becoming 'wraiths' in the next mission stage. (Does this also affect XCOM-EU, e.g. the 2-stage Cydonia mission?) *<br />
** Any Captured aliens that are carried will die when they reach phase two. The actual working logic behind this is that since the new map is generated with a new set of enemies, the 'stats' that make up the stunned alien aren't retained, but only the physical object that represents the alien is carried over. This makes capturing aliens on the first part pointless unless you intend to abort the first part after physically hauling the stunned alien back to the transport. <br />
** '''TFTD V1.0''' any equipment that is left on the ground on the first part of a two parter mission are not collected when you abort or complete the second part. This includes everything in the troop transport, which is lost forever. The V2.0 patch fixes this bug and returns everything on the first map. <br />
<br />
* [[Dye Grenade]]s are to all intents and purposes, useless. Arguably not a bug, but it should not have survived basic playtesting. Weak weapons (eg [[Dart Gun]]) are one thing, but Dye Grenades are pointless because they never generate enough of a screen to block visibility. The best they would do is reduce alien visual range from 20 to 17. There would be a strong case to fix the strength of the Dye 'explosion' upward from 10 to 60 (like the [[Smoke Grenade]]) or at least 30-40. *<br />
* Stunned Aquanaut bugs. (These might not be specific to TFTD, the situations are rare enough).<br />
** In some cases, when moving a stunned body elsewhere, and it is subsequently killed by an explosion, the corpse may appear back at its original location. *<br />
** Stunned Aquanauts in the Triton are not reported as either inside or outside the transport sub when you abort a terror mission. *<br />
*** Stunned aquanauts that are carried by other aquanauts are listed as MIA if mission is aborted even if the carrier is aboard the Triton.<br />
**It is possible to abort a mission even if all Aquanauts are stunned. Not sure if this should be possible?<br />
**If the Triton is lost (aborting with no survivors), the stunned Aquanauts are shown as assigned to "Weapon-1", not their Triton, and they become inaccessible, basically lost/gone. *<br />
** The animation for stunning a Civilian falling down shows them being violently killed.<br />
<br />
* Zrbite spawns in locations unrelated to the Ion Accelerators. This is a result that the developers either 1) set the location of zrbite and later the ship maps were changed or 2) the developers confused the x and y coordinates in the database which specifies the specific location in the USO. ''In the game, Zrbite spawns when the alien items are created. Each Zrbite's OBPOS coordinates are established based on the USO position then reading the additional x, y, and z coordinates from a database, referenced to each USO.''-[[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]]) 05:56, 3 April 2015 (EDT)<br />
<br />
* In the CE version, clips that are loaded into weapons dropped on the battlefield will be given to the player at the time of an abort, even if the weapon in question was left on the battlefield. This is very apparent on USO recovery missions if the player immediately aborts when the battle starts and several aliens have died prior to the start of battle.*<br />
<br />
==Manufacturing Rate Limit Bug(TFTD)*==<br />
<br />
In UFO Enemy Unknown, the Manufacturing Rate Limit is just an irritant: The game prevents you from allocating more Engineers than the PRODUCT.DAT files says are needed to complete the item in one hour. This result in a minimum of one hour per item being necessary for the whole order. In an attempt to overcome this, the programmers eliminated this cap on the manufacture screen but failed to alter the code that actually determines what is produced every hour. Any extra technicians assigned over the number shown when you start an order produce nothing and their hours are wasted.<br />
<br />
== Ufopedia Discrepancies ==<br />
<br />
* [[Deep One]]s are portrayed carrying a weapon, in fact it appears to be carrying an X-com issue [[P.W.T. Cannon|P.W.T. Cannon]] craft weapon, instead of being unarmed other than its built in attack. *<br />
* The [[Tasoth]] species is described as more resembling some sort of foot soldier in Ufopedia. It seems highly likely that the Tasoth were supposed to be one of the grunt races, and planning issues caused there to only be 4 main races in TFTD, making Tasoth the default Psionic (MC using) race.<br />
* The [[Tentaculat]] description states that ([[Zombie]]s) cause death by touch even through armor. That's very wrong. The resulting zombies have a rather weak melee attack, especially compared to the Tentaculats. Also, the description says nothing about Zombies turning into Tentaculats upon death.<br />
* The Ufopedia shows the damage of a [[Displacer/Sonic]] cannon as 130, but the coded value is 110. *<br />
* See also the Craft Bugs where the map layout, interception picture and the Ufopedia picture are inconsistent with each other.<br />
* The Ufopedia describes the [[Dart Gun]] as having a ten round magazine, when in fact it has a twelve round magazine.<br />
<br />
== Questionable logic== <br />
* Aquanauts and SWSs are unable to move vertically in water without the use of alien technology. Apparently no one has heard of ballast belts, propellers, or flippers.<br />
** Actually, most of the aliens are unable to move vertically in water, despite most of them being aquatic creatures!<br />
* Thrown objects behave underwater with identical physics as on land - impossible.<br />
* Explosions behave underwater with identical physics as on land - impossible. (See [http://science.howstuffworks.com/explosion-land-water1.htm this link])<br />
* Projectile weapons behave underwater with identical physics as on land - extremely unlikely.<br />
* Vehicles behave the same underwater as in the air, fuel, acceleration, speed, etc. - impossible <br />
* Alien "Molecular Control" is said to work via MC implants on the subject, but works on human Aquanauts (and civilians), regardless of whether the humans have MC implants. (They should've just called this Psionics like in Enemy Unknown.)<br />
* X-com craft mounted Gas Cannon has an effective range of 8km. A gas reservoir capable of launching a solid bolt 8km underwater? - ridiculous.<br />
* Underwater missions will at most take place in the light during the day and in the dark during the night. This is impossible. Sunlight won't penetrate deep in the water and most of the seabed is permanently dark.<br />
<br />
== [[XcomUtil]] Bugs ==<br />
<br />
These bugs relating to XComutil may be outdated. <br />
<br />
* Gillmen are reported as Snakemen in some pop up messages, when using XcomUtil. <br />
<br />
*Sometimes at the start of the 2nd level of a mission, all items, not loaded onto Aquanauts in the equip phase, appear to be lost. And some/all weapons have an ammo count of zero / no clips (possibly when the ammo was loaded automatically in the equip phase). (Believed to be related to XcomUtil teleporting 'spare' equipment back to base at the end of a level. See Talk page and [[Talk:XcomUtil#Open Bugs]])<br />
<br />
==TFTD Extender ==<br />
Items marked with an asterisk (*) have been fixed with the Extender.<br />
<br />
= TFTD-Specific Exploits =<br />
<br />
== Massively Profitable Alternate Craft Gauss Ammo ==<br />
<br />
(Possibly should be defined as 'Light Modding' rather than an exploit, in the language of the Enemy Unknown [[Exploits]] pages.)<br />
<br />
There is an alternate Craft Gauss Ammo type (in [[BASE.DAT (TFTD)]] at offset 0xD2). There appears to be no research path to unlock this ammo type. It looks like a late design decision was taken to have both the [[Coelacanth/Gauss]]'s cannon and the Craft [[Gauss Cannon]] use the same ammo type (in BASE.DAT (TFTD) at offset D0), unlocked by Gauss Cannon research, and unusually (uniquely?) without its own ammo Research topic. This is just as well, since the 0xD2 ammo type is incredibly expensive to manufacture and uses a huge amount of storage space. The production start cost is $10,000, and each unit uses 0.6 base storage. Perhaps this was intended to be a 50-round ammo pack, like the Craft [[Gas Cannon]] (and Enemy Unknown's [[Cannon]]), in which case the cost would not have been unreasonable.<br />
Probably due to a typing / data entry error, the sell price of the 0xD2 ammo is set to $53,300, which is the sell price of Craft P.W.T. Ammo (and the Fusion Ball in Enemy Unknown). The extremely favourable spread between the build price and the sell price makes this item more than 5 times more profitable to manufacture than Gauss Cannon, far and away the most profitable item in the game.<br />
If it is true that there is no Research path to unlock this 0xD2 ammo, then unlocking it requires game file manipulation, so this is arguably a Game File exploit, and of course if one is manipulating Game Files, it's easier just to hack ridiculously large amounts of money. For those who are not inclined to edit a binary file themselves, the XcomUtil TEC:ALL option will unlock this ammo type. Possibly XcomHack could also be used. The clear profit with two full Workshops is $22.866 million per month - after all expenses including Technician salaries. <br />
<br />
= See Also =<br />
<br />
*[[Known Bugs|Known Bugs (Enemy Unknown and generic)]]<br />
*[[Exploits|Exploits (Enemy Unknown and generic)]]<br />
<br />
[[Category: Oddities and bugs]]<br />
[[Category:TFTD]]</div>
Spike
https://www.ufopaedia.org/index.php?title=Hallucinoid&diff=72328
Hallucinoid
2016-06-07T14:47:35Z
<p>Spike: /* General Information */ hyperlinked ranged attack bug</p>
<hr />
<div>== General Information ==<br />
<br />
{{Ref Open|title = Hallucinoid}}<br />
[[Image:Hallucinoid.png|right|Hallucinoid]]Having harvested the oceans the aliens have bred these huge Earth creatures as a weapon. Do not be lulled into a false sense of security when facing these harmless looking sailors of the deeps.<br><br>Possessed of a formidable, ranged, freezing blast and a close combat icy strike, the Hallucinoid is a deadly foe. <br clear="all" /><br />
{{Ref Close | source = Terror From The Deep Ufopaedia}}<br />
<br />
<br />
{{Ref Open|title = Hallucinoid Autopsy}}<br />
[[Image:HallucinoidAutopsy.png|right|Hallucinoid Autopsy]]Nested in the many layers of the gelatinous body of this organism is a powerful chemical freezer, its main offensive capability. The soft and supple skin of the Hallucinoid seems susceptible to heat based attacks. Often this mutant is found in the company of its masters, the Aquatoids. <br clear="all" /><br />
{{Ref Close | source = Terror From The Deep Ufopaedia}}<br />
<br />
{{Infobox open}}<br />
{{Statbox module<br />
| name = Hallucinoid<br />
| time_units = 62 - 91<br />
| health = 120<br />
| energy = 90 - 133<br />
| reactions = 90 - 122<br />
| strength = 90 - 111<br />
| bravery = 100<br />
| firing_acc = 32 - 129<br />
| throwing_acc = 80<br />
| MC_skill = 0<br />
| MC_strength = 90 - 111<br />
| armour_front = 14 - 42<br />
| armour_left = 14 - 42<br />
| armour_right = 14 - 42<br />
| armour_back = 14 - 42<br />
| armour_under = 10 - 30<br />
}}<br />
{{Statbox module/hidden stats<br />
| melee_acc = 90 - 133<br />
| energy_recharge = 50<br />
| victory_points = 35<br />
| standing_height = ?<br />
| kneeling_height = ?<br />
| intelligence = 7<br />
| aggression = 2<br />
}}<br />
{{Statbox module/unique stats<br />
| armour_category = Hallucinoid<br />
| rank_types = Terrorist<br />
| unique_attributes = Melee Attack, Can "Fly"<br />
}}<br />
{{Infobox close}}<br />
<br />
The Hallucinoid is a large, "flying" alien jellyfish usually found in the company of Aquatoids underwater. It is fairly resilient, but is limited to physical melee attacks. Contrary to the Ufopaedia description, due to [[Known_Bugs_(TFTD)#Alien_Glitches|a game bug]] it does not normally have a ranged attack. (The bug can be fixed using 3rd party utilities).<br />
<br />
Since it is not particularly aggressive and has no means of harassing enemies at range, it is not an immediate threat to Aquanauts as long as they maintain their distance. However, if allowed to close to melee range, it can seriously damage or kill any Aquanaut.<br />
<br />
Hallucinoids' ability to change elevation allows them to pursue Aquanauts wearing [[Magnetic Ion Armor]]. However, their large size renders them unable to chase [[Aquanauts]] through narrow gaps or passages.<br />
<br />
The Hallucinoid appears in Terror From the Deep. Its closest approximation in UFO Enemy Unknown is the [[Reaper]].<br />
<br />
==Tactics==<br />
The Hallucinoid is not a very dangerous alien, as it has no ranged weaponry (in an unpatched game) and is not amazingly fast or aggressive like the [[Tentaculat]]. It does, however, have a great deal of bulk between its immense health, wide array of resistances, and significant armour.<br />
<br />
Sonic weapons are effective for hunting Hallucinoids, as they aren't resisted and have enough power to punch through the armour. Thermal Shok Launchers are also very effective, though this may clog your [[Alien Containment]]. Explosives deal 4x damage due to Hallucinoids' large size, but their significant HE resistance and Under Armour mean that only very powerful explosives such as the [[Torpedo Launcher]] and [[Disrupter Pulse Launcher]] can really benefit from this. Gauss weapons do a decent job on lower difficulty settings, but on the higher difficulties Hallucinoids' armour is just too tough. Hallucinoids' ability to swim makes it difficult to use grenades against them, but the [[Magna-Pack Explosive]] and [[Sonic Pulser]] will deal massive damage if you can catch one on the ground. Finally, do not attempt to use [[Vibroblade]]s against Hallucinoids. Their high armour and resistance to melee damage make these drills ineffective. Stronger drills like the [[Heavy Thermic Lance]] have a better chance at armour penetration. Note that approaching a Hallucinoid to use a drill also puts the Aquanaut in its striking range.<br />
<br />
==Notes==<br />
The following are some miscellaneous notes on the Hallucinoid:<br />
* The Hallucinoid takes 0.6x damage from melee and armour piercing attacks, 0.7x damage from explosives, 0.8x from Gauss, but 1.7x damage from incendiary attacks.<br />
* It appears exclusively underwater.<br />
* Takes up 4 squares on the battlescape.<br />
<br />
==See Also==<br />
* [[Alien Life Forms (TFTD)|Alien Life Forms]]<br />
* [[Overviews_of_Aliens_(TFTD)|Overviews of Aliens]]<br />
* [[Terror_Units_(TFTD)|Terror Units]]<br />
* [[Calcinite]]<br />
* [[Aquatoid]]<br />
<br /><br />
{{Aliens (TFTD)}}<br />
<br />
[[Category:Alien Life Forms (TFTD)]]<br />
[[Category:TFTD]]</div>
Spike
https://www.ufopaedia.org/index.php?title=Calcinite&diff=72327
Calcinite
2016-06-07T14:45:08Z
<p>Spike: /* Tactics */ Hallucinoids only weak due to bug</p>
<hr />
<div>== General Information ==<br />
<br />
{{Ref Open|title = Calcinite}}<br />
[[Image:Calc.PNG|right|Calcinite]]In the diving suits of lost mariners, these aliens stalk the seabed for the unwary. A vicious swipe by the creature's stronger than steel claws can be enough to send the best divers to the bottom.<br><br>A gelatinous green form can be seen swirling around in the face mask. No hint of the real creature can be divined from the often lethal encounters we have had with them. <br clear="all" /><br />
{{Ref Close | source = Terror From The Deep Ufopaedia}}<br />
<br />
<br />
{{Ref Open|title = Calcinite Autopsy}}<br />
[[Image:CalciniteAutopsy.png|right|Calcinite Autopsy]]Once the armoured suit is stripped away the Calcinite is revealed to be a huge amorphous blob of protoplasm. No visible brain, limbs or sensory organs exist, a small metallic component resides deep in the liquid body.<br><br>Once dead we can only guess at the creature's nature. An inexplicable enigma of our alien enemies. <br clear="all" /><br />
{{Ref Close | source = Terror From The Deep Ufopaedia}}<br />
<br />
{{Infobox open}}<br />
{{Statbox module<br />
| name = Calcinite<br />
| time_units = 68 - 101<br />
| health = 55<br />
| energy = 96 - 142<br />
| reactions = 75 - 102<br />
| strength = 110 - 136<br />
| bravery = 90<br />
| firing_acc = 48 - 120<br />
| throwing_acc = 80<br />
| MC_skill = 0<br />
| MC_strength = 90 - 112<br />
| armour_front = 14 - 42<br />
| armour_left = 14 - 42<br />
| armour_right = 14 - 42<br />
| armour_back = 14 - 42<br />
| armour_under = 4 - 12<br />
}}<br />
{{Statbox module/hidden stats<br />
| melee_acc = 85 - 126<br />
| energy_recharge = 40<br />
| victory_points = 20<br />
| standing_height = ?<br />
| kneeling_height = ?<br />
| intelligence = 5<br />
| aggression = 2<br />
}}<br />
{{Statbox module/unique stats<br />
| armour_category = Calcinite<br />
| rank_types = Terrorist<br />
| unique_attributes = Melee Attack<br />
}}<br />
{{Infobox close}}<br />
<br />
A terror unit that may accompany the Aquatoids on land missions. Fortunately, while its diving suit makes a good disguise, no Terror mission involves civilian aquanauts. So unless you have an agent obsessed with yellow diving suits (and refuses to take off his helmet on land), there should be no problem identifying this armored blob. <br />
<br />
The creature's corpse is crucial for XCom weapon research, since it provides information needed to study melee weapons like the [[Vibro Blade]]. Unfortunately for the scientists, [[Aquatoid]]s don't enjoy terror missions much and X-Com commanders may not encounter this green blob until late in the game when [[Mixed Crew]] missions occur.<br />
<br />
==Tactics==<br />
<br />
Not much to say here. Calcinites are fairly straightforward: they run up to you and try to claw you to death - leave TUs so your Aquanauts can reaction fire, or use [[Particle Disturbance Grenade]]s. They don't have ranged weapons, so they're completely helpless against during your own turn. They aren't particularly tough, so any weapon is effective against them. Still, they're more dangerous than the Aquatoids' other pets, the [[Hallucinoid]]s (which are also melee-only, unless the relevant [[Known_Bugs_(TFTD)#Alien_Glitches|bug]] is fixed), since they're smaller and more aggressive.<br />
<br />
==Notes==<br />
The following are some miscellaneous notes on the Calcinite:<br />
* The Calcinite takes 0.8x damage from Melee attacks, 0.9x damage from Incendiary and Gauss attacks, but 1.1x damage from Sonic weapons. <br />
* It appears exclusively on land, in the company of Aquatoids or Mixed crews.<br />
* Those old diving suits they wear actually give better protection than X-com's [[Diving Suit]]!<br />
<br />
==See Also==<br />
* [[Alien Life Forms (TFTD)|Alien Life Forms]]<br />
* [[Overviews_of_Aliens_(TFTD)|Overviews of Aliens]]<br />
* [[Terror_Units_(TFTD)|Terror Units]]<br />
* [[Hallucinoid]]<br />
* [[Aquatoid]]<br />
<br /><br />
{{Aliens (TFTD)}}<br />
<br />
[[Category:Alien Life Forms (TFTD)]]<br />
[[Category:TFTD]]</div>
Spike
https://www.ufopaedia.org/index.php?title=Hallucinoid&diff=72326
Hallucinoid
2016-06-07T14:43:50Z
<p>Spike: /* Tactics */ noted ranged attack bug</p>
<hr />
<div>== General Information ==<br />
<br />
{{Ref Open|title = Hallucinoid}}<br />
[[Image:Hallucinoid.png|right|Hallucinoid]]Having harvested the oceans the aliens have bred these huge Earth creatures as a weapon. Do not be lulled into a false sense of security when facing these harmless looking sailors of the deeps.<br><br>Possessed of a formidable, ranged, freezing blast and a close combat icy strike, the Hallucinoid is a deadly foe. <br clear="all" /><br />
{{Ref Close | source = Terror From The Deep Ufopaedia}}<br />
<br />
<br />
{{Ref Open|title = Hallucinoid Autopsy}}<br />
[[Image:HallucinoidAutopsy.png|right|Hallucinoid Autopsy]]Nested in the many layers of the gelatinous body of this organism is a powerful chemical freezer, its main offensive capability. The soft and supple skin of the Hallucinoid seems susceptible to heat based attacks. Often this mutant is found in the company of its masters, the Aquatoids. <br clear="all" /><br />
{{Ref Close | source = Terror From The Deep Ufopaedia}}<br />
<br />
{{Infobox open}}<br />
{{Statbox module<br />
| name = Hallucinoid<br />
| time_units = 62 - 91<br />
| health = 120<br />
| energy = 90 - 133<br />
| reactions = 90 - 122<br />
| strength = 90 - 111<br />
| bravery = 100<br />
| firing_acc = 32 - 129<br />
| throwing_acc = 80<br />
| MC_skill = 0<br />
| MC_strength = 90 - 111<br />
| armour_front = 14 - 42<br />
| armour_left = 14 - 42<br />
| armour_right = 14 - 42<br />
| armour_back = 14 - 42<br />
| armour_under = 10 - 30<br />
}}<br />
{{Statbox module/hidden stats<br />
| melee_acc = 90 - 133<br />
| energy_recharge = 50<br />
| victory_points = 35<br />
| standing_height = ?<br />
| kneeling_height = ?<br />
| intelligence = 7<br />
| aggression = 2<br />
}}<br />
{{Statbox module/unique stats<br />
| armour_category = Hallucinoid<br />
| rank_types = Terrorist<br />
| unique_attributes = Melee Attack, Can "Fly"<br />
}}<br />
{{Infobox close}}<br />
<br />
The Hallucinoid is a large, "flying" alien jellyfish usually found in the company of Aquatoids underwater. It is fairly resilient, but is limited to physical melee attacks. Contrary to the Ufopaedia description, due to a game bug it does not normally have a ranged attack. (The bug can be fixed using 3rd party utilities).<br />
<br />
Since it is not particularly aggressive and has no means of harassing enemies at range, it is not an immediate threat to Aquanauts as long as they maintain their distance. However, if allowed to close to melee range, it can seriously damage or kill any Aquanaut.<br />
<br />
Hallucinoids' ability to change elevation allows them to pursue Aquanauts wearing [[Magnetic Ion Armor]]. However, their large size renders them unable to chase [[Aquanauts]] through narrow gaps or passages.<br />
<br />
The Hallucinoid appears in Terror From the Deep. Its closest approximation in UFO Enemy Unknown is the [[Reaper]].<br />
<br />
==Tactics==<br />
The Hallucinoid is not a very dangerous alien, as it has no ranged weaponry (in an unpatched game) and is not amazingly fast or aggressive like the [[Tentaculat]]. It does, however, have a great deal of bulk between its immense health, wide array of resistances, and significant armour.<br />
<br />
Sonic weapons are effective for hunting Hallucinoids, as they aren't resisted and have enough power to punch through the armour. Thermal Shok Launchers are also very effective, though this may clog your [[Alien Containment]]. Explosives deal 4x damage due to Hallucinoids' large size, but their significant HE resistance and Under Armour mean that only very powerful explosives such as the [[Torpedo Launcher]] and [[Disrupter Pulse Launcher]] can really benefit from this. Gauss weapons do a decent job on lower difficulty settings, but on the higher difficulties Hallucinoids' armour is just too tough. Hallucinoids' ability to swim makes it difficult to use grenades against them, but the [[Magna-Pack Explosive]] and [[Sonic Pulser]] will deal massive damage if you can catch one on the ground. Finally, do not attempt to use [[Vibroblade]]s against Hallucinoids. Their high armour and resistance to melee damage make these drills ineffective. Stronger drills like the [[Heavy Thermic Lance]] have a better chance at armour penetration. Note that approaching a Hallucinoid to use a drill also puts the Aquanaut in its striking range.<br />
<br />
==Notes==<br />
The following are some miscellaneous notes on the Hallucinoid:<br />
* The Hallucinoid takes 0.6x damage from melee and armour piercing attacks, 0.7x damage from explosives, 0.8x from Gauss, but 1.7x damage from incendiary attacks.<br />
* It appears exclusively underwater.<br />
* Takes up 4 squares on the battlescape.<br />
<br />
==See Also==<br />
* [[Alien Life Forms (TFTD)|Alien Life Forms]]<br />
* [[Overviews_of_Aliens_(TFTD)|Overviews of Aliens]]<br />
* [[Terror_Units_(TFTD)|Terror Units]]<br />
* [[Calcinite]]<br />
* [[Aquatoid]]<br />
<br /><br />
{{Aliens (TFTD)}}<br />
<br />
[[Category:Alien Life Forms (TFTD)]]<br />
[[Category:TFTD]]</div>
Spike
https://www.ufopaedia.org/index.php?title=Hallucinoid&diff=72325
Hallucinoid
2016-06-07T14:38:30Z
<p>Spike: /* General Information */ Noted that the lack of ranged attack is a bug, and fixable.</p>
<hr />
<div>== General Information ==<br />
<br />
{{Ref Open|title = Hallucinoid}}<br />
[[Image:Hallucinoid.png|right|Hallucinoid]]Having harvested the oceans the aliens have bred these huge Earth creatures as a weapon. Do not be lulled into a false sense of security when facing these harmless looking sailors of the deeps.<br><br>Possessed of a formidable, ranged, freezing blast and a close combat icy strike, the Hallucinoid is a deadly foe. <br clear="all" /><br />
{{Ref Close | source = Terror From The Deep Ufopaedia}}<br />
<br />
<br />
{{Ref Open|title = Hallucinoid Autopsy}}<br />
[[Image:HallucinoidAutopsy.png|right|Hallucinoid Autopsy]]Nested in the many layers of the gelatinous body of this organism is a powerful chemical freezer, its main offensive capability. The soft and supple skin of the Hallucinoid seems susceptible to heat based attacks. Often this mutant is found in the company of its masters, the Aquatoids. <br clear="all" /><br />
{{Ref Close | source = Terror From The Deep Ufopaedia}}<br />
<br />
{{Infobox open}}<br />
{{Statbox module<br />
| name = Hallucinoid<br />
| time_units = 62 - 91<br />
| health = 120<br />
| energy = 90 - 133<br />
| reactions = 90 - 122<br />
| strength = 90 - 111<br />
| bravery = 100<br />
| firing_acc = 32 - 129<br />
| throwing_acc = 80<br />
| MC_skill = 0<br />
| MC_strength = 90 - 111<br />
| armour_front = 14 - 42<br />
| armour_left = 14 - 42<br />
| armour_right = 14 - 42<br />
| armour_back = 14 - 42<br />
| armour_under = 10 - 30<br />
}}<br />
{{Statbox module/hidden stats<br />
| melee_acc = 90 - 133<br />
| energy_recharge = 50<br />
| victory_points = 35<br />
| standing_height = ?<br />
| kneeling_height = ?<br />
| intelligence = 7<br />
| aggression = 2<br />
}}<br />
{{Statbox module/unique stats<br />
| armour_category = Hallucinoid<br />
| rank_types = Terrorist<br />
| unique_attributes = Melee Attack, Can "Fly"<br />
}}<br />
{{Infobox close}}<br />
<br />
The Hallucinoid is a large, "flying" alien jellyfish usually found in the company of Aquatoids underwater. It is fairly resilient, but is limited to physical melee attacks. Contrary to the Ufopaedia description, due to a game bug it does not normally have a ranged attack. (The bug can be fixed using 3rd party utilities).<br />
<br />
Since it is not particularly aggressive and has no means of harassing enemies at range, it is not an immediate threat to Aquanauts as long as they maintain their distance. However, if allowed to close to melee range, it can seriously damage or kill any Aquanaut.<br />
<br />
Hallucinoids' ability to change elevation allows them to pursue Aquanauts wearing [[Magnetic Ion Armor]]. However, their large size renders them unable to chase [[Aquanauts]] through narrow gaps or passages.<br />
<br />
The Hallucinoid appears in Terror From the Deep. Its closest approximation in UFO Enemy Unknown is the [[Reaper]].<br />
<br />
==Tactics==<br />
The Hallucinoid is not a very dangerous alien, as it has no ranged weaponry and is not amazingly fast or aggressive like the [[Tentaculat]]. It does, however, have a great deal of bulk between its immense health, wide array of resistances, and significant armour.<br />
<br />
Sonic weapons are effective for hunting Hallucinoids, as they aren't resisted and have enough power to punch through the armour. Thermal Shok Launchers are also very effective, though this may clog your [[Alien Containment]]. Explosives deal 4x damage due to Hallucinoids' large size, but their significant HE resistance and Under Armour mean that only very powerful explosives such as the [[Torpedo Launcher]] and [[Disrupter Pulse Launcher]] can really benefit from this. Gauss weapons do a decent job on lower difficulty settings, but on the higher difficulties Hallucinoids' armour is just too tough. Hallucinoids' ability to swim makes it difficult to use grenades against them, but the [[Magna-Pack Explosive]] and [[Sonic Pulser]] will deal massive damage if you can catch one on the ground. Finally, do not attempt to use [[Vibroblade]]s against Hallucinoids. Their high armour and resistance to melee damage make these drills ineffective. Stronger drills like the [[Heavy Thermic Lance]] have a better chance at armour penetration. Note that approaching a Hallucinoid to use a drill also puts the Aquanaut in its striking range. <br />
<br />
==Notes==<br />
The following are some miscellaneous notes on the Hallucinoid:<br />
* The Hallucinoid takes 0.6x damage from melee and armour piercing attacks, 0.7x damage from explosives, 0.8x from Gauss, but 1.7x damage from incendiary attacks.<br />
* It appears exclusively underwater.<br />
* Takes up 4 squares on the battlescape.<br />
<br />
==See Also==<br />
* [[Alien Life Forms (TFTD)|Alien Life Forms]]<br />
* [[Overviews_of_Aliens_(TFTD)|Overviews of Aliens]]<br />
* [[Terror_Units_(TFTD)|Terror Units]]<br />
* [[Calcinite]]<br />
* [[Aquatoid]]<br />
<br /><br />
{{Aliens (TFTD)}}<br />
<br />
[[Category:Alien Life Forms (TFTD)]]<br />
[[Category:TFTD]]</div>
Spike
https://www.ufopaedia.org/index.php?title=Air_Combat_(EU2012)&diff=67881
Air Combat (EU2012)
2015-10-03T19:25:58Z
<p>Spike: /* Dogfight Minigame */ added links to modules</p>
<hr />
<div>==Air Combat Mechanic==<br />
===UFO Detection===<br />
[[UFOs (EU2012)|UFOs]] can only be engaged after they are detected by [[Satellite (EU2012)|satellites]] and these will never detect UFOs on [[Alien Abductions (EU2012)|Abductions]] or [[Alien Terror (EU2012)|Terror]] missions.<br />
There can be two UFOs each month, with the second UFO having a 50% or 100% chance of being generated, depending on the number of missions - see [[Missions (EU2012)#UFOs|Missions (UFOs)]]. UFOs will be detected either flying or landed - see [[UFOs (EU2012)#UFO Missions|UFO Missions]] for details.<br />
<br />
===Dogfight Minigame===<br />
Once the Interceptor has been launched, you will watch it chase the UFO on the world map until it catches up, at which point you will enter the dogfight minigame interface.<br />
<br />
[[File:InterceptionEX.jpg|450px|thumb|right|A Raven intercepts an Alien Supply Barge UFO. The Raven has taken about 20% damage and has Aim and Dodge modules active, indicated by the highlighting.]]<br />
<br />
Key:<br />
# Time to loss of contact. If this reaches 0, the UFO will escape the Interceptor and will have to be re-engaged with another interceptor, if one is available.<br />
# The Interception craft.<br />
# The UFO. With practice you can learn to identify different UFO types in this interface.<br />
# Damage meter. When hit, this fills from the bottom. If this turns all red, the Interceptor is destroyed. You'll get a warning from the pilot at about 75% damage accumulated.<br />
# Abort Interception. Break off the interception and return to base. Useful if the Interception craft is getting pounded.<br />
# Engage [[UFO_Tracking_(Boost)_(EU2012)|UFO Tracking module]], if one is available. Freezes Loss of Contact clock for five seconds, and decreases approach time for close range weapons.<br />
# Engage [[Uplink_Targeting_(EU2012)|Uplink Targeting module]], if one is available. Guarantees next two attacks from Interceptor hit UFO.<br />
# Engage [[Defense_Matrix_(EU2012)|Defensive Matrix module]], if one is available. Allows Interceptor to dodge next two attacks from the UFO that would otherwise hit.<br />
<br />
===After Action Report===<br />
After the minigame ends, you will receive an Interception After Action Report. This will summarize the results of the interception. This is divided into three categories.<br />
<br />
*Result: This states whether the UFO escaped pursuit, was shot down, or the interception was aborted.<br />
*Crash: If the UFO was shot down, this will indicate that crew was seen moving at the crash site, allowing a Crash Recovery mission.<br />
*Interceptor: This indicates what happened to your interceptor. It can receive NO damage, LIGHT damage (1-33%), HEAVY damage (33-66%), SEVERE damage(66-99%) or have been shot down altogether.<br />
<br />
===Multiple Craft Interception===<br />
Unlike the original XCOM, you cannot use multiple craft to simultaneously attack a single UFO. Instead, multiple craft serve as sequential opportunities to shoot down the UFO, with each aircraft being deployed one after another to attack the UFO.<br />
<br />
If the 1st interceptor fails to shoot down the UFO, you can still launch more craft to try to shoot it down. However, after the 1st attempt the UFO will immediately try to escape and success in posterior attempts will depend on your craft and the UFO's speeds, their relative positions and the escape route chosen by the UFO. <br />
<br />
==Craft & Armaments Stats==<br />
<br />
{| class="wikitable" width="100%" <br />
|+ Craft Stats<br />
| align="center" style="background:#f0f0f0;"|'''Craft'''<br />
| align="center" style="background:#f0f0f0;"|'''Range'''<br />
| align="center" style="background:#f0f0f0;"|'''Size'''<br />
| align="center" style="background:#f0f0f0;"|'''Default Weapons'''<br />
| align="center" style="background:#f0f0f0;"|'''Speed'''<br />
| align="center" style="background:#f0f0f0;"|'''Engagement Speed'''<br />
| align="center" style="background:#f0f0f0;"|'''HP'''<br />
| align="center" style="background:#f0f0f0;"|'''Armor'''<br />
| align="center" style="background:#f0f0f0;"|'''Armor Penetration'''<br />
|- align="center"<br />
| Interceptor||25||Small||Avalanche||1500||10||2500||5||0<br />
|- align="center"<br />
| Skyranger <sup>1</sup>||25||Small||N/A||2000||10||8||0||0<br />
|- align="center"<br />
| Firestorm||25||Small||Avalanche||3500||20/20/15/15||6500||25||34/34/16/16<br />
|- align="center"<br />
| Small Scout||25||Small||UFO Plasma I||1500||20||800||0||7<br />
|- align="center"<br />
| Large Scout||25||Medium||UFO Plasma I||1800||22||1600||0/0/0/2||7<br />
|- align="center"<br />
| Abductor||25||Large||UFO Plasma II||2000||17||1800/1800/2200/200||5/5/10/13||3<br />
|- align="center"<br />
| Supply Barge||25||Large||UFO Plasma II||2500||25||2000/2000/2400/2400||16/16/30/36||4<br />
|- align="center"<br />
| Battleship||25||Very Large||UFO Fusion||3000||40||2400/2400/2900/2900||52/52/42/52||20<br />
|- align="center"<br />
| Overseer||25||Medium||UFO Plasma I<br>UFO Plasma II||3500||60||2500||64/64/45/52||25<br />
|-<br />
| colspan="9" | <sup>1</sup>Although the Skyranger isn't used for air combat, the game files have values for it.<br> Values in brackets display differences between difficulty levels (Easy/Normal/Classic/Impossible)<br>Source: XComStrategyGame.upk game file, XGItemTree class, [[XCOM: Enemy Within DLC (EU2012)|Enemy Within DLC]] version.<br />
|}<br />
<br />
{| class="wikitable" width="100%" <br />
|+ Armament Stats<br />
| align="center" style="background:#f0f0f0;"|'''Weapon'''<br />
| align="center" style="background:#f0f0f0;"|'''Range'''<br />
| align="center" style="background:#f0f0f0;"|'''Firing Time'''<br />
| align="center" style="background:#f0f0f0;"|'''Damage'''<br />
| align="center" style="background:#f0f0f0;"|'''Armor Pen'''<br />
| align="center" style="background:#f0f0f0;"|'''To Hit'''<br />
|- align="center"<br />
| Phoenix Cannon||85||1||350||11/11/6/6||95%<br />
|- align="center"<br />
| Avalanche||100||2||400||0||70%<br />
|- align="center"<br />
| Laser Cannon||85||0,75||400||25/25/25/28||85%<br />
|- align="center"<br />
| Plasma Cannon||100||1,25||800/800/700/700||48/48/33/33||85%<br />
|- align="center"<br />
| EMP Cannon||85||1,25||1200||44||100%<br />
|- align="center"<br />
| Fusion Lance||100||1,5||1400||44||90%<br />
|- align="center"<br />
| UFO Plasma I||101||1,25||300||0||75%<br />
|- align="center"<br />
| UFO Plasma II||101||1,25||400/400/400/500||20||75%<br />
|- align="center"<br />
| UFO Fusion||101||1,25||1200/1200/1250/1625||25||75%<br />
|-<br />
| colspan="6" | Values in brackets display differences between difficulty levels (Easy/Normal/Classic/Impossible)<br>Source: XComStrategyGame.upk game file, XGItemTree class, [[XCOM: Enemy Within DLC (EU2012)|Enemy Within DLC]] version.<br />
|}<br />
<br />
===Damage Formula===<br />
<br />
Damage from the shots is calculated according to the following formulas: <br />
<br />
0.05 * (Target Ship Armor - (Weapon AP + Firing Ship AP) = Final Mitigation (value clamped between 0 and 0.95)<br />
Target Ship Damage = Weapon Damage * (1 - Final Mitigation)<br />
<br />
===Damage Table===<br />
<br />
Matchups proven winnable without the use of modules:<br />
<br />
<div style="text-align: center;"><br />
{| class="wikitable" width="100%" style="text-align: center<br />
|- <br />
! width="10%" | Difficulty <br />
! width="22.5%" | Easy<br />
! width="22.5%" | Normal<br />
! width="22.5%" | Classic<br />
! width="22.5%" | Impossible<br />
|-<br />
|Scout<br />
|Interceptor w/Avalanche Missiles<br />
|Interceptor w/Avalanche Missiles<br />
|Interceptor w/Avalanche Missiles<br />
|Interceptor w/Avalanche Missiles<br />
|-<br />
|Large Scout<br />
|Interceptor w/Avalanche Missiles<br />
|Interceptor w/Avalanche Missiles<br />
|Interceptor w/Avalanche Missiles<br />
|Interceptor w/Avalanche Missiles<br />
(misses and timeout may require 2)<br />
|-<br />
|Abductor<br />
|Interceptor w/Avalanche Missiles<br />
|Interceptor w/Phoenix Cannon<br />
or Interceptor w/Avalanche Missiles x2 (x1 possible)<br />
|Interceptor w/Phoenix Cannon x2 (x1 possible)<br />
or Interceptor w/Avalanche Missiles x3 (x2 possible)<br />
|Interceptor w/Laser Cannon<br />
or Interceptor w/Phoenix Cannon x2<br />
|-<br />
|Supply Barge<br />
|Interceptor w/Phoenix Cannon <br />
|Interceptor w/Phoenix Cannon x2 (x1 possible)<br />
|Interceptor w/Laser Cannon<br />
|Interceptor w/Laser Cannon x2<br />
|-<br />
|Battleship<br />
|Interceptor w/Plasma Cannon<br />
|Interceptor w/Plasma Cannon x2 (x1 possible)<br />
|Firestorm w/Laser Cannon<br />
|Firestorm w/Plasma or EMP Cannon<br />
|-<br />
|Overseer UFO<br />
|Firestorm w/Laser Cannon<br />
|Firestorm w/Laser Cannon x2 (x1 possible)<br />
|Firestorm w/Laser Cannon x2<br />
|Firestorm w/EMP Cannon (1 w/Plasma Cannon possible)<br />
|}<br />
</div><br />
In Enemy Within, UFO "hit points" seem to be slightly higher in Classic, and significantly so in Impossible. The listed matchups are still possible, but for ''regular'' success against Impossible Abductors, Barges, and Battleships, a module (or luck) may be needed on top of these matchups, or another Interceptor to make up the difference. The Battleship's Fusion Lance seems more potent, as well.<br />
<br />
==Interception Tactics==<br />
===Time...===<br />
Note that it take 3 days to transfer either Interceptors, or to buy a Raven, 14 (or 7 days with [[Foundry (EU2012)#Advanced Construction|Advanced Construction]], a late-game Foundry project) to build a Firestorm, and 24 hours to equip either kind of Interceptor with any type of weapon. Weapons removed from an Interceptor immediately become available for installation on other Interceptors, and if you dismiss a ship, its weapon will be automatically returned to your inventory. A detected UFO (landed or in-flight) will remain on the map for about 6 hours before leaving, often spawning a [[Battleship (EU2012)|Battleship]] that is scanning to destroy your hard-earned satellite, if it is not subsequently intercepted itself (if a satellite is destroyed, that country immediately goes into full [[Panic (EU2012)|Panic]], and the whole continent's panic levels also rise). You can idle on the [[Mission Control (EU2012)|Mission Control]] screen at the speed of about 1 minute a second, if it comes down to the wire. Beyond the Battleship (which can destroy satellites), letting a UFO go only affects the monthly score (which itself does not affect game play), and gets you nagged at by [[Bradford (EU2012)|Central]], and possibly the [[The Council (EU2012)|Council]] representative during the Monthly Report.<br />
<br />
===...& Money===<br />
For cost's sake: only bother putting an Interceptor on a continent with at least one satellite on it, as otherwise it cannot be called to action, as you will not be able to detect any UFOs at all over it. North America's Cover Bonus (3 satellites needed, or setting your home base there) is '''Air and Space''': "All aircraft and aircraft weapons cost 50% less to purchase, build and maintain." Note that the basic maintenence cost is §20 for a Raven and §10 for a Firestorm: it may not be cost effective to splurge on Ravens in early months, particularly if you find yourself regularly hurting for credits. Thus, it's more efficient to have one or two well-equipped Ravens (ideally per continent) rather than the cost of maintaining (and possibly replacing) a bunch of Ravens with just Avalanche Missiles for your early months. If save-scumming, you may be able to get away with only building one or two of the latest Interceptor weapons, and slapping it on the appropriately located Interceptor (or moving just the one well-equipped Interceptor around), if there's enough time between a UFO appearance and a preceeding save state. Ravens cost §40 to buy (or §20 with the Bonus). Lastly, when constructing Firestorms: initial credit and resource cost is reduced by the number of Engineers and the aforementioned Cover Bonus, and if you have Workshop base facilities placed next to each other (Enemy Within: the Foundry and the MEC Lab included), you will get refunds of credits, alloys, and Elerium once the Firestorm is completed.<br />
<br />
===Practice===<br />
You begin all games with two Ravens at your home base equipped with Avalanche Missiles, and for the first and second month, this will be all you need, even on Impossible Difficulty: Scouts and Large Scouts will fall easily enough to one basic Raven. If the first satellite you put up (besides the one already up as your Home Base satellite) is on another continent, consider moving the second Raven to that continent's hangar the same day, so both will be ready on the same time (and do so about 4-5 days before the end of the month: if a country is covered ''before'' the end of the month, Abductions will no longer occur on it, making you potentially 'waste' the -3 Panic that placing a satellite gives).<br />
<br />
However, when [[Abductor (EU2012)|Abductor]] ships begin to appear...<br />
<br />
Keeping pace with Interceptor-related research is ideal, so that even if you don't have the resulting items on hand, that with enough time between a save state and the appearance of a larger UFO, you can buy and install a stronger weapon, and/or at least buy another Raven for that continent. If you have 2 or more Interceptors on one continent, then like earlier games, you ''can'' send them both after a single UFO - just not at the same time: the Interceptor you send out before the next has to either return to base, or be destroyed, before sending the next one. Besides a missed UFO summoning a Battleship, it is a rare -- but not unheard of - occurrence that two UFOs will appear over a continent within a few days of one another, and repair times are much kinder than in the 1994 game: though if you can afford it, two interceptors a continent is still good for peace of mind and for just-in-case.<br />
<br />
If you don't mind a bit of save-scumming when you need to send multiple Interceptors after one UFO: the runs aren't seeded, so you can reload/redo untill your ship has a good run (ie; the pilot doesn't decide to catch every plasma bolt with his face, while attempting to shoot with his ass clenching the yoke), and then save before sending out the next Interceptor.<br />
<br />
Worst case (but still winnable) scenario is having to wait 5 hours for weapon installations to be completed (ie: [[Phoenix Cannon (EU2012)|Phoenix Cannons]] on two Ravens), sending the first Interceptor to the larger UFO (Abductor) and letting it attack until it is destroyed, then sending the second right after it, which may or may not reach the UFO, depending on the completely random path the UFO takes (even if savescumming right before, a UFO doesn't take the same path, though it will always be over the same country: UFO appearances are pre-chosen at the start of each month). A reload may place it on a more favorable flight path for your Interceptors, if you find that the UFO escapes your window of oppertunity to attack it.<br />
<br />
Naturally, researching for a Firestorm is a priority (complete both the [[UFO Flight Computer (EU2012)|Alien Navigation Computer]] and the [[UFO Power Source (EU2012)|UFO Power Source]] projects, then the [[New Fighter Craft (EU2012)|New Fighter Craft]] research), and you should hoard recovered Flight Computers and Power Sources away from [[Grey Market (EU2012)|Grey Market]] sales or Council requests until you have at least 1 Firestorm for each continent. Don't forget that a Thin Man Interrogation gives a research credit to UFO Tech, and the Heavy Floater Interrogation gives another credit to Flight Research (though you easily can (and should) complete the Firestorm's research, and even get a few Firestorms out of Engineering, well before Heavy Floaters begin to show up).<br />
<br />
You need 2 Computers and 1 Power Source per Firestorm. You may also be more likely to have a surplus of the Computers than Power Sources, so you may risk selling them, especially if you reach, say, a 10 Computer/5 Power Source quota (or however many left to put a Firestorm on each continent)-- though depending on how you're doing on Panic, you might find it more worthwhile to hold off on getting another Firestorm, and put up a [[Satellite_Nexus_(EU2012)|Satellite Nexus]] instead. Note that Firestorms will always be built on your Home Base, so plus the Interceptor you should always have there, that means you can only build up to 3 at a time (or, spend up to two weeks without an Interceptor over your base's continent. Obviously, a bad idea), and that it is also another 3 days to transfer, and one more day to give it the latest weapon. <br />
<br />
The best way to get Firestorms out to each continent without gimping yourself at home is usually to first get [[Plasma Cannon (EU2012)|Plasma Cannons]]. Then, put two Ravens at your home base with Plasma Cannons and order two Firestorms. These two Plasma Cannon equipped Interceptors should be enough to bring down anything that comes your way while you wait for the Firestorms. Equip your first two Firestorms with whatever weapon suits your fancy (Plasma Cannons, [[EMP Cannon (EU2012)|EMP Cannons]] or [[Fusion Lance (EU2012)|Fusion Lances]]). Once they're ready, move the two Interceptors elsewhere, along with one of your new Firestorms, leaving your other one at home. Build three more Firestorms. Equip them and send them out. Provided you have enough materials, this can get you one Firestorm on each Continent with whatever weapon you so desire in 33 days:<br />
*Day 1: First two Firestorms are ordered.<br />
*Day 14: First two Firestorms are completed and equipping begins.<br />
*Day 15: First two Firestorms are equipped. Hanger is cleared, next three Firestorms enter production.<br />
*Day 18: Firestorm shipped off from home continent arrives, 2 continents covered.<br />
*Day 29: Second batch of Firestorms are built, begin equipping.<br />
*Day 30: Second batch of Firestorms are equipped and sent out.<br />
*Day 33: Second Batch of Firestorms arrive at destinations, all 5 continents are covered.<br />
<br />
Your weapons for Interceptors have to be researched and, as mentioned, it is good to at least research them in advance, so that you can buy them from [[Engineering (EU2012)|Engineering]] (while it's a 24 hour ''installation'', their ''construction'' is immediate) as needed (though, of course, if you can afford it, you should equip all craft with the latest available weapons ASAP). As stated, Avalanche Missiles are sufficient for [[Small Scout (EU2012)|Small Scouts]] and [[Large Scout (EU2012)|Large Scouts]]. The Phoenix Cannon is also good, though your interceptors may get battered closing the distance required. Once in range, the firing rate and accuracy tends to outweigh the risks of approaching. The Phoenix Cannon will generally add some peace of mind if you find yourself really stretched thin on Interceptors in the early parts of the game. <br />
<br />
If you manage to capture and interrogate a [[Muton (EU2012)|Muton]] during their first appearance (at earliest in the 3rd month-- or if Slingshot is activated: depending on Difficulty and if in Enemy Unknown or Enemy Within, possibly as early as the 1st or 2nd month), they give a research credit to Plasma Weapons, starting with the [[Light Plasma Rifle (EU2012)|Light Plasma Rifle]], then to the long-distance, medium-rate, high-damage Plasma Cannon, often 'sequence breaking' over the short-range [[Laser Cannon (EU2012)|Laser Cannon]], especially if you find yourself wanting for Plasma Weapons for most of your troops rather than Heavy Lasers for only the Heavy class (though, in Enemy Within, due to the larger reseach times required, the Laser Cannon does become the more realistic choice to proritize).<br />
<br />
The Plasma Cannon itself is a highly effective weapon that will quickly become your go-to weapon for your Interceptors and you wouldn't be harming yourself if you equipped every plane you had (Firestorm or Raven) with Plasma Cannons and called it a day. By about this time, you may be completing the research for the Firestorm, which leads to the ability to research the EMP Cannon, a must-have for recovering max amounts of alloys, computers, and Power Sources - though at the cost of leaving more aliens alive (note that, unlike earlier XCOM games, there is never any DOA/Instant Win occasions of a UFO Crash having no survivors, or exploding outright). Lastly, the Fusion Lance, used by alien Battleships, found only after destroying a Battleship (or with the [[Slingshot DLC (EU2012)|Slingshot DLC]]) and usable only by the Firestorm, is for making sure the UFOs die and stay dead. Not even a Battleship will be able to withstand a Fusion Lance.<br />
<br />
Modules are of moderate use, but can be helpful for your early-game dogfights. Their construction requires the corpses of [[Sectoid Corpse (EU2012)|Sectoids]] and [[Floater Corpse (EU2012)|Floaters]] (for Targeting and Defense, respectively), both of which tend to disappear late-game, and [[Cyberdisc Wreck (EU2012)|Cyberdisc wrecks]] for Tracking.<br />
*The [[Uplink Targeting (Aim) (EU2012)|Uplink Targeting]] module is of somewhat unpredictable use, as it guarantees the next two shots, which may or may not have hit anyways, possibly 'wasting' it. The Avalanche Missiles are the most inaccurate weapons by a large margin; while they would benefit the most from this module, you should be phasing the Missiles out at the earliest opportunity anyways. The higher accuracy of all other weapons reduces this module's usefulness fairly early into a campaign.<br />
*The [[Defense Matrix (Dodge) (EU2012)|Defense Matrix]] module guarantees that the UFO's next two shots miss: more useful in that it's more likely that you are to be hit than you are to miss, the ideal time to use this is when the next shot the aliens take is likely to destroy your Interceptor, particularly for a Battleship's slow Fusion Lance shots.<br />
*The [[UFO Tracking (Boost) (EU2012)|UFO Tracking]] module extends the time your Interceptor is allowed to actually fire on a UFO before being forced to return to base. It also shortens the approach time for your short-range weapons, so you can get firing sooner and (ideally) take less damage meantime. Not too useful if you keep up with research, and get Firestorms ASAP: only the [[Overseer (EU2012)|Overseer]] UFO and Battleships have a chance of outrunning/timing out a Firestorm, so one with a Plasma/EMP/Lance won't even need this.<br />
<br />
Speaking of which: the Overseer UFO, like the Alien Base Assault, is a one time [[Storyline (EU2012)|storyline]] mission, and you can (somewhat) dictate when it will appear (a few hours to a few weeks after completion of the [[Hyperwave Relay (EU2012)|Hyperwave Relay]] base facility). It is recommended to take it down with a Firestorm equipped with Plasma Cannons or better, as the UFO has both a small and a double-Plasma Cannon, and fires both of them with impunity. It does carry a large supply of Elerium (equal to a Barge), stored in two unique pairs of "Double Generators", so you may want to use EMP Cannons for the sake of this resource. You actually might not find modules to be of much use against this UFO: as said you shouldn't be using low-accuracy Avalanche Missiled against this craft, even with the Aim module, using short-range weapons is incredibly risky, so the Boost module may not be needed, and this UFO fires so rapidly, that the Dodge module will be used up in less than a second.<br />
<br />
Also, since all continents have their hangars in a roughly centralized location, and only South America has a small "surface area" for UFOs to be engaged in, you may find it hard to attack fast UFOs like the Overseer with Ravens alone: often they'll simply make your first Raven chase them for too long, to the point that a second Raven will not have time to intercept before the UFO flies out of range entirely (Case in point: the hangar whose Interceptors will have to cover all of Russia's airspace seems to be in Poland).<br />
<br />
The first UFO contact is always a Small Scout, and in the next month of April, you will begin to encounter Large Scouts, both of which should be easy prey for your starting 2 Ravens, even with the basic missiles (unless you're having a really unlucky day). Abductors will be the first UFOs you may have trouble with, starting in May. [[Supply Barge (EU2012)|Supply Barges]] tend to appear in June, and have a significant firepower increase over the smaller UFOs. Battleships are also on equal footing with a Firestorm equipped with Plasma, EMP, or Fusion weapons, but fortunately, don't appear randomly until very late game (more often in August than July), and a speed-run (or lucky) game may not see them at all: otherwise, you can allow a UFO to escape if you feel confident about attempting to take one down, for the sake of completion and resources and experience, as it attempts to destroy your [[satellite (EU2012)|satellite]] network (incidentally, UFO's that are an active risk for attacking your satellite will be noted by [[Bradford (EU2012)|Bradford]] to be having "a strange signal, like it's searching for something", and will be on the map with a scanning highlight (concentric rings)).<br />
<br />
===Perfect===<br />
The ideal endgame Interceptor situation is two Firestorms on each continent (or three if you want to feel redundant): one with a Fusion Lance, the other with either another Lance, or EMP cannons if you wish to farm UFOs (ie: more aliens to kill to level the Psi soldiers you've been buying with the money made on Grey Market sales from Computers, Sources, Elerium, and Alloys) (and the third with Plasma Cannons, because why not? Not like you can sell, say, those Phoenix Cannons you no longer need). With the strategy of sending the first Firestorm to soften the target (and abort ''before'' it gets destroyed), then sending the second to finish it off, even Battleship interceptions can become routine, without the use of modules, negating the need for the now-rare Floater and Sectoid corpses (incidentally: on Impossible Difficulty, Cyberdiscs also become rare in late-game months)(Enemy Within addendum: Sectoids will still be regularly fielded throughout a campaign as supports to Mechtoids). However, having 1 or 2 (depending on how many Firestorms you have) regular Interceptors with Plasma Cannons can add a safety net to your coverage. These can deal with smaller threats without risking your heavier hitters giving you some peace of mind for when XCOM decides to be XCOM and immediately throw a Battleship at you after you splashed a Small Scout.<br />
<br />
As a final note, never hesitate to abort an interception, especially if you have more planes waiting in the wings, your interceptor is equipped with something stronger than Avalanche Missiles or your interceptor is a Firestorm. As long as the UFO dies, you won't have a problem with the Council, even if it takes all 4 Interceptors, and only if you have extraordinarily bad luck will you get a second UFO over the same continent before any of your interceptors are back on their feet.<br />
<br />
==See Also==<br />
* [[UFOs (EU2012)|UFOs]]<br />
<br><br />
{{Craft Armaments (EU2012)}}<br />
<br />
[[Category: Enemy Unknown (2012)]]<br />
[[Category: Aircraft (EU2012)]]<br />
[[Category: Guides (EU2012)]]<br />
[[Category:Strategy Guide (EU2012)]]</div>
Spike
https://www.ufopaedia.org/index.php?title=Officer_Training_School_(EU2012)&diff=67877
Officer Training School (EU2012)
2015-10-02T15:48:52Z
<p>Spike: Renamed duplicate headings and reorganized earlier rough edit</p>
<hr />
<div>{{Ref Open | title = Description }}<br />
[[Image:OTC.jpg|right|200px|The Officer Training School]]<br />
Increase XCOM squad size, earn promotion bonuses, and unlock powerful combat medical techniques for your soldiers.<br />
{{Ref Close | source = XCOM: Enemy Unknown (2012)}}<br />
<br />
==General Notes==<br />
{{Facilities Data Box (EU2012)<br />
|requires=N/A<br />
|manpower=N/A<br />
|costs=§125<br />
|power=3<br />
|maintenance=§25 per month<br />
|build time=8 days<br />
|provides=see notes<br />
|adjacency=N/A<br />
|}}<br />
<br />
*The Officer Training School (OTS) is a facility in the [[HQ (EU2012)|XCOM base]], where you can buy 'tactics' that improve your [[Squads (EU2012)|squads]]. Some tactics require you to have a soldier reach a particular [[Soldiers (EU2012)#Ranks|rank]] in order to unlock it.<br />
*Your base starts without an OTS on Classic and Impossible [[Difficulty (EU2012)|difficulty]] levels. One of your Soldiers has to reach Sergeant rank to unlock the OTS for building.<br />
*The purchased improvements require the continued existence of the Officer Training School. So all purchased improvements will be disabled if the school was demolished. <br />
*The continent bonus '''Future Combat''' (earned by achieving satellite coverage over all 4 countries in Asia or choosing Asia for your headquarters location) reduces the cost of all OTS projects by 50%.<br />
<br />
<onlyinclude>{| class="wikitable sortable" width="100%" <br />
|+ [[OTS (EU2012)|OTS]] Abilities<br />
|- <br />
! width="20%" align="center" | Ability <br />
! width="5%" align="center" | Rank Required <br />
! width="5%" align="center" | Cost<br />
! width="75%" align="center" | Description <br />
|- style="vertical-align:top;"<br />
|- <br />
| align="center" |[[File:OTS WETWORK.png|32px|left]] '''Wet Work''' || align="center" | Sergeant || align="center" | §125 || align="center" | +25% experience gained from kills<br />
|-<br />
| align="center" |[[File:OTS SQUADSIZEI.png|32px|left]] '''Squad Size I''' || align="center" | Sergeant || align="center" | §50 || align="center" | Squad size increased to 5 soldiers<br />
|-<br />
| align="center" style="background: #F2F2F2" |[[File:OTS RAPIDRECOVERY.png|32px|left]] '''Rapid Recovery''' || align="center" style="background: #F2F2F2" | Lieutenant || align="center" style="background: #F2F2F2" | §150 || align="center" style="background: #F2F2F2" | Soldiers heal twice as fast from wounds taken in combat.<br />
|-<br />
| align="center" |[[File:OTS SQUADSIZEII.png|32px|left]] '''Squad Size II''' || align="center" | Captain || align="center" | §75 || align="center" | Squad size increased to 6 soldiers.<br />
|-<br />
| align="center" style="background: #F2F2F2" |[[File:OTS IRONWILL.png|32px|left]] '''Iron Will''' || align="center" style="background: #F2F2F2" | Major (EU)<br>Sergeant (EW)|| align="center" style="background: #F2F2F2" | §200 || align="center" style="background: #F2F2F2" | Soldiers receive a larger Will bonus each time they are promoted. <br />
(Adds between 2-6 extra Will increases per promotion on top of the default +2-6)<br />
|-<br />
| align="center" style="background: #F2F2F2" |[[File:OTS NEWGUY.png|32px|left]] '''New Guy''' || align="center" style="background: #F2F2F2" | Major || align="center" style="background: #F2F2F2"| §250 || align="center" style="background: #F2F2F2" | New soldiers are automatically promoted to the "Squaddie" rank.<br />
|-<br />
| align="center" |[[File:OTS DONTDIEONME.png|32px|left]] '''Don't Die On Me''' || align="center" | Colonel || align="center" | §275 || align="center" | The higher the rank, the more likely the soldier will be critically wounded instead of killed ''(Enemy Unknown Only)''<br />
|-<br />
| align="center" |[[File:OTS LEAD BY EXAMPLE (EU2012).png|32px|left]] '''Lead by Example''' || align="center" | Lieutenant || align="center" | §50 || align="center" | The Squad leader substitutes his or her Will for that of all nearby lower Will squadmates ''(Enemy Within Only)''<br />
|}</onlyinclude><br />
<br />
==Additional Notes==<br />
*Iron Will improves your Will boost for 2-6 points per promotion. Plus the [[Second Wave (EU2012)|Second Wave]] option '''Hidden Potential''', this means a will boost of up to 13 points: and with '''Not Created Equally''', your [[Psionic (EU2012)|Psi]] solders can easily surpass +100 Will scores.<br />
[[File:ABILITY LEAD BY EXAMPLE (EU2012).png|32px|right]]<br />
*On the [[XCOM: Enemy Within DLC (EU2012)|Enemy Within DLC]], the current squad leader will have the '''Lead By Example''' icon on its list of abilities during the pre-mission loadout. During the mission the icon will appear also on any soldiers benefiting from this ability, visible either on the list of abilities on the lower left corner of the main screen or through the F1 view. The radius is about 7 tiles.<br />
*Removing the facility causes all bought upgrades to cease functioning, but will be re-enabled when you re-build the OTS. Only do this as a last resort if you make a serious mistake, such as finding yourself 3.5 hours too late to build a Power Generator to get a Satellite Uplink up in the second month on Ironman. /headdesk<br />
*'''Lead By Example''' is great if a [[MEC Trooper (EU2012)|MEC Trooper]] with high Will is [[Squads (EU2012)#Squad Leader|squad leader]] as other soldiers will have their Will boosted to the MEC Trooper's Will plus bonus from suit, not just MEC Trooper's base will. Example: 90 Will (base) + 20 Will ([[MEC-3 Paladin (EU2012)|MEC-3 Paladin]] bonus) = 110 Will total will be boosted for other soldiers. Also, if other soldiers have +Will medals, they receive the boost (110) + whatever [[Medals (EU2012)|medals]] provide for total of (120 example).<br />
**After discovering some [[Psionic (EU2012)|Psi soldiers]], having your highest Will Psionic as the squad leader is amazing, especially with [[Mind Shield (EU2012)|Mind Shield]] & [[Psi Armor (EU2012)|Psi Armor]] as these stack and your Psi squad leader could easily lead a squad of 190+ Will soldiers. Hopefully you've been using the [[Gene Mods (EU2012)#Neural Feedback|Neural Feedback]] gene mod; as your soldiers will not only have a great chance of resisting Psi attacks with '''Lead By Example''' but '''Neural Feedback''' will easily kill Sectoid Commanders and those Ethereals won't know what hit 'em!<br />
*'''Wet Work''' is also great for MECs, since it partially negates the XP penalty they get for being a MEC (only 50% normal XP for kills.)<br />
<br />
==Trivia==<br />
The seven banners on the back wall of the facility start out with the [[XCOM (EU2012)|XCOM]] logo, and change to the symbol of each OTS ability as its researched, in the order that they're purchased. In the above picture for example, the player acquired, from first to last, Squad Size I, Wet Work, Squad Size II, Rapid Recovery, New Guy, Don't Die on Me and lastly, Iron Will.<br />
<br />
==See Also==<br />
{{Base Facilities (EU2012)}}<br />
<br />
{{StyleEU2012}}<br />
[[Category: Enemy Unknown (2012)]]<br />
[[Category: Base Facilities (EU2012)]]<br />
[[Category: Soldiers (EU2012)]]</div>
Spike
https://www.ufopaedia.org/index.php?title=Psionic_(EU2012)&diff=67794
Psionic (EU2012)
2015-09-29T17:21:30Z
<p>Spike: /* Tips & Trix */ Cleanup and added some more quirks and limitations</p>
<hr />
<div>[[File:PSIONICS (EU2012).png|thumb|480px|Psionic Squad]][[File: CLASS PSIONIC.png|right|frame|64px|Psionic]]A Psionic is a late game 'extra' <noinclude>[[Classes (EU2012)|class]]</noinclude><includeonly>class</includeonly> that appears once you tested your soldiers for psionic ability. Higher Will makes the more likely to have the gift. They can use their mental powers on the battlefield to panic/control enemy units or to create physical attacks. Psionic soldiers get access to their regular class abilities in addition to their psychic powers, allowing for some interesting combinations. A Psionic soldier will have a purple effect applied to their class identifier. <br />
<br />
The [[Psi Lab (EU2012)|Psi Lab]] is required to rest soldiers for psionic powers, and will only be available after conducting a Sectoid Commander [[Sectoid Commander Autopsy (EU2012)|autopsy]], or interrogating a Psionic alien, if the [[Second Wave (EU2012)|Second Wave]]'s '''More Than Human''' option is activated. <br />
<br />
On the [[XCOM: Enemy Within DLC (EU2012)|Enemy Within DLC]] [[MEC Trooper (EU2012)|MEC Troopers]] can't become Psionic soldiers. If the Second Wave's option '''Mind Hates Matter''' is enabled, it is not possible also to test [[Gene Mods (EU2012)|gene modded]] soldiers. <br />
<br />
==== Abilities ====<br />
{| class="wikitable" width="70%"<br />
|-<br />
! width="10%" align="center" | Rank <br />
! width="90%" align="center" colspan="2"| Ability<br />
|- align="center" <br />
! rowspan="1" | '''Psionic'''<br />
| colspan="2" | [[File:PSIONIC MINDFRAY.png|32px|center]]'''Mindfray''' <br/> '' Causes the target to lose grip on reality, inflicting penalties to Aim(-25), Will(-25), and Movement, and doing 5 base Damage. Robotic units are immune. Lasts 2 turns. 1 turn cooldown.''<br />
|- align="center"<br />
! rowspan="1" | '''Specialist'''<br />
| width="40%" | [[File:PSIONIC PSIINSPIRATION.png|32px|center]]'''Psi Inspiration''' <br/> ''Removes Mindfray and panic from all allies within 3 tiles, and strengthen their Will by +30 for 2 turns. 4 turn cooldown.''<br />
| width="40%" | [[File:PSIONIC PANIC.png|32px|center]]'''Psi Panic''' <br/> ''Cause target to panic on its following turn, if the target's Will is overcome. Robotic enemies are immune. 2 turn cooldown.''<br />
|- align="center"<br />
! rowspan="1" | '''Operative'''<br />
| width="40%" | [[File:PSIONIC TELEKINETICFIELD.png|32px|center]]'''Telekinetic Field''' <br/> ''Create an immobile telekinetic field that lasts through the enemy turn. The field distorts and deflects incoming attacks, granting +40 Defence.''<br />
| width="40%" | [[File:PSIONIC MINDCONTROL.png|32px|center]]'''Mind Control''' <br/> ''Very difficult psi technique that, if successful, grants control of the target for 3 turns. Robotic enemies are immune. 5 turn cooldown.''<br />
|- align="center"<br />
! rowspan="1" | '''The Volunteer'''<br />
| width="40%" colspan="2"| [[File:PSIONIC RIFT.png|32px|center]]'''Rift''' <br/>''Devastate an area with a storm of psi energy. The rift does more damage against targets with low Will, and reduced damage against targets with high Will. 4 turn cooldown.''<br />
<br />
|}<br />
<br />
==== Tips & Trix ====<br />
*Targeting<br />
** Psionics can only be used on an alien that can be seen by the psionic unit.<br />
** Generally the success probability is based on Will and ignores factors like cover and range. <br />
* Mindfray<br />
** Will penalty from '''Mindfray''' stacks with multiple application. Other effects does not stack.<br />
* Psi Panic<br />
** Contrary to the description, '''Psi Panic''' will cause the victim to panic immediately and then skip its next turn. This will often cause it to fire on you in your turn if it can see you.<br />
* Telekinetic Field<br />
** '''Telekinetic Field''' will be centered on the psi user that created it, so it should be given to soldiers that will be near the front line.<br />
** '''Telekinetic Field''' doesn't give defense to enemy units unlike smoke grenades.<br />
* Mind Control<br />
** A Mind Controlled unit cannot act on the turn it is controlled. <br />
** Mind Control will end at the beginning of your turn, usually giving you an opportunity to attack the previously Mind Controlled unit before it attacks or moves. <br />
** If you Mind Control a psionic alien, you will have access to making the alien use some (not all) of its psionic capabilities, including abilities that the XCOM psi operative does not possess. For example if you mind control an Ethereal, you can use its Rift ability, which normally is only available to the Volunteer. <br />
** Mind Control has no effect or limitation on the psi operative performing it. They can move and attack with weapons freely, that does not interrupt or end the Mind Control. <br />
** An alien under the effects of '''Mind Control''' is treated as one of your soldiers for pretty much all intents and purposes. You cannot target the unit with direct fire weapons. Surprisingly, your soldiers will take the Will penalty if he dies, as if a friendly unit had died. <br />
** Killing an MCed alien (such as with rockets or grenades) does not give Experience Points (XPs), however it does count to that soldier's list of kills.<br />
** Therefore you may want to damage the alien while it is MC'd (for example by making it fight other aliens, or dropping a grenade on itself as well as aliens), and then easily perform the kill when it is back under its own control. <br />
** However if it does die while being MC'd, the alien's equipment does '''not''' self-destruct (unless it's killed with explosives), allowing you to recover its equipment (usually a weapon and maybe a grenade) at the end of the mission, similar to if you had stunned it with an Arc Thrower.<br />
***(EW: An MCed [[Mechtoid (EU2012)|Mechtoid]] does not drop anything).<br />
** Surprisingly, a psionic alien unit that is performing a successful Mind Control cannot itself be Mind Controlled until its Mind Control has ended. Possibly the same applies to XCOM psi operatives?<br />
* Psi Inspiration<br />
** '''Psi Inspiration''' also affects the psi unit who uses it (this isn't clear in the description). This makes the ability very powerful for increasing the success rate of other abilities such as Mind Control, as well as improving defense when tackling psionic aliens. <br />
** '''Psi Inspiration''' does not stack with itself.<br />
** '''Psi Inspiration''' also removes the Fallen Comrade Will debuff. This is especially useful when using Mind Control.<br />
** '''Psi Inspiration''' does not stack with the new [[XCOM: Enemy Within DLC (EU2012)|Enemy Within DLC]] OTS perk [[Officer Training School (EU2012)|Lead By Example]]. Whichever provides the most Will will be chosen. [[Squads (EU2012)#Squad Leader|Squad Leader]] with 140 Will will override any soldier boosted by Psi Inspiration if less, otherwise will be given the Inspired bonus. Any soldier within range of Psi Inspiration will still receive bonus but it is not "tacked" on to Lead By Example, for clarification purposes.<br />
** However, it is extremely important to have your highest Will soldier as Squad Leader because if his Will is boosted, every nearby soldier regardless if they were Inspired or not, will receive the boosted Will. (Great way to get all nearby soldiers to nearly 200 Will! High Will Psi soldier with [[Psi Armor (EU2012)|Psi Armor]], [[Mind Shield (EU2012)|Mind Shield]], + Will [[Medals (EU2012)|medals]], Psi Inspired and Squad Leader will turn squads into [[Ethereal (EU2012)|Ethereal]] Death Squads.)<br />
** The Support's Combat Drugs includes a Will bonus, but this does '''not''' affect any Psi Abilites (ie: will not stack with Inspiration, or enhance MC/Panic/Mindfray probability).<br />
* Rift<br />
**Only one psi unit can become '''The [[Volunteer (EU2012)|Volunteer]]''', and this occurs when they use the alien device in the [[Gollop Chamber (EU2012)|Gollop Chamber]]. This unit gains the Rift ability, which is otherwise only possessed by Ethereals. <br />
** The '''Rift''' ability is a wide area-effect psi attack that can inflict massive damage, but has a long down-time. <br />
** '''Rift''' is the only Psi attack that can attack Robotic units, and, if the Volunteer is a [[Heavy (EU2012)|Heavy]], it does benefit from the HEAT ammo ability.<br />
*** Enemy Within: Mindfray benefits from HEAT ammo if used against Mechtoids.<br />
<noinclude><br />
<!-- everything below here not included on the classes summary page --><br />
<br />
==Testing for Psionics==<br />
After the [[Psionic Lab (EU2012)|Psi Lab]] is built it is possible to test up to three soldiers at a time to discover their Psionic potential. Testing takes 10 days for each soldier and the result is dependent upon the soldier's Will, rank and number of already existing Psionic soldiers. For the actual formula, see [[Psi Lab (EU2012)#Psi Chance|Psi Chance]].<br />
<br />
==Tactical Advice==<br />
Psionics are clearly an asset to any class. Shotgun [[Assault (EU2012)|Assaults]] can use psionics to engage at medium range when it's not possible for them to Run & Gun for a close range shot. [[Sniper (EU2012)|Snipers]] can use psionics as a weapon after moving. [[Heavy (EU2012)|Heavies]] can use psionics as a complement to their moderate aim at high levels. [[Support (EU2012)|Supports]] in a way gain the least from psionics, but their Deep Pockets ability allows them to carry a [[Mind Shield (EU2012)|Mind Shield]] without hampering their other functions greatly. This grants them psi defense and a higher offensive ability hit chance.<br />
<br />
===Abilities===<br />
'''Mind Fray'''<br />
<br />
All psionic soldiers have this as their first ability. The main advantage of Mind Fray over simply shooting a target is that (like all psi abilities) it ignores Defense and cover and targets the alien's Will, which unless it is a psionic enemy, [[Chryssalid (EU2012)|Chryssalid]] or [[Berserker (EU2012)|Berserker]] is often a much easier target. While the damage is low compared to end-game weapons, it is fixed and guaranteed if the attack hits, which makes it a nice way of killing an alien with 5 HP or less left.<br />
<br />
Mind Fray's Will reduction will make further psionic attacks easier, and is the easiest psionic attack to land. This means you can use it to soften up an alien for a Mind Control or Panic, or for a further Mind Fray by a lower ranked soldier. This is particularly useful when going for the '''Xavier''' [[Achievements (EU2012)|achievement]].<br />
<br />
<br />
'''Psi Inspiration''' vs '''Psi Panic'''<br />
<br />
'''Psi Panic''' causes the unit to panic immediately upon use and then skip the next turn. The main problem with this skill is that often the unit's panic action will be to take a shot at you, which isn't a massive improvement on what it would have done had you not panicked it. The unit will sometimes do something else like hunker down or run away. In any case, a successful psi panic prevents the use of any special abilities like grenades and will prevent the unit from moving to flank.<br />
<br />
Unlike Mind Fray, Psi Panic will not decloak a soldier using the [[Ghost Armor (EU2012)|Ghost Armor]]'s Ghost ability. The panicked alien will not attack the hidden psi user, but may attack other soldiers that it can immediately see. When used carefully, this can be a good way to disable key enemies for a turn. Unfortunately, aliens don't suffer from regular panic like you do, so you can't start a panic chain among the enemy by getting them to shoot each other.<br />
<br />
'''Psi Inspiration''' gives a +30 boost to Will for 2 turns and removes Mind Fray and Panic. The most important thing this ability does that isn't mentioned is remove the Fallen Comrade Will debuff. This is very useful when using Mind Control, because mind controlled aliens dying will cause this debuff and you'll want to get rid of it so it doesn't hamper your morale and psi abilities for the rest of the mission. The Will bonus will buff your soldiers' offensive psi ability hit chance and defense against enemy psi attacks, making it a useful ability to use before breaching a room. Psi Inspiration can be used to level up to the next psi level quickly, because it can be used on spare turns when not in combat. While Psi Inspiration is an area effect ability, it only reaches two tiles, so can be a pain to get many other soldiers without forming your [[Squads (EU2012)|squad]] into grenade bait formation. <br />
<br />
<br />
'''Telekinetic Field''' vs '''Mind Control'''<br />
<br />
'''Mind Control''' is easily the most powerful ability in the game in most encounters. While it's difficult-to-impossible to pull off against psionic enemies, they usually have non-psionic guards ([[Muton Elite (EU2012)|Muton Elites]] in particular) who can be controlled. The only major enemies it doesn't help against are [[Cyberdisc (EU2012)|Cyberdiscs]] and [[Sectopod (EU2012)|Sectopods]], though mind controlled aliens from a previous group will make for good cannon fodder for them. Mind Control is one of the hardest skills to pull of, and requires high Will to succeed. If your soldier has reasonably high Will, then this is the skill to take. <br />
<br />
Like Panic, Mind Control also does not decloak a soldier using the Ghost ability. This way only the mind controlled alien will be at risk of attacks from its allies. Additionally, MCing an alien in an inactive squad (i.e.: while in Ghost Mode) will not activate the remainder of the squad (or any others nearby) until your next action is taken. With Squad Sight, [[Sniper (EU2012)|Snipers]] can wipe out an entire alien squad at once.<br />
<br />
An alien or human who is ''psi-linked'' is not a valid target for mind control. A psi-linked unit is one who is using or is the target of Mind Merge or Mind Control. This means if an alien MCs a soldier, you cannot attempt to MC the soldier back, or attempt to MC the alien to break the link. Likewise, if you MC an [[Ethereal (EU2012)|Ethereal]]'s Muton Elite guard, the Ethereal will not be able to MC that soldier or the guard.<br />
<br />
You can keep track of how many turns are left of a controlled alien by the ability tile on the controlling soldier: if it reads '''T-3''', then the alien will be released at the start of the next Alien Action. Some aliens will immediately fire if your soldiers are in range, and be especially wary of any with grenades. However, you ''can'' 'force' their action-- or inaction: when the tile reads T-3, have the soon-to-be-free alien Hunker Down, and it will stay in that mode when released. As flanking ignores Hunker Down, and your soldier only needs to be a little away to be invisible to it, this is a safe way to either MC it again, or finish it off.<br />
<br />
When MCing an alien, you have access to all their abilities. If they are a grenade-wielding alien, making them use it (such as on other aliens or themselves) does take up their use for it, so they cannot grenade you afterwards if you elect to keep the alive a bit longer. You may not face against many Sectoids by the time you get MC (except for EW Mechtoid supporters), but they make decent scouts and canon fodder. Both varieties of Floaters make great flying scouts (land them on their last turn if you want to kill them afterwards), though the touchy nature of their Launch ability may restrict it's use for flanking/long-range moves. The Muton breeds and their high HP are good for taking up the other alien's attention: if you get a few of them under your control, and at least one a green-armored variety, Blood Call may be worth a use. Chryssalids are extremely difficult to MC, often requiring to Mind Fray them first to soften their will-- cutting their movement dramatically, reducing the payoff of the effort to MC them. The Mechtoid, having a living pilot, is an excellent MC target: their Sectoid/Commander supporters cannot do much damage to them with just Plasma Pistols, Psi-Linking to them keeps them from getting shields, Plasma Barrage acts like a Heavy's Bullet Swarm, and as a hardened mechanical out-of-cover unit, they can easily soak up the damage from any other nearby aliens. And the Sectoid Commanders and Ethereals are, naturally, very difficult to MC. As the Commander will be Psi-Linked, you cannot use it's Greater Mind Merge, and the Ethereal will often be the last alien you see (and only in a UFO Assault), reducing the point of attempting to MC them-- though it is fun to make them Rift themselves and any other remaining aliens.<br />
<br />
'''Telekinetic Field''' (TK) is essentially a psionic smoke grenade that is reusable after a 4 turn cooldown. It is always centered on the soldier creating it, rather than being placeable like a smoke grenade, but it makes up for this by being much larger. It also gives +40 defence like a dense smoke grenade. The main use for this ability is to protect your squad from the attacks of a Sectopod or Cyberdisc if you have to finish your turn under its guns. Telekinetic Field will not decloak a soldier using the Ghost ability. You may want to take this if your psionic has low Will.<br />
<br />
If you decide to have 4 troopers with TK field, and have them cast in turn, that means you can have a 'continuous' TK field for as long as you desire. Add Mindfrays, advanced armors' Defense bonus and a smoke grenade if things look dicey, and this can make you almost immune to hits in a straight-up firefight. Focusing this much on TK field comes at the cost of Mind Control though, and limits how far apart you can deploy your squad while benefiting from it.<br />
<br />
Telekinetic Field can be a good replacement for smoke grenades if you take ''Combat Drugs'' on your Supports, since this makes their smoke grenades no longer give a Defense bonus.<br />
<br />
===Chances of Psi attacks===<br />
Chance to land Mindfray/Psi panic is 50 + (your will) - (target's will) %.<br/><br />
Chance to land Mind control is 30% lower, 20 + (your will) - (target's will) %.<br/><br />
Psi armor and Mind shield gives bonus 20% and 30% (respectively) chance to all psi attacks, on top of will bonus.<br/><br />
On classic and Impossible difficulty, there is -10% and -20% (respectively) penalty to all psi attacks.<br/><br />
*Will boost from Combat drugs does not apply on psi attack.<br />
*Will bonus from medals does not apply on psi attack.<br />
*If you have 205 will with Psi armor and Mind shield, then you can MC an Ethereal with 100% chance on impossible difficulty.<br />
<br />
===Equipment===<br />
The requirements of your primary class will probably dominate your equipment choice. The only items of particular note for psionic soldiers are the [[Mind Shield (EU2012)|Mind Shield]] and [[Psi Armor (EU2012)|Psi Armor]]. The Mind Shield's description portrays it as a defensive item against hostile psionics, but the Will bonus it gives is equally useful for boosting your own psi ability hit rate. Psi Armor is an option for psionics that gives a Will bonus and all the effects that entails, but it's by no means automatic that Psi Armor is the best choice; Ghost and Titan have better defence and Ghost and Archangel have better mobility.<br />
<br />
When deciding on whether to use the Mind Shield or Psi Armor, look at the soldier's Will level and consider the sort of psi skills that your soldier will be using the most. A soldier mainly concentrating on buff skills for example will not need to use either, as these skills are not dependent on their Will level. A soldier specialising in Mind Control may want to take one or even both to get Will close to or beyond 100. Most combat oriented builds can get away without either and can use Mind Fray and Psi Panic to a good degree of success against most common enemies except the Berserkers and Ethereals.<br />
<br />
Again: note that Combat Drugs' (Support's skill) or Combat Stims' (item) boosts to Will do not add to Psi techniques.<br />
<br />
===Care and Feeding of Psionics===<br />
<br />
You want to avoid your potential (or already identified) psi troopers being Critically Wounded, since this gives a ''permanent'' reduction to Will.<br />
<br />
Once you've obtained the '''Iron Will''' [[OTS (EU2012)|OTS]] upgrade, you may want to replace your current crop of high ranking soldiers with new ones, since these new soldiers will end up with significantly higher will scores than soldiers that gained their ranks without Iron Will. Even if your original soldiers test positive, the higher will of your new ones will make them more powerful psionics.<br />
<br />
To maximise the will of your soldiers, save before the final shot of each mission (usually either a [[Sectoid Commander (EU2012)|Sectoid Commander]], an [[Ethereal (EU2012)|Ethereal]], or the last action of a [[Missions (EU2012)#Council Missions|Council Mission]]). This way, when you get back to base, if they didn't get the Will upgrade you'd like, you can reload and try again. If playing with the Second Wave '''Hidden Potential''' option this can also be done to maximize other stats.<br />
<br />
Whether a soldier will be gifted or not is decided when they are placed in the Psi-Lab, so with saving and loading you can make any soldier a guaranteed psionic by placing them in the lab, saving, fast forwarding 10 days (skipping missions) and seeing what the result is. If it's positive, reload and play normally, if negative, reload, pull them out and back in to the lab, save again and repeat. Again, a positive or negative result is dependent on when that soldier is ''entered'', so removing the soldier in slot 2 will not change the result of the soldiers already in slot 3 or 1.<br />
<br />
If playing on Iron Man (or are just unwilling to abuse saving and loading in this way) then after testing your current ranked soldiers, get the '''New Guy''' upgrade and recruit and test new squaddies of the class you want with high starting will as often as possible to identify psionics. If you are playing with the [[Second Wave (EU2012)|Second Wave]] option '''Not Created Equal''', then you will also want to pay attention to aim and move as well. Psi Snipers in particular will want to prioritize aim. While Will is a factor (higher ranked soldiers will have a better chance of testing positive), it is more economical to test masses of squaddies than to promote soldiers to higher ranks before testing and then discarding that effort if they test negative.<br />
<br />
If you are playing with the Second Wave '''More Than Human''' keep in mind that you'll most likely only have 1 or 2 Psionics available at all times during the game. Once your single Psionic is dead you'll have to find and train a new one so you may want to think first before sending him/her on a risky move.<br />
<br />
===[[XCOM: Enemy Within DLC (EU2012)|Enemy Within DLC]]===<br />
<br />
While there's no direct change to Psionics, several additions from EW indirectly help your Psi Squad to be downright lethal:<br />
* [[Foundry (EU2012)#Tactical Rigging|Tactical Rigging]] means one more item slot, such as for the Mind Shield (generic +30 Will), or Chitin Plating or a Respirator to make up in the deficiencies of [[Psi Armor (EU2012)|Psi Armor]].<br />
* The two [[Gene Mods (EU2012)|Gene Mods]] to your soldier's brain means either a significant defense boost, or an automatic counter-attack.<br />
* The Second Heart mod keeps you soldier alive from one 'lethal' hit a mission, and the resulting Critically Wounded status won't mean for a permanent Will reduction, either.<br />
* The Bone Marrow mod further helps keep your Psionic soldiers alive and fighting.<br />
* "Lead By Example" from the [[OTS (EU2012)|OTS]] means your Psi Squad Leader will be protecting and boosting the whole squad-- especially in the [[Storyline Missions (EU2012)#Temple Ship Assault|Temple Ship]], where he'll be required to wear the Psi Armor.<br />
* If the '''Mind Hates Matter''' Second Wave option is chosen Psionic soldiers can't have Gene Mods, and already genetically modified soldiers can't be tested in the [[Psi Lab (EU2012)|Psi Lab]].<br />
* The alien AI programming has been slightly modified in reaction to Mind Controlled aliens: in EU, as MCed aliens would usually be flanked, in the open, or closest nearby, they would be targeted first by hostile aliens. In an alien squad of 3, that usually means only 1 of them would strike at your troops. In Enemy Within, this is no longer the case: aliens will prioritize attacking soldiers directly. This is most evident in MCing an Ethereal's Muton Elite guard, in which instead of distracting the Ethereal for a turn by it killing the Muton with a Psi Lance, the Ethereal's first action will almost always be to attempt to MC any nearby XCOM soldiers.<br />
<br />
===Leveling===<br />
<br />
As Psionics is a subclass, a newbie psionic can be a Rookie or a Colonel. Psionic leveling is rather quick, and dependent on successful Psionic actions. Basically, just make a lot of successful Mindfrays. And once you get the next level (Inspire or Panic), use that one a lot, too (if with Inspire, level faster by Inspiring multiple other soldiers in the same turn.<br />
<br />
As for starting a newbie Psionic ''as'' a Rookie/Squaddie or a Colonel: while hits made with Mindfray and Panic (and supporting with Inspire) level Psionic abilities, ''kills'' made with Mindfray still count as EXP for leveling Soldier Rank, and an additional 'weapon' technique for a new recruit (whom may have low aim) that always hits does wonders for faster leveling (kills made ''with'' an MCed alien, or an MCed alien getting killed, do not grant EXP). Meanwhile, an experienced soldier's higher Will means that a Psionic attack is less likely to fail. If you have a backlog of high-stat recruits for Psi Testing, you may consider sending the choice soldiers into battle in the meanwhile, so at least they level some amount, reducing the odds of failed Mindfrays--- or remove all worry by giving them Psi Equipment: note that any soldier can equip Mind Shields, but only those that have already tested positive for Psi Potential can equip the Psi Armor.<br />
<br />
Council Missions, which are almost always only [[Thin Man (EU2012)|Thin Men]], are excellent missions to train new Psi soldiers on: on all but Impossible [[Difficulty (EU2012)|difficulty]], Mindfraying a Thin Man is a 1-hit kill.<br />
<br />
==See Also==<br />
{{XCOM Units (EU2012)}}<br />
<br />
[[Category: Enemy Unknown (2012)]]<br />
[[Category: Soldiers (EU2012)]]<br />
</noinclude></div>
Spike
https://www.ufopaedia.org/index.php?title=Arc_Thrower_(EU2012)&diff=67786
Arc Thrower (EU2012)
2015-09-29T16:33:03Z
<p>Spike: /* Tactics */ Arc thrower not usable on friendlies.</p>
<hr />
<div>{{Ref Open | title =Project Spark Results }}[[Image:Arc Thrower Research (EU2012).png|right|100px|Arc Thrower Research]]<br />
We've completed our research into the Arc Thrower prototype and we believe this device is ready for final production in Engineering. The mechanism functions on the basic premise of neurological disruption, emitting a focused electromagnetic pulse capable of confusing and incapacitating targets within a limited range. As this is our first venture into the field of non-lethal weapons based on the alien physiology, it's safe to assume there may be unexpected results in the field. It's very likely that some aliens will resist the disabling effects of the weapon, in which case it might be more effective to weaken the enemy first. The Arc Thrower is also constrained by our current power supply technology, which limits its effectiveness to two shots per deployment. Any captives retrieved from the field will have to be housed in an [[Alien Containment (EU2012)|Alien Containment]] facility; I strongly advise we build that facility before attempting to capture live specimens.<br />
{{Ref Close | source = XCOM: Enemy Unknown (2012) [[Research (EU2012)|Research]] Archives}}<br />
<br><br />
{{Ref Open | title = Description}}[[Image:Arc Thrower (EU2012).png|right|100px|Arc Thrower]]<br />
The Arc Thrower is a non-lethal sidearm designed to stun hostile targets. The mechanism seems to be most effective against weakened enemies.<br />
*A nonlethal weapon that can stun enemies<br />
*The chance of a successful stun is much greater if the target has low health<br />
*Does not affect robotic enemies<br />
*Advanced versions have a better chance to stun, can heal friendly SHIVs, and take control of certain enemies<br />
{{Ref Close | source = XCOM: Enemy Unknown (2012) }} <br />
<br />
==Notes==<br />
{{Item Data Box (EU2012)<br />
|requires=[[Xeno-Biology (EU2012)| Xeno-Biology]]<br />
|costs=§35<br>5 Engineers<br />
|abilities/stats=Stun<br />
}}<br />
<br />
"''I trust you have '''tested''' this thing...''" - [[Shaojie Zhang (EU2012)|Shaojie Zhang]]<br />
<br />
The Arc Thrower will be one of your first plot-centric fabrications; and like the various stun devices in previous iterations of XCOM, it may actually be the most important weapon in your arsenal against the alien invaders. Not also is it needed to move the story along, but the weapon drops from captures, and the results from interrogations will vastly expand the potency of XCOM. Off-the-shelf, it costs a maximum of 35 credits (the first handful of Engineers you receive will easily drop it to the mid-low 20s), and holds a charge for two stun attempts, but even then only if the target has 4 or fewer health remaining (49/70/80/90% on 4/3/2/1hp). Its main drawback is an extremely limited range, barely safer than the old touch-range [[Stun_Rod|Stun Rod]], that usually extends to 3 squares from the target alien.<br />
<br />
* '''[[Foundry (EU2012)|Foundry]] Upgrades''':<br />
** '''Improved Arc Thrower''': increases effectiveness to enemies with up to to 7hp (49/70/80/90% on 7/6/5/4hp and 95% chance on 3hp or lower).<br />
*** Requires: Elerium research, 4 Drone Wrecks, 20 Weapon Fragments, 10 Engineers.<br />
** '''Drone Hack''': Take control of an enemy [[Drone (EU2012)|Drone]] for combat (similar to Mind Control).<br />
*** Requires: Drone Autopsy, 4 Drone Wrecks, 20 Weapon Fragments, 10 Engineers.<br />
** '''Repair SHIVs''': Allows Arc Thrower to repair friendly [[S.H.I.V. (EU2012)|S.H.I.V.s]] or captured Drones, 6 HPs repaired for each use. On the Enemy Within DLC it can also be used to repair [[MEC Trooper (EU2012)|MEC Trooper]]s.<br />
*** Requires: EMP Canon Research, 10 Engineers.<br />
** Stun, Drone Hack, and Repair SHIV have separate commands from each other, but the Arc Thrower only holds two charges total: So it's two total of any combination of Stun, Hack, '''or''' Repair.<br />
<br />
==Tactics==<br />
* You'll need to get the target down to low HP in order to have any chance of capture (the lower the better). This can be quite challenging itself given the random damage of weapons - a "lucky" damage roll could kill a target you're preparing to capture.<br />
** Pistols are good for whittling away a target's HP. They have a base crit chance of 0, so provided you're not flanking the target you should do reliably low damage.<br />
** Alternatively, grenades and rockets do a fixed, reliable amount of damage.<br />
* Given the close range, a [[Support (EU2012)|Support]] class soldier with '''Sprinter''' is a fairly good candidate for packing the Arc Thrower. <br />
** The [[Support_(EU2012)|Support]]'s '''Deep Pockets''' ability does not allow him/her to carry another Arc Thrower...<br />
** But in the Enemy Within DLC, the ability has been changed to allow for an extra use, for a total of 3 charges (Tactical Rigging still doesn't allow for a second Thrower to be carried, though).<br />
* Alternatively, an [[Assault (EU2012)|Assault]] class soldier with '''Lightning Reflexes''' is another good candidate for the Arc Thrower as they can avoid the first [[Overwatch (EU2012)|overwatch]] shot of the target.<br />
* To ensure you don't lose soldiers because of a failed stun attempt, try stunning the alien using at least two people in one turn or have another soldier with a clear line of sight that can take out the target if the attempt fails. <br />
* Note that the Arc Thrower does not affect [[Chryssalid (EU2012)|Chryssalids]], [[Zombie (EU2012)|Zombies]], [[Cyberdisc (EU2012)|Cyberdiscs]], [[Sectopod (EU2012)|Sectopods]], [[Seeker (EU2012)|Seekers]] or [[Mechtoid (EU2012)|Mechtoids]], so you do not have to capture them to gain all the research topics. Also, [[EXALT Units (EU2012)|EXALT soldiers]] would rather [[Achievements (EU2012)#Enemy Within DLC|commit suicide]] than be captured alive!<br />
* Also note that the Arc Thrower cannot be used on civilians, nor on your own soldiers, including if they are Panicked and even if they are Mind Controlled by the aliens. If you want to avoid killing a Mind Controlled soldier you will just have to run away and take cover until the alien Mind Control wears off. (Presumably also can't be used on aliens while the aliens are being Mind Controlled by XCOM?)<br />
* If you have a [[Sniper (EU2012)|Sniper]] with the '''Disabling Shot''' skill, you can make the stun much safer on the approach, and should the stun attempt fail the enemy will be unable to return fire on their next turn.<br />
* Enemies, particularly lone ones, will tend to retreat continually when approached. Overwatching will usually keep them in place, since the AI is very reluctant to move when it knows it would provoke an overwatch shot.<br />
* Use of [[Suppression (EU2012)|Suppression]] fire is a good way to keep an enemy immobile and limit its ability to shoot while your Arc Thrower soldier approaches. Note that suppressing a target disables its overwatch fire.<br />
** An Alloy S.H.I.V with S.H.I.V Suppression makes a particularly good support unit for a stunner, as it can suppress and give the stunner cover exactly where they need it for an optimal approach.<br />
* In vanilla Enemy Unknown, there is an AI glitch for aliens: if they see two or more in-cover soldiers, at least one is flanking them, and they see either one go into overwatch, their AI locks up and they'll skip their next action. This is an excellent method to close in for a stun.<br />
** This is fixed in Enemy Within: aliens and EXALT agents will most often move and risk overwatch fire rather than leave themselves exposed to flanking shots.<br />
* The weapons of aliens taken down with the Arc Thrower will not shatter into fragments. Instead, the weapon is recovered in working condition and will appear in the [[HQ (EU2012)|XCOM base]] inventory (although it still needs to be researched the before soldiers can use it).<br />
* Repair SHIV and Drone Hack have more range than the stun function.<br />
* For any applicable targets (alien, Drone (hacked or not), or S.H.I.V.) where any Arc Thrower action is available, a range of use is shown as a blue ring with lightning bolt symbols, centered on the target. There is some leeway in differences in altitude, but the distance range for if a soldier might not make it entirely in the circle, is if the dot at the end of a soldier's movement line (in the center of the square you'll be moving your soldier to) is within the circle. Be sure to change the camera angle, as the line is directly on the floor, while the circle hovers a few feet off the ground: perspective may not make it clear if a soldier will be in range in 1 move.<br />
** A soldier can usually stun at a maximum of 2 squares between him/her and the alien. <br />
* The Arc Thrower's chance of success is not a normal hit roll, so is not affected by wounds, high ground, Holo-Targeting or anything else that normally affects aim.<br />
* Stunning a mind-merging Sectoid does not kill or stun the mind-merged unit, the latter only loses its buff.<br />
<br />
==See Also==<br />
{{Equipment (EU2012)}}<br />
{{Research (EU2012)}}<br />
<br />
[[Category: Enemy Unknown (2012)]]<br />
[[Category: Equipment (EU2012)]]<br />
[[Category: Research (EU2012)]]</div>
Spike
https://www.ufopaedia.org/index.php?title=UFOextender&diff=58930
UFOextender
2014-08-17T17:43:52Z
<p>Spike: /* Mods */ fixed link to Limited Military</p>
<hr />
<div>This is the loader for Enemy Unknown, created by [[user:seb76|Seb76]] and now being developed by [[User:Morgan525|Tycho]], which adds fixes, more features, and improvements to the Collector's Edition (a.k.a. CE or Gold Edition) of the game. It is fully customizable: One can play a "pure vanilla" game with only the video fixes enabled or with as many of the modifications as you want. Everything can be enabled or disabled in the loader's INI file. <br />
[[File:X-com1994cover.jpg|480px|right|]]<br />
== General Information ==<br />
<br />
The loader patches the program in memory, it does '''not''' modify the executable. The advantage is that it doesn't change the file on disk so there is little risk of destroying your game installation (still, it is wise to do a backup of your game folder before using this). <br />
Of course, if your computer starts pestering you to play "Global Thermonuclear War", I don't take any responsibility...<br />
<br />
This program only works with the Windows version '''and will not work through DOSbox'''. There will not be a DOS-compatible version.<br />
<br />
Do not hesitate to report any problem you encounter with it, I'll try to help you fix it.--[[User:Morgan525|Tycho]]<br />
<br />
===Installation===<br />
<br />
*You need a program that can extract zip files.<br />
*You need the Microsoft VC++2008 redistributable package to run this program. If you don't already have it installed, you can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here].<br />
*Download the appropriate version and/or patches. [[Image:UFOLoader.zip ]]<br />
*Extract these files into the game folder containing the UFO Defense.exe (or whatever the windows version of Enemy Unknown executable is on your machine.)<br />
*Using a simple text editor (like Windows notepad), open the '''UFOextender.INI''' file and enable the options you wish to use. <br />
**For most options, you enable it by changing the value from zero to one. Some options do have more settings. Refer to this page or the README file for more information on each one.<br />
**The extender looks for the file ''UFO Defense.exe'' but this can be changed under the [Loader] section.<br />
**You may have to leave certain options disabled if you intend to run the extender with other mod programs.<br />
*For enhanced music, you will need to create a folder called MP3 in the same folder as your UFO Defense executable. Copy the music files to this folder.<br />
*Run ''UFOloader.exe'' instead of UFO Defense.exe.<br />
<br />
: ''Note : Prior to version 1.30, if you wished to use enhanced music, you needed to have Window Media Player installed.''<br />
<br />
=== FAQs ===<br />
*Does it fix the difficulty bug?<br />
::The infamous difficulty bug only applies to the DOS version of the game. It was never an issue with the Windows version.<br />
*MP3 music crashes the game or doesn't work<br />
:'''Starting with version 1.30, the Extender plays enhanced music utilizing the BASS audio library and sound system[http://www.un4seen.com]'''.<br />
::Prior to version 1.30, the loader used basic calls to the MCI control layer to play enhanced music through the OS. Other video or sound programs may load codecs that can interfere with the playback resulting in no music or it will cause the MCI layer to generate an error which will force the game to exit. Some people have experienced this after upgrading their OS even though no other changes were made and music played prior to the upgrade. ''Someone has developed a good method to help isolate and maybe resolve these conflicts. See [[TFTDextender#FAQs| TFTDextender FAQs]]. Otherwise, the only solution is to uninstall whatever audio/video programs you have loaded to determine the source and solution to the problem.''<br />
* Can I change the music/SFX volume || The music is louder than the DOS version.<br />
::The problem here is that the game only selects the effect/music to be played and then dumps it to the OS sound mixer. There is no capacity to adjust in-game volumes, which is why the windows version uses MIDI for music since Windows OS prior to Vista had seperate volume controls for WAV and MIDI. In game volume cannot be simply added because the game creates secondary sound buffers for each effect in order to speed up playback. The specifications used to create these buffers does not allow individual volume control so a new sound buffer creation routine is necessary first.<br />
*"X-COM crashed at 0x45E6A5 with error ..."<br />
::Usually this occurs when playing with a mod program that splits the executable in order to run. A part that gets altered during the split conflicts with the Extender's option to "skip the intro". Disabling this option in the Extender will stop the error.<br />
*"X-COM crashed at 0x7------- with error ..." (when quiting the game or starting combat)<br />
:This will occur after the player has viewed one of the aircraft pages in the in-game Ufopaedia. The game uses the memory range for the file TAC00.SCR to load the ufopaedia graphic images (probably to conserve memory usage. [This was originally a DOS game after all]) However, the graphics files for the aircraft are 6 bytes larger than TAC00.SCR. I expanded TAC00.SCR by several bytes to compensate. [[:file:TAC00.zip|Download it here.]] Extract the file into the UFOGRAPH folder and overwrite the current one.<br />
*The zip only contains a single file called ''patcher.dll''. Where is the rest of the loader?<br />
::The minor versions (aka patches) only include an update to this file. For the other files you need to download the most recent major version. If you look at the page for the zip file, you will see a link to the most current release at the top of the page, information on the release, and then beneath that you will see a table that has links to all the previous releases, with the version number listed in the comments field. This is intentional so patches can be downloaded and installed easily without fear of overwriting a custom INI file by mistake.<br />
*Using Extender in Steam (seamlessly) [aka attempting to run Extender directly from the Steam interface]<br />
::I suggest seeking help on the Steam forums. For most digital downloads, the Windows version can be run independently and that is the only method for which I am able to help. You might also try [[XcomUtil#XcomUtil_.2B_UFO_Extender| the UFOpaedia XCOMutil page]] where some information is available.<br />
*I don't recover clips in missions. // I am losing ammo in every mission.<br />
:: This usually occurs with people playing Extender and XcomUtil. Each has a different way to fix the partial-clips-lost issue and are incompatible.<br />
*The text in the mission debriefing that is associated with the 'Wreck Analysis' mod is incomprehensible.<br />
:: An altered version of the ENGLISH.DAT file that came with version 1.23 and 1.24 has an error. Restoring this file to its original should fix the issue.<br />
*My anti-virus software reports that the Extender is a trojan.<br />
:: Anti-virus companies are extremely sensitive to malicious software which means that software from private individuals can be falsely reported as a problem and be removed or quarantined. When it has done this in error, you'll need to navigate to the settings of your software, restore the extender from the restricted list and/or add an exception for the extender in your anti-virus settings. The terminology and methods for each AV software are different so please consult the AV's help section.<br />
<br />
=== Some Disclaimers===<br />
:'''Extender and XcomUtil''': When Seb76 stopped development on the Extender, both programs were fairly compatible. Since the Extender has been developed further but XcomUtil has not, there are more areas of incompatibility now. If errors arise, it is advised to try to recreate those issues without using XcomUtil before reporting them. Even splitting the executable, as is done by XComUtil, has caused problems.<br />
:'''Extender and other modified game executables''': [such as ET_2005] These may work together but there is no guarentees. ET_2005 heavily modifies the binary and trying to patch on top of it will produce unexpected data corruption or crash the game. <br />
:'''DAT file mod requests''': DAT files modifications are not done because there are already lots of them and various data editors available to do them for yourself. This rule allows all data mods to keep working with the loader (that is why some xcomutil features should still work, as long as they are those only based on resource modifications). ''Any bug fix that requires a change to some resource data in order to compensate for the fix, will have an option to exclude the data change so that any player changes will not be overwritten.''<br />
<br />
=== Version 1.32 ===<br />
Several important changes were made with this version. The amount of changes that were required in order to offer balance in the game has made compatibility with XcomUtil extremely difficult. This version will not work with any program that requires the executable to be split.<br />
<br />
Version 1.32 is different as it focuses on correcting many of the imbalanced aspects of the strategic layer, in a logical manner by comparing each to other elements in the game. (UFO plasmas have standard ranges and power. The human plasma cannon is stronger with better range than the smaller UFOs' but not as good as the larger UFOs'. The laser cannon is twice as powerful as the cannon, with the plasma cannon being 3x more powerful than the craft cannon.) <br />
In previous versions, each bug fix and mod could be independently enabled or disabled by the player. In version 1.32, this is changed so that most bug fixes <s>and some mods</s> are enabled/disabled as one. <br />
However, many elements that change game play in the strategic layer are active at higher difficulty levels. This is done to preserve the many game balancing features. <br />
<br />
The bug fix section only has an 'apply=' option to enable {1} or disable {0} all older bug fixes. New fixes are provided to be individually enabled/disabled to isolate any errors that may occur. <br />
<s>A new section 'Enhanced Game' has a similar option to enable or disable a collection of modifications.</s><br />
<br />
Here is a breakdown of which features of the Extender are active at each level of difficulty:<br />
<br />
<u>beginner</u><br />
*Alien unit hp and stats reduced in combat. (vanilla game setting)<br />
*Retaliation ships vary depending upon game time.<br />
<br />
<u>experienced</u><br />
*Alien units have full stats in combat. (vanilla game setting)<br />
<br />
<u>Veteran</u> <br />
*Craft/UFO data and craft/UFO weapons stats balanced. [moved with 1.32.2]<br />
*Economic model balanced better. ''Values may need to be tweaked depending on playtesting and feedback.'' [moved with 1.32.2]<br />
*The selling price of alien items drops as nations sign pacts.<br />
*Score for civilians higher in Terror missions. [moved with 1.32.2]<br />
*Soldier can only MC one unit per turn.<br />
*UFOs take more damage before crashing.<br />
*Alien Base daily penalty increases the longer the base is active.<br />
*Zombies will hatch into chryssalids after several turns if fire not used against them.<br />
*Alien AI in interceptions.<br />
*Random elerium recovered per ball.<br />
*Battleships bomb the access lift if when attacking an X-COM base. [moved with 1.32.2]<br />
{1.32.8}<br />
*More alien missions at game start. Amount increase with difficulty level.<br />
*Changes to the mission routines to make harvester and abductor UFOs appear more frequently.<br />
*Alien leaders will only appear on "capital" ships and commanders will only be in bases.<br />
*Only alien soldiers and terror units are present in terror missions.<br />
<br />
<u>Genius</u><br />
*No hold on Terror Site expiration timer due to inbound dropship.<br />
*Battleships can perform terror missions.<br />
*Alien will use base busters after failed attempts to assualt an X-COM base.<br />
*Game ends if too many nations sign pacts.<br />
*UFOs take more damage to crash than previous level.<br />
*The effect of nations signing pacts on prices for alien items is higher.<br />
*Alien ships attack base defenses.<br />
*A Missile Defense will spend money when attacking // A Fusion ball defense requires 4 <s>blaster bombs</s> {1.32.8} fusion bombs in base stores to activate.<br />
*Game will not end due to two consecutive months of extremely low scores but rather from getting high scores. The threshold value is determined by game difficulty. {1.32.8}<br />
<br />
<u>Superhuman</u><br />
*Aliens use base busters quicker.<br />
*UFOs take even more damage to crash.<br />
*Aliens will conduct more terror missions as game progresses.<br />
*Average amount of elerium recovered is lower.<br />
*The effect of nations signing pacts on prices is severe.<br />
*<s>A Fusion Ball defense requires 6 blaster bombs in base stores to activate.</s> {1.32.8}<br />
<br />
<u>Interception stances</u><br />
*Standoff: No changes from vanilla.<br />
*Cautious: Aircraft closes to longest weapon range. {"True Cautious Mode enabled: With two similar weapons only one will fire until ammo is depleted before attacking with the second weapon. Cannon/beam weapons fire slower. Imparts a -15% to UFO accuracy.}<br />
*Standard: Aircraft will close to weapon range for both weapons and both similar weapons will fire. Cannon/beam weapons fire at a standard rate. <br />
*Aggressive: Aircraft move as close a possible to the UFO. Cannon/beam weapons fire faster. UFOs receive a 10% bonus to hit.<br />
*Abort: When alien interception AI is active, aircraft that are slower than UFO cannot automatically escape unless another craft is intercepting (or UFO gives up.) Imparts a -30% to UFO accuracy.<br />
:''Missiles fire rates are the same in all stances.''<br />
<br />
==Extender INI references==<br />
<br />
===Video===<br />
<br />
* '''Video Pitch''': fixes garbled video output due to pitch error similar to f0dder's loader.<br />
* '''D3D''': replace DirectDraw calls to Direct3D9. It sets the monitor to its default resolution and uses D3D to stretch the image on screen. It may also fix the speed issues if your video driver is configured properly. <br />
* '''HQ4x''': raise the resolution of the game and apply some filtering. It is quite CPU intensive though...<br />
* '''Linear Filter''': Enables bilinear filtering. Set to 2 to prescale the game (makes game less blurry in full screen mode).<br />
* '''D3D Fullscreen Width''': Set the width (pixels) for fullscreen.<br />
* '''D3D Fullscreen Height''': Set the height (pixels) for fullscreen.<br />
* '''D3D Windowed''': run the game in a window.<br />
* '''D3D Window Position''': set the initial position of the window in X Y cooordinates. <br />
:=0 0 will have the windows placed in the upper right corner of your display.<br />
:''These numbers will be updated automatically if the window is moved later.''<br />
* '''D3D Window Width''': set the width (pixels) of the game window. ''This is the actual playable area. Borders will add extra pixels to the entire window.''<br />
* '''D3D Window Height''':set the height (pixels) of the window. ''The title bar and border will add to the height.''<br />
* '''Screen Ratio''': add black bars to keep aspect ratio on non 16:10 monitors (based on patch from mikawo) for full screen mode only. '''''Use common display resolution terminology to specify the aspect ratio: 16:10, 16:9, 4:3, etc [version 1.31.5 or later.]''''' <br />
:''In prior versions, this setting was based on a formula with the idea that a value of 1 specified 16:10. Players needed to calculate what this value should be depending on their monitor: For example, the formula to get a 4:3 ratio is: 4/3x = 16/10, which equals 1.2 (or 0.83333 depending on where one wishes the black bars to be on the display.) ''<br />
* '''Always On Top''': force the window to be in the foreground.<br />
* '''Clip Cursor''': prevents the cursor from going outside the window.<br />
* '''Scale Mouse''': attempt to fix the cursor running off screen when using HQ4x and/or D3D in full screen mode.<br />
* '''Slow Geoscape Clock''': [Two Modes: =1 or =2] <br />
:=1: The speed buttons reflect how fast time passes for each second of real time. ''Time will pass faster at the lowest rate. This option does not produces the step effect that other speed mods do. A small side effect is that the globe doesn't rotate as fast when the time frame is at a lower rate.''<br />
:=2: Similar to Mok's Clock mod. The buttons reflect the rate of time at which the clock will change. ''This option produced a jumping effect at higher time rates.''<br />
* '''Interception Delay''': This will slow animations and the passage of time in interception windows. The player specifies the amount of time in milliseconds [version 1.32 or later.] ''Only up to 2 or 3 milliseconds should be necessary.''<br />
* '''Battlescape Delay''': All animations and scroll speed will be slowed. The player chooses the amount time in milliseconds. The value should be any number over 4. The higher the number the greater the effect. ''Too high and the player will experience lag. The player can further fine tune the movement speeds and shot animations from the options menu buttons.'' <br />
* '''Force Language''': Tired of selecting your language every time the start the game? This is for you. Options are 1,2,or 3.<br />
* '''Skip intro''': Skip the movie when you start the program.<br />
* '''CPU Mask''': force the process on a specific processor (1 is processor 0, 2 is processor 1, 4 is processor 2, etc).<br />
* '''High Priority''': run XCOM with "above normal" priority<br />
* '''Max FPS''': limit the framerate for the ones that cannot get vsync working. Not as smooth as vsync limited, but better than nothing (only works with D3D or Video Pitch enabled). ''Use this as an option in conjuction with, or as an alternative to, the Geoscape Clock and Battlescape Delay mods if your still having animation speed issues or the other mods cause any lag with the mouse cursor. Use this if using Video Pitch and shot speed is too fast in battles, even with Battlescape Delay set.''<br />
<br />
=== Mods ===<br />
<br />
* '''Doubleclick Movement''': change the requirement for moving a unit in the battlescape from clicking a tile once, to doubleclicking it (within 500ms). Failing to doubleclick will result in no action being taken. This allows for a considerable safety margin with movement, as the default movement controls are easy to accidentally trigger on the wrong tiles.<br />
* '''TFTD Doors''': open a facing door by right-clicking. The time cost is 4 TUs.<br />
* '''De-equip crafts''': provides an option to remove a weapon from an aircraft slot.<br />
[[Image:Deequip.png|center]]<br />
* '''Reorder soldiers in craft''': Move soldiers up or down via a simple interface. If you hold the mouse button for more than 200ms when clicking, the soldier will be moved to the top/bottom of the list. You can check the soldiers' stats by clicking on their names.<br />
[[Image:SoldiersPosition.png|center]]<br />
<br />
* '''Save Reserve Mode''': keeps the chosen TU reserve mod between turns.<br />
* '''Keep Base Navigation Modules''': keeps the navigation controls that are in the base control center after a successful base assault.<br />
* '''More Chryssalid Sound Effects''': victims will howl during zombification and newly emerged Chryssalids scream.<br />
* '''Alien Inventory''': get direct access to an alien's inventory when it is mind controlled.<br />
* '''Alien Bleeding''': most aliens will suffer from fatal wounds.<br />
* '''More Reaction Fire''': Units turning in place will provoke reaction fire from enemy units that can see them. ''In scenarios where a quick exchange of multiple reaction fire occurs, the weapon fire may remain what the previous reaction shot was. Alien units with grenades may toss them in a wrong direction.'' <br />
* '''Hot grenades''': <s>They do explode even when held.</s> Grenades do not have a timer and explode after they are thrown. Only high explosives have a timer.<br />
* '''Stunned Units KIA''': Usually, unconscious units just disappear when they blow up. Now you score the kill when you blast stunned units with explosives (with the experience, morale and all the stuff that goes with it).<br />
::::::::[[Image:Blasted1.png]] [[Image:Blasted2.png]]<br />
:In case of XCom units destroyed that way, they'll no longer go MIA but KIA<br />
<br />
* '''No Blaster Bomb Drift''': disable the randomness applied to blaster bomb trajectories between waypoints. It'll solve drifting issues experimented with the blaster launcher, but also make aliens even more deadly with that weapon since the hard coded accuracy of 55% they have won't affect their shots anymore.<br />
* '''More Smoke''': set the limit of smoking tiles to 2048 (up from 400). I don't expect this to work perfectly on the first try; smoke is referenced on lots of places and I'm not sure I patched everywhere needed. Report what works and what fails. ''You won't be able to load a saved game that used this option when this option is not enabled.''<br />
* '''Heavy laser''': This adds 2 firing modes to the heavy laser. <s>Firing the weapon will cost 50 energy.</s> ''version 1.31+: Each mode has a recharge time cost.''<br />
::'''Burst mode''': you select 3 target points, and the soldier will shoot a 5 shots burst (on each and between points). Recharge time: 2 turns.<br />
::[[Image:burst1.png]] [[Image:burst2.png]] [[Image:burst3.png]]<br />
<br />
::'''Full auto''': you select 2 points, the soldier will spray the area inbetween with 8 shots. Recharge time: 3 turns.<br />
::[[Image:fullauto1.png]] [[Image:fullauto2.png]] [[Image:fullauto3.png]]<br />
<br />
* '''Stun Fest''': Add the "Stun" command in the menu for most weapons. The TU/Damage is based on the weapon's class:<br />
:::::::::<table {{StdCenterTable}}><br />
:::::::::<tr {{StdDescTable_Heading}}><th align="left" width="150">Weapon Class</th><th width="90">Stun Damage</th><th width="75">TU %s</th></tr><br />
:::::::::<tr><th align="left">Pistols</th><td>20</td><td>15</td></tr><br />
:::::::::<tr><th align="left">Rifles and small launcher</th><td>50</td><td>40</td></tr><br />
:::::::::<tr><th align="left">"Heavy" weapons and auto-cannon</th><td>65</td><td>50</td></tr><br />
:::::::::<tr><th align="left">Launchers</th><td>80</td><td>80</td></tr><br />
:::::::::<tr><th align="left">Stun Rod (unchanged)</th><td>65</td><td>30</td></tr><br />
:::::::::</table><br />
<br />
* '''No Auto Wake Up''': stunned unit still have their stun level decrease, but they won't wake up on there own<br />
* '''No Alien Freak Out Messages''': don't show "Alien Commander has panicked" and the like messages. ''With CE, you'll only see this message if the alien is visible to the player.'' <br />
* '''Auto Sell''': allows the player to activate an automatic production and automatic selling mode in manufacturing. By pressing the down arrow button to reduce the quantity of desired items below zero, the mode will switch to the autosell mode, represented by three dollar signs ("$$$"). In this mode, production will never cease unless resources become unavailable, and all produced items will be immediately sold. By pressing the down arrow a second time, it will switch to autoproduce mode, represented by three asterisks ("***"). This functions in the same way as autosell, but the results will not be sold, merely stockpiled forever; caution should be used with this mode, as it can drain resources quickly<br />
* '''Start With All Missiles''': Craft cannons and ammo will be sold and an equivalent price of Avalanche launchers and missiles will be bought. Crafts will be automatically equipped with the new items.<br />
* '''Assign All Personnel''': Set the maximum amout of scientists/engineers on a project quickly by using the down arrow when the quantity is at zero (Ã la ET)<br />
* '''General Store Capacity''': change the capacity of general stores (default is 50). Capped at 187 to prevent integer overflows. ''This is the value that the base stores will have. Any value below below 51 is ignored and the default value is used.''<br />
* '''Rank In Inventory''': The icon for the character's rank will be displayed on the inventory screen.<br />
* '''Show Money''': shrink the clock in the date/time panel on the main geoscape screen, and adds a funds display above it. It is useful for examining remaining funds during manufacturing projects, while waiting for time to pass.<br />
* '''Base Build Stacking''': You can place base stuctures in advance. The construction will start when possible:<br />
<br />
:::::::[[Image:Queue1.png]] [[Image:Queue2.png]]<br />
<br />
:Funds are credited when you place an element. No refund is possible. There might be some issues with 2x2 structures, report any problem you encounter.<br />
* '''Fast Base Defenses''': remove the wait periods during base defense sequence. The need to press the button can be removed too<br />
* '''Improved Laser Tank''': The tank stats are improved but it requires Alien Alloys to produce. ''In-game UFOpaedia will display the updated information on the new tank.''<br />
* '''Know Thy Enemy''': Damage is reduced against targets until an autopsy has been preformed. There is a small chance that a "lucky" shot will do full damage. Explosives and Fire are not affected. ''The reduction only affects the damage that is applied against a unit's health not armor.''<br />
* '''Ablative Armor''': No changes for AP weapons but armor is more effective against HE, laser, and plasma. However, these attacks quickly reduce the armor in the location hit. In regards to the armor value used to determine stun damage applied to a target, the stun rod is treated as an AP attack but the Stun Bomb is treated like HE. ''Neither stun attack damages the armor.''<br />
* '''Alternate Weapon Loadouts''': reduces ammo carried by the aliens. ''This balances the game after implementing the Recover Clip Fix. Players will recover more clips than originally expected.''<br />
* '''EU2012 Item Rules''': Alien weapons have a high chance to self-destruct: A unit dying to direct damage has a high chance of destroying the weapon. Explosions leave no items behind. Panicked units don't drop items. Fire is bad for high tech items.<br />
* '''Weak Sectoids''':Sectoids will have heavy plasmas replaced with rifles or pistols depending on rank. Only sectoid engineers will carry blaster launchers.<br />
* '''Zombies Will Hatch''': Zombies will automatically convert to Chryssalids after a few turns. The resulting "mature" Chryssalid will have stats based on game difficulty. Killing a zombie will result in an "immature" Chryssalid emerging. Fire is still the only means to kill a Chryssalid in a zombie. Fire damage slows the hatching process. ''Any amount of fire damage will delay the Chryssalid's hatching.''<br />
* '''Human Limits''': Engineers and Scientists will work in 12 hours shifts. The project screen will assign two people per click but only one space will be used between them. Research and production times are adjusted accordingly.<br />
* '''Alternate Research Tree''':<br />
**=1<br />
***Laser cannon requires research into E-115 and UFO power to produce and E-115 is a production material.<br />
***Plasma weapons and Blaster Bombs require "help" from various alien engineers to obtain the knowledge to produce.<br />
***Hyperwave may require multiple species navigators to be interrogated in order to be finally unlocked. (depending on game difficulty)<br />
***Only a Etheral can give the required technology to unlock Psionics. Sectoids provide other options.<br />
***Improved detectors after the correct technologies have been researched or can be produced.<br />
***Quicker access to Mind Shield with the right research and Psionic testing. <br />
**=2 ''Alternate progression for laser weapons''<br />
***The first breakthrough allows the production of Heavy Lasers but damage is minimal.<br />
***Each new level researched allows a new item to be made and increases the damage for the prevous stage(s) items.<br />
* '''Difficulty Level of Interception''': adjusts the difficulty of hitting UFOs. [values from 1-5]<br />
* '''Manual Interception Fire Mode''': craft will no longer fall back when the last shot is expended or when damage is taken<br />
* '''True Cautious Mode''': craft with two similar weapons will only fire one-at-a-time and the stance gives a penalty for UFO's accuracy (-10%).<br />
* '''Crafts Always Ready''': change when craft are available after returning to base.<br />
::=1 allow crafts to take off even when not 100% refueled/rearmed/repaired. <br />
::=2 only damaged craft are grounded.<br />
* '''Retaliate Against Ground Assault''': Aliens do not seem to care if you assault a landed UFO. You can now have them retaliate as if their ship was shot down. ''Note that this was not extensively tested so feel free to report any odd thing that may happen when this patch is activated!!-Seb76''<br />
* '''No Funkers''': only guys that went on the last mission are checked for promotion.<br />
* '''Bloodthirst''': compute the "promotion score" based on killing stats only<br />
* '''Disable Base Defenses''': disable the base defence mechanism. Useful if you want to use some defence modules for tactical purposes. ''This is unnecessary if the Base Retaliation Loop Fix is enabled, since it allows right-clicking to disable defenses.''<br />
* '''Surrender Defense Missions''': [[Making_the_Game_Harder#Base_Defense | Surrender Defence Missions]]<br />
* '''Initial Alien Bases''': [[Aliens_Own_Earth | Initial Alien Bases]] <br />
* '''Funding Council Income Only''': [[Making_the_Game_Harder#Funding_Council_Income_Only | Funding Council Income Only]]<br />
* '''Limited Military''': [[ Making_the_Game_Harder#Limited_Military | Limited Military ]]<br />
* '''Max Aliens''': Setting this will make the game treat all combat as if the game was on Superhuman difficulty despite the actual difficulty of the game. This will affect the number of aliens created and those stats which are affected by the normal rules for the difficulty setting. [''Version 1.32 only'']<br />
<br />
=== Bug Fixes ===<br />
''These fixes are '''not''' enabled by default.''<br />
::* '''Tactical Scroll''': Enable/disable the fix that reduces the scroll speed in tactical mode<br />
::* '''Animations Speed''': reduce the speed of in-game animations (cursors, fire, smoke...) [''moved to video in version 1.32'']<br />
:::: ''Both of these and other battlescape speed issues are addressed by the Battlescape Delay feature.''<br />
::* '''Intro Sounds''': restore the sound effects during the intro<br />
::* '''Music Change Freeze''': try to prevent the freeze that happens ingame when the MIDI music changes (experimental)<br />
<br />
'' The following fixes are enabled by default. There is no listing for each one in the INI and no other actions are required by the player to use them. Any can be disabled by copying the appropriate line(s) from the bug reference file, which is included with the Extender, to this section in the INI.''<br />
<br />
* [[Known_Bugs#Radar_Stacking | Radar stacking ]] enabled. Credits go to [[User:Spike#Base_Fixer | Spike]] for I used something close to his formula.<br />
* [[Known_Bugs#Funky_Fire | Funky fire]] fix: Fire/stun damage applied at the end of each X-Com and Alien turn. ''Units standing on a tile with fire will be damaged as well as those units that are immolated.''<br />
* [[Known_Bugs#Collectors_Edition_Blaster_Bomb_Bug | Vertical waypoints blaster bomb bug]]<br />
* [[Known_Bugs#Door_jam | Door jam]] fixed.<br />
* '''Personnel Overflow''': [[ExploitsA#Robotic Factories|Robotic Factories]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]]. You cannot get more than 255 engineers/scientists, buying more will just result in them being lost during transfer.<br />
* [[Why civilians go rogue | Hostile Civilians]] fix. All units under mind control will have their proper faction restored after recovering thier wits.<br />
* '''Crash On First Move''': Fix occasional crash when moving your first unit out of the craft.<br />
* '''Tactical Sounds Fix''': fixes problems with snakeman, celatid, and zombie movement and the mind probe and stun rod sound effects.<br />
* '''Craft Weapon UFOpaedia Fix''': Accuracy is correct, Re-load time is obtained from correct dataset, and flavor text added. UFO weapon range is now in KM and all numbers positioned better.<br />
* '''UFOs Respond to Interception''': UFOs will close to weapons range when attacked. Craft that are slower than their attacker cannot abort* but the stance does give a strong defensive bonus. Also fixes the last shot missing. [*version 1.32: slow craft with a wingman present can abort.]<br />
* [[Known_Bugs#Paying_For_Dirt | Pay for dirt]] removed.<br />
* [[Known_Bugs#Phantom_Radar | Phantom radar bug]] fixed. Radar coverage is updated when facilities are removed.<br />
* [[Known_Bugs#Base_Disjoint_Bug | Base disjoint bug]] fixed. [[Image:Disjoint.png|center]]<br />
* [[Known_Bugs#Base_Facility_Dismantle-Construction_Crash | Base Facility Dismantle-Construction Crash]]<br />
* [[Known_Bugs#The_trouble_with_Mines_in_General | Armed state issues]] with proximity grenades when reloading a game. Should also fix [[Known_Bugs#What_just_exploded.3F | "What just exploded?"]]<br />
* [[Known_Bugs#The_trouble_with_Mines_in_General | Experience issue]] with proximity grenades. The thrower now gets the experience, not the poor alien that blows up...<br />
* [[Known_Bugs#Fuel_dump_on_transfer | Refueling issue]] when transfered crafts arrive (enabled by default if you use the "Crafts Always Ready" mod)<br />
* [[Known_Bugs#Elerium-fueled_Craft_Bug | Elerium fueled crafts bug]] fixed.<br />
* [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug | Displayed Base Maintenance Cost Bug]] fixed.<br />
* '''Unconscious Unit MC fix''': A unit under mind control will have the effect removed and its proper faction restored when knocked unconscious.<br />
* '''EOB fix''': Units under Mind Control are not lost if battle is won, or if they are in the xcraft when mission aborted.<br />
* '''Tank/Cannon Ammo Storage Fix''': The tank/cannon ammo will not take up room in storage similar to Craft Cannon ammo.<br />
* '''Clip Weight Fix''': Clip weight in weapons is correctly assigned to the unit and removed when the weapon leaves the unit's possession.<br />
* '''Large Unit MC Fix''': All sections of a large unit will be correctly controlled on a successful mind control attack.<br />
* '''Large Unit Explosion Fix''':Explosions will now only affect a large unit once and not per section.<br />
* '''Large Unit Deaths''':Certain large units will not be "killed" multiple times at the end of the turn after dying from the initial attack. [version 1.32]<br />
* '''Alien Weapon Selection Crash Fix''': fixes the crash after an alien throws a grenade and does not have another weapon available.<br />
* '''Alien Attacks Base Location Fix''':An alien that attempts to attack one of the base's areas will not crash the game.<br />
* '''Weapon Loadout Fix''': Corrects the weapon loadout on the small scout pilot and on the abductor's leaders.<br />
* '''Change Sectopod Laser Modifer''': Removes the vulnerability to laser damage when 'Ablative Armor' mod is active since the armor rating is directly reduced by laser damage and the unit takes damage to its accuracy rating, which is closer to the description in the ufopaedia.<br />
* '''Armor Modifer Fix''':Personal Armor is now assigned the correct category of damage modifiers.<br />
* '''Zombie Fix''': Fixes the exploit where an MCed zombie that dies will give the player permanent control of the resulting Chryssalid. Also makes zombies to drop their weapons.<br />
* '''No Freebies for Tanks''': Available tanks during Base Defense missions will get their ammo from what is available in the base stores.<br />
* '''Recover Clips Fix''': Each ammo type on the battlefield is tallied and placed into a clip. Thus, only any leftover ammo that cannot make a full clip will be discarded.<br />
* '''Tank Death Penalty Fix''': The penalty for losing a tank is fixed at 20 points, not based on the rank of the first unit in SOLDIER.DAT<br />
* '''Slow Death Screams on Alien Turn''': puts a small delay after a death scream on the alien turn. Useful in Terror Missions for civilain deaths.<br />
* '''Bezerk Unit Crash Fix''': Tanks will not suffer moral loss, and large units or units with in-built range weapons will not go Bezerk. <br />
* '''Explosion Fix''': All explosions now behave the same for all walls. (if the proper byte for the tile is set in the MCD records.)<br />
* '''Smoke&Fire Propagate Fix''': Fire and smoke will not spread through solid walls. (with the same provisions as above.)<br />
:''The MCD records for Xcom Bases don't have the proper bit set for smoke and fire. A corrected set of files is [[:File:XBASEx.zip | here]].''<br />
* '''Terror Mission Score Fix''': The score for each civilian in a terror mission is now [base score / number of civilian]. [version 1.32: the total score for civilians is determined by the difficulty rating, starting with veteran difficulty. The base score is {252*difficulty rating}. If the mission is aborted the base score gets set to 1008.] ''Removes the land-and-abort exploit to reduce the penalty of a terror mission.''<br />
* '''Research Medic Crash Fix''': Researching an alien medic will no longer crash the game which happens under certain circumstances.<br />
* '''Base Retaliation Loop Fix''': UFOs fire on base defenses and the aliens respond more logically at failed attempts to assault a base. Missile Defenses will spend money when activated. Fusion Ball Defenses require blaster bombs in base stores to work: 4 bombs required per unit on Genius difficulty, 6 for Superhuman.<br />
* '''Grenade Throw Test Fix''': Removes the problem where units with high strength can't throw items when indoors or under something. ''Hypothetical: please report any issues! - [[User:Morgan525|Tycho]]''<br />
* '''Alien Base Exploit Fix''': The aliens' monthly score for a base increases with game difficulty and the longer the base stays in operation.<br />
* '''Base Defense Prep''': Players are taken to the base editor screen before starting a base defense mission.<br />
* '''BB Exploit Fix''': Production materials are in the correct order and Sell Price adjusted.<br />
* '''Staff Transfer Exploit Fix''': Engineers and Scientists being transferred at the end of a month still get paid.<br />
* '''Alien Psi Attack Fix''': Aliens will only remember the location of an unseen target for 1 turn. ''Of course, a successful Psionic Attack may renew this memory.'' [version 1.32: aliens randomly target known units and will give preference to those units in line of sight. Aliens are more likely to only panic units not in line of sight.]<br />
<br />
=== Tactical AI ===<br />
*'''Apply''': Aliens are less indecisive and more aggressive.<br />
*'''Autofire Distance''': The number of squares that if a target is within, an alien will try to use autofire against it.<br />
*'''Snap Distance''': The number of squares that an alien will use a snap shot against a target. Otherwise, alien will try to use an aimed shot.<br />
<br />
=== Equipment Screen ===<br />
This patch changes the equipment screen. It effectively renders [[Statstrings|statstrings]] obsolete ;-)<br />
*Before battle, it changes the screen like this (the psi stats are only shown when the soldier has been trained):<br />
<br />
[[Image:Equip.png|center]]<br />
<br />
*During a mission, it looks like this:<br />
<br />
[[Image:Ingame.png|center]]<br />
<br />
*You can also have the rank shown:<br />
<br />
[[Image:Rank.png|center]]<br />
<br />
<br />
<br />
*Show Grenade State: if you select a primed grenade, it'll be indicated in the description<br />
*Save Equipment: automatically reequip your team with their last weapon layout ('''HIGHLY EXPERIMENTAL'''). New recruits will be given a gun and some ammo but nothing outstanding. Don't forget to properly equip them<br />
*Auto Flares: automatically equip flares (if available in the craft) during night missions (only works with Save Equipment)<br />
<br />
=== Range Based Accuracy ===<br />
This modifies the accuracy based on the distance from the target. The accuracy decreases linearly (2% per tile) when shooting beyond the limit of the firing mode:<br />
* auto shot: 7 tiles<br />
* snap shot: 15 tiles<br />
* aimed shot: no penalty<br />
These values should be considered as a first draft; they are configurable in the ini file so feel free to test other settings and report back if you find good ones.<br />
<br />
[[Image:Acc0000.png]] [[Image:Acc0001.png]] [[Image:Acc0002.png]]<br />
<br />
''Advanced options''<br />
*Add these lines to your INI in the [Range Based Accuracy] section<br />
<br />
::Aimed Penalty Distance=200<br />
::Auto Accuracy Dropoff=2<br />
::Snap Accuracy Dropoff=2<br />
::Aimed Accuracy Dropoff=3<br />
<br />
:''Change the numbers to your own personal preferences. Remember that the distance number is twice the number of hexes on the battlescape.''<br />
<br />
=== Line Of Fire Check ===<br />
A soldier will need a line of fire toward the targeted alien to use psionic device. It is configurable for each ability:<br />
<br />
*Mind Control<br />
*Panic<br />
*Mind Probe<br />
<br />
=== Music ===<br />
==== PSX CD ====<br />
If you have the PSX version of the game, you can enjoy the CD music with this patch. The tracks are mapped like that:<br />
* 1,2,3,4: geoscape music<br />
* 5: gmdefend<br />
* 6: gmenbase<br />
* 7: gmmars<br />
* 8: gminter<br />
* 9: gmstory<br />
* 10,11: battlescape music<br />
* 12: gmnewmar<br />
<br />
gmwin and gmlose are not available. Because of similarity, gmlose is replaced with gmstory and gmwin with gminter.<br />
<br />
==== MP3 music ====<br />
If you have mp3 music files available for the game, you can use them instead of the default MIDI ones (see default ini file as an example). Note that the intro music will still use the original files.<br />
<br />
:Battlescape=*tactical*.mp3<br />
:Start Menu=*Final Briefing*.mp3<br />
:Bad Ending=*Final Briefing*.mp3<br />
:Good Ending=*intercept*.mp3<br />
:Geoscape=*Geoscape*.mp3<br />
:Dogfight=*intercept*.mp3<br />
:Mission Debriefing=*Debriefing*.mp3<br />
:UFO Assault=*Briefing1.mp3<br />
:Base Defense=*Briefing2.mp3<br />
:Base Attack=*Briefing1.mp3<br />
:Mars=*Debriefing*.mp3<br />
:Terror Mission=*Briefing2.mp3<br />
<br />
''Note that the above files are only an example. You can change the music played during any event by changing the file name. All files must be in a folder named MP3 which should be in the same list as the SOUND folder.''<br />
<br />
=== Initial Base ===<br />
Change the layout of your starting base. <br />
Possible modules:<br />
*AccessLift<br />
*LivingQuarters<br />
*Laboratory<br />
*Workshop<br />
*SmallRadar<br />
*LargeRadar<br />
*MissileDefense<br />
*GeneralStores<br />
*AlienContainment<br />
*LaserDefense<br />
*PlasmaDefense<br />
*FusionBallDefense<br />
*GravShield<br />
*MindShield<br />
*PsionicLaboratory<br />
*HyperWaveDecoder<br />
*HangarTL<br />
*HangarTR<br />
*HangarBL<br />
*HangarBR<br />
*Empty<br />
<br />
=== Wreck Analysis ===<br />
Until the construction of hyper-wave decoders, it is impossible to know what missions aliens are performing. Even after recovering an alien ship, XCOM intelligence is unable to determine what was its purpose. This is no longer true. Salvaged navigation modules can now be analysed and may reveal what evil intentions the aliens had:<br />
<br />
::::::::[[Image:Wreck_analysis.png]]<br />
<br />
The probability of retrieving the information is based on the difficulty and on the number of UFO navigation items recovered from the mission. UFO mission and geographical zone can be discovered individually too.<br />
<br />
=== Craft Ready Message ===<br />
A message will notify the player when a craft is ready.<br />
::::::::[[Image:CraftReady.png]]<br />
<br />
=== Roswell mod ===<br />
Make scout ships possibly crash during their missions:<br />
<br />
::::::::[[Image:Roswell.png]]<br />
<br />
It can happen to all scouts, either detected or not. Crashed UFOs will be made visible so that you can initiate recovery missions.<br />
<br />
=== Shortcuts ===<br />
Enable keyboard shortcuts. The keymap is qwerty.<br />
<br />
==== Default key mapping in geoscape ====<br />
*UpArrow: Rotate Up<br />
*DownArrow: Rotate Down<br />
*LeftArrow: Rotate Left<br />
*RighArrow: Rotate Right<br />
*MouseWheelUp: Zoom In<br />
*MouseWheelDown: Zoom Out<br />
*1: Geo Speed1<br />
*2: Geo Speed2<br />
*3: Geo Speed3<br />
*4: Geo Speed4<br />
*5: Geo Speed5<br />
*6: Geo Speed6<br />
*MouseMiddle: Intercept<br />
*B: Bases<br />
*G: Graphs<br />
*U: Ufopaedia<br />
*Escape: Options<br />
*F: Fundings<br />
<br />
==== Default key mapping in battlescape ====<br />
*UpArrow: unit goes up<br />
*DownArrow: unit goes down<br />
*LeftArrow: left menu<br />
*RightArrow: right menu<br />
*Return: end of turn<br />
*Escape: options menu<br />
*BackSpace: go to next unit, remove current from the queue<br />
*Tab: go to next unit<br />
*Space: go to inventory<br />
*PageUp: view goes up one level<br />
*PageDown: view goes down one level<br />
*1: reserve mode off<br />
*2: reserve mode snap<br />
*3: reserve mode auto<br />
*4: reserve mode aimed<br />
<br />
==== Key names ====<br />
Standard keys (A, 2, etc) are indicated as-is, the following "special" keynames are available (case insensitive):<br />
{|<br />
|<br />
*Back<br />
*BackSpace<br />
*Back Space<br />
*Tab<br />
*Clear<br />
*Return<br />
*Enter<br />
*Shift<br />
*Control<br />
*Menu<br />
|<br />
*Pause<br />
*Escape<br />
*Space<br />
*Prior<br />
*PageUp<br />
*Next<br />
*PageDown<br />
*End<br />
*Home<br />
*Left<br />
|<br />
*Up<br />
*Right<br />
*Down<br />
*Print<br />
*Insert<br />
*Delete<br />
*Num0<br />
*Numpad0<br />
*Num1<br />
*Numpad1<br />
|<br />
*Num2<br />
*Numpad2<br />
*Num3<br />
*Numpad3<br />
*Num4<br />
*Numpad4<br />
*Num5<br />
*Numpad5<br />
*Num6<br />
*Numpad6<br />
|<br />
*Num7<br />
*Numpad7<br />
*Num8<br />
*Numpad8<br />
*Num9<br />
*Numpad9<br />
*Multiply<br />
*Add<br />
*Separator<br />
*Subtract<br />
|<br />
*Decimal<br />
*Divide<br />
*F1<br />
*F2<br />
*F3<br />
*F4<br />
*F5<br />
*F6<br />
*F7<br />
*F8<br />
|<br />
*F9<br />
*F10<br />
*F11<br />
*F12<br />
*MouseMiddle<br />
*MouseWheelUp<br />
*MouseWheelDown<br />
*MouseWheelLeft<br />
*MouseWheelRight<br />
|}<br />
<br />
If you need a key not listed here and you know its VK_* code, you can specify it with it's hex value (e.g. 0x90 for num lock)<br />
<br />
The implementation is rather messy, expect side effects and report them...<br />
<br />
=== Caps ===<br />
<br />
: This sections sets the highest number for each stat to which it can be raised by in-game methods. See [[Experience#Regarding_Caps | experience caps]].<br />
<br />
=== OBDATA.DAT patching ===<br />
Change the value of some OBDATA.DAT settings on the fly.<br />
To change a value, add a line "itemname setting=value" (without the quotes). For example:<br />
<br />
High Explosive Damage=200<br />
<br />
Available settings:<br />
*Damage<br />
*Resistance (to explosions)<br />
*Weight<br />
*Damage Type<br />
*Auto accuracy<br />
*Snap accuracy<br />
*Aimed accuracy<br />
*Auto TUs<br />
*Snap TUs<br />
*Aimed TUs<br />
*Size (clip size)<br />
*get <br />
<br />
Item names are case insensitive and available at [[OBDATA.DAT]].<br />
<br />
=== Text ===<br />
''This section contains almost all of the strings that are used in the Extender. Useful for multilanguage support. To change one, modify the text after the equal sign. Others may require that you copy the line to the [Text] section of the INI.''<br />
*equipment screen texts<br />
::Weight=Weight><br />
::Accuracy=Accur><br />
::Reaction=React><br />
::Psi Strength=P.Str><br />
::Psi Skill=P.Skill><br />
::Primed=primed<br />
<br />
*Roswell mod texts<br />
:{Terrain names}<br />
::Jungle=Jungle<br />
::Farm=Farm<br />
::Mountain=Mountain<br />
::Desert=Desert<br />
::Polar=Polar<br />
:{Dialog strings}<br />
::RoswellTitle=UFO Incident<br />
::Roswellinfo=Crash reported<br />
::Location=LOCATION<br />
::Type=TYPE<br />
::Terrain=TERRAIN<br />
<br />
*Wreck Analysis<br />
::Zone Discovered=Intel found out that the %s UFO was raiding %s<br />
::Mission Discovered=Inspection showed that the %s UFO was on an %s mission<br />
::Both Discovered=Ship investigation revealed that the %s UFO was on an %s mission in %s<br />
<br />
*Craft Ready<br />
::CraftReadyTitle=Aircraft ready<br />
::CraftReadyInfo=A craft has been refitted<br />
<br />
*Other<br />
::research needed=research needed<br />
::to produce=in order to produce<br />
::full auto=Full Auto<br />
::burst shot=Burst Shot<br />
::laser rifle=The laser rifle is lighter and more accurate than the older design.<br />
::plasma cannon=This is a devastatingly powerful weapon based on accelerating particles from within a minute anti-gravity field.<br />
::base strike=<br />
::ship crash=<br />
::lift hit=<br />
::detector=<br />
::gravshield=<br />
::avalanche=This heavy air-to-air missile is designed to attack bombers and large craft. It is less useful against smaller, more agile targets.<br />
::fusionball=This launcher fires missiles propelled by an anti-gravity system. A massive anti-matter explosion is created when the weapon reaches its target.<br />
::rental=Craft Maintenance<br />
::firestorm=An experimental unmanned craft that replicates the classic saucer design. Faster and more maneuverable than any other conventional aircraft. <br />
::base control=ALIEN BASE CONTROL<br />
::production time=Days/Hours Left To Next Unit<br />
<br />
----<br />
<blockquote><br />
<u>'''Hacks '''</u><br />
<br />
:''This section is not part of the normal INI but are available. These hacks heavily alter the gameplay and should only be used for testing purpose. Those options with a <s>strike-through</s> are not available in release versions. [currently in 1.31, no hacks are available.]''<br />
<br />
* <s>Prevent game over when score is really bad at the end of the month </s><br />
* Big brother: follow all units in combat.<br />
* Alien pets: Alien turn handed over to the human player<br />
* <s>Show All Locations: displays all active locations, detected or not.</s><br />
* FPS: show an FPS counter in the geoscape. Mostly used for debugging D3D.<br />
* <s>Directly Use Alien Weapons: After all a gun's a gun, you just pull the trigger. When activated, you can use all alien items you recovered. Of course you still do need to research items before you're able to manufacture them!</s><br />
* <s>No Alien Psi: no more psi trouble when fighting sectoids/ethereals</s><br />
</blockquote><br />
<br />
[[Category:Enemy Unknown/UFO Defense]]</div>
Spike
https://www.ufopaedia.org/index.php?title=WORLD.DAT&diff=58882
WORLD.DAT
2014-08-16T15:58:39Z
<p>Spike: /* Relationship to Real World Geography */</p>
<hr />
<div>The original XCOM file is 13320 bytes long, while TFTD is 14660 bytes long. However, each uses the same 20-byte record format giving the original 666 entries and TFTD 733 entries. This file describes the terrain on the geoscape screen using quadrilateral polygons and triangles.<br />
<br />
The first 16 bytes of file contain the points for the polygon. 4 sets of 2 short (2-byte) integers, designating the 'X' and 'Y' coordinate (or longitude and latitude respectively, if you prefer). If the last set has an x value of -1 then it is to be rendered as a triangle, otherwise it is a quad.<br />
<br />
The last 4 bytes in the record contain the terrain type. This could be a long integer or 2 short integers as the last 2 bytes in each record are 0.<br />
<br />
== Structure ==<br />
{| {{StdDescTable}}<br />
|- {{StdDescTable_Heading}}<br />
! Offsets !! Meaning !! Values<br />
|-<br />
| 0-1 || First X coordinate/longitude || 0 - 2879<br />
|-<br />
| 2-3 || First Y coordinate/latitude || -720 - 720<br />
|-<br />
| 4-5 || Second X coordinate/longitude || 0 - 2879<br />
|-<br />
| 6-7 || Second Y coordinate/latitude || -720 - 720<br />
|-<br />
| 8-9 || Third X coordinate/longitude || 0 - 2879<br />
|-<br />
| 10-11 || Third Y coordinate/latitude || -720 - 720<br />
|-<br />
| 12-13 || Fourth* X coordinate/longitude || 0 - 2879<br />
|-<br />
| 14-15 || Fourth* Y coordinate/latitude || -720 - 720<br />
|-<br />
| 16-19 || Terrain Type/Texture || 0-12<br />
|}<br />
<small><nowiki>*</nowiki> As mentioned above, the fourth coordinate could be (-1, 0) denoting a triangle</small><br />
<br />
== Relationship to Real World Geography ==<br />
<br />
As the 2880 possible longitude values range from 0 to 2879 (hex: 3F 0B) and the latitude values range from -720 to 720, the resulting map could be said to have a spatial resolution of one-eighth of a degree, both in latitude and in longitude (0.125° or 00°07'30"). (2880 = 360 x 8, and 720 = 90 x 8.)<br />
<br />
This implies that, at the equator, each possible map location on the Geoscape occupies a square that is 60 nautical miles (111 kilometres, 69 statute miles) on its side, or an area of 4,761 square miles / 12,321 square kilometres. This area would of course reduce with North or South latitude as you move away from the equator (and also the shape of the area will become progressively less square).<br />
<br />
The X coordinate starts with X = 0 at 0° longitude (the Prime Meridian or Greenwich Meridian) and increases going eastward. Unlike real-world longitude, there is only "East" longitude, from 0°E to 359.875°E. This is the result of forcing the coordinate system to be positive-only, for algorithmic purposes. So, for example, the equivalent of 90°W longitude would be "270°E longitude", with a game X coordinate of 270 x 8 = 2160. <br />
<br />
A Y coordinate value of 720 (hex: D0 02) corresponds to 90°S latitude (the South Pole); a Y coordinate value of -720 (hex: 30 FD) corresponds to 90°N latitude (the North Pole).<br />
<br />
The coordinate system used in EU and TFTD is a form of geodetic coordinate system [http://en.wikipedia.org/wiki/Geodetic_coordinates].<br />
<br />
== Texture / Terrain Type ==<br />
<br />
The final value in each record points to the [[TEXTURE.DAT|texture type]] to be displayed for that polygon. It also serves to determine the terrain type used when you start a battle in that area.<br />
<br />
<b>UFO</b> <b>TFTD</b><br />
0: Forest / Jungle 0: (Nothing?)<br />
1: Farm 1: Pipes <br />
2: Farm 2: Crashed Plane <br />
3: Farm 3: Atlantis<br />
4: Farm 4: Mu<br />
5: Mountain 5: Sunken Galleon<br />
6: Forest / Jungle 6: Sunken Liner<br />
7: Desert 7: Volcanic<br />
8: Desert 8: (Nothing?)<br />
9: Polar Ice 9: Volcanic<br />
10: Forest / Jungle 10: Sunken Liner<br />
11: Forest / Jungle 11: Pipes <br />
12: Polar Seas w/Icebergs 12: Mu<br />
<br />
In UFO, terrain types 0, 6, 10 and 11 will produce forest missions in the northern hemisphere and jungle mission in the south. (11 is not actually used in the game, but hacking reveals this.)<br />
<br />
For TFTD, the terrain type is always selected randomly from a choice of three - Coral, Seabed, and whatever the terrain type for that actual polygon is. In the case of a type 0 or 8, the mission will always be in either the Coral or Seabed terrains.<br />
<br />
Although TFTD has three choices of underwater depth that can be associated with any given mission (plus a forth "depth" for surface missions), that value is not derived from this file. Most likely it's taken from the [[LOC.DAT]] record that points to the mission in concern.<br />
<br />
<gallery widths="400" heights="225"><br />
Image:xcom_render2.gif|Rendering of the data in WORLD.DAT for the original XCOM. The colors are obtained by using offset 16-19 for each record. Click on the image to see the exact color key, generally speaking though it goes bright green to dark green for 0-5, and dark yellow to white for 6 - 12. Value 11 however is not used anywhere in the map.<br />
Image:tftd_render.gif|Rendering of the data in WORLD.DAT for TFTD. Colors again are obtained by using the same offset as before. They go from blue to white for 0 to 12. <br />
</gallery><br />
<br />
<i>TFTD seems to have overlapping polygons at places whereas XCOM didn't (exception to the poles, which is probably because these polygons are rendered to a sphere, not a flat surface).</i><br />
<br />
--[[User:Pi Masta|Pi Masta]] 15:24, 10 April 2007 (PDT)<br />
<br />
Each polygon has its light calculated individually. This gives rise to the effect of a large area of the same texture having different colors, depending on how much sunlight the particular area defined by the WORLD.DAT record is receiving.<br />
<br />
Country and regional borders must be stored in the executable somewhere. I've tried hard looking for the position of cities in there hoping the position would be near its [[ENGLISH.DAT]] index, but I haven't had much luck.<br />
<br />
--[[User:Pi Masta|Pi Masta]] 16:06, 10 April 2007 (PDT)<br />
<br />
== See Also ==<br />
<br />
*[[COS.DAT]]<br />
*[[TEXTURE.DAT]]<br />
[[Category:Game Files]]<br />
[[Category:Enemy Unknown/UFO Defense]]</div>
Spike
https://www.ufopaedia.org/index.php?title=Known_Bugs&diff=58881
Known Bugs
2014-08-16T14:51:13Z
<p>Spike: /* Other Bugs */ Celatid</p>
<hr />
<div>== Game Destroying Bugs ==<br />
<br />
These are the list of the worst bugs of them all, because they can render your entire game unplayable. Until a fix/ workaround is found, these bugs result in your entire X-com campaign being scuttled:<br />
* [[Minimized interceptor bug]]<br />
* [[Big text bug]]<br />
*[[Small window bug]]<br />
<br />
== Base Construction Bugs ==<br />
<br />
=== Base Disjoint Bug ===<br />
Base facilities built along the right or bottom edges of the base building area may end up being cut off from each other by dirt walls, a bug in the routine meant to keep soldiers from accidentally exiting the map edges during [[Base Defense]] missions. The dirt walls can be knocked down by Blaster Bombs or excessive amount of heavy plasma fire during combat but are otherwise unbreakable. <br />
<br />
[[image:bdb.gif|center|Base Disjoint Bug]]<br />
<br />
The walls marked in white are removed if there is an adjacent module. All green modules are not affected while the yellow modules are. The red module will be sealed off completely if anything smaller than a hangar is placed here at any given time. <br />
<br />
[[XcomUtil]] works around this problem by stripping out the walls entirely in all the base modules.<br />
<br />
The bug can be profitable if the hangars and the lift are accessible only through in these areas - you can gather and supply all your soldiers heavily without aliens interfering, then knock a hole in the wall and cover the area with explosives and blaster launcher fire.<br />
<br />
===Displayed Base Maintenance Costs===<br />
Although X-COM charges the right monthly fees for base modules, the maintenance fee displayed ''in the base info screen'' is always wrong. The displayed number is actually based on the placement within the base grid, '''not''' the price displayed in the in-game UFOpaedia. However, at the end of the month, the right fee is deducted. For more information, see [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]]. The Geo finance Graph shows a correct maintenance summary ([[LIGLOB.DAT]], updated once a month). Also see the next section.<br />
<br />
===Paying For Dirt===<br />
If you take down any facility in any base that you own and leave bare dirt, then you will continue to pay maintenance on it. But not at the old rate of whatever the facility cost per month, filling the hole back with dirt means it needs special attention at all times by specialists. In fact for every square of dirt you have that used to be a facility you will pay 80k per month. Thats 320k per hangar you take down. There are only two known ways to stop paying this premium - if you completely dismantle the base you stop paying any money for it, or if you build over all the spaces that you have vacated. In fact as soon as you start building the new facility you stop paying the premium, as well as not having to pay the cost of the new facility until it is complete.<br />
<br />
It is also possible to stop the 80k per month charge by hex editing the base.dat file in the save game. If you change the byte that indicates the number of days until the destroyed module from 00 to ff, you no longer pay for the dirt.<br />
<br />
If you start a facility and change your mind before it is complete, after the time when it would have completed you will start paying this 80k premium on that land as well.<br />
<br />
Note that this also applies to facilities that have been destroyed due to battle damage in [[Base Defense|Base Defense]] missions. If you have lost a facility in a base defense mission and you cannot afford to replace the original facility, consider building something cheap here to keep down this bug.<br />
<br />
===Base Facility Dismantle-Construction Crash===<br />
In the Collectors Edition version, dismantling a facility while its construction is in progress can cause a crash when a second facility on another base square completes its construction. To work around this, dismantle a facility only after its construction is complete. If you have already dismantled such a facility, build something like a general stores on the same square to avoid the crash. It is not known if this crash happens intermittently or always, or if it happens on most versions of the game or just the Collectors Edition.<br />
<br />
===Radar Stacking===<br />
Despite the "Short Range" and "Long Range" detection bars displayed on each base's Information screen, only one radar of each type will be used at each base. Building additional radars of the same type will have no effect. One short and one long are useful until the [[Hyper-wave Decoder|Hyper-Wave Decoder]] makes both of them obsolete.<br />
<br />
===Phantom Radar===<br />
When you dismantle detection equipment such as a radar or hyperwave detector, the related detection ability of the base does not decrease until a new facility of some kind is built in that base. Until a new facility is completes building at that base, the base continues to use this "phantom radar".<br />
<br />
This bug allows you to "upgrade in place", for example building a new Hyper-Wave Decoder over the top of an existing Large Radar, and retaining the detection capability of the Large Radar until the Hyper-Wave Decoder completes building. (Unless something else completes building first).<br />
<br />
===Fixes for Base Construction Bugs===<br />
<br />
As mentioned above, [[XcomUtil]] prevents the Base Disjoint bug (crudely). The [[User:Spike#Base_Fixer|BaseFixer]] utility corrects the Paying for Dirt, Phantom Radar, and Radar Stacking bugs. BaseFixer can be used manually on saved game files, or automatically via XcomUtil's hook mechanism.<br />
<br />
==Geoscape Bugs==<br />
<br />
===First Radar Detection Data bug===<br />
When a UFO is detected by a radar, you get certain data on it depending on the type of radar that detected it. If the UFO later enters the range of another radar while staying in the range of the first, you will continue to get the initial data given, even if the new radar is more powerful than the first! So if you detect a craft with a [[Small Radar System]], then the UFO moves into the range of a [[Hyper-wave Decoder]], clicking on the UFO will only give you the data as if the Small Radar detected it, so long as it remains in the Small Radar range! In effect, the data you get about a UFO is determined when you first detect it, and not changed after that until you lose detection on the craft with the radar that first detected it.<br />
<br />
This bug most commonly shows up when a UFO is first detected by a patrolling aircraft and then remains in the range of the aircraft while also entering the range of a Hyper-Wave Decoder.<br />
<br />
=== Minimized Interceptor Bug ===<br />
One fairly consistent cause of crashes is saving the geoscape game during a UFO standoff, with a [[UFO Interception]] window minimized to an icon. The next mission after that point will likely dump you to the green text screen, and perhaps an earlier battlescape mission instead of the proper one. What it seems to do is zoom back out of the combat too far when the fight is over, eventually causing the crash once it has gone a couple of steps further than it normally allows you.<br />
<br />
'''Solution:''' Open up [[UIGLOB.DAT]] in a hex editor. Change hex offset 0x06 to 00. This will reset the number of minimized interceptor windows to zero. Your interceptor unit can be selected to either return to base or continue on to complete its ground assault mission. ''NOTE: Make sure to back up your save game before editing it.''<br />
<br />
''-- I was able to recover from this state by quickly sending in another interceptor ([[Firestorm]]) to take over, which allowed my first interceptor ([[Avenger]]) to break off and go home without crashing the game again. After the shootdown I overwrote the buggy savegame. --[[User:JellyfishGreen|JellyfishGreen]] 03:11, 22 Aug 2005 (PDT)''<br />
<br />
''This happened to me also. I fixed it by replacing "[[UIGLOB.DAT]]" in the save folder with the same file from another saved game (from the same campaign a month earlier) [[User:bylund|bylund]] 00:15, January 12, 2007 (GMT+01)''<br />
<br />
=== Interceptions: Last Shot Always Misses ===<br />
When using Cautious attack when [[UFO Interception|intercepting a UFO]], your craft will stay at the maximum range of your longest-range weapon. When using Standard attack, your craft will stay at the maximum range of your shortest-range weapon. (Usually players use two weapons of the same type, so Cautious and Standard attack will behave the same in this regard.)<br />
<br />
As soon as the craft fires its last shot (expending all its ammo), it will drop back to "Standoff" range (70km). This will make it appear that the UFO has backed away while the last missile(s) are in-flight, causing them to miss. <br />
<br />
In order to hit a UFO with your last salvo of missiles (Stingrays, Avalanches, or Fusion Balls), you must switch to "Aggressive" attack before the last salvo reaches the UFO. This will cause your craft to close in with the UFO, allowing the missiles to be in range when they reach the UFO. However, Aggressive attacks will also bring you within range of the UFO's weapons, so you should hit the "Disengage" button as soon as the last salvo hits.<br />
<br />
===Elerium-fueled Craft Bug===<br />
A [[Skyranger]] or [[Interceptor]], once dispatched, will return to base when its fuel supply has dropped to a level that it will only have just enough fuel to return to base. Craft fueled by Elerium-115, however, will always report the "Low Fuel" message as soon at the fuel supply is 50% depleted, no matter where they are on the globe. This significantly shortens the already minute time that a [[Firestorm]], [[Lightning]], or [[Avenger]] can be dispatched to patrol.<br />
<br />
===Medic Research Bug===<br />
Every single time a Floater Medic is found and researched, the game crashes after it is interrogated! I [[muton commander]] used a hack system to view the alien's profile, and it was a Commander with no race attached. This is probably the cause, but I have no explaination for why this situation occurs.<br />
<br />
<br />
Addendum:<br />
<br />
Based on report from various players, the crash appears to happen with medics in general, and isn't confined just to floaters.<br />
<br />
''The portion of the code that is responsible for selecting the unresearched alien topic to provide when completing the research on a medic is the problem. The array that holds the avaiable topics, so that one can be randomly selected, is four bytes too short. If a player has never researched an alien species or performed an autopsy, the program will crash after it displays the random alien topic. This is because the portion of memory that holds the return address for the function has been overwritten by the array creation code and upon completion of this subroutine, the game is directed to an invalid memory address. This error won't occur if the player performs two autopies, alien interrorgations or a combination of both before researching a medic.'' [[User:Morgan525|Tycho]] 21:04, 22 June 2013 (EDT)<br />
<br />
===Never-ending Retaliation Bug===<br />
Some times the aliens will send a [[battleship]] on a [[Alien_Retaliation|retaliation mission]] to the "wrong" base. F.ex: the [[Hyper-wave_Decoder|hyper-wave decoder]] may report its destination as South East Asia, but the ship will actually fly to your base in North America and attack it.<br />
<br />
Even if the battleship succeeds in getting past the base defences and its crew is subsequently defeated, the aliens won't "forget" the base's location as they normally do and instead keep sending another battleship every week or so. If your base is constructed with [[Base_Layout_Strategy|defendability]] in mind and crewed by experienced operatives this will net you heaps and heaps of alien weapons, corpses and prisoners very quickly. The downsides are, of course, playing the same base defence mission over and over again and having to maintain a garrison there at all times.<br />
<br />
More research is needed to find out what causes this bug, but it ''could'' have something to do with [[Mind_Shield|mind shields]] being finished between the scouting and assault parts of the aliens' retaliation mission.<br />
<br />
=== Great Circle Bug ===<br />
<br />
The shortest distance between two points on the surface of a sphere is called a Great Circle. The wayfinding algorithm used by XCom aircraft has unfortunately never heard of this. XCom aircraft tend to move toward, and then along, lines of latitude. This is inefficient in terms of time, fuel, range and time on station. The inefficiency is most evident when crossing over the poles, and least evident when moving east-west or west-east. <br />
<br />
As a workaround, you can set manual waypoints to approximate the Great Circle route. <br />
<br />
Note that this does not seem to affect combat interception of moving UFOs, or at least not as much. Intercept courses seem to be continually updated, and head straight toward the current position of the UFO (also not an optimum algorithm, but that's another story).<br />
<br />
<br />
=== Geoscape Intercept Bugs ===<br />
<br />
==== Side-On Intercept Bug ====<br />
<br />
Unlike fighter controllers since at least the 1930s, X-Com ground controllers and/or onboard avionics are incapable of calculating a predictive course for a target that is moving, at a known course and speed, laterally relative to its bearing as seen from the intercept base (so that the bearing from the base is constantly changing). In other words, in any situation except when the alien craft is heading directly toward/away from the X-Com craft/base, a non-optimum interception course is used. Instead, X-Com craft simplistically just keep heading toward the current bearing toward the target. This results in inefficient parabolic intercept courses, rather than efficient straight line courses toward a predicted intercept point. Parabolic courses often fail to intercept, or give very brief interception windows, that would have been avoided by a proper predictive, straight-line course.<br />
<br />
==== Head-On Intercept Bug ====<br />
<br />
It is not possible for a slower-moving X-Com craft to intercept a faster-moving Alien craft, even if the X-Com craft is directly ahead of the alien craft and waiting in position to intercept it. This is true whether the X-Com craft is stationary, or flying in the same heading as the alien craft and at nearly the same speed. Even if the alien craft moves right through the X-Com craft's exact position while travelling only slightly faster than the X-Com craft. Interception only occurs if the alien craft voluntary slows down for long enough for the X-Com craft to catch it. <br />
<br />
(It's true that such interceptions would be difficult, whether attempted head-on at high closing speed - extremely brief period to fire - or tail-on at low closing speed - very easy for the alien to avoid entering X-Com craft's weapon arcs by breaking away. So it could be argued that making these interceptions impossible is just a simplification of the fact that they would be much more difficult than normal interception combat.)<br />
<br />
==== Instant Getaway Bug ====<br />
<br />
If you park an interception craft directly over a touched-down alien craft, the alien craft will still escape, if the alien craft has superior maximum speed. The alien craft basically seems to instantly accelerate to its maximum speed, with no concept of progressive acceleration. Interception only occurs if the alien craft voluntary slows down for long enough for the X-Com craft to catch it. This probably has the same root cause as the Head-On Intercept Bug (arguably it is a special case of the Head-On Intercept Bug).<br />
<br />
== Battlescape Bugs ==<br />
<br />
=== Load bug after successful mission ===<br />
After you finish a game you have saved and load the same game file again - the alien side goes first! I think it may be caused when you succesfully complete the mission and you get a notification like that the alien has died beacuse of no alien containment. The game still thinks that it is the aliens' turn. So when I load the mission again- the aliens move first. If you load the same saved game again it will be OK. [[User:ElfKaa|ElfKaa]]<br />
<br />
=== Faulty Large Units ===<br />
If you move a tank off a northward facing ledge, the rest of the tank will sink into a wall (if there is one), and cause the tank to get stuck. This won't happen if the tank moves off a south facing ledge as the primary quarter will fall after the rest of the tank. Aliens can also get stuck this way.<br />
<br />
Another, potentially annoying bug occurs when a large unit's graphics become messed up. During a base defense mission, a rocket tank may end up looking like 4 silacoids bunched together.<br />
<br />
===Unconscious Units are items===<br />
This is actually an intentional programming choice... but it leads to several consequences which are bugs.<br />
<br />
Firstly, any unconscious unit can be killed instantly by even a weak explosion, like being nearby an exploding AC-HE shell... even a Muton with 125 Health or an X-com agent in Flying Armor whose high armor ratings normally make him immune to AC-HE damage.<br />
Secondly, no experience is gained for killing enemies in this manner.<br />
<br />
You can prevent an unconscious unit's death from an explosion by picking it up... if a blaster bomb strikes the carrier and kills him, the unconscious unit will safely fall to the floor, unharmed.<br />
<br />
Unlike a conscious unit (not wearing x-com armor), an unconscious unit can laze about in the middle of a fire without taking damage, since a UNIT standing in fire takes damage, but an unconscious unit is an item, which all ignore fire.<br />
<br />
Forcing an MCed alien to pick up an unconscious X-com agent and carry him in its right hand can cause weird things to occur when you release the mind control. I think the game might crash when the alien tries to shove the agent into its magic pocket.<br />
<br />
If a non-flying unconscious unit wakes up while being carried by a flying unit, it will gain some sort of temporary hover ability. (I once placed an unconscious Chryssalid in my flying agent's backpack. A few turns later, some growls and screams were heard from overhead.)<br />
<br />
Save space! Each conscious unit takes up 1 tile (4 tiles for large units). An unconscious unit does not use up the tile... this might conceivably be useful if you wanted to abort a mission, but several panicked units were preventing other agents from boarding the skyranger... <br />
X-com agents refuse to ride piggyback or be picked up while conscious. So, if you want a non-flying unit to reach an 2nd floor place with no stairs or elevator, you will have to knock him out, then either throw him up, or have a flying unit pick him up and drop him... and presumably administer stimulant.<br />
<br />
This also leads to the INVISIBLE UNIT glitch. Frequently happens during Base Defence missions, since the item table is usually maxed out. Basically, the item table is so full that killed units do not leave corpses. However, this also means that unconscious units do not turn into the Unconscious Unit item. The KOed unit will disappear from sight, but will still be visible as a red number and as a blue/yellow dot on overhead map. Since the unit is still a unit and not an item, you will be able to shoot it with projectile weapons and kill it. ALSO, this method enables you to raise any unit's stun bar all the way to 255, since you can still increase the stun meter, despite them already being unconscious.<br />
<br />
===Funky Fire===<br />
If a unit (alien or friendly) is on fire or standing in flames, an [[Incendiary]] explosion ''anywhere else on the map'' will do a small amount of damage to it, even if you just shoot an IC round at a random patch of ground. <br />
<br />
Similarly, if a unit (friendly units only) is standing in smoke when an incendiary explodes, it will take stun damage. This makes the combination of incendiary munitions and smoke quite hazardous until such time as all troops are armored.<br />
<br />
<s>There is a [[Talk:Incendiary#Incendiary_Bug|working hypothesis]] for</s> The cause of this bug is that each and every Incendiary explosion triggers the "Smoke and Fire" routine: applying fire damage, applying stun damage from smoke, calculating fire and smoke spreading, and "catch on fire" checks for units in fire. <br />
<br />
Note that X-Com units wearing any kind of armor are immune to fire damage and IC-induced stun damage. Xcom HWPs are immune to stun, but take 40% damage from Incendiaries and WILL get killed quite efficiently by funky fire.<br />
<br />
=== Collectors Edition Blaster Bomb Bug ===<br />
<br />
Also known as Vertical Waypoint Blaster Bomb Bug. <br />
<br />
In the Collectors Edition of UFO, the [[Blaster Launcher]] has a bug that prevents it from going up or down on the same tile. Or in other words, you cannot change the elevation of the missile vertically on the same tile. <br />
<br />
Instead of flying down (or up) to the next waypoint, it will instead fly directly to the south at the pivot waypoint. Relative to the screen, this would be the lower left side of the screen. <br />
<br />
This does not happen if you plot the waypoints at an angle. Or, if the blaster bomb flies right off the map, it will reappear at the proper waypoint as long as there are additional waypoints placed after the vertical move. The bug makes it impossible to fire Blaster Bombs up or down elevator shafts. Aliens are also affected by this bug. <br />
<br />
The Blaster Bomb bug in turn permits the [[Tactical Exploits#Milking Alien Bases|Elevator Shielding - Base Milking Exploit]], which provides unlimited risk-free experience and ultra-low-risk booty, so fixing it is a Good Thing. Base Milking in general is a legitimate tactic, but doing Base Milking risk-free via the Elevator Shielding is just an exploit.<br />
<br />
This bug also applies to the [[Disruptor Pulse Launcher]] in TFTD.<br />
<br />
===Blaster Launcher Dud Shells Bug===<br />
<br />
Shots which have only one waypoint, or explode before reaching their first waypoint, leave the Blaster Launcher showing 0 rounds, but still containing a dud shell which must be unloaded before the launcher can be reloaded. On earlier versions of the game (pre-Win CE) this also happens with reaction fire, and with 1-waypoint shots that fly off the map. <br />
<br />
=== The trouble with Mines in General === <br />
<br />
Proximity mines are strangely implemented in UFO and TFTD. While they behave as you would expect them to half of the time, the mines do not behave like conventional weapons. <br />
<br />
First, experience attribution is awarded to the person that sets off the mine. <br />
<br />
Secondly, the armed states for [[Proximity Grenade]]s in both UFO and TFTD are NOT stored in save games. If a proximity grenade is primed, then the game is saved and reloaded, the grenade will not only not go off as it should, but the "Prime Grenade" action will still be absent, so it's impossible to re-arm it.<br />
<br />
=== Grenade Timer Behaviour === <br />
<br />
A primed explosive (Grenade, High Explosive, Alien Grenade) will not explode if it's still in your inventory (hand, belt etc) when the timer runs out. It will only detonate when it's on the ground. If your soldier falls unconscious or gets killed, the primed explosive will be counted as being on the ground. Then it will blow up, likely taking out your gear and body. This 'feature' allows for the hot potato or [[Grenade Relay]] strategy which is fairly unique to X-COM where a live grenade well past its use-by date can be passed from squad member to squad member. <br />
<br />
For a more a detailed explanation on detonation conditions, see [[Understanding Grenades]].<br />
<br />
=== Mountain Map ===<br />
Due to a bug in the way this tileset was created, when you shoot the ground, it doesn't burn up - it turns into a tree stump.<br />
<br />
Because the stump is on object, as opposed to actual ground, any objects that were in the tile already (for example, UFO hulls or the landing gear of your craft) get replaced by these stumps, making it seem as if they were destroyed.<br />
<br />
Tree stumps don't take much damage, so they often get burnt up immediately if an explosive goes off, leaving nothing but burnt ground behind. It is easier to view the effects of this bug by shooting the ground instead.<br />
<br />
For more details, see [[Explosions#Mile-High_Madness|Mountain Madness]].<br />
<br />
=== What just exploded? ===<br />
In some versions of the game, a bug allows an armed proximity mine to transfer its properties to some other item in the next mission, which then may explode unexpectedly. (If the item is left on the floor of the XCOM craft, it will explode as you walk past it.) This problem can be rectified by reloading the game -- as a precaution, save before you move your first soldier.<br />
<br />
=== Door jam ===<br />
If a door is open when a game is saved on the Battlescape and that game is subsequently restored, the door will remain open for the remainder of that mission.<br />
<br />
<br />
=== MIA Bugs ===<br />
<br />
A number of bugs cause units to be unexpectedly listed as MIA. In the case of X-COM units, this also means the soldier is permanently lost from your roster, probably along with any armour/equipment carried. <br />
<br />
====Mind Controlled Soldiers go MIA====<br />
If you complete a mission successfully while a [[soldier]] is currently [[Mind Control]]led he will be listed as MIA at the end of the combat. This is quite an easy bug to fall into as on any [[Sectoid]] or [[Ethereal]] mission the only, or most powerful, psionic aliens will usually be holed up in the bridge or command centre, which is the likely location of the final combat turn.<br />
<br />
====Stunned Mind Controlled Soliders go MIA====<br />
Similarly an X-COM soldier who was Mind Controlled by the aliens and then stunned (usually by X-COM), and who is still stunned at the end of the mission (victory or abort), will count as MIA. Presumably the game does not set the ownership flag on the unit back to XCom's side until the unit wakes up. <br />
<br />
====Mind Controlled Aliens Count as MIA if you Abort====<br />
If you happen to abort a mission with any Mind-Controlled aliens under your control, who are NOT in the dropship, the computer tallies them up as "X-COM Operatives Missing In Action." Thus, every Mind Controlled alien left behind when you dust off is -20 points to your score! If you're leaving anyways, avoid this by bringing them back to the ship or mowing them down on the way back to the ship.<br />
<br />
In the Playstation version of the game, any aliens under Mind Control at missions end are considered captured and hence, this bug is not a factor.<br />
<br />
====Stunned, Carried, Not Dropped Soldiers are MIA on Abort====<br />
<br />
If a soldier is stunned anywhere outside the transport and then carried back to (or thrown into) the transport for an Abort, they are still considered MIA. The game considers them to be still at the location where they were stunned and picked up from. You must drop the soldier on the ground in the transport in order to recover them back to base in an Abort. Throwing into the transport does not work. <br />
<br />
====Stunned Inside, Thrown Outside Soldiers not MIA on Abort====<br />
<br />
A soldier who is stunned inside the transport and then thrown (not dropped) outside the transport prior to a mission Abort does not count as MIA, but is successfully recovered back to base. This is presumably because throwing does not reset the location of the unit. <br />
<br />
===20 Proximity Grenade Limit===<br />
<br />
The array used to denote armed [[Proximity Grenade]]s is limited to 20 entries, meaning you are limited to 20 active mines at a time. The 21st and subsequent Proximity grenades can be primed like normal and will give appropriate messages, but they will not detonate even when the normal trigger conditions are met. Note that Proximity Mines that have detonated or otherwise been destroyed are removed from the array, freeing up positions; the limit is 20 ACTIVE Proximity Grenades at one time. In normal gameplay, this is probably not a restriction, in light of the [[Known_Bugs#80-Item_Limit|80 Item Limit]], since you'd need to have more than 1/4th of the cargo space in the dropship filled with Proximity Grenades.<br />
<br />
===Base Defense Elerium bug===<br />
<br />
On DOS versions of UFO Defense, Elerium pods may spawn as items from the base stockpile during a Base Defense bug. Each pod represents 50 units of Elerium and will be normally collected after the mission, same as any other item such as Heavy Lasers or Blaster Bombs. HOWEVER. The program will potentially generate 1 elerium POD for every 1 UNIT of elerium in your inventory. Thus, if you had only 10 lasers and 50 Elerium listed in your Sell screen, you would see 10 lasers and 50 Elerium Crystals in your Soldier Equip Screen, which would translate to 50 Elerium pods and 10 lasers scattered around your base. This equals 2500 Elerium, BTW. You basically have the potential to multiply your elerium stocks by 50.<br />
<br />
===Berserk HWP crashes the game===<br />
<br />
Admittedly, this is unlikely to arise under normal play. But, anyhow, your HWPs can only lose morale by killing friendly units. Not much for each unit killed, either. Anyhow, a berserk HWP will crash the game. (except for the Hovertank/Launcher, which does not fire when it goes berserk.)<br />
Likewise, if you MC a cyberdisc or Sectopod and have it kills lots of aliens, it'll go berserk and crash the game. The error happens because of an oversight from the developers: the built-in weapons of HWP are handled differently from handed weapons, no OBDATA.DAT entries exist for them. The berserk code will try to access the nonexistent entry, resulting in a crash. The Celatid has yet to be tested.<br />
<br />
''The part about HWPs only losing morale by blue-on-blue isn't true: I had a rocket tank go berserk on me in a terror mission when a floater blew up my whole force with a single grenade in the first alien turn. The game crashed alright; I have the CE version with UFOextender.--[[User:Amitakartok|amitakartok]] 08:24, 11 January 2012 (EST)''<br />
:''Unless my memory is playing tricks on me, I clearly remember an very bizarre incident like yours but where the rocket HWP panicked (all other X-COM units had just been killed) but the game didn't crash (I play the DOS version) and the tank shot all its rockets randomly until it ran out of ammo. I remember that its TU numbers being while firing showed 255 TUs or some other impossible value (I hadn't done any manual edits). I don't remember if it crashed at the end but it did fire!'' [[User:Hobbes|Hobbes]] 10:47, 11 January 2012 (EST)<br />
::''And this reminds me of yet another panicked HWP incident but involving a Cannon HWP. I was expecting it to waste all its ammo (based on my previous experience) but it only fired a few shots and the TU level didn't went up crazy.'' [[User:Hobbes|Hobbes]] 10:47, 11 January 2012 (EST)<br />
<br />
===Limited Unit Slots - Battlescape Crash===<br />
<br />
This tends to arise during Base Defence Missions. The game is was designed to be limited to 40 soldiers/hovertanks and XXXX aliens for a total of XXXX . Having a full complement of soldiers during a Superhuman difficulty base defence will max out these limits. Thus when either side starts playing around with mind control too much, something goes wrong causing the entire game to crash.<br />
It might also be something to do with maximum items on the battlescape.<br />
In any case, the workaround seems to be killing aliens and destroying items on the battlescape... doesn't always work, but it seems to help.<br />
You might want to make several in-battle saves for these situations, even if you normally play Ironman mode.<br />
<br />
===Left arm fatal wound instead of torso (energy penalty)===<br />
<br />
According to UFO Defence [http://cdn.steampowered.com/Manuals/7760/x-com%20ufo%20defense%20manual.pdf manual], torso fatal wounds affect energy replenish rate, which is logical. But in the game fatal wounds of the '''left arm''' affect energy replenish rate, '''not the torso'''. Which is an obvious coding bug (though not a fatal one).<br />
<br />
===Invisible Chryssalids===<br />
<br />
After reloading a saved game with a mission where zombies are present, the resulting Chryssalids might be invisible. This only happens when zombies are present but all Chryssalids are either dead or KO. This issues occurs because the load-game routine only loads graphics files for active units. When the chryssalids' files are loaded, the game also loads the files for zombies but this is not true in reverse. [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])<br />
<br />
== Character Inventory Bugs ==<br />
<br />
=== Alien Inventory Stacking Bug ===<br />
<br />
'''WARNING:''' When examining an Alien's inventory (via an Exploit), you will see that sometimes the alien will stack multiple items of equipment on the same slot - its right leg. It's not always obvious that there are multiple objects in the slot until you 'pick up' the first object and can see other objects still in the slot. <br />
Before you remove an item from the Alien's right leg, make sure you have enough time units to place it somewhere else. If you run out of time units, you will likely have to force a quit and cannot save your game. It '''may''' be possible to move the item to the left leg slot for 0 TUs, '''if''' the item will fit in that slot. If not, you will have to terminate the game. (Press ALT-TAB to get to any other window, then CTRL-ALT-DEL to bring up Task Manager, and then terminate the process that corresponds to the game).<br />
<br />
=== XComUtil Inventory Stacking Bug ===<br />
<br />
A problem similar to the Alien Inventory Stacking Bug can also occur for X-COM Soldiers, when using XComUtil. The algorithm used to assign weapons in XComUtil MUST assign all weapons to troops, so if there are more weapons than soldiers, excess weapons are stacked onto the leg slot of the first soldier in the dropship. This was a deliberate choice by Scott Jones to make this encumbrance obvious to the player. This can be readily corrected in the "equip soldiers" screen before a mission. Else, see "Alien Inventory Bug", above.<br />
<br />
=== Item-stacking Bug ===<br />
It is possible to put more than one item in a given spot. When an item is stacked with a [[Stun Rod]], this can make it possible for X-COM soldiers to perform "melee" attacks. See [[Item Stacking Bug]] for more details.<br />
<br />
===Carrying Unconscious Units===<br />
If one of your soldiers is carrying an unconscious unit in their hands and the unit either wakes up from stun or dies, they will be removed from the Inventory display, but will still appear to be in the carrying soldier's hands in the Battlescape. Clicking on the phantom body in the Battlescape will crash the game!<br />
This error can be easily cleared by switching to the Inventory screen and moving another item into the hand that used to be carrying the body. Even swapping the gun to the other hand will do. Refer to : [[Unconscious#Bug|Unconscious]].<br />
<br />
===Disappearing Ammo===<br />
Partially-used clips in alien or X-COM weapons disappear at the end of a mission. This dictates that you should try to use clips that are not full. However, in DOS versions of the game, you can unload used clips to recover them as full clips with the tradeoff of all loaded clips (used or otherwise) will count as spent and disappear (this shouldn't seem to be a problem, until you start using blasters and will find that you're running out of ammo fast). You can also use [[XcomUtil]] to recover partially used clips. Even when used clips are discarded, you will still get credit ([[Scoring|score]]) at the end of missions for recovering them.<br />
<br />
When aborting a mission, any full clips loaded in any alien weapons brought back to the transport/access lift will not be recovered unless the clips are unloaded first. This includes [[Blaster Bomb]]s and [[Stun Bomb]]s.<br />
<br />
=== Ammo Weight Bugs ===<br />
<br />
In general, the game engine handles the weight allocation of ammo/clips '''loaded into weapons''' very badly. There was a good design to handle ammo weight, but it was not properly implemented. As a result there is a set of bugs relating to ammo/clip weight and encumbrance that share overlapping causes and effects.<br />
<br />
==== Equip Phase Ammo Load Error ====<br />
<br />
The game routine for placing ammo into weapons at the beginning of the equip phase does not correctly set all object and unit values. It should set the ammo as loaded into the weapon, the weapon as being held by the soldier, and the map position of the weapon and the ammo as the same as the soldier. Looks like it does not do one or more of these things. Whatever values the game doesn't set, do get set if you manually load or reload the weapon, either during the equip phase, or during the game. <br />
<br />
Specifically, the game's auto-equip functions at the beginning of the equip phase fail to set offset 0x04 of the [[OBPOS.DAT]] record to point to the soldier who owns the ammo. These functions leave the value = 0xff, which implies "on the ground". They also leave the ammo location as being the equipment pile, rather than the location of the soldier. The other values are set correctly. Manually loading ammo into a weapon, during the equip phase or during combat, correctly sets all values. The ownership points to the soldier and the location to the soldier's location. <br />
<br />
This bug is the cause of [[Known_Bugs#Weightless_Loaded_Ammo|Weightless Loaded Ammo]]. Probably the only other impact of this bug is that XComUtil can't detect the fact that the ammo is loaded into the weapon, for the purpose of AutoCombat. It might have other subtle effects on any utilities that deal with equipping soldiers. <br />
<br />
====Weightless Loaded Ammo====<br />
<br />
Ammo that is automatically pre-loaded into a weapon at the start of the Equip Phase of a mission does not initially count towards any soldier's carried weight (Encumbrance). If the weapon is subsequently unloaded during the Equip Phase or later in the mission, the soldiers encumbrance will ''increase''. This will probably only be noticed if the unloaded clip was not discarded (e.g. because it was not fully empty). This is due to a bug in the game's original weight calculation routine that was uncovered (but not caused) by Seb76's inventory screen improvements.<br />
<br />
The Weightless Loaded Ammo bug slightly advantages X-Com. It leads to a set of relatively minor exploits. Using this bug, you can get weak soldiers to carry heavy weapons with (usually) a single clip and no TU penalty. For weapons that use multiple ammo types (which auto-equip with AP by preference), by manipulating the overall supply of ammo of different types you can to some extent persuade the auto equip algorithm to load your preferred ammo type for these weaker soldiers.<br />
<br />
[[User:Spike|Spike]] 22:51, 6 September 2012 (EDT)<br />
<br />
==== Displaced Ammo Weight ====<br />
<br />
'''Guidance: Apart from weapons pre-loaded by the game, be sure to unload any weapons before dropping them. Drop, pick up and transfer ammo only when it is not loaded into a weapon.'''<br />
<br />
Dropped ammo clips that are still loaded into dropped weapons are not un-assigned from the unit carrying them. The weight of the ammo / clips continues to count against the unit's [[Time Units#Encumbrance|Encumbrance]] as 'displaced weight' that can't be removed by ordinary means. This is an original game bug that only becomes apparent when using mods that display the unit's current encumbrance. The effect continues until the ammo is unloaded (either by the original holder picking up the weapon again and unloading it, or someone else picking it up and unloading it). Once the ammo is unloaded, its weight is applied to the actual current holder, only, and is released from the original holder. <br />
<br />
This bug also applies during the Equip Phase, if one soldier loads a weapon, drops it, and another soldier picks it up. <br />
<br />
In some senses this bug is the opposite of the Weightless Ammo Bug, and each bug has probably tended to obscure the effects of the other. For example, clips affected by the Weightless Ammo Bug (clips automatically loaded by the game) are not so obviously affected by this bug, since their displaced weight is 'carried' by the Equipment Pile rather than any specific Soldier. (In another sense, this is the same bug, with the weight displaced to the Equipment Pile rather than to another soldier.)<br />
<br />
See [[User_talk:Seb76#Inventory_screen_ammo_weight_bug|this discussion]] for more information on this bug.<br />
<br />
==== Ammo Weight Exploits ====<br />
<br />
As noted above, Weightless Ammo is, in itself, a minor exploit, since it provides some extra penalty-free carrying capacity in combat. <br />
<br />
On the face of it, the Displaced Weight Bug is not an exploit, since for every decrease in weight on one soldier there is a corresponding increase in weight on another soldier. However the Displaced Weight bug could potentially be exploited by having one soldier first load and then drop a lot of weapons, and then move away from the resulting pile to allow others to pick up. This would create a reserve of weapons where all the ammo weight was being 'carried' by this "weight sink" soldier, freeing up encumbrance for other soldiers. For example, all recon and front line soldiers required to be mobile could get reduced weight, at the expense of a single soldier having extremely reduced mobility/TUs. However, as the game's auto equip routines already load all initial weapons with weightless ammo, this would only be useful after combat had been progressing for some time, for reloads rather than initial loads, and it would require the squad to regroup around this "sink", or ferry weapons to/from the "sink". It might be most useful with Rocket Launchers (high weight, high ammo weight, one round before reload).<br />
<br />
Hypothetically, Displaced Weight could be exploited to overflow the Weight value of a unit and allow that unit to carry massive weight with minimal encumbrance. For example, carrying 32 rocket launchers and 32 rockets (ammo weight 256) into combat. There is not enough Equip space in the Equipment Pile to manipulate this equipment pre-combat, as the loaded weapons must be dropped, and there is only enough space for 20 rocket launchers in the Equipment pile, so the remaining manipulation would have to be done during combat time (and over more than one Battlescape square). However, it looks like the Weight subroutine and the value it returns into are both bigger than 2 byte numbers (256). There is no way to push Displaced Weight into the 32,000 or 64,000 range with using some kind of game file editing or hacking/modding. <br />
<br />
[[User:Spike|Spike]] 09:06, 29 September 2012 (EDT)<br />
<br />
== Storage and Transfer Bugs ==<br />
<br />
=== 80-item Limit ===<br />
When loading up your Avenger for a massive UFO assault or arming soldiers for a [[Base Defense]] from your overflowing stores, you will likely hit this limit. <br />
<br />
You only get a max of 80 items, and you don't get to choose which ones, so you may end up with 80 clips and no rifles for the base defense. <br />
<br />
The solution is timely housekeeping. Sell off your spare personal equipment. See our handy [[Spring Cleaning Tips]], and also [[Managing the Item Limit]] for ideas.<br />
<br />
Another bug concerning this limit happens when there are unresearched (alien) items in your stores during a base defense mission. Even though the item cannot be used during the mission, the game still allows you to equip your soldiers with them. This rarely happens as the alien items are very low on the item list, but if your base is lean and mean with under 80 items total, everything will spawn regardless of research.<br />
<br />
===Sticky Craft Transfer Fee glitch===<br />
As pointed out by [[User:Zombie|Zombie]] and [[User:Danial|Danial]], transferring any craft causes '''''all subsequent transfers to have that cost added to it''''', for as long as the craft is in transit. Additional craft in transit will add additional fees. (This has also been called the Exponential Transfer Fee bug, although it's actually additive, not exponential.)<br />
<br />
Example (all numbers are only approximations):<br />
<u>Cost of pistol transfer (&harr; = to or from)</U><br />
EU &harr; USA 80<br />
EU &harr; Asia 100<br />
USA &harr; Asia 120<br />
<br />
<u>Cost of craft transfer</U><br />
EU &harr; USA 1600 ''Notice how transfer fees always work as relative percents,<br />
EU &harr; Asia 2000 ''probably on a distance-based formula<br />
USA &harr; Asia 2400<br />
<br />
<u>Cost to transfer '''pistol''', after transferring craft from EU to Asia for $2000</U><br />
EU &harr; USA 1680 (80+1600)<br />
EU &harr; Asia 2100 (100+2000)<br />
USA &harr; Asia 2520 (120+2400)<br />
<br />
The cost of the craft transfer "sticks" to '''all''' subsequent transfers, until the craft arrives - although it acts on a proportionate basis, which is probably distance related.<br />
<br />
Unfortunately, this cost is '''additive'''. That is to say, if you transferred a second craft from EU to Asia while the first was still in transit, it would cost $4000 ($2000 plus $2000 - it too suffers from the glitch!), it would then cost e.g. $4100 to transfer a pistol from EU to Asia. Having even more craft in transit would add even more fees.<br />
<br />
This only appears to happen with aircraft, although it does happen for them all. So try to transfer aircraft individually, and not transfer anything else while you do - assuming you aren't awash in money. (The bug will cost you in the low thousands of dollars per craft being transferred.)<br />
<br />
A related problem is that, if you are in the Transfer screen, start to transfer a craft, and then cancel because you remembered you wanted to send something else first - if you then try to Transfer something on that same screen, ''it will still get the sticky craft fee added''. Try it and see. You have to back up out to the main Base screen and hit Transfer again, to get rid of the sticky fee from a canceled craft transfer.<br />
<br />
===Fuel dump on transfer===<br />
Transferring a craft with 100% fuel will dump it somewhere along the way. <br />
When it arrives at its destination, its fuel gauge will read empty (ie: 0% FUEL), but it will be listed as ready. If you launch your craft for a mission (any mission will do) its fuel gauge will still read empty. <br />
<br><br />
This can be [[ExploitsA#Infinite_Fuel|exploited]], but it is very annoying if you want to quickly turn around a troop transport for another mission. <br />
<br><br />
You can force a refuel by sending out the craft and immediately recalling it back to base.<br />
<br />
===Transfer Limit cash eater===<br />
Only 100 items can be in transit at a time. (Here, a transfer of e.g. 200 Elerium counts as one "item". Also, all soldiers are counted individually.) If you go over the limit, you will get a warning that there is no more transport capacity. If you STILL try to transport something after getting the warning, the item will stay where it is, but the transportation cost still gets deducted. Bad if you're shuffling expensive aircraft. The extra cost isn't that bad. Recovering just one alien weapon will likely cover the money you will lose to this bug over the course of a game.<br />
<br />
{| {{stdTable}} width = "80%" align = "center" <br />
|- {{stdTable Heading}}<br />
| Tip<br />
|-<br />
| To Clarify what constitutes an item in the transfer screen, think of them as batches of X amount. For example, if you transfer 200 alien alloys now, and then decide to transfer another 50 alloys later, this will count as two items in transit. Now, when you look at your transfers, you'll now have two items. Two batches of alien alloys, one with 200 units and the other with 50 units.<br />
|}<br />
<br />
=== Transfer crash ===<br />
If you transfer something to another base the game crashes right after acknowledging the transfer price.<br />
<br />
Solution: Start UFO, select English language, finish your transfer, save game, restart with your normal language settings (http://www.xcomufo.com/x1faq.html)<br />
<br />
===Purchase Limit===<br />
The purchase limit for any item you buy via the purchase screen is 255 per line item, because it is a one-byte field. However, the impact of this bug is small, for if you have space remaining in your 100-item transfer queue, you can immediately order another 255 of said item as another line item.<br />
<br />
===Storage Limit===<br />
You can not store more than 9,999 of any one item in the general stores at a specific base at one time. However, this will likely only happen with [[Alien Alloys]] or [[Elerium-115]]. <br />
Still, consider yourself warned. If you're coming close to the limit, consider transferring the extra to other bases or even selling it, as any extra collected beyond the limit will 'disappear' and be wasted.<br />
<br />
===Exceeding Storage Limits===<br />
<br />
The storage capacity of a base is normally limited by the capacity of the General Stores. However this can be exceeded in a number of ways:<br />
<br />
* By exploiting some of the Base Storage Anomalies (see below)<br />
* By storing surplus equipment in transport aircraft (up to the 80 item limit). Note that if both the aircraft and the base are full, you can no longer move equipment between the aircraft and base (in either direction). <br />
* Anything manufactured at the base will be stored there regardless of the base's General Stores capacity. <br />
* Anything captured on a mission by an aircraft operating from the base will be stored at the base, regardless of the base's General Stores capacity. <br />
<br />
These could perhaps be considered minor exploits.<br />
<br />
===Base Storage Anomalies===<br />
<br />
There are some quirks in how the game calculates, and displays, base storage capacity used and available. These quirks are not all consistent with each other, which leads to some strange behaviour. A typical example would be moving a set of items out of Stores, immediately trying to put the exact same set of items back into Stores, and this failing due to "insufficient space". A more detailed discussion is in [[Talk:Base Stores#Base Stores Anomalies]].<br />
<br />
===Exceeding Storage Limits when Transferring Craft===<br />
<br />
Usually you can't transfer crafts to bases without capacity for them as you'll get an error when you press the Up arrow. However, if you press the Down arrow when the craft quantity is already at 0, the game will still think you're removing crafts from the destination base and "add capacity", so you can then press the Up arrow again to transfer the crafts without error. This doesn't work with other transferable items.<br />
<br />
Once you've broken the limit once, you don't need to do this trick anymore as the error won't show up again (the game probably doesn't check for negative capacity). You can also exceed storage and personnel capacity this way, as Transport Crafts will carry their contents over. For example, if you press the Down arrow on a Skyranger with 14 soldiers, the game will "add capacity" for 1 craft and 14 personnel on the destination base.<br />
<br />
You can also orphan crafts this way by removing a base with crafts but no hangars, which can cause all sorts of weird behavior.<br />
<br />
===50 Unit Limit for Captured Aliens[[http://www.ufopaedia.org/index.php?title=Alien_Containment#Functionality]]===<br />
<br />
You can only ever have 50 captured aliens in [[Alien Containment]] at any time, no matter how many you build, no matter what base they're in.<br />
<br />
== Soldier Limits and Recruiting Bugs ==<br />
<br />
=== Soldier Recruiting Limit ===<br />
<br />
There is a hard limit in the game of 250 X-COM soldiers in total across all bases (not 250 per base).<br />
<br />
The error message that pops up when you try to hire more is: <br />
<br />
"NO MORE SOLDIERS ALLOWED"<br />
<br />
"You have already recruited the maximum number of soldiers."<br />
<br />
=== Soldier Recruiting Bugs ===<br />
<br />
Also there are 3 bugs related to recruiting soldiers: <br />
<br />
* You still get charged for Soldiers you try to purchase above the No More Soldiers limit.<br />
* The error message that appears when you hire too many soldiers must be dismissed (click OK) once for each soldier over the limit, i.e. up to 255 times. <br />
* You get also charged for Soldiers you try to purchase above the Transfer Limit (100 at a time).<br />
<br />
=== Soldier Battlescape Limit ===<br />
<br />
In the Battlescape, there is a limit of 40 X-COM soldiers that can participate in any battle. Tanks/HWPs each count as 4 soldiers against this limit. Unless you use custom-modified aircraft, you will only see this limit in a Base Defence mission. In a Base Defence mission, all tanks/HWPs will be deployed first, in preference to soldiers.<br />
<br />
== Manufacturing and Research Bugs ==<br />
<br />
=== Zero Unit Manufacturing Exploit ===<br />
<br />
If you start a manufacturing project with zero items to build, close the screen, and then go back to assign staff and a non-zero build amount later, the first item is built for free. If you only build one item at a time, you can build them all for free. Obviously, this is cheating. It's also a bit tedious. It might be excusable if you're really short of money.<br />
<br />
=== Research Rollover ===<br />
<br />
At midnight, research projects are checked for completion in the order shown on your Projects screen (which is the same order as for picking new Projects, for [[RESEARCH.DAT]], etc.). But X-COM does not track the effort of individual scientists, so when a project ends, its scientists can be re-assigned before the game checks the next project.<br />
<br />
The upshot is that you can re-use scientists from completed projects as long as you put them on projects (existing or new) that are [[RESEARCH.DAT|farther down the list]] than the one that just finished. And if you assign more scientists than projects need, you can finish multiple projects immediately! <br />
<br />
To best use this exploit:<br />
*If projects (new or existing) have equal priority to you, start new scientists at the top of your list (the [[RESEARCH.DAT|lowest-numbered]] project) and work them "down" from there. This minimizes the number of times that scientists wind up at the end of the project list (where you can't exploit them).<br />
*It works especially well later in the game if you have a full complement of scientists (practical limit of 250 at a base) and apply them to the many "fluff" alien, corpse, and alien-room projects that [[Research_Technical_Details#Research_Time|average less than 250 research days]]. You might finish a lot at once.<br />
*If using it, you don't have to worry about "wasted" research effort due to allocating too many scientists to a project on its last day. Unless you're at the end of the project list, wasted scientists can be re-used, too - sometimes many times.<br />
<br />
=== Overcrowded Engineers And Scientists ===<br />
In the Dos version (probably the others as well) if you hire more than 255 engineers in a single base, the number of engineers in the base will read a negative number once the 257th engineer arrives. Any Engineers engaged in projects will continue to work on them, but if you cancel the project you will lose engineers until you have lost 255 of them. <br />
This bug also affects scientists. It may be exploitable to pay a negative salary at the end of the month.<br />
<br />
If you hire exactly 256 scientists or engineers, the total rolls over to zero. You pay zero salaries, and the resulting free Manufacturing / Research is limited only by the capacity of your Factories / Laboratories. Also works in TFTD.<br />
<br><br />
NOTE: you need to make sure that not all of their projects finish at the same time.<br />
Otherwise, you would be stuck with 0 'available' workers/scientists, i.e. unable to assign them to a new project.<br />
<br />
===Manufacturing Limit Bug===<br />
The number of hours remaining on a [[Manufacturing_Profitability#Profit_tables|manufacturing project]] is stored in a two-byte integer. If you build enough items that the total number of Engineer Hours required for construction is above 65535 hours, it will wrap around to 0 hours and display from there. Typically this drastically understates the amount of time that will be spent working on the items, but strictly speaking, it only subtracts 65k hours (so a huge project like 120k hours would still show ~55k hours' worth of Engineer time needed).<br />
<br />
This bug is not dependent on the number of engineers assigned to the project; it is a function of the number of engineer hours needed. You will most likely run into it when trying to build 2 Avengers at the same time or when queuing up large orders of items in bulk, such as armor or Laser Cannons. As a practical example, the number of Avengers needed to trigger the bug is 2. The number of Laser Cannons is 219. Toggle back and forth between 218 and 219 laser cannons at the beginning of a project to see the effects.<br />
<br />
It is known with certainty that this exists as a display issue - the screen will say you need less time than you should when you go over 65536 Engineer hours. [[User:Arrow Quivershaft|Arrow Quivershaft]] is also sure he's seen it eat an Avenger... he ordered two but only got one, even though it took the time, and cost the money, for two. He's tried to replicate this and hasn't been able to, however. So it clearly is at least a superficial display issue, and may be more than that ... possibly dependent on even something else. In any event, keep an eye on projects with more than 65k Engineer hours (and report back here!)... or just avoid going that high.<br />
<br />
===Manufacturing Completion Time Display Bug===<br />
<br />
If you start a new manufacturing project at 00:01, and the screen displays a completion time of 5 hours, you might expect the work to complete at 05:00 or 05:01. In fact it will complete at 06:00, one hour longer than indicated. <br />
<br />
The reason for this bug is that the time left to complete a project is decremented by the game by one hour, every hour, on the hour(XX:00).<br />
<br />
This display behaviour is consistent with what is shown while manufacturing is in progress. For example, if time remaining is shown as 0 hours, the work will complete at the beginning of the ''next'' hour. In effect, the displayed number is the integer-truncated form of the real time remaining. In the first example given above, the real time to completion is 5 hrs 59 min, misleadingly truncated to 5 hrs.<br />
<br />
===Manufacturing Rate Interruption Loss===<br />
<br />
In addition, as a result of integer truncation (see previous bug, Manufacturing Completion Time Display Bug), every time production stops, you lose an hour of manufacturing. Therefore, for most efficient production, manufacture in large batches (or increase batches while they are still in progress) to keep manufacturing as continuous as possible. <br />
<br />
<br />
===Manufacturing Rate Limit===<br />
<br />
There is a maximum production rate of one unit of any given type per hour per base. For example, though Alien Alloys / Aqua Plastics require 100 Engineer/Technician Hours per unit, even with 250 Engineers/Technicians you can only produce 1 unit per hour.<br />
<br />
===HWP Fusion Bomb Ammo Cost Bug===<br />
<br />
The HWP Fusion Bomb ammunition type, and its TFTD equivalent the ammunition for the SWS PWT/Displacer, appear to have the wrong manufacturing costs. <br />
The vehicle version is ''less'' portable and ''less'' powerful than the personal version (Blaster Bomb), ''less'' capable than the craft version (Fusion Bomb) - and costs ''more'' than either of the others in total cash and in materials. In particular, it makes no sense that the small missiles on the HWP/SWS use up ''more'' of both Elerium/Zrbite and Alien Alloys/Aqua Plastics than the Craft version. <br />
<br />
To correct this error, the craft round should have the higher base price, ''and'' the material requirements that are currently assigned to the SWS/HWP round. (It's debatable whether the SWS/HWP rounds should be more expensive than the man-carried rounds.) More discussion is on the talk page of this article.<br />
<br />
== UFOPaedia Errors ==<br />
<br />
=== UFOPaedia Craft Weapon Hit Probability Bug ===<br />
<br />
There is a bug in the in-game UFOPaedia. It mistakenly reads the damage value field when reporting the hit chance for a craft weapon. Hence:<br />
<br />
* Cannon shows 10% not 25%<br />
* Avalanche shows 100% not 80%<br />
* Laser Cannon shows 70% not 35%<br />
* Plasma Beam shows 140% not 50%<br />
* Fusion Ball shows 230% (!!!) not 100%<br />
<br />
Possibly the reason this bug was missed during testing is that the first weapon in the data files, Stingray, actually does have Damage equal to its hit probability.<br />
<br />
In the CE version, this is the problem piece of code:<br />
.text 45B2CC: 0F BF 4E 06 <br />
<br />
Change the 06 to 04. The offset may not be correct for everyone but it should be close. I don't know the offset in the DOS version.<br />
[[User:Morgan525|Tycho]] 06:27, 1 April 2012 (EDT)<br />
<br />
=== UFOPaedia Craft Weapon Reload Rate Bug ===<br />
<br />
From empirical research it looks like the reload rates of craft weapons are not stated correctly in the UFOPaedia. For example, the rates of fire of the Laser Cannon and Plasma Cannon are actually the same as each other, and they are both about six times slower than the regular Cannon (so about 12s) - whereas the UFOPaedia entry gives the reload times (inverse of the rate of fire) as being:<br />
<br />
Cannon 2s<br />
Laser Cannon 4s<br />
Plasma Beam 6s<br />
<br />
Similarly the UFOPaedia shows the Fusion Ball as having 3/5 the rate of fire of a Stingray missile, with the Fusion Ball being slower than an Avalanche missile; but empirically the Fusion Ball and Stingray have the same rate of fire, and so the Fusion Ball is faster than the Avalanche. See the discussion in [[Craft_Combat_Mechanics#Observed_Rates_of_Fire|Craft Combat Mechanics - Observed Rates of Fire]] for more details, but keep in mind recent code digs have clarified the picture from this initial rough approximation. It seems reasonable to assume the actual reload rates are coming from a different part of the executable, different to the locations used populate these values that are displayed in the UFOPaedia. [[User:Spike|Spike]] 23:25, 6 September 2012 (EDT)<br />
<br />
== Other Bugs ==<br />
<br />
=== Difficulty Bug ===<br />
The DOS version has a problem where no matter what difficulty level you choose, it will revert to "Beginner" level after the first mission. This is caused by one incorrectly set bit in all DOS versions of the game (1.0 through to 1.4). The Collectors Edition Windows port (also commonly known as UFO Gold or CE) does not have this problem. To check your [[Difficulty Levels|Difficulty Level]]:<br />
*Look at offset 60 in [[IGLOB.DAT]]. (If this file is only 60 bytes long, you've got the bug!) <br />
*Look at [[Alien Stats|statistics for aliens]] in your game with a [[Mind Probe]] or [[Psi-Amp]]<br />
<br />
To fix the Difficulty Bug, you can install [[XcomUtil]] and it will repair this bug. Alternately for those familiar with hex editing, you can fix this bug by referring to the appropriate section on the [[GEOSCAPE.EXE#XCOM: UFO Defense DOS Versions, difficulty setting bug | GEOSCAPE.EXE]] article and manually setting the incorrect byte to its proper value. <br />
<br />
:[http://tvtropes.org/pmwiki/pmwiki.php/Main/X-COM This TVTropes page] has been known to state that due to the bug, players asked the developers to increase game difficulty. The rumour goes that a new bug was supposedly introduced as a result, where TFTD's difficulty would reset to Superhuman instead of Beginner. The facts of the matter are that, while the overall difficulty of the game ''was'' increased, TFTD does manage to correctly keep track of which specific mode you're supposed to be playing in.<br />
<br />
=== Chrysallid / Tentaculat Difficulty Bug ===<br />
<br />
Stats of Chrysallids or Tentaculats that emerge from Zombies during combat have stats that ignore the difficulty level.<br />
<br />
=== Big Text Bug ===<br />
There are a few bugs in XCOM, especially early versions, that can build up and make the game unstable enough that it crashes and prints out a screen full of green 40-column text, essentially debug or memory dump information useless to you.<br />
<br />
You can also forced a crash by pressing CTRL-C at the start of a new game (DOS only). If you don't have any missions automatically saved within the [[Game_Files#Missdat_Files|MISSDAT]] folder, you will get this big text to appear. Typically it is green for Enemy Unknown, and blue for Terror From The Deep. Other colours have been observed such as pink, purple, brown and yellow.<br />
<br />
In the dos version, the text that you see is simply a memory dump in mode-13h (the 320x200x256 colour screen resolution) and the text colour is based off the changes to the palette that the game made. The batch file coordinating the two main programs [[Geoscape]] and [[Battlescape]] often succeeds in soldiering on after a crash. In the Windows version of the game, the game simply crashes back to the desktop, unless you're using the [[XcomUtil]] split executable variant (which uses a batchfile).<br />
<br />
Some things which will tend to cause this problem:<br />
* Overzealous use of Psi<br />
<br />
At least some of the instability crashes can be fixed by replacing the DOS/4GW dos extender with a later version from another DOS game. <br />
<br />
[http://syndicate.lubie.org/synd/html/synd_patches.php One of these], for example. Link to Syndicate fansite, instructions included.<br />
<br />
=== Cash Rollover Bug ===<br />
<br />
When your cash balance goes over $2,147,483,647, it will rollover and become $-2,147,483,647. Which means your game is done for, unless you use an editor. Fortunately, by the time you accumulate this much cash, you have usually completed all necessary research to win the game.<br />
<br />
=== Losing My Favourite Game ===<br />
<br />
There is a check whether the "Has X-com received a financial warning?" flag has been raised. If no, a warning is issued and the flag is raised. If yes, then the game ends, and the flag is lowered. HOWEVER, this flag is erronously not connected to any particular savegame, it is global across all savegames. This allows strange results when saving and loading games.<br />
<br />
=== Celatid aim bug ===<br />
<br />
The Celatid typically misses. User Tycho has identified this is due to a bug that causes the Celatid to aim at the ground, rather than the middle of the target. The bug is being fixed in UFO Extender. The same bug may apply to the same grenade-like weapon routine used in TFTD.<br />
<br />
== See Also ==<br />
<br />
=== [[Known Bugs (TFTD)]] ===<br />
For bugs that '''only''' affect X-COM: Terror From The Deep.<br />
<br />
[[Category: Oddities and bugs]]<br />
[[Category:Enemy Unknown/UFO Defense]]</div>
Spike
https://www.ufopaedia.org/index.php?title=Known_Bugs&diff=58880
Known Bugs
2014-08-16T14:47:05Z
<p>Spike: /* Side-On Intercept Bug */</p>
<hr />
<div>== Game Destroying Bugs ==<br />
<br />
These are the list of the worst bugs of them all, because they can render your entire game unplayable. Until a fix/ workaround is found, these bugs result in your entire X-com campaign being scuttled:<br />
* [[Minimized interceptor bug]]<br />
* [[Big text bug]]<br />
*[[Small window bug]]<br />
<br />
== Base Construction Bugs ==<br />
<br />
=== Base Disjoint Bug ===<br />
Base facilities built along the right or bottom edges of the base building area may end up being cut off from each other by dirt walls, a bug in the routine meant to keep soldiers from accidentally exiting the map edges during [[Base Defense]] missions. The dirt walls can be knocked down by Blaster Bombs or excessive amount of heavy plasma fire during combat but are otherwise unbreakable. <br />
<br />
[[image:bdb.gif|center|Base Disjoint Bug]]<br />
<br />
The walls marked in white are removed if there is an adjacent module. All green modules are not affected while the yellow modules are. The red module will be sealed off completely if anything smaller than a hangar is placed here at any given time. <br />
<br />
[[XcomUtil]] works around this problem by stripping out the walls entirely in all the base modules.<br />
<br />
The bug can be profitable if the hangars and the lift are accessible only through in these areas - you can gather and supply all your soldiers heavily without aliens interfering, then knock a hole in the wall and cover the area with explosives and blaster launcher fire.<br />
<br />
===Displayed Base Maintenance Costs===<br />
Although X-COM charges the right monthly fees for base modules, the maintenance fee displayed ''in the base info screen'' is always wrong. The displayed number is actually based on the placement within the base grid, '''not''' the price displayed in the in-game UFOpaedia. However, at the end of the month, the right fee is deducted. For more information, see [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]]. The Geo finance Graph shows a correct maintenance summary ([[LIGLOB.DAT]], updated once a month). Also see the next section.<br />
<br />
===Paying For Dirt===<br />
If you take down any facility in any base that you own and leave bare dirt, then you will continue to pay maintenance on it. But not at the old rate of whatever the facility cost per month, filling the hole back with dirt means it needs special attention at all times by specialists. In fact for every square of dirt you have that used to be a facility you will pay 80k per month. Thats 320k per hangar you take down. There are only two known ways to stop paying this premium - if you completely dismantle the base you stop paying any money for it, or if you build over all the spaces that you have vacated. In fact as soon as you start building the new facility you stop paying the premium, as well as not having to pay the cost of the new facility until it is complete.<br />
<br />
It is also possible to stop the 80k per month charge by hex editing the base.dat file in the save game. If you change the byte that indicates the number of days until the destroyed module from 00 to ff, you no longer pay for the dirt.<br />
<br />
If you start a facility and change your mind before it is complete, after the time when it would have completed you will start paying this 80k premium on that land as well.<br />
<br />
Note that this also applies to facilities that have been destroyed due to battle damage in [[Base Defense|Base Defense]] missions. If you have lost a facility in a base defense mission and you cannot afford to replace the original facility, consider building something cheap here to keep down this bug.<br />
<br />
===Base Facility Dismantle-Construction Crash===<br />
In the Collectors Edition version, dismantling a facility while its construction is in progress can cause a crash when a second facility on another base square completes its construction. To work around this, dismantle a facility only after its construction is complete. If you have already dismantled such a facility, build something like a general stores on the same square to avoid the crash. It is not known if this crash happens intermittently or always, or if it happens on most versions of the game or just the Collectors Edition.<br />
<br />
===Radar Stacking===<br />
Despite the "Short Range" and "Long Range" detection bars displayed on each base's Information screen, only one radar of each type will be used at each base. Building additional radars of the same type will have no effect. One short and one long are useful until the [[Hyper-wave Decoder|Hyper-Wave Decoder]] makes both of them obsolete.<br />
<br />
===Phantom Radar===<br />
When you dismantle detection equipment such as a radar or hyperwave detector, the related detection ability of the base does not decrease until a new facility of some kind is built in that base. Until a new facility is completes building at that base, the base continues to use this "phantom radar".<br />
<br />
This bug allows you to "upgrade in place", for example building a new Hyper-Wave Decoder over the top of an existing Large Radar, and retaining the detection capability of the Large Radar until the Hyper-Wave Decoder completes building. (Unless something else completes building first).<br />
<br />
===Fixes for Base Construction Bugs===<br />
<br />
As mentioned above, [[XcomUtil]] prevents the Base Disjoint bug (crudely). The [[User:Spike#Base_Fixer|BaseFixer]] utility corrects the Paying for Dirt, Phantom Radar, and Radar Stacking bugs. BaseFixer can be used manually on saved game files, or automatically via XcomUtil's hook mechanism.<br />
<br />
==Geoscape Bugs==<br />
<br />
===First Radar Detection Data bug===<br />
When a UFO is detected by a radar, you get certain data on it depending on the type of radar that detected it. If the UFO later enters the range of another radar while staying in the range of the first, you will continue to get the initial data given, even if the new radar is more powerful than the first! So if you detect a craft with a [[Small Radar System]], then the UFO moves into the range of a [[Hyper-wave Decoder]], clicking on the UFO will only give you the data as if the Small Radar detected it, so long as it remains in the Small Radar range! In effect, the data you get about a UFO is determined when you first detect it, and not changed after that until you lose detection on the craft with the radar that first detected it.<br />
<br />
This bug most commonly shows up when a UFO is first detected by a patrolling aircraft and then remains in the range of the aircraft while also entering the range of a Hyper-Wave Decoder.<br />
<br />
=== Minimized Interceptor Bug ===<br />
One fairly consistent cause of crashes is saving the geoscape game during a UFO standoff, with a [[UFO Interception]] window minimized to an icon. The next mission after that point will likely dump you to the green text screen, and perhaps an earlier battlescape mission instead of the proper one. What it seems to do is zoom back out of the combat too far when the fight is over, eventually causing the crash once it has gone a couple of steps further than it normally allows you.<br />
<br />
'''Solution:''' Open up [[UIGLOB.DAT]] in a hex editor. Change hex offset 0x06 to 00. This will reset the number of minimized interceptor windows to zero. Your interceptor unit can be selected to either return to base or continue on to complete its ground assault mission. ''NOTE: Make sure to back up your save game before editing it.''<br />
<br />
''-- I was able to recover from this state by quickly sending in another interceptor ([[Firestorm]]) to take over, which allowed my first interceptor ([[Avenger]]) to break off and go home without crashing the game again. After the shootdown I overwrote the buggy savegame. --[[User:JellyfishGreen|JellyfishGreen]] 03:11, 22 Aug 2005 (PDT)''<br />
<br />
''This happened to me also. I fixed it by replacing "[[UIGLOB.DAT]]" in the save folder with the same file from another saved game (from the same campaign a month earlier) [[User:bylund|bylund]] 00:15, January 12, 2007 (GMT+01)''<br />
<br />
=== Interceptions: Last Shot Always Misses ===<br />
When using Cautious attack when [[UFO Interception|intercepting a UFO]], your craft will stay at the maximum range of your longest-range weapon. When using Standard attack, your craft will stay at the maximum range of your shortest-range weapon. (Usually players use two weapons of the same type, so Cautious and Standard attack will behave the same in this regard.)<br />
<br />
As soon as the craft fires its last shot (expending all its ammo), it will drop back to "Standoff" range (70km). This will make it appear that the UFO has backed away while the last missile(s) are in-flight, causing them to miss. <br />
<br />
In order to hit a UFO with your last salvo of missiles (Stingrays, Avalanches, or Fusion Balls), you must switch to "Aggressive" attack before the last salvo reaches the UFO. This will cause your craft to close in with the UFO, allowing the missiles to be in range when they reach the UFO. However, Aggressive attacks will also bring you within range of the UFO's weapons, so you should hit the "Disengage" button as soon as the last salvo hits.<br />
<br />
===Elerium-fueled Craft Bug===<br />
A [[Skyranger]] or [[Interceptor]], once dispatched, will return to base when its fuel supply has dropped to a level that it will only have just enough fuel to return to base. Craft fueled by Elerium-115, however, will always report the "Low Fuel" message as soon at the fuel supply is 50% depleted, no matter where they are on the globe. This significantly shortens the already minute time that a [[Firestorm]], [[Lightning]], or [[Avenger]] can be dispatched to patrol.<br />
<br />
===Medic Research Bug===<br />
Every single time a Floater Medic is found and researched, the game crashes after it is interrogated! I [[muton commander]] used a hack system to view the alien's profile, and it was a Commander with no race attached. This is probably the cause, but I have no explaination for why this situation occurs.<br />
<br />
<br />
Addendum:<br />
<br />
Based on report from various players, the crash appears to happen with medics in general, and isn't confined just to floaters.<br />
<br />
''The portion of the code that is responsible for selecting the unresearched alien topic to provide when completing the research on a medic is the problem. The array that holds the avaiable topics, so that one can be randomly selected, is four bytes too short. If a player has never researched an alien species or performed an autopsy, the program will crash after it displays the random alien topic. This is because the portion of memory that holds the return address for the function has been overwritten by the array creation code and upon completion of this subroutine, the game is directed to an invalid memory address. This error won't occur if the player performs two autopies, alien interrorgations or a combination of both before researching a medic.'' [[User:Morgan525|Tycho]] 21:04, 22 June 2013 (EDT)<br />
<br />
===Never-ending Retaliation Bug===<br />
Some times the aliens will send a [[battleship]] on a [[Alien_Retaliation|retaliation mission]] to the "wrong" base. F.ex: the [[Hyper-wave_Decoder|hyper-wave decoder]] may report its destination as South East Asia, but the ship will actually fly to your base in North America and attack it.<br />
<br />
Even if the battleship succeeds in getting past the base defences and its crew is subsequently defeated, the aliens won't "forget" the base's location as they normally do and instead keep sending another battleship every week or so. If your base is constructed with [[Base_Layout_Strategy|defendability]] in mind and crewed by experienced operatives this will net you heaps and heaps of alien weapons, corpses and prisoners very quickly. The downsides are, of course, playing the same base defence mission over and over again and having to maintain a garrison there at all times.<br />
<br />
More research is needed to find out what causes this bug, but it ''could'' have something to do with [[Mind_Shield|mind shields]] being finished between the scouting and assault parts of the aliens' retaliation mission.<br />
<br />
=== Great Circle Bug ===<br />
<br />
The shortest distance between two points on the surface of a sphere is called a Great Circle. The wayfinding algorithm used by XCom aircraft has unfortunately never heard of this. XCom aircraft tend to move toward, and then along, lines of latitude. This is inefficient in terms of time, fuel, range and time on station. The inefficiency is most evident when crossing over the poles, and least evident when moving east-west or west-east. <br />
<br />
As a workaround, you can set manual waypoints to approximate the Great Circle route. <br />
<br />
Note that this does not seem to affect combat interception of moving UFOs, or at least not as much. Intercept courses seem to be continually updated, and head straight toward the current position of the UFO (also not an optimum algorithm, but that's another story).<br />
<br />
<br />
=== Geoscape Intercept Bugs ===<br />
<br />
==== Side-On Intercept Bug ====<br />
<br />
Unlike fighter controllers since at least the 1930s, X-Com ground controllers and/or onboard avionics are incapable of calculating a predictive course for a target that is moving, at a known course and speed, laterally relative to its bearing as seen from the intercept base (so that the bearing from the base is constantly changing). In other words, in any situation except when the alien craft is heading directly toward/away from the X-Com craft/base, a non-optimum interception course is used. Instead, X-Com craft simplistically just keep heading toward the current bearing toward the target. This results in inefficient parabolic intercept courses, rather than efficient straight line courses toward a predicted intercept point. Parabolic courses often fail to intercept, or give very brief interception windows, that would have been avoided by a proper predictive, straight-line course.<br />
<br />
==== Head-On Intercept Bug ====<br />
<br />
It is not possible for a slower-moving X-Com craft to intercept a faster-moving Alien craft, even if the X-Com craft is directly ahead of the alien craft and waiting in position to intercept it. This is true whether the X-Com craft is stationary, or flying in the same heading as the alien craft and at nearly the same speed. Even if the alien craft moves right through the X-Com craft's exact position while travelling only slightly faster than the X-Com craft. Interception only occurs if the alien craft voluntary slows down for long enough for the X-Com craft to catch it. <br />
<br />
(It's true that such interceptions would be difficult, whether attempted head-on at high closing speed - extremely brief period to fire - or tail-on at low closing speed - very easy for the alien to avoid entering X-Com craft's weapon arcs by breaking away. So it could be argued that making these interceptions impossible is just a simplification of the fact that they would be much more difficult than normal interception combat.)<br />
<br />
==== Instant Getaway Bug ====<br />
<br />
If you park an interception craft directly over a touched-down alien craft, the alien craft will still escape, if the alien craft has superior maximum speed. The alien craft basically seems to instantly accelerate to its maximum speed, with no concept of progressive acceleration. Interception only occurs if the alien craft voluntary slows down for long enough for the X-Com craft to catch it. This probably has the same root cause as the Head-On Intercept Bug (arguably it is a special case of the Head-On Intercept Bug).<br />
<br />
== Battlescape Bugs ==<br />
<br />
=== Load bug after successful mission ===<br />
After you finish a game you have saved and load the same game file again - the alien side goes first! I think it may be caused when you succesfully complete the mission and you get a notification like that the alien has died beacuse of no alien containment. The game still thinks that it is the aliens' turn. So when I load the mission again- the aliens move first. If you load the same saved game again it will be OK. [[User:ElfKaa|ElfKaa]]<br />
<br />
=== Faulty Large Units ===<br />
If you move a tank off a northward facing ledge, the rest of the tank will sink into a wall (if there is one), and cause the tank to get stuck. This won't happen if the tank moves off a south facing ledge as the primary quarter will fall after the rest of the tank. Aliens can also get stuck this way.<br />
<br />
Another, potentially annoying bug occurs when a large unit's graphics become messed up. During a base defense mission, a rocket tank may end up looking like 4 silacoids bunched together.<br />
<br />
===Unconscious Units are items===<br />
This is actually an intentional programming choice... but it leads to several consequences which are bugs.<br />
<br />
Firstly, any unconscious unit can be killed instantly by even a weak explosion, like being nearby an exploding AC-HE shell... even a Muton with 125 Health or an X-com agent in Flying Armor whose high armor ratings normally make him immune to AC-HE damage.<br />
Secondly, no experience is gained for killing enemies in this manner.<br />
<br />
You can prevent an unconscious unit's death from an explosion by picking it up... if a blaster bomb strikes the carrier and kills him, the unconscious unit will safely fall to the floor, unharmed.<br />
<br />
Unlike a conscious unit (not wearing x-com armor), an unconscious unit can laze about in the middle of a fire without taking damage, since a UNIT standing in fire takes damage, but an unconscious unit is an item, which all ignore fire.<br />
<br />
Forcing an MCed alien to pick up an unconscious X-com agent and carry him in its right hand can cause weird things to occur when you release the mind control. I think the game might crash when the alien tries to shove the agent into its magic pocket.<br />
<br />
If a non-flying unconscious unit wakes up while being carried by a flying unit, it will gain some sort of temporary hover ability. (I once placed an unconscious Chryssalid in my flying agent's backpack. A few turns later, some growls and screams were heard from overhead.)<br />
<br />
Save space! Each conscious unit takes up 1 tile (4 tiles for large units). An unconscious unit does not use up the tile... this might conceivably be useful if you wanted to abort a mission, but several panicked units were preventing other agents from boarding the skyranger... <br />
X-com agents refuse to ride piggyback or be picked up while conscious. So, if you want a non-flying unit to reach an 2nd floor place with no stairs or elevator, you will have to knock him out, then either throw him up, or have a flying unit pick him up and drop him... and presumably administer stimulant.<br />
<br />
This also leads to the INVISIBLE UNIT glitch. Frequently happens during Base Defence missions, since the item table is usually maxed out. Basically, the item table is so full that killed units do not leave corpses. However, this also means that unconscious units do not turn into the Unconscious Unit item. The KOed unit will disappear from sight, but will still be visible as a red number and as a blue/yellow dot on overhead map. Since the unit is still a unit and not an item, you will be able to shoot it with projectile weapons and kill it. ALSO, this method enables you to raise any unit's stun bar all the way to 255, since you can still increase the stun meter, despite them already being unconscious.<br />
<br />
===Funky Fire===<br />
If a unit (alien or friendly) is on fire or standing in flames, an [[Incendiary]] explosion ''anywhere else on the map'' will do a small amount of damage to it, even if you just shoot an IC round at a random patch of ground. <br />
<br />
Similarly, if a unit (friendly units only) is standing in smoke when an incendiary explodes, it will take stun damage. This makes the combination of incendiary munitions and smoke quite hazardous until such time as all troops are armored.<br />
<br />
<s>There is a [[Talk:Incendiary#Incendiary_Bug|working hypothesis]] for</s> The cause of this bug is that each and every Incendiary explosion triggers the "Smoke and Fire" routine: applying fire damage, applying stun damage from smoke, calculating fire and smoke spreading, and "catch on fire" checks for units in fire. <br />
<br />
Note that X-Com units wearing any kind of armor are immune to fire damage and IC-induced stun damage. Xcom HWPs are immune to stun, but take 40% damage from Incendiaries and WILL get killed quite efficiently by funky fire.<br />
<br />
=== Collectors Edition Blaster Bomb Bug ===<br />
<br />
Also known as Vertical Waypoint Blaster Bomb Bug. <br />
<br />
In the Collectors Edition of UFO, the [[Blaster Launcher]] has a bug that prevents it from going up or down on the same tile. Or in other words, you cannot change the elevation of the missile vertically on the same tile. <br />
<br />
Instead of flying down (or up) to the next waypoint, it will instead fly directly to the south at the pivot waypoint. Relative to the screen, this would be the lower left side of the screen. <br />
<br />
This does not happen if you plot the waypoints at an angle. Or, if the blaster bomb flies right off the map, it will reappear at the proper waypoint as long as there are additional waypoints placed after the vertical move. The bug makes it impossible to fire Blaster Bombs up or down elevator shafts. Aliens are also affected by this bug. <br />
<br />
The Blaster Bomb bug in turn permits the [[Tactical Exploits#Milking Alien Bases|Elevator Shielding - Base Milking Exploit]], which provides unlimited risk-free experience and ultra-low-risk booty, so fixing it is a Good Thing. Base Milking in general is a legitimate tactic, but doing Base Milking risk-free via the Elevator Shielding is just an exploit.<br />
<br />
This bug also applies to the [[Disruptor Pulse Launcher]] in TFTD.<br />
<br />
===Blaster Launcher Dud Shells Bug===<br />
<br />
Shots which have only one waypoint, or explode before reaching their first waypoint, leave the Blaster Launcher showing 0 rounds, but still containing a dud shell which must be unloaded before the launcher can be reloaded. On earlier versions of the game (pre-Win CE) this also happens with reaction fire, and with 1-waypoint shots that fly off the map. <br />
<br />
=== The trouble with Mines in General === <br />
<br />
Proximity mines are strangely implemented in UFO and TFTD. While they behave as you would expect them to half of the time, the mines do not behave like conventional weapons. <br />
<br />
First, experience attribution is awarded to the person that sets off the mine. <br />
<br />
Secondly, the armed states for [[Proximity Grenade]]s in both UFO and TFTD are NOT stored in save games. If a proximity grenade is primed, then the game is saved and reloaded, the grenade will not only not go off as it should, but the "Prime Grenade" action will still be absent, so it's impossible to re-arm it.<br />
<br />
=== Grenade Timer Behaviour === <br />
<br />
A primed explosive (Grenade, High Explosive, Alien Grenade) will not explode if it's still in your inventory (hand, belt etc) when the timer runs out. It will only detonate when it's on the ground. If your soldier falls unconscious or gets killed, the primed explosive will be counted as being on the ground. Then it will blow up, likely taking out your gear and body. This 'feature' allows for the hot potato or [[Grenade Relay]] strategy which is fairly unique to X-COM where a live grenade well past its use-by date can be passed from squad member to squad member. <br />
<br />
For a more a detailed explanation on detonation conditions, see [[Understanding Grenades]].<br />
<br />
=== Mountain Map ===<br />
Due to a bug in the way this tileset was created, when you shoot the ground, it doesn't burn up - it turns into a tree stump.<br />
<br />
Because the stump is on object, as opposed to actual ground, any objects that were in the tile already (for example, UFO hulls or the landing gear of your craft) get replaced by these stumps, making it seem as if they were destroyed.<br />
<br />
Tree stumps don't take much damage, so they often get burnt up immediately if an explosive goes off, leaving nothing but burnt ground behind. It is easier to view the effects of this bug by shooting the ground instead.<br />
<br />
For more details, see [[Explosions#Mile-High_Madness|Mountain Madness]].<br />
<br />
=== What just exploded? ===<br />
In some versions of the game, a bug allows an armed proximity mine to transfer its properties to some other item in the next mission, which then may explode unexpectedly. (If the item is left on the floor of the XCOM craft, it will explode as you walk past it.) This problem can be rectified by reloading the game -- as a precaution, save before you move your first soldier.<br />
<br />
=== Door jam ===<br />
If a door is open when a game is saved on the Battlescape and that game is subsequently restored, the door will remain open for the remainder of that mission.<br />
<br />
<br />
=== MIA Bugs ===<br />
<br />
A number of bugs cause units to be unexpectedly listed as MIA. In the case of X-COM units, this also means the soldier is permanently lost from your roster, probably along with any armour/equipment carried. <br />
<br />
====Mind Controlled Soldiers go MIA====<br />
If you complete a mission successfully while a [[soldier]] is currently [[Mind Control]]led he will be listed as MIA at the end of the combat. This is quite an easy bug to fall into as on any [[Sectoid]] or [[Ethereal]] mission the only, or most powerful, psionic aliens will usually be holed up in the bridge or command centre, which is the likely location of the final combat turn.<br />
<br />
====Stunned Mind Controlled Soliders go MIA====<br />
Similarly an X-COM soldier who was Mind Controlled by the aliens and then stunned (usually by X-COM), and who is still stunned at the end of the mission (victory or abort), will count as MIA. Presumably the game does not set the ownership flag on the unit back to XCom's side until the unit wakes up. <br />
<br />
====Mind Controlled Aliens Count as MIA if you Abort====<br />
If you happen to abort a mission with any Mind-Controlled aliens under your control, who are NOT in the dropship, the computer tallies them up as "X-COM Operatives Missing In Action." Thus, every Mind Controlled alien left behind when you dust off is -20 points to your score! If you're leaving anyways, avoid this by bringing them back to the ship or mowing them down on the way back to the ship.<br />
<br />
In the Playstation version of the game, any aliens under Mind Control at missions end are considered captured and hence, this bug is not a factor.<br />
<br />
====Stunned, Carried, Not Dropped Soldiers are MIA on Abort====<br />
<br />
If a soldier is stunned anywhere outside the transport and then carried back to (or thrown into) the transport for an Abort, they are still considered MIA. The game considers them to be still at the location where they were stunned and picked up from. You must drop the soldier on the ground in the transport in order to recover them back to base in an Abort. Throwing into the transport does not work. <br />
<br />
====Stunned Inside, Thrown Outside Soldiers not MIA on Abort====<br />
<br />
A soldier who is stunned inside the transport and then thrown (not dropped) outside the transport prior to a mission Abort does not count as MIA, but is successfully recovered back to base. This is presumably because throwing does not reset the location of the unit. <br />
<br />
===20 Proximity Grenade Limit===<br />
<br />
The array used to denote armed [[Proximity Grenade]]s is limited to 20 entries, meaning you are limited to 20 active mines at a time. The 21st and subsequent Proximity grenades can be primed like normal and will give appropriate messages, but they will not detonate even when the normal trigger conditions are met. Note that Proximity Mines that have detonated or otherwise been destroyed are removed from the array, freeing up positions; the limit is 20 ACTIVE Proximity Grenades at one time. In normal gameplay, this is probably not a restriction, in light of the [[Known_Bugs#80-Item_Limit|80 Item Limit]], since you'd need to have more than 1/4th of the cargo space in the dropship filled with Proximity Grenades.<br />
<br />
===Base Defense Elerium bug===<br />
<br />
On DOS versions of UFO Defense, Elerium pods may spawn as items from the base stockpile during a Base Defense bug. Each pod represents 50 units of Elerium and will be normally collected after the mission, same as any other item such as Heavy Lasers or Blaster Bombs. HOWEVER. The program will potentially generate 1 elerium POD for every 1 UNIT of elerium in your inventory. Thus, if you had only 10 lasers and 50 Elerium listed in your Sell screen, you would see 10 lasers and 50 Elerium Crystals in your Soldier Equip Screen, which would translate to 50 Elerium pods and 10 lasers scattered around your base. This equals 2500 Elerium, BTW. You basically have the potential to multiply your elerium stocks by 50.<br />
<br />
===Berserk HWP crashes the game===<br />
<br />
Admittedly, this is unlikely to arise under normal play. But, anyhow, your HWPs can only lose morale by killing friendly units. Not much for each unit killed, either. Anyhow, a berserk HWP will crash the game. (except for the Hovertank/Launcher, which does not fire when it goes berserk.)<br />
Likewise, if you MC a cyberdisc or Sectopod and have it kills lots of aliens, it'll go berserk and crash the game. The error happens because of an oversight from the developers: the built-in weapons of HWP are handled differently from handed weapons, no OBDATA.DAT entries exist for them. The berserk code will try to access the nonexistent entry, resulting in a crash. The Celatid has yet to be tested.<br />
<br />
''The part about HWPs only losing morale by blue-on-blue isn't true: I had a rocket tank go berserk on me in a terror mission when a floater blew up my whole force with a single grenade in the first alien turn. The game crashed alright; I have the CE version with UFOextender.--[[User:Amitakartok|amitakartok]] 08:24, 11 January 2012 (EST)''<br />
:''Unless my memory is playing tricks on me, I clearly remember an very bizarre incident like yours but where the rocket HWP panicked (all other X-COM units had just been killed) but the game didn't crash (I play the DOS version) and the tank shot all its rockets randomly until it ran out of ammo. I remember that its TU numbers being while firing showed 255 TUs or some other impossible value (I hadn't done any manual edits). I don't remember if it crashed at the end but it did fire!'' [[User:Hobbes|Hobbes]] 10:47, 11 January 2012 (EST)<br />
::''And this reminds me of yet another panicked HWP incident but involving a Cannon HWP. I was expecting it to waste all its ammo (based on my previous experience) but it only fired a few shots and the TU level didn't went up crazy.'' [[User:Hobbes|Hobbes]] 10:47, 11 January 2012 (EST)<br />
<br />
===Limited Unit Slots - Battlescape Crash===<br />
<br />
This tends to arise during Base Defence Missions. The game is was designed to be limited to 40 soldiers/hovertanks and XXXX aliens for a total of XXXX . Having a full complement of soldiers during a Superhuman difficulty base defence will max out these limits. Thus when either side starts playing around with mind control too much, something goes wrong causing the entire game to crash.<br />
It might also be something to do with maximum items on the battlescape.<br />
In any case, the workaround seems to be killing aliens and destroying items on the battlescape... doesn't always work, but it seems to help.<br />
You might want to make several in-battle saves for these situations, even if you normally play Ironman mode.<br />
<br />
===Left arm fatal wound instead of torso (energy penalty)===<br />
<br />
According to UFO Defence [http://cdn.steampowered.com/Manuals/7760/x-com%20ufo%20defense%20manual.pdf manual], torso fatal wounds affect energy replenish rate, which is logical. But in the game fatal wounds of the '''left arm''' affect energy replenish rate, '''not the torso'''. Which is an obvious coding bug (though not a fatal one).<br />
<br />
===Invisible Chryssalids===<br />
<br />
After reloading a saved game with a mission where zombies are present, the resulting Chryssalids might be invisible. This only happens when zombies are present but all Chryssalids are either dead or KO. This issues occurs because the load-game routine only loads graphics files for active units. When the chryssalids' files are loaded, the game also loads the files for zombies but this is not true in reverse. [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])<br />
<br />
== Character Inventory Bugs ==<br />
<br />
=== Alien Inventory Stacking Bug ===<br />
<br />
'''WARNING:''' When examining an Alien's inventory (via an Exploit), you will see that sometimes the alien will stack multiple items of equipment on the same slot - its right leg. It's not always obvious that there are multiple objects in the slot until you 'pick up' the first object and can see other objects still in the slot. <br />
Before you remove an item from the Alien's right leg, make sure you have enough time units to place it somewhere else. If you run out of time units, you will likely have to force a quit and cannot save your game. It '''may''' be possible to move the item to the left leg slot for 0 TUs, '''if''' the item will fit in that slot. If not, you will have to terminate the game. (Press ALT-TAB to get to any other window, then CTRL-ALT-DEL to bring up Task Manager, and then terminate the process that corresponds to the game).<br />
<br />
=== XComUtil Inventory Stacking Bug ===<br />
<br />
A problem similar to the Alien Inventory Stacking Bug can also occur for X-COM Soldiers, when using XComUtil. The algorithm used to assign weapons in XComUtil MUST assign all weapons to troops, so if there are more weapons than soldiers, excess weapons are stacked onto the leg slot of the first soldier in the dropship. This was a deliberate choice by Scott Jones to make this encumbrance obvious to the player. This can be readily corrected in the "equip soldiers" screen before a mission. Else, see "Alien Inventory Bug", above.<br />
<br />
=== Item-stacking Bug ===<br />
It is possible to put more than one item in a given spot. When an item is stacked with a [[Stun Rod]], this can make it possible for X-COM soldiers to perform "melee" attacks. See [[Item Stacking Bug]] for more details.<br />
<br />
===Carrying Unconscious Units===<br />
If one of your soldiers is carrying an unconscious unit in their hands and the unit either wakes up from stun or dies, they will be removed from the Inventory display, but will still appear to be in the carrying soldier's hands in the Battlescape. Clicking on the phantom body in the Battlescape will crash the game!<br />
This error can be easily cleared by switching to the Inventory screen and moving another item into the hand that used to be carrying the body. Even swapping the gun to the other hand will do. Refer to : [[Unconscious#Bug|Unconscious]].<br />
<br />
===Disappearing Ammo===<br />
Partially-used clips in alien or X-COM weapons disappear at the end of a mission. This dictates that you should try to use clips that are not full. However, in DOS versions of the game, you can unload used clips to recover them as full clips with the tradeoff of all loaded clips (used or otherwise) will count as spent and disappear (this shouldn't seem to be a problem, until you start using blasters and will find that you're running out of ammo fast). You can also use [[XcomUtil]] to recover partially used clips. Even when used clips are discarded, you will still get credit ([[Scoring|score]]) at the end of missions for recovering them.<br />
<br />
When aborting a mission, any full clips loaded in any alien weapons brought back to the transport/access lift will not be recovered unless the clips are unloaded first. This includes [[Blaster Bomb]]s and [[Stun Bomb]]s.<br />
<br />
=== Ammo Weight Bugs ===<br />
<br />
In general, the game engine handles the weight allocation of ammo/clips '''loaded into weapons''' very badly. There was a good design to handle ammo weight, but it was not properly implemented. As a result there is a set of bugs relating to ammo/clip weight and encumbrance that share overlapping causes and effects.<br />
<br />
==== Equip Phase Ammo Load Error ====<br />
<br />
The game routine for placing ammo into weapons at the beginning of the equip phase does not correctly set all object and unit values. It should set the ammo as loaded into the weapon, the weapon as being held by the soldier, and the map position of the weapon and the ammo as the same as the soldier. Looks like it does not do one or more of these things. Whatever values the game doesn't set, do get set if you manually load or reload the weapon, either during the equip phase, or during the game. <br />
<br />
Specifically, the game's auto-equip functions at the beginning of the equip phase fail to set offset 0x04 of the [[OBPOS.DAT]] record to point to the soldier who owns the ammo. These functions leave the value = 0xff, which implies "on the ground". They also leave the ammo location as being the equipment pile, rather than the location of the soldier. The other values are set correctly. Manually loading ammo into a weapon, during the equip phase or during combat, correctly sets all values. The ownership points to the soldier and the location to the soldier's location. <br />
<br />
This bug is the cause of [[Known_Bugs#Weightless_Loaded_Ammo|Weightless Loaded Ammo]]. Probably the only other impact of this bug is that XComUtil can't detect the fact that the ammo is loaded into the weapon, for the purpose of AutoCombat. It might have other subtle effects on any utilities that deal with equipping soldiers. <br />
<br />
====Weightless Loaded Ammo====<br />
<br />
Ammo that is automatically pre-loaded into a weapon at the start of the Equip Phase of a mission does not initially count towards any soldier's carried weight (Encumbrance). If the weapon is subsequently unloaded during the Equip Phase or later in the mission, the soldiers encumbrance will ''increase''. This will probably only be noticed if the unloaded clip was not discarded (e.g. because it was not fully empty). This is due to a bug in the game's original weight calculation routine that was uncovered (but not caused) by Seb76's inventory screen improvements.<br />
<br />
The Weightless Loaded Ammo bug slightly advantages X-Com. It leads to a set of relatively minor exploits. Using this bug, you can get weak soldiers to carry heavy weapons with (usually) a single clip and no TU penalty. For weapons that use multiple ammo types (which auto-equip with AP by preference), by manipulating the overall supply of ammo of different types you can to some extent persuade the auto equip algorithm to load your preferred ammo type for these weaker soldiers.<br />
<br />
[[User:Spike|Spike]] 22:51, 6 September 2012 (EDT)<br />
<br />
==== Displaced Ammo Weight ====<br />
<br />
'''Guidance: Apart from weapons pre-loaded by the game, be sure to unload any weapons before dropping them. Drop, pick up and transfer ammo only when it is not loaded into a weapon.'''<br />
<br />
Dropped ammo clips that are still loaded into dropped weapons are not un-assigned from the unit carrying them. The weight of the ammo / clips continues to count against the unit's [[Time Units#Encumbrance|Encumbrance]] as 'displaced weight' that can't be removed by ordinary means. This is an original game bug that only becomes apparent when using mods that display the unit's current encumbrance. The effect continues until the ammo is unloaded (either by the original holder picking up the weapon again and unloading it, or someone else picking it up and unloading it). Once the ammo is unloaded, its weight is applied to the actual current holder, only, and is released from the original holder. <br />
<br />
This bug also applies during the Equip Phase, if one soldier loads a weapon, drops it, and another soldier picks it up. <br />
<br />
In some senses this bug is the opposite of the Weightless Ammo Bug, and each bug has probably tended to obscure the effects of the other. For example, clips affected by the Weightless Ammo Bug (clips automatically loaded by the game) are not so obviously affected by this bug, since their displaced weight is 'carried' by the Equipment Pile rather than any specific Soldier. (In another sense, this is the same bug, with the weight displaced to the Equipment Pile rather than to another soldier.)<br />
<br />
See [[User_talk:Seb76#Inventory_screen_ammo_weight_bug|this discussion]] for more information on this bug.<br />
<br />
==== Ammo Weight Exploits ====<br />
<br />
As noted above, Weightless Ammo is, in itself, a minor exploit, since it provides some extra penalty-free carrying capacity in combat. <br />
<br />
On the face of it, the Displaced Weight Bug is not an exploit, since for every decrease in weight on one soldier there is a corresponding increase in weight on another soldier. However the Displaced Weight bug could potentially be exploited by having one soldier first load and then drop a lot of weapons, and then move away from the resulting pile to allow others to pick up. This would create a reserve of weapons where all the ammo weight was being 'carried' by this "weight sink" soldier, freeing up encumbrance for other soldiers. For example, all recon and front line soldiers required to be mobile could get reduced weight, at the expense of a single soldier having extremely reduced mobility/TUs. However, as the game's auto equip routines already load all initial weapons with weightless ammo, this would only be useful after combat had been progressing for some time, for reloads rather than initial loads, and it would require the squad to regroup around this "sink", or ferry weapons to/from the "sink". It might be most useful with Rocket Launchers (high weight, high ammo weight, one round before reload).<br />
<br />
Hypothetically, Displaced Weight could be exploited to overflow the Weight value of a unit and allow that unit to carry massive weight with minimal encumbrance. For example, carrying 32 rocket launchers and 32 rockets (ammo weight 256) into combat. There is not enough Equip space in the Equipment Pile to manipulate this equipment pre-combat, as the loaded weapons must be dropped, and there is only enough space for 20 rocket launchers in the Equipment pile, so the remaining manipulation would have to be done during combat time (and over more than one Battlescape square). However, it looks like the Weight subroutine and the value it returns into are both bigger than 2 byte numbers (256). There is no way to push Displaced Weight into the 32,000 or 64,000 range with using some kind of game file editing or hacking/modding. <br />
<br />
[[User:Spike|Spike]] 09:06, 29 September 2012 (EDT)<br />
<br />
== Storage and Transfer Bugs ==<br />
<br />
=== 80-item Limit ===<br />
When loading up your Avenger for a massive UFO assault or arming soldiers for a [[Base Defense]] from your overflowing stores, you will likely hit this limit. <br />
<br />
You only get a max of 80 items, and you don't get to choose which ones, so you may end up with 80 clips and no rifles for the base defense. <br />
<br />
The solution is timely housekeeping. Sell off your spare personal equipment. See our handy [[Spring Cleaning Tips]], and also [[Managing the Item Limit]] for ideas.<br />
<br />
Another bug concerning this limit happens when there are unresearched (alien) items in your stores during a base defense mission. Even though the item cannot be used during the mission, the game still allows you to equip your soldiers with them. This rarely happens as the alien items are very low on the item list, but if your base is lean and mean with under 80 items total, everything will spawn regardless of research.<br />
<br />
===Sticky Craft Transfer Fee glitch===<br />
As pointed out by [[User:Zombie|Zombie]] and [[User:Danial|Danial]], transferring any craft causes '''''all subsequent transfers to have that cost added to it''''', for as long as the craft is in transit. Additional craft in transit will add additional fees. (This has also been called the Exponential Transfer Fee bug, although it's actually additive, not exponential.)<br />
<br />
Example (all numbers are only approximations):<br />
<u>Cost of pistol transfer (&harr; = to or from)</U><br />
EU &harr; USA 80<br />
EU &harr; Asia 100<br />
USA &harr; Asia 120<br />
<br />
<u>Cost of craft transfer</U><br />
EU &harr; USA 1600 ''Notice how transfer fees always work as relative percents,<br />
EU &harr; Asia 2000 ''probably on a distance-based formula<br />
USA &harr; Asia 2400<br />
<br />
<u>Cost to transfer '''pistol''', after transferring craft from EU to Asia for $2000</U><br />
EU &harr; USA 1680 (80+1600)<br />
EU &harr; Asia 2100 (100+2000)<br />
USA &harr; Asia 2520 (120+2400)<br />
<br />
The cost of the craft transfer "sticks" to '''all''' subsequent transfers, until the craft arrives - although it acts on a proportionate basis, which is probably distance related.<br />
<br />
Unfortunately, this cost is '''additive'''. That is to say, if you transferred a second craft from EU to Asia while the first was still in transit, it would cost $4000 ($2000 plus $2000 - it too suffers from the glitch!), it would then cost e.g. $4100 to transfer a pistol from EU to Asia. Having even more craft in transit would add even more fees.<br />
<br />
This only appears to happen with aircraft, although it does happen for them all. So try to transfer aircraft individually, and not transfer anything else while you do - assuming you aren't awash in money. (The bug will cost you in the low thousands of dollars per craft being transferred.)<br />
<br />
A related problem is that, if you are in the Transfer screen, start to transfer a craft, and then cancel because you remembered you wanted to send something else first - if you then try to Transfer something on that same screen, ''it will still get the sticky craft fee added''. Try it and see. You have to back up out to the main Base screen and hit Transfer again, to get rid of the sticky fee from a canceled craft transfer.<br />
<br />
===Fuel dump on transfer===<br />
Transferring a craft with 100% fuel will dump it somewhere along the way. <br />
When it arrives at its destination, its fuel gauge will read empty (ie: 0% FUEL), but it will be listed as ready. If you launch your craft for a mission (any mission will do) its fuel gauge will still read empty. <br />
<br><br />
This can be [[ExploitsA#Infinite_Fuel|exploited]], but it is very annoying if you want to quickly turn around a troop transport for another mission. <br />
<br><br />
You can force a refuel by sending out the craft and immediately recalling it back to base.<br />
<br />
===Transfer Limit cash eater===<br />
Only 100 items can be in transit at a time. (Here, a transfer of e.g. 200 Elerium counts as one "item". Also, all soldiers are counted individually.) If you go over the limit, you will get a warning that there is no more transport capacity. If you STILL try to transport something after getting the warning, the item will stay where it is, but the transportation cost still gets deducted. Bad if you're shuffling expensive aircraft. The extra cost isn't that bad. Recovering just one alien weapon will likely cover the money you will lose to this bug over the course of a game.<br />
<br />
{| {{stdTable}} width = "80%" align = "center" <br />
|- {{stdTable Heading}}<br />
| Tip<br />
|-<br />
| To Clarify what constitutes an item in the transfer screen, think of them as batches of X amount. For example, if you transfer 200 alien alloys now, and then decide to transfer another 50 alloys later, this will count as two items in transit. Now, when you look at your transfers, you'll now have two items. Two batches of alien alloys, one with 200 units and the other with 50 units.<br />
|}<br />
<br />
=== Transfer crash ===<br />
If you transfer something to another base the game crashes right after acknowledging the transfer price.<br />
<br />
Solution: Start UFO, select English language, finish your transfer, save game, restart with your normal language settings (http://www.xcomufo.com/x1faq.html)<br />
<br />
===Purchase Limit===<br />
The purchase limit for any item you buy via the purchase screen is 255 per line item, because it is a one-byte field. However, the impact of this bug is small, for if you have space remaining in your 100-item transfer queue, you can immediately order another 255 of said item as another line item.<br />
<br />
===Storage Limit===<br />
You can not store more than 9,999 of any one item in the general stores at a specific base at one time. However, this will likely only happen with [[Alien Alloys]] or [[Elerium-115]]. <br />
Still, consider yourself warned. If you're coming close to the limit, consider transferring the extra to other bases or even selling it, as any extra collected beyond the limit will 'disappear' and be wasted.<br />
<br />
===Exceeding Storage Limits===<br />
<br />
The storage capacity of a base is normally limited by the capacity of the General Stores. However this can be exceeded in a number of ways:<br />
<br />
* By exploiting some of the Base Storage Anomalies (see below)<br />
* By storing surplus equipment in transport aircraft (up to the 80 item limit). Note that if both the aircraft and the base are full, you can no longer move equipment between the aircraft and base (in either direction). <br />
* Anything manufactured at the base will be stored there regardless of the base's General Stores capacity. <br />
* Anything captured on a mission by an aircraft operating from the base will be stored at the base, regardless of the base's General Stores capacity. <br />
<br />
These could perhaps be considered minor exploits.<br />
<br />
===Base Storage Anomalies===<br />
<br />
There are some quirks in how the game calculates, and displays, base storage capacity used and available. These quirks are not all consistent with each other, which leads to some strange behaviour. A typical example would be moving a set of items out of Stores, immediately trying to put the exact same set of items back into Stores, and this failing due to "insufficient space". A more detailed discussion is in [[Talk:Base Stores#Base Stores Anomalies]].<br />
<br />
===Exceeding Storage Limits when Transferring Craft===<br />
<br />
Usually you can't transfer crafts to bases without capacity for them as you'll get an error when you press the Up arrow. However, if you press the Down arrow when the craft quantity is already at 0, the game will still think you're removing crafts from the destination base and "add capacity", so you can then press the Up arrow again to transfer the crafts without error. This doesn't work with other transferable items.<br />
<br />
Once you've broken the limit once, you don't need to do this trick anymore as the error won't show up again (the game probably doesn't check for negative capacity). You can also exceed storage and personnel capacity this way, as Transport Crafts will carry their contents over. For example, if you press the Down arrow on a Skyranger with 14 soldiers, the game will "add capacity" for 1 craft and 14 personnel on the destination base.<br />
<br />
You can also orphan crafts this way by removing a base with crafts but no hangars, which can cause all sorts of weird behavior.<br />
<br />
===50 Unit Limit for Captured Aliens[[http://www.ufopaedia.org/index.php?title=Alien_Containment#Functionality]]===<br />
<br />
You can only ever have 50 captured aliens in [[Alien Containment]] at any time, no matter how many you build, no matter what base they're in.<br />
<br />
== Soldier Limits and Recruiting Bugs ==<br />
<br />
=== Soldier Recruiting Limit ===<br />
<br />
There is a hard limit in the game of 250 X-COM soldiers in total across all bases (not 250 per base).<br />
<br />
The error message that pops up when you try to hire more is: <br />
<br />
"NO MORE SOLDIERS ALLOWED"<br />
<br />
"You have already recruited the maximum number of soldiers."<br />
<br />
=== Soldier Recruiting Bugs ===<br />
<br />
Also there are 3 bugs related to recruiting soldiers: <br />
<br />
* You still get charged for Soldiers you try to purchase above the No More Soldiers limit.<br />
* The error message that appears when you hire too many soldiers must be dismissed (click OK) once for each soldier over the limit, i.e. up to 255 times. <br />
* You get also charged for Soldiers you try to purchase above the Transfer Limit (100 at a time).<br />
<br />
=== Soldier Battlescape Limit ===<br />
<br />
In the Battlescape, there is a limit of 40 X-COM soldiers that can participate in any battle. Tanks/HWPs each count as 4 soldiers against this limit. Unless you use custom-modified aircraft, you will only see this limit in a Base Defence mission. In a Base Defence mission, all tanks/HWPs will be deployed first, in preference to soldiers.<br />
<br />
== Manufacturing and Research Bugs ==<br />
<br />
=== Zero Unit Manufacturing Exploit ===<br />
<br />
If you start a manufacturing project with zero items to build, close the screen, and then go back to assign staff and a non-zero build amount later, the first item is built for free. If you only build one item at a time, you can build them all for free. Obviously, this is cheating. It's also a bit tedious. It might be excusable if you're really short of money.<br />
<br />
=== Research Rollover ===<br />
<br />
At midnight, research projects are checked for completion in the order shown on your Projects screen (which is the same order as for picking new Projects, for [[RESEARCH.DAT]], etc.). But X-COM does not track the effort of individual scientists, so when a project ends, its scientists can be re-assigned before the game checks the next project.<br />
<br />
The upshot is that you can re-use scientists from completed projects as long as you put them on projects (existing or new) that are [[RESEARCH.DAT|farther down the list]] than the one that just finished. And if you assign more scientists than projects need, you can finish multiple projects immediately! <br />
<br />
To best use this exploit:<br />
*If projects (new or existing) have equal priority to you, start new scientists at the top of your list (the [[RESEARCH.DAT|lowest-numbered]] project) and work them "down" from there. This minimizes the number of times that scientists wind up at the end of the project list (where you can't exploit them).<br />
*It works especially well later in the game if you have a full complement of scientists (practical limit of 250 at a base) and apply them to the many "fluff" alien, corpse, and alien-room projects that [[Research_Technical_Details#Research_Time|average less than 250 research days]]. You might finish a lot at once.<br />
*If using it, you don't have to worry about "wasted" research effort due to allocating too many scientists to a project on its last day. Unless you're at the end of the project list, wasted scientists can be re-used, too - sometimes many times.<br />
<br />
=== Overcrowded Engineers And Scientists ===<br />
In the Dos version (probably the others as well) if you hire more than 255 engineers in a single base, the number of engineers in the base will read a negative number once the 257th engineer arrives. Any Engineers engaged in projects will continue to work on them, but if you cancel the project you will lose engineers until you have lost 255 of them. <br />
This bug also affects scientists. It may be exploitable to pay a negative salary at the end of the month.<br />
<br />
If you hire exactly 256 scientists or engineers, the total rolls over to zero. You pay zero salaries, and the resulting free Manufacturing / Research is limited only by the capacity of your Factories / Laboratories. Also works in TFTD.<br />
<br><br />
NOTE: you need to make sure that not all of their projects finish at the same time.<br />
Otherwise, you would be stuck with 0 'available' workers/scientists, i.e. unable to assign them to a new project.<br />
<br />
===Manufacturing Limit Bug===<br />
The number of hours remaining on a [[Manufacturing_Profitability#Profit_tables|manufacturing project]] is stored in a two-byte integer. If you build enough items that the total number of Engineer Hours required for construction is above 65535 hours, it will wrap around to 0 hours and display from there. Typically this drastically understates the amount of time that will be spent working on the items, but strictly speaking, it only subtracts 65k hours (so a huge project like 120k hours would still show ~55k hours' worth of Engineer time needed).<br />
<br />
This bug is not dependent on the number of engineers assigned to the project; it is a function of the number of engineer hours needed. You will most likely run into it when trying to build 2 Avengers at the same time or when queuing up large orders of items in bulk, such as armor or Laser Cannons. As a practical example, the number of Avengers needed to trigger the bug is 2. The number of Laser Cannons is 219. Toggle back and forth between 218 and 219 laser cannons at the beginning of a project to see the effects.<br />
<br />
It is known with certainty that this exists as a display issue - the screen will say you need less time than you should when you go over 65536 Engineer hours. [[User:Arrow Quivershaft|Arrow Quivershaft]] is also sure he's seen it eat an Avenger... he ordered two but only got one, even though it took the time, and cost the money, for two. He's tried to replicate this and hasn't been able to, however. So it clearly is at least a superficial display issue, and may be more than that ... possibly dependent on even something else. In any event, keep an eye on projects with more than 65k Engineer hours (and report back here!)... or just avoid going that high.<br />
<br />
===Manufacturing Completion Time Display Bug===<br />
<br />
If you start a new manufacturing project at 00:01, and the screen displays a completion time of 5 hours, you might expect the work to complete at 05:00 or 05:01. In fact it will complete at 06:00, one hour longer than indicated. <br />
<br />
The reason for this bug is that the time left to complete a project is decremented by the game by one hour, every hour, on the hour(XX:00).<br />
<br />
This display behaviour is consistent with what is shown while manufacturing is in progress. For example, if time remaining is shown as 0 hours, the work will complete at the beginning of the ''next'' hour. In effect, the displayed number is the integer-truncated form of the real time remaining. In the first example given above, the real time to completion is 5 hrs 59 min, misleadingly truncated to 5 hrs.<br />
<br />
===Manufacturing Rate Interruption Loss===<br />
<br />
In addition, as a result of integer truncation (see previous bug, Manufacturing Completion Time Display Bug), every time production stops, you lose an hour of manufacturing. Therefore, for most efficient production, manufacture in large batches (or increase batches while they are still in progress) to keep manufacturing as continuous as possible. <br />
<br />
<br />
===Manufacturing Rate Limit===<br />
<br />
There is a maximum production rate of one unit of any given type per hour per base. For example, though Alien Alloys / Aqua Plastics require 100 Engineer/Technician Hours per unit, even with 250 Engineers/Technicians you can only produce 1 unit per hour.<br />
<br />
===HWP Fusion Bomb Ammo Cost Bug===<br />
<br />
The HWP Fusion Bomb ammunition type, and its TFTD equivalent the ammunition for the SWS PWT/Displacer, appear to have the wrong manufacturing costs. <br />
The vehicle version is ''less'' portable and ''less'' powerful than the personal version (Blaster Bomb), ''less'' capable than the craft version (Fusion Bomb) - and costs ''more'' than either of the others in total cash and in materials. In particular, it makes no sense that the small missiles on the HWP/SWS use up ''more'' of both Elerium/Zrbite and Alien Alloys/Aqua Plastics than the Craft version. <br />
<br />
To correct this error, the craft round should have the higher base price, ''and'' the material requirements that are currently assigned to the SWS/HWP round. (It's debatable whether the SWS/HWP rounds should be more expensive than the man-carried rounds.) More discussion is on the talk page of this article.<br />
<br />
== UFOPaedia Errors ==<br />
<br />
=== UFOPaedia Craft Weapon Hit Probability Bug ===<br />
<br />
There is a bug in the in-game UFOPaedia. It mistakenly reads the damage value field when reporting the hit chance for a craft weapon. Hence:<br />
<br />
* Cannon shows 10% not 25%<br />
* Avalanche shows 100% not 80%<br />
* Laser Cannon shows 70% not 35%<br />
* Plasma Beam shows 140% not 50%<br />
* Fusion Ball shows 230% (!!!) not 100%<br />
<br />
Possibly the reason this bug was missed during testing is that the first weapon in the data files, Stingray, actually does have Damage equal to its hit probability.<br />
<br />
In the CE version, this is the problem piece of code:<br />
.text 45B2CC: 0F BF 4E 06 <br />
<br />
Change the 06 to 04. The offset may not be correct for everyone but it should be close. I don't know the offset in the DOS version.<br />
[[User:Morgan525|Tycho]] 06:27, 1 April 2012 (EDT)<br />
<br />
=== UFOPaedia Craft Weapon Reload Rate Bug ===<br />
<br />
From empirical research it looks like the reload rates of craft weapons are not stated correctly in the UFOPaedia. For example, the rates of fire of the Laser Cannon and Plasma Cannon are actually the same as each other, and they are both about six times slower than the regular Cannon (so about 12s) - whereas the UFOPaedia entry gives the reload times (inverse of the rate of fire) as being:<br />
<br />
Cannon 2s<br />
Laser Cannon 4s<br />
Plasma Beam 6s<br />
<br />
Similarly the UFOPaedia shows the Fusion Ball as having 3/5 the rate of fire of a Stingray missile, with the Fusion Ball being slower than an Avalanche missile; but empirically the Fusion Ball and Stingray have the same rate of fire, and so the Fusion Ball is faster than the Avalanche. See the discussion in [[Craft_Combat_Mechanics#Observed_Rates_of_Fire|Craft Combat Mechanics - Observed Rates of Fire]] for more details, but keep in mind recent code digs have clarified the picture from this initial rough approximation. It seems reasonable to assume the actual reload rates are coming from a different part of the executable, different to the locations used populate these values that are displayed in the UFOPaedia. [[User:Spike|Spike]] 23:25, 6 September 2012 (EDT)<br />
<br />
== Other Bugs ==<br />
<br />
=== Difficulty Bug ===<br />
The DOS version has a problem where no matter what difficulty level you choose, it will revert to "Beginner" level after the first mission. This is caused by one incorrectly set bit in all DOS versions of the game (1.0 through to 1.4). The Collectors Edition Windows port (also commonly known as UFO Gold or CE) does not have this problem. To check your [[Difficulty Levels|Difficulty Level]]:<br />
*Look at offset 60 in [[IGLOB.DAT]]. (If this file is only 60 bytes long, you've got the bug!) <br />
*Look at [[Alien Stats|statistics for aliens]] in your game with a [[Mind Probe]] or [[Psi-Amp]]<br />
<br />
To fix the Difficulty Bug, you can install [[XcomUtil]] and it will repair this bug. Alternately for those familiar with hex editing, you can fix this bug by referring to the appropriate section on the [[GEOSCAPE.EXE#XCOM: UFO Defense DOS Versions, difficulty setting bug | GEOSCAPE.EXE]] article and manually setting the incorrect byte to its proper value. <br />
<br />
:[http://tvtropes.org/pmwiki/pmwiki.php/Main/X-COM This TVTropes page] has been known to state that due to the bug, players asked the developers to increase game difficulty. The rumour goes that a new bug was supposedly introduced as a result, where TFTD's difficulty would reset to Superhuman instead of Beginner. The facts of the matter are that, while the overall difficulty of the game ''was'' increased, TFTD does manage to correctly keep track of which specific mode you're supposed to be playing in.<br />
<br />
=== Chrysallid / Tentaculat Difficulty Bug ===<br />
<br />
Stats of Chrysallids or Tentaculats that emerge from Zombies during combat have stats that ignore the difficulty level.<br />
<br />
=== Big Text Bug ===<br />
There are a few bugs in XCOM, especially early versions, that can build up and make the game unstable enough that it crashes and prints out a screen full of green 40-column text, essentially debug or memory dump information useless to you.<br />
<br />
You can also forced a crash by pressing CTRL-C at the start of a new game (DOS only). If you don't have any missions automatically saved within the [[Game_Files#Missdat_Files|MISSDAT]] folder, you will get this big text to appear. Typically it is green for Enemy Unknown, and blue for Terror From The Deep. Other colours have been observed such as pink, purple, brown and yellow.<br />
<br />
In the dos version, the text that you see is simply a memory dump in mode-13h (the 320x200x256 colour screen resolution) and the text colour is based off the changes to the palette that the game made. The batch file coordinating the two main programs [[Geoscape]] and [[Battlescape]] often succeeds in soldiering on after a crash. In the Windows version of the game, the game simply crashes back to the desktop, unless you're using the [[XcomUtil]] split executable variant (which uses a batchfile).<br />
<br />
Some things which will tend to cause this problem:<br />
* Overzealous use of Psi<br />
<br />
At least some of the instability crashes can be fixed by replacing the DOS/4GW dos extender with a later version from another DOS game. <br />
<br />
[http://syndicate.lubie.org/synd/html/synd_patches.php One of these], for example. Link to Syndicate fansite, instructions included.<br />
<br />
=== Cash Rollover Bug ===<br />
<br />
When your cash balance goes over $2,147,483,647, it will rollover and become $-2,147,483,647. Which means your game is done for, unless you use an editor. Fortunately, by the time you accumulate this much cash, you have usually completed all necessary research to win the game.<br />
<br />
=== Losing My Favourite Game ===<br />
<br />
There is a check whether the "Has X-com received a financial warning?" flag has been raised. If no, a warning is issued and the flag is raised. If yes, then the game ends, and the flag is lowered. HOWEVER, this flag is erronously not connected to any particular savegame, it is global across all savegames. This allows strange results when saving and loading games.<br />
<br />
== See Also ==<br />
<br />
=== [[Known Bugs (TFTD)]] ===<br />
For bugs that '''only''' affect X-COM: Terror From The Deep.<br />
<br />
[[Category: Oddities and bugs]]<br />
[[Category:Enemy Unknown/UFO Defense]]</div>
Spike
https://www.ufopaedia.org/index.php?title=Talk:UFO_Interception&diff=58879
Talk:UFO Interception
2014-08-16T14:41:10Z
<p>Spike: /* Interception Attack Modes */</p>
<hr />
<div>= Pursuit =<br />
<br />
TBD: Discuss pursuit on the Geoscape, bad intercept vector algorithm, speed differences, etc. <br />
Also re-engaging targets, targets that land, over land vs over water, multiple interceptors.<br />
<br />
= Engagement =<br />
<br />
<br />
<br />
<br />
<br />
==Interception Attack Modes==<br />
<br />
[TBD Summarise. Actually the main article already summarises this well.]<br />
<br />
I noticed recently that the different attack modes have different functions. I'll briefly summarize what I saw here, and if someone can confirm, we can add it to the wiki.<br />
<br />
Cautious Attack: Enter range to fire with longest range weapon. Pull back to standoff distance if craft takes damage from UFO return fire.<br><br />
Standard Attack: Enter range to fire with both weapons. Pull back to standoff distance if craft takes significant damage from UFO return fire [in one shot?].<br><br />
Aggressive Attack: Chase UFO to get as close as possible(64 range units), firing weapons all the way. Never pull back to standoff distance.<br />
<br />
Also, the UFO seems to have a greater chance of running away at the more cautious settings, [and vice versa] but that makes sense. ;) [[User:Arrow Quivershaft|Arrow Quivershaft]] 01:29, 29 February 2008 (PST)<br />
<br />
: I'm not entirely sure what the differences in behaviour regarding pulling out into standoff range when damaged are between the various modes (hadn't really noticed it too much myself), but the modes mainly function at adjusting the range of the craft and UFO. <br />
<br />
: In short: out of firing range, longest ranged weapon, shortest range weapon and as close as possible. One note about cautious mode is that it will revert to the next closest ''loaded'' weapon. If the longest range weapon runs out of ammo, the ship will close in to the next best weapon. <br />
<br />
: It's odd we left this explanation out, but yeah it needs to be there. - [[User:NKF|NKF]] 02:22, 29 February 2008 (PST)<br />
<br />
Any Interception craft at "Cautious Attack" that takes damage will attempt to retreat out of range to Standoff distance. Craft on "Standard Attack" will do the same sometimes. I see it most often when chasing Battleships with Firestorms or Avengers, and they get knocked good by a shot from the Battleship. Happens more often with Firestorms, so it's probably percentage based. Craft on "Aggressive Attack" will never return to standoff distance unless changed to a different mode or ordered to pull back or disengage; in that mode, the mentality is "Him or me." <br />
<br />
I don't get to see this much anymore because I usually use Aggressive Attack because a lone Avenger can go toe-to-toe with a Battleship and still make it back in fairly good shape(30% damage or so). A Firestorm can usually manage to limp back as well, but in considerably worse condition. [[User:Arrow Quivershaft|Arrow Quivershaft]] 12:25, 29 February 2008 (PST)<br />
<br />
----<br />
<br />
I've changed the main page to show some scepticism as to whether UFO damage vs interceptors increases due to interceptor attack mode. I don't believe it does. [[User:spike|Spike]] 08:40, 16 August 2014 (PST)<br />
<br />
=== Engaging with multiple craft ===<br />
<br />
If I understand the latest edit, UFOs will not "divide" their fire amongst multiple targets, but will fire at each of them as frequently as they would fire at a single ship. If that's the case, is there really any advantage to having all ships engage at the same time?--[[User:Ethereal Cereal|Ethereal Cereal]] 15:29, 5 March 2007 (PST)<br />
<br />
Thats because whoever wrote it was a moron, thats precisely what doesn't happen as I finally managed to identify just before writing it. Its tough to tell though, especially as you cant get them all to go in at once, and if you go in on aggressive attack it gets very quick at the end and hard to say whats going on. --[[User:Sfnhltb|Sfnhltb]] 15:43, 5 March 2007 (PST)<br />
<br />
The most convincing aspect for me anyway was the results - three interceptors armed with plasma mostly going in singly almost always get eaten, three at once (or as close as you can get it, and setting the cycle speed way down helps synchronise them better) nearly always wins and often doesn't take a single casualty. --[[User:Sfnhltb|Sfnhltb]] 15:47, 5 March 2007 (PST)<br />
<br />
: From what I can remember, the UFO's rate of fire gets faster and faster the closer you get to the UFO. I've tested this with two different ships with identical armament, with one on aggressive and the other on cautious. The one on cautious fired normally, but the one that got right up to the UFO was exchanging and receiving ammo at a considerably faster rate than the one on cautious. <br />
<br />
: That still this doesn't answer the question wether the UFO splits the attacks or fires on the ships normally. <br />
<br />
: Still, I find the odds of knocking out a UFO with multiple ships a lot better than to attempt it sequentially. (edit: or mind you if I'd checked through all the edits, all this has been covered already. Oh well.) - [[User:NKF|NKF]]<br />
<br />
:I did 10 tests each way yesterday from the same save - sequentially 1 win from 10, even that the last interceptor was fully red damage at the end (cant tell the exact numbers, for some reason after the fight the geoscape was zooming out past maximum and crashing to the battlescape). Simultaneous was 9 wins from 10, 0 shot down 2 times, 1 down 4 times, 2 down three times. I then did a few further tries later with all three having slowed the cycle rate down and got 0 shot down 3 times out of 4, as generally the first one in was the one that almost always died if any did, if you can get them all attacking closer together it ensures it doesnt take the first two or two of the first three salvoes. --[[User:Sfnhltb|Sfnhltb]] 05:06, 6 March 2007 (PST)<br />
<br />
I think some of what's written at [[Battleship#Weapons]] should be copied over. I've never tried it myself, personally; I don't bother engaging battleships until I have an Avenger. What I'd really like is some way to stop Terror Ships before I get Plasma Cannons... two Interceptors armed with Avalanches? Or does it take three?--[[User:Ethereal Cereal|Ethereal Cereal]] 21:59, 5 March 2007 (PST)<br />
<br />
:From the encounter I had yesterday, would suggest 3 is needed, it can trash them so quickly that you need to throw in loads. The one thing I noticed was that Avalanches in some ways seemed better than the Plasma cannons because you can get off a 1-2 rounds of missiles before the Plasma even starts firing due to the range difference, which is critical with your paper thin Interceptors vs the Battleships. --[[User:Sfnhltb|Sfnhltb]] 04:56, 6 March 2007 (PST)<br />
<br />
:2 interceptors with avalanches can bring down a terror ship and make it back to base in one piece. I think 10 avalanches will kill it. You do need to do the agressive trick with at least one interceptor to make sure all 6 missiles actually hit.<br />
:(Never tried interceptors vs battleship, it sounds suicidal.) --[[User:MB|MB]] 11:56, 6 March 2007 (PST)<br />
<br />
== Review of Air Combat Mechanics ==<br />
<br />
Moved to its own article [[Air Combat Mechanics]]<br />
<br />
= Operational and Logistic Aspects =<br />
<br />
==[[Repairs]]==<br />
==[[Refueling]]==<br />
==[[Rearming]]==<br />
<br />
*Seb76 Loader option to relaunch aircraft before they are fully ready.<br />
*Add link to "Duty Cycle" discussions & table<br />
<br />
<br />
==Patrolling fuel usage==<br />
<br />
TBD: Summarise fuel consumption for patrol/not, hybrid/not.<br />
----<br />
<br />
I saw somewhere that the skyranger at least uses less fuel when patrolling, but I have this vague recollection that the hybrids don't. Am I right in this or does it need investigating to determine one way or the other? --[[User:Sfnhltb|Sfnhltb]] 16:05, 5 March 2007 (PST)<br />
<br />
:You are correct, hybrids don't conserve fuel while patrolling. Only the originals do. --[[User:Pi Masta|Pi Masta]] 17:15, 5 March 2007 (PST)<br />
<br />
::That does appear to be the case. I just tested this with a Firestorm (not an Avenger), and there were a few quirks: fuel consumption was the same whether patrolling or not (which is what you were asking about); fuel readout only decreased in 5% increments (not well-documented); it returned to base when it hit 50% fuel, regardless of distance-to-base (argh). (Skyrangers and Interceptors will stay out below 50%, based on distance.) Fuel consumption was 0.5% of total per minute. <br />
<br />
::A patrolling Skyranger used up 0.02% of fuel per minute. A constantly-moving one used up 0.0455% per minute. This is more or less consistent with what is documented at [[Skyranger]].--[[User:Ethereal Cereal|Ethereal Cereal]] 18:29, 5 March 2007 (PST)<br />
<br />
<br />
= Strategic Aspects =<br />
<br />
<br />
== Scoring vs Location of Intercept ==<br />
<br />
I am currently on 23rd January, so should be able to check whether XCOM Activity relates more or less directly to your pay rise at the end of the month fairly soon, but if it does then clearly you will always want to shoot down UFOs over a sponsor country instead of neutral territory (especially the big scoring recovery missions).<br />
<br />
--[[User:Sfnhltb|Sfnhltb]] 06:31, 28 February 2007 (PST)<br />
----<br />
IIRC the amount of money you get is randomly assigned, though increase, decrease, or no change is based upon 'score', and the country's 'happiness' with XCOM. I think this can be seen by saving near the end of the month and noting the funding changes on each save (w/o doing anything special), I believe each time they will be random amounts (but again the sign of the change is dependent on the score, directly or indirectly).<br />
<br />
I'm not sure if a higher score as an effect on the average increase (or conversely lower score with average decrease). It is possible. However I imagine that you are still correct that downing a UFO over a sponsors country is better than over a neutral country.<br />
[[User:Pi Masta|Pi Masta]] 11:51, 28 February 2007 (PST)<br />
<br />
:Hmm, we should add a graphic to the wiki showing where the sponsor land masses are.--[[User:Ethereal Cereal|Ethereal Cereal]] 12:22, 28 February 2007 (PST)<br />
<br />
Yeah I had noticed it was random, I think your starting cash is as well, where the random range comes is was something I will be testing at the end of the current month of the game I am on, which might take a while as I am only playing intermittently (lots of work on atm)<br />
<br />
--13:11, 28 February 2007 (PST)<br />
<br />
----<br />
Don't bother with the funding deals. I did this looong ago, both at the [http://www.strategycore.co.uk/forums/index.php?showtopic=652 StrategyCore forums] as well as a complete country-by-country funding breakdown at the [http://www.xcomufo.com/forums/index.php?showtopic=7424 xcomufo.com forums]. Granted, this was for the starting funds, not for subsequent months. But I did run about 2000 trials on that scenario and found that funding was random within a certain range. --[[User:Zombie|Zombie]] 14:44, 28 February 2007 (PST)<br />
<br />
Hmm, well compared to the starting funds that you tested that were almost static overall (unless I am misreading it, +/- 15k or so?), the monthly amount varies a whole lot more, certainly +/- 250k from the average on a given good month I tested briefly to get an idea of it (and could grow more for an even better month I suspect). I would be interested in finding out what exactly affects it, and how responsive it is to key elements you might be able to control (like how beneficial is shooting down more aliens in sponsor country, compared to the same region (if that affects anything at all), and overall.<br />
<br />
Btw, in case you still are thinking about the question regarding the discrepancy between your income and expenditure at startup, i can tell you where the 1860000 comes from at least - its in LIGLOB (A0611C00 in backwards hex) - its basically the source of the Finance graph (except score, which comes from XCOM.DAT combined with UIGLOB), which of course assigns it all to Maintenance - which in theory could include 1.7 million for the planes, 300k for the scientists, 250k for the engineers, 160k for the soldiers, and 224k for the maintaince of facilities of the base, so it doesnt solve it, but at least you can eliminate paying for things in trying to work out what it is.<br />
<br />
The most obvious answer here is that you pay for craft rental (1.7 mill) and your soldiers (160k) = 1.86 million, and you dont pay for the scientists, engineers or base maintainance. --[[User:Sfnhltb|Sfnhltb]] 16:41, 28 February 2007 (PST)<br />
<br />
----<br />
The monthly funding (according to the OSG) is determined by these two equations:<br />
<br />
Alien activity in country + (Overall alien activity/5)<br><br />
X-COM activity in country + (Overall X-COM activity/10)<br />
<br />
These numbers are compared and if the alien score is greater than X-COM, the country decreases funding by a random amount, but no less than 20%. If X-COM is greater than the alien score, the country increases funding by a random amount, but no greater than 20%. I'm not sure what the upper or lower boundary is. It could be 0%. Who knows, the frequency of the non-20% limits may increase as score does. Suppose the easiest way would be to edit alien score to 0 and X-COM score to something high and check the results. That would correspond to "EXCELLENT" on the End Of Month report. Another test is to edit both X-COM and alien score to zero and check the funding there. This would correspond to "OK" on the EOM report. One thing is for certain, it would take a great many reloads to form any type of conclusion. One of these days I'll have to write up an AHK script and dedicate some computer time to this project. It won't be right away though. --[[User:Zombie|Zombie]] 21:47, 28 February 2007 (PST)<br />
<br />
:Ah, that explains something I was seeing - basically if you get double the Alien score, everything is good, if you are less than that everything is bad. When using very large numbers that is, to minimise other factors.<br />
<br />
:I think the increase is between 5-20%, if they come up as happy. But sometimes even with the same scores they turn out just to be satisified (current game I am playing, overall score 2.6k, alien score was 132 (and I think quite a bit of that I am double counting, country and region)<br />
<br />
:And yeah, no matter how high the XCOM scores went (very high values in the 4th byte didnt register, but I could get 30k or 60k I think, and there was no change in the range of values to cursory inspection at least. I am fairly sure that happy/satisfied/unhappy is an on/off switch that is fired by a comparision of the scores in a manner as you list above (but there is some randomness in it however).<br />
<br />
:The scale of the increase in funds seems to be based entirely on the existing funding level, so basically you just get a random percentage value within fixed limits (5-20% on the upswing, havent explored going down enough to say with enough confidence). If US is paying out 10 Million (and you have removed the funding cap, or it wont go higher), values are in the range of 500k to 2 Million if it increases, or 0 if they are only satisfied.<br />
<br />
:There isnt a whole lot of random numbers it rolls either, which you see with that nice round 10 mill, you get nice neat values spread out every 100k (rounding issues would make it look like there were more possibilities with a smaller existing fund). So its a random int between 5 and 20. Going down is probably a mirror image I would guess, but thats not got any real evidence behind it. --[[User:Sfnhltb|Sfnhltb]] 18:16, 1 March 2007 (PST)<br />
<br />
<br />
= Misc =<br />
<br />
= Old Chat =<br />
<br />
<br />
<br />
== Ye Olde Bayse Maynetaynanse ==<br />
<br />
Of course the thing that has lead me onto, is trying to work out how it calculates base maintenance. A lift only new base costs 30k (4k for the lift, 26k extra somewhere), and a vanilla starter base costs 224k, but the parts only add up to 169k, so the extra unassigned part raises to 55k. Whats going on?<br />
<br />
So I dismantle the starter base (after dumping all loose objects like people, planes and guns), the first Hangar drops the cost by 10k (not 25k), the next one by 4k (huh?), then 10k again for the last hangar, workshop drops it by 35k (correct!), the radar drops it another 35k (way high!), the living quarters are 30k, the lab 35k (a bit high), the stores 35k (massive - 7 times what it should be), and the lift 30k (4k in UFOpedia).<br />
<br />
I thought maybe this was messed up somehow because of being the starter base, but it seems to behave the same way in new bases - as I say empty base with lift 30k, lift + stores + small radar = 95k, adding alien containment, stores, living quarters to starter base is 55k up on the starting cost (second stores 10k off when removed, second living quarters 10k, alien containment 35k)<br />
<br />
So the same facilities take different maintainance depending on how many you have of them (it seems), and most of them cost different to what it says they do. No idea what the relationship or reasoning is behind all of this.<br />
<br />
--[[User:Sfnhltb|Sfnhltb]] 17:05, 28 February 2007 (PST)<br />
<br />
:No what's happening is that there are completed 'empty' modules. When you dismantle a facility it doesn't set the days to build to 255 like it should, and instead just puts the dirt tile there. Apparently these completed dirt modules take monthly maintenance (but isn't shown in the monthly costs IIRC). If you want me to find the post I can, but this is something I'm familiar with and in fact the 'editor' I'm making (PyXCom) should be able to fix it. (another thing is even if you build something and dismantle it before it's built, it will still count down and suck your money away)<br />
<br />
:Atleast I think this is the issue you are having. [[User:Pi Masta|Pi Masta]] 19:57, 28 February 2007 (PST)<br />
<br />
No I worked it out, I added the basic details to [[Known_Bugs#Facility_Maintenance_Costs]], there might be something additional as you say, as destruction a facility doesnt clear the construction counter as you say - in fact you can see that it keeps construction counters from previous saves as well at times, the clearest indication its doing stuff like this is if you start a game and name your first base something long, say 'ABCDEFG', and then start again and make a new base with a one character 'X', in the BASE.DAT you will see something like 'X CDEFG' (the space indicating actually a null (00) to show end of string). So when you save it doesnt 100% overwrite all bytes, just the minimum it needs to save the information for your current save (which may have errors like you suggest).<br />
<br />
--[[User:Sfnhltb|Sfnhltb]] 20:03, 28 February 2007 (PST)</div>
Spike
https://www.ufopaedia.org/index.php?title=UFO_Interception&diff=58878
UFO Interception
2014-08-16T14:36:58Z
<p>Spike: some additional data on interception and a slight reorg</p>
<hr />
<div>'''In other languages: [[UFO 요격|í•œêµì–´]].'''<br />
<br />
To attempt a '''UFO Interception''' select the global intercept command or click on the base you want the ship to be launched from. The second option only lists the ships at that base, where the general list is good for launching drop ships but may be a little too cluttered for launching interceptors once you have a number of them. <br />
<br />
While selecting the interceptor's destination, world time is halted. You can continue to scroll the map by way of the controls or the more recommended centre-on-location command (RMB). This is a great way to pause the map in order to survey the globe if there are too many things happening at the same time - and if your [[Geoscape]] time is moving too fast for your liking. <br />
<br />
==Movement==<br />
* Elerium-based ships have the highest acceleration and maximum speed but the shortest aloft time. Conventional aircraft have the longest aloft time, but are much slower. By virtue of its speed and large fuel capacity, the [[Avenger]] has the longest range overall, about twice that of a [[Skyranger]].<br />
<br />
* Your ship autopilot prefers to move along lines of latitude (parallel to the equator) for long-range travel. This is especially noticeable when charting trans-polar routes: the ship will circle around the pole instead of flying straight across it. You can shorten the route taken by directing the ship to several intermediate way points along a straight line towards your destination. This way, you can probably squeeze a little more range out of the Lightning, which has very little air-time, and squeeze a greater probability of interception from slower craft. <br />
<br />
* Note that when you tell your craft to intercept a UFO, they will head directly for it. This is fine when you have plenty of fuel to spare or if it is headed directly towards you. If the UFO is traveling at an oblique angle to your base however, you will find that your craft will follow a roughly parabolic arc in its pursuit, using up more fuel and time than is strictly necessary. It may be worth trying to judge an approximate interception point and sending your craft to that way point and then re-targeting as the distance closes.<br />
<br />
* With slower conventional aircraft (or faster UFOs), you may end up in a protracted, frustrating tail chase, waiting for the UFO to slow down and/or veer back on itself. Even when it does, the poor intercept algorithms (and/or poor acceleration?) of conventional craft mean you will often miss the UFO on the turn. <br />
<br />
* It is not possible to intercept a UFO if its current speed is faster than the maximum speed of the intercepting craft. Furthermore, if the maximum speed of the intercepted UFO is faster than the maximum speed of the intercepting craft, the UFO will have the option to break off combat, closing the Interception Window. <br />
<br />
* While chasing a UFO, it may land. It will stop and turn to a green icon. At that point, if you feel tactically strong enough, launch an immediate UFO Ground Assault mission against the landed UFO. Keep the interceptor stationed above the UFO, in case it moves off. UFO Ground Assaults are harder than Crash Recovery missions, for the simple reason that more aliens are left alive to fight back. However, the rewards are correspondingly greater. An interceptor can do you a better service by tracking a UFO to a landing site, than it can by forcing the UFO to crash, and much less by destroying the UFO (which earns only victory points, no material gains). <br />
<br />
* When intercepting a UFO, you may want to take care where you actually complete the interception - sometimes you might have little choice, but if you shoot down a UFO over water you will not be able to perform a [[UFO Crash Recovery]] mission later. In addition, shooting down a UFO (and later performing a mission on the crash site) over a sponsor countries airspace will cause increase in X-COM activity for that month (based on the score awarded), which helps keep that country happy and might persuade them to increase their [[Country Funding|funding]] at the end of the month.<br />
<br />
* There is a 'scramble' delay while your aircraft gets airborne, and before it starts moving toward the target. For Interceptors this delay is about 4 minutes after issuing the order to Intercept.<br />
<br />
== Interception ==<br />
[[Image:Interception.PNG|300px|right]]<br />
* [[Craft Armaments|Ship weapons]] will fire continuously at set intervals (based on weapon type, weapon speed, current attack mode, and possibly range) at an enemy target as long as it is within maximum firing range (represented by the range bars) - until it runs out of ammo. After one weapon type runs out of ammo, the ship will move to the maximum range of the remaining weapon (if any). <br />
<br />
* The three different attack modes have various effects. Attack mode affects the distance of the interceptor and the [[UFOs|UFO]], and the rate of fire between the interceptor and the UFO. (Possibly the return fire from the UFO is also faster; this is not clear). This means the UFO and possibly the interceptor will be exposed to more fire from each other's weapons, possibly at a shorter range, and are possibly engaged by additional (shorter range) weapons. Another effect is that the more aggressive the attack mode, the harder it is for either side to break off, and escape. Note, the selected attack mode for each interceptor controls the exchange of fire between that individual interceptor and the UFO only. Apparently, if you have two ships engaging the UFO at the same time using different attack modes, one on a more cautious mode will give and receive fire at a slower rate than a ship that's on a more Aggressive mode.<br />
<br />
* Also be aware when intercepting using Cautious attack that there is a [[Known_Bugs#Interceptions:_Using_Cautious_Attack|bug]] when you fire you final shots that will cause them to always miss. Try to change modes before the last shot ('aggressive' while last missile is en route, 'disengage' after it hits), or use a tool that fixes this bug.<br />
<br />
* Multiple ships (up to 4), can join the battle by way of minimising the controls while in stand-off and waiting for extra friendlies to arrive on the scene. This can be key if you only have regular Interceptors when a Terror Ship or Battleship turns up. Multiple ships take a UFO down faster, and the UFO splits its fire between all of them that are in range. I.e. fires randomly, making each of your craft more likely to survive longer on average. Try to make it so that all your ships come into firing range at the same time, so you can maximise the advantage of bringing them all together.<br />
<br />
* When chasing a ship, if the UFO starts to back off and you minimise the window, you must wait until your interceptor starts to catch up with the UFO before you re-open the intercept window, otherwise the interception will break off and will only start again once the UFO is back in stand-off range. If you let the UFO get away, the interception will halt and will only resume when the ship catches up with the UFO again - the net result is the same. The only difference is that the first method keeps the intercept window open while the other mode exits and then enters the intercept screen. There's no real advantage to this, except perhaps in TFTD when your ships are near the coast. <br />
<br />
<br />
===Interception Window===<br />
<br />
The Interception Window shows several things. It graphically displays the range, type, and remaining ammunition of the Interceptor's weapons with small brackets, shows shots traveling to each combatant, indicates distance to and relative size of the UFO, and shows the amount of damage that the interception craft has taken so far.<br />
<br />
There are several commands available to you in Interception:<br />
<br />
*Standoff (Top Left): Aircraft maintains standoff range with UFO (70km). Neither side can shoot due to range. If selected during active combat, the aircraft ceases fire ''immediately'' (regardless of whether any weapons are in range) and attempts to open the range out to stand-off range, and hold there.<br />
*Cautious Attack (Top Right): Interceptor will close to the UFO until it can fire its weapon with the longest range (unless the aircraft carries identical paired weapons, only one weapon will fire.) Should this weapon's ammo be depleted, the Interceptor will then close until the other weapon can be brought to bear. Should the Interceptor be damaged by alien fire, it will retreat back to Standoff range and mode. The UFO has a good chance of successfully fleeing if the interceptor's top speed is lower.<br />
*Standard Attack (Top-middle Left): The interceptor will close with UFO until it can fire both weapons and then maintain that distance. (If paired weapons are carried, this is the same as Cautious) If the interceptor is damaged badly in a single shot, it will retreat back to Standoff range and mode. The UFO has a chance of successfully fleeing if the interceptor's top speed is lower.<br />
*Aggressive Attack (Top-middle Right): Interceptor will attempt to get as close as possible to the UFO, firing both weapons as soon and as often as possible. Interception craft '''will not retreat''' regardless of damage, unless switched to a different combat mode. UFO will have difficulty fleeing combat even if interceptor is slower.<br />
*Disengage (Bottom-middle Right): Interception craft will ''immediately'' cease firing (regardless of whether any weapons are in range), and attempt to open the range beyond Interception range, > 75km. Once out of the Interception window, on the Geoscape the aircraft will disengage the UFO and start returning to base, though it can be ordered to do something else as soon as combat is broken.<br />
*View UFO (Bottom Right): View a side picture of the UFO; the same picture that will appear in the UFOpaedia upon successfully gaining the details of the vessel from an alien Engineer. Can be used to identify targets.<br />
*Minimise Window (Outside Top Left). Returns to the Geoscape view. Used to wait until target is over land, or until the aircraft closes to Intercept range, or to allow other aircraft to join the battle. Can only be activated when at Stand-off range. Geoscape time stops if any interception window is open (maximised). Minimise ''all'' windows to allow other aircraft to converge on the target in Geoscape and join the battle.<br />
<br />
===Interception Damage===<br />
<br />
Every time the weapon from an interceptor hits, it will deal anywhere from 50% to 100% of the damage rating listed on [[Craft Armaments]]. <br />
If a UFO has taken 50% or more of its damage capacity in Interception damage, it will crash-land (assuming it is over land) and X-COM will be credited UFO Grounding points and can later launch a UFO Crash Recovery raid to clean up anything left. <br />
<br />
If the UFO takes 100% or more of its damage capacity without crash landing, the UFO will be destroyed. No crash site will be generated, and X-COM is credited with UFO Destroyed points (which are double the points given for grounding the UFO).<br />
<br />
It should be noted that most UFOs yield enough points in recoverable loot to make it preferable to ground them, instead of destroying them. <br />
More to the point, UFO Crash Recovery missions yield tactical experience, salable loot, and researchable items, all of which are essential to winning the game and usually (but not always) more important than scoring points.<br />
<br />
===Interception Results===<br />
<br />
Short of a failed interception resulting in destruction of the interceptor, the outcome of a successful air skirmish will reward you with shoot-down points for the UFO and a crash site where you can salvage the remnants of the crew and what ever is left of the ship. <br />
<br />
Shooting a UFO down over a water will not produce a crash site. <br />
<br />
Destroying a UFO has the benefit of rewarding you with twice the usual shoot-down points, but no crash site is produced. <br />
<br />
<br />
==Patrolling== <br />
You can use this command to make ships act as mobile radars, sending them out to areas of suspected alien activity, or just as radar pickets to cover areas distant from your base (similar to an aircraft carrier's Sentry early warning aircraft). Particularly when looking for [[Alien Missions#Alien Bases|Alien Bases]] you will need to patrol a suspect area, but your crafts localised but powerful onboard radars can be useful elsewhere, and means they can be sent after a UFO which has left your tracking radius and should be able to reacquire them if you can anticipate the UFOs movement in the interim. Another potential benefit is that [[Interceptor]]s and [[Skyranger]]s will consume half as much fuel when patrolling than when flying around at top speed. This means they can stay "on station" for twice as long. This can make one or two conventional aircraft useful to have around even in the later game when they are otherwise mostly redundant in their original roles.<br />
<br />
[[Category:Game Mechanics]]<br />
[[Category:Enemy Unknown/UFO Defense]]</div>
Spike
https://www.ufopaedia.org/index.php?title=Talk:Known_Bugs&diff=42824
Talk:Known Bugs
2012-12-26T15:03:59Z
<p>Spike: /* Bad Paths Bug */ yes, and clean up needed.</p>
<hr />
<div>= Classification etc =<br />
<br />
== Bugs vs Exploits ==<br />
<br />
Could someone comment please on the distinction between a bug and an exploit, and where to put each one? I would guess that a bug is something that undesirable and an exploit "might be" desirable, if you want to cheat. But what about exploits that happen by accident, or bugs that need to be forced to happen? <br />
<br />
I was going to add the Research Rollover bug to the Exploits sections, but they seem to all be under construction. What's the agreed approach?<br />
<br />
[[User:Spike|Spike]] 04:16, 15 March 2008 (PDT)<br />
<br />
* i think that an exploit is somthing you can trigger and gain an advantage from. a bug may or may not have a known trigger, and does not give an advantage if it does.<br />
: All exploits are bugs, either in implementation or design. When using a bug to gain advantages that bug is used as an exploit (you are exploiting the bug). [[User:FrederikHertzum|FrederikHertzum]] 13:39, 10 May 2011 (EDT)<br />
<br />
:: IMHO, Laser Pistols Gifts to train reactions is an exploit, but it does not involve any bugs. It merely exploits the fact that laser pistols will not penetrate the front armor of Flying Suits. [[User:Jasonred|Jasonred]] 16:31, 10 May 2011 (EDT)<br />
<br />
::: I guess the point is to differentiate if it's a bug that's being exploited to your advantage, or it it's something confined within the game mechanics that you are exploiting to your advantage (even if using it as intended). -[[User:NKF|NKF]] 02:31, 11 May 2011 (EDT)<br />
<br />
:::: Another definition: An exploit is <br />
::::: a) a move allowed by game interface <br />
::::: b) that sidesteps another part of the game mechanics<br />
::::: c) and creates inadequate advantage for the moving player in the process.<br />
::::: An exploit is not a bug, but it can be connected with a bug, if the latter allows a move mentioned in a). Most obvious exploits render whole parts of game mechanics obsolete (see b) above), because they are always more advantageous. In games that feature equal terms for AI and the player, an exploit can be discerned simply by the fact that AI does not use it (sadly this is not true in X-COM). Clear exploit in X-COM: Transfer soldiers = no monthly payment. Suspect exploits: grenade layout. Most probably not an exploit: Sniping (although the inequality with AI is suspect). Clearly not an exploit: dropping weapons to prevent Psi mass murder (this one is made exploitable by the AI unable to pick up weapons, but is not an exploit per se).--[[User:Kyrub|kyrub]] 05:30, 11 May 2011 (EDT)<br />
<br />
The dropping weapons sort of turns into an exploit if you do the "everyone suspect of being a psi weakling drops their weapons at the end of the turn. They all pick up their weapons again if unpsied in the next turn." The grenade layout or grenade hot potato is probably not what the game designers had in mind, but I shudder at the thought of someone who only played X-com then joined the army pulling the pin out of his grenade and then dropping it into his haversack or slinging it on his belt. [[User:Jasonred|Jasonred]] 07:43, 11 May 2011 (EDT)<br />
<br />
: Yeah, I think we agreed somewhere that shoving live grenades in your pockets and not having them go off is madness. The relay however is not sensible but certainly possible if only a very short one (if with a live grenade), or to toss a grenade forward and prime it at the second to last person. Or more reasonably, something like a stick of dynamite with an extra long fuse. Even that's very dangerous. <br />
<br />
: By the way, what does everyone here think of using the mind probe to check if it's safe to attack an alien while standing in full view of it, or if you're right up next to it? I've been using it a lot lately (in lieu of the psi amp), so you could say I've been exploiting the mind probe to my advantage to help me with my decision making. But is that counted as a cheat since I'm picking my moments to attack up close when the enemy cannot return fire? -[[User:NKF|NKF]] 03:30, 12 May 2011 (EDT)<br />
<br />
:: When identifying a mechanic as an "unfair exploit" (as opposed to just a "tactic"), perhaps a simpler checklist is this (though Kyrub's is spot-on):<br />
<br />
:: a) Is this something the developers should've expected players to do?<br />
:: b) Is this something the developers could've easily prevented?<br />
<br />
:: If the answer to both is "yes", then it seems fair game to me. For eg, sniping at aliens: The game KNOWS whether the soldier can see the target (you get a flashing indicator if so), and so it would've been trivial to prevent it. Is it something the regular gamer will try? Certainly; therefore it can be considered expected behaviour. Ditto for using the Mind Probe to make attacks without fear of reaction fire; those things aren't cheap, they sell for a bunch, so it stands to reason that they'd have tactical value!<br />
<br />
:: Things like the transfer bug are clear exploits. The devs would've implemented that system so that, if you order personal near the end of the month, you don't end up paying for them twice before they ever arrive - but in the process, they forgot that "purchase" transfers are treated in the same way as "between-base" transfers. To fix one scenario without breaking the other, they'd've needed to code in some extra stuff so the game could tell the difference - they probably just figured the regular gamer would never notice, assuming they ever realised the problem existed.<br />
<br />
:: The "dropping weapons" thing is a little trickier to work out - yes, the devs should've seen it coming, but would it've been easy to fix? Aliens could've been twigged to either ignore un-armed soldiers... but those soldiers could re-equip next turn. Aliens could also've been twigged to attack randomly... but that would make their psi powers far LESS effective! I suppose the fix, if any, would've been unarmed melee attacks, but the implementation they went with seems to be the next best thing IMO.<br />
<br />
:: In regards to the "grenades in inventory" thing, it's probably common knowledge by now, but they DO go off in the alpha of the game. Presumably someone made a conscious decision to change that, though it could still just be an accidental bug. - <span style="font-size:xx-small">&nbsp;[[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 09:02, 12 May 2011 (EDT)<br />
<br />
Sniping at aliens is a very bizarre case, since almost all players will fall prey to the aliens sniping at you long before they snipe the aliens. The behaviour of the aliens to step within sight radius, take one step back, then fire without fear of retaliation *looks* and *feels* like clear exploitation of the rules, but the computer can't be a cheater, can it? So we humans carry that one step further. Mind you, I think X-com would be in trouble if the aliens could snipe you from across the map once they know your positions... especially since the aliens have cheating "if I spot 1 human, I spot ALL of them" abilities. Especially on maps where the aliens get Blaster Bombs...<br />
<br />
An interesting note about sniping and LOS: When I first played Xcom, my first mission was in the jungle. Because of all those plants, when my first soldiers spotted an alien, after he shot at him, I tried to make my 2nd soldier open fire and was informed "NO Line of Fire". I could only get my 2nd soldier to fire by positioning him in such a way that I got the flashing number. Henceforth, I assumed that you could ONLY fire at the aliens when the flashing number was there. LOL. LOF. LOS.<br />
<br />
Transfer bug wise, I thought that the devs merely programmed the game to count how many staff were currently in the base, then deduct that from Xcom coffers? As far as ordering personnel near month end goes, you end up paying salary for them if you order them more than 48 hours from month end, right? "realistically", they should make staff draw salaries based on when they were hired, but this would be too much effort.<br />
<br />
"dropping weapons" would have been easy enough to fix... just teach alien AI how to pick up weapons. Like they did in Apocalypse.<br />
<br />
As far as grenade relays go, if you ever join the army, and you toss a live grenade at your squadmate, you're gonna be court martialled! lol. Xcom grenades are weird cause they presumably come with a computer console where you program them or something that takes a lot of TU, if I already have a grenade in my hand I don't think it takes long to prime it compared to throwing it...<br />
<br />
Pretty clear exploit/bug is tossing grenades through the ceiling? That breaks all laws of realism/logic/whatever, and I'm sure the devs didn't plan for THAT to happen! [[User:Jasonred|Jasonred]] 18:18, 12 May 2011 (EDT)<br />
<br />
: Turns out the "spot one, spot all" thing was wrong all these years. However, units can be "spotted" by sniping an alien, hitting it, but failing to outright kill it; this may have contributed to the misconception.<br />
<br />
: The game considers the base to have the correct amount of personal as soon as you initiate a transfer - if a base has room for ten people, you can't send two groups of ten, as soon as the first is in transit the game will correctly recognise that the destination is now filled up and won't allow you to send any more. Likewise, if you hire soldiers, they'll count towards the allowance of more promotions in your ranks before they ever arrive at a base. That is to say, the payment system deals with personal counts in a different way to every other system in the game, making it look like it's intentional (if badly exploitable) behaviour. In terms of transit times, those seem to vary, I know a purchase of scientists takes 72 hours to arrive.<br />
<br />
: Er, yes, getting aliens to pick up weapons would've indeed fixed the dropping thing. Shoulda thought of that...<br />
<br />
: The grenade thing is indeed unrealistic however you look at it. Certainly throwing the things through ceilings is a bug, and its use is a large exploit. - <span style="font-size:xx-small">&nbsp;[[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 20:02, 12 May 2011 (EDT)<br />
<br />
:: Then how do the aliens "spot" the psi weakling to target him for psi attacks? Doesn't the game ALWAYS start blasting the juiciest target, regardless of LOS? Or is it just coincidence? [[User:Jasonred|Jasonred]] 22:22, 12 May 2011 (EDT)<br />
<br />
::: They really have to "[[UNITPOS.DAT#8|spot]]" the target before they can blast them (however, it appears that later in a campaign this rule gets broken). If they've only spotted a psi-''resistant'' trooper, they typically won't bother to make attacks at all. There's a lot of relevant information in [http://www.strategycore.co.uk/forums/Can-alien-attempt-Mind-control-Pani-t8115.html this thread]. - <span style="font-size:xx-small">&nbsp;[[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 23:28, 12 May 2011 (EDT)<br />
<br />
: Your talking about your post on http://www.strategycore.co.uk/forums/Can-alien-attempt-Mind-control-Pani-t8115.html&pid=96123&mode=threaded#entry96123 ? Well, I'd just like to point out a massive flaw in your testing logic. You forgot that aliens will launch psi attacks based on chance of success, and chance of success varies based on distance from aliens. In other words, it could easily be that the aliens only attempted psi when your soldier was within sight of them because your soldier was now NEAR to them and therefore they had a strong chance of success.<br />
<br />
: Also, as you have noted, it appears that your rule gets broken. In fact, it is not uncommon at all for the Ethereal Commander who is boxed up in the Command Center to launch psi attacks on victims who are separated from him by several layers of walls, as long as their proximity to him is near enough. [[User:Jasonred|Jasonred]] 21:19, 13 May 2011 (EDT)<br />
<br />
:: Those are valid points. I've hence built a somewhat more robust testing scenario, which you may wish to [[:Image:Alien Psi Demonstration 1.rar|try for yourself]].<br />
<br />
:: The save game consists of cloned Ethereal soldiers (all cranked up to 100 psi strength/skill), and many clones of a single trooper (most of whom have the same psi values). The Ethereals are all cooped up in a sealed room in the SW of the map, with a single trooper who has 140 psi strength/skill.<br />
<br />
:: Directly outside the building is another trooper who only has 1 strength/skill. In the NE of the map, in another sealed room, is a soldier with 40 strength/skill. Before placing him there, I had him shoot one of the Ethereals just once, resetting index 8 of his UnitPos record to 0. Only he and the trooper inside the room with the Ethereals have hence been "exposed" to the aliens, but the "best chance of success" is obviously the psi-weakling directly outside the building.<br />
<br />
:: If you load the map and end turn, the aliens will first attempt to take control of the dude on the other side of the map, then get to work on the guy in the room with them. Once they've taken these two, they'll completely ignore all other units.<br />
<br />
:: In short, aliens can't use psi attacks on a unit UNLESS their UnitPos[8] index is set to less then that of the alien's intelligence stat. - <span style="font-size:xx-small">&nbsp;[[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 05:41, 14 May 2011 (EDT)<br />
<br />
::: Good one. That test definitely proves a lot, rather conclusively. [[User:Jasonred|Jasonred]] 06:53, 14 May 2011 (EDT)<br />
<br />
== Bugs vs Limits ==<br />
<br />
''(Discussion continued from [[Talk:Known Bugs#Soldier Recruiting Bugs Tested|Soldier Recruiting Bugs Tested]])''<br />
<br />
The "Soldier Recruiting Limit" is <b>not</b> a bug, it is a limitation of the game. Therefore, this should be removed from the page. If we want it somewhere else (like a new page such as [[Game Limitations]]), that would be appropriate. --[[User:Zombie|Zombie]] 01:42, 9 November 2008 (CST)<br />
<br />
::Not sure that's necessarily the best idea, Zombie, since many of the entries on the Known Bugs article(as well as some entries on the Exploits pages) are limitations of the game engine. On just a brief glance through, the following caught my eye as engine limitations: Manufacturing limit, Storage limit, Purchase limit, 80-item limit, Proximity Grenade limit, Large units not waking up from stun, Interception last shot bug, Alien UFL radar blitz-through bug(Passing through the detection range of a radar before the detection check comes up), Free manufacturing, free wages, UFO Redux, point-scoring with Ctrl-C, permanent MC of chryssalids, Zombie-MC resurrection of agents, alien inventory exploits, anything involved with bad collision detection, extinguishing fire with a Smoke Grenade, and even your personal favorite, denying the aliens access to their own spawn points. So in conclusion, maybe it should just be left as it is; conversely, all of these entries could be kept where they are and also on a Game Limitations page, or we could leave the headers there and link them over to the appropriate topics on Game Limitations. What do you think? [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:21, 9 November 2008 (CST)<br />
<br />
: I agree with AQ (great list of examples by the way - and the Smoke/Fire limit would be another). Many, if not most, of the bugs are "Limitations" but they are logically inconsistent and not what a player would expect to happen: they are imposed by (at best) memory limitations or (at worst) design/programming oversights. I think the easiest thing to do would be to change the title of the page to Known Bugs and Limitations, or put an explanatory note at the beginning of the section to explain that "Bugs" is taken to included "Limitations". [[User:Spike|Spike]] 13:16, 9 November 2008 (CST)<br />
<br />
By the strictest sense of meaning, a "bug" is a mistake or error on the programmers part. Limitations imposed <i>by design</i> or memory are not the same creature as the people involved were consciously aware of the decision. I suppose that to the normal player, any type of behavior which is unexpected/unwanted is automatically dumped in the bug category because to them there is no difference. To those of us who study the game files however, the two are unequivalent. Programming oversights, yes, those are bugs.<br />
<br />
Some of those limitations AQ mentions are (to me at least) bugs: free manufacturing, free wages, permanent MC of Cryssies (or actually any alien for that matter), Zombie resurrections and collision detection. Large aliens not waking up from stun is again, a bug. The programmers obviously had some issues when dealing with large units in general and never quite got it right. They made some progress in TFTD by trying to fix mind controlling each section of a large unit, but royally screwed it up by selecting the next 3 entries in UNITPOS.DAT no matter what they pointed to.<br />
<br />
Perhaps it's just my background in logic which makes me want to push for a separate category for limitations. Then again, as long as everything is listed somewhere I'm happy. --[[User:Zombie|Zombie]] 22:06, 9 November 2008 (CST)<br />
<br />
: Actually, taking a look through the page as a whole there are various other Limits described, and the distinction between Bugs and Limits is made quite rigorously throughout - not just in the Soldier Limits and Bugs section, where the Soldier Recruiting Limit is referred to as a Limit whereas other bugs (such as paying salaries for soldiers you can't recruit) are referred to as Bugs. So we maybe just need to rename the pages "Bugs and Limits" and add an explanatory note on the distinction. From a user point of view, rather than a programmer point of view, a bug is an unexpected (inconsistent or illogical) behaviour, so for that reason I think it makes sense to keep them on the same page but try to ensure they are all correctly classified as Bug or Limit.<br />
<br />
: By the way, it could be hard to absolutely distinguish Bugs from Limits as I suspect there are going to be some grey areas where you would have to second-guess the intentions and decisions of the coders to know for sure if something was a designed-in Limit, or just an oversight (Bug). [[User:Spike|Spike]] 06:50, 10 November 2008 (CST)<br />
<br />
::If we distinguish in this manner, I suggest the definition of "Limit" should be, "Something imposed by the game files or engine as a limitation, most likely in context to the capabilites of the then-current personal computer." More succinctly, anything that was done to allow the game to run acceptably on what was then a PC. This would include both the Soldier and 80-Item limits, the spawn limit(40 units per side), Smoke/Fire limit, and some of the others listed. (The Purchase limit was probably more of a convienence for the programmers than anything, but it is clearly an intended feature.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:11, 10 November 2008 (CST)<br />
<br />
: I would add to this that sometimes a Limit may be imposed as a game design / gameplay decision, rather than in order to conserve a constrained resource in the platform (=PC). Also, I would suggest that ''intended'' Limits are Limits, but ''unintended'' consequences of Limits are Bugs. Obviously, making this distinction involves some guesswork. But I would guess that while the limit on total smoke/fire hexes was an intended Limit (to conserve PC resources), the ability to put out fires with smoke grenades and disperse smoke with IC rounds is probably an unintended consequence of the Limit, and so should probably be considered a Bug. Similarly, Base Defence spawn points are probably an intended limit, but the ability to flood spawn points is an unintended consequence of this, and thus a Bug (and an Exploit). (Spawn points should have been shared out 50/50, not humans-first). [[User:Spike|Spike]] 12:07, 11 November 2008 (CST)<br />
<br />
::The limit on Soldier and Interception craft were probably more of a limit imposed because they capped the file and figured that X-COM wouldn't ever need more than 40 interception craft or 250 soldiers. (And I've never needed that many, case in point.)<br />
<br />
::As for spawns, its actually difficult to take advantage of it in any reasonably established base. X-COM can spawn up to 40 soldiers in a base defense mission(tanks count as 4 soldiers), as a limit of LOC.DAT. Aliens have the same limit. So in order to take advantage of the bug, the base needs 40 or less spawns total. The Access Lift has 8 spawn points, General Stores(weapon-handling) has 11, Living Quarters has 8 more. This is 27 Spawns just getting soldiers in a base and armed. (Although the General Stores can be cut out if you perform the bug properly). Large Radar and HWD have 6 spawns(Small Radar has 2), and Hangar has 15. So overall, the "Spawn prevention" can be hard to take advantage of with all but the smallest bases. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:48, 11 November 2008 (CST)<br />
<br />
Just to clarify, X-COM interception craft are not capped at 40 ships. LOC.DAT has a cap of 50 "things" on the geoscape screen at a time. This is shared between X-COM bases, X-COM ships, alien bases, seen or unseen UFO's, terror sites, crash sites, landing sites and waypoints. In a perfect game world with little alien activity and normally constructed bases, the max number of X-COM craft possible is 44: 5 bases with 8 hangars each plus one base with 4 hangars (or any combination thereof). If you illegally modify your base layout with an editor to get rid of the access lift, the max can be increased to 45 ships (9 hangars in 5 bases). Once clogged, all alien activity will cease.<br />
<br />
The base defense limit of 40 units exists because of UNITPOS.DAT which has a cap of 80 entries total (tanks occupy 4 entries in this file). Auto-win missions in a base defense mission by clogging all the spawn points with X-COM units isn't as tough as it sounds, especially if your base is small or doesn't contain hangars. The main thing is getting your full quota of 40 units to spawn (meaning you should try not to have any tanks as they count as 4 units but only occupy one spawn point). This limits the base size to something like 5-6 modules depending on what you build. Still, even having more than 6 modules isn't bad as it forces aliens to spawn intermingled between your troops. With 40 armed guys staring in every direction, you can get positions of all the aliens in the first round and possibly even kill them all (depends on weapons and alien race of course). --[[User:Zombie|Zombie]] 20:12, 11 November 2008 (CST)<br />
<br />
: I would say that Limits are the CAUSE of bugs... also, I feel that fire/smoke limit can be called a bug, because a player normally has no way to tell this, other than observation. Whereas the game DIRECTLY and CLEARLY informs you whenever you hit the 80 item or 250 soldier limits, which is more fair. [[User:Jasonred|Jasonred]] 15:22, 23 March 2009 (EDT)<br />
<br />
= Specific Bug Discussions =<br />
<br />
== Misc Technical Bug ? ==<br />
<br />
''(The context of this discussion seems to have been lost)''<br />
<br />
This is a technical bug that doesn't happen to everyone and one this article wasn't really meant to chronical - but we won't turn away helping a fellow player if it can't be helped. It's just that there are so many random crash points in this game that it would take far too long to find them all or come up with solutions for them. <br />
<br />
Certainly, the transfer crash can happen to some players, but it's not one that can be reproduced easily. It's just like the random crash that some players get when they research a floater medic. It crashes the game for some of us, but others don't seem to notice it at all. <br />
<br />
It really depends on your hardware and OS setup, whether or not your copy of the game is damaged or your savegame is damaged, etc. <br />
<br />
Does it happen in all games or just this one savegame? <br />
<br />
- [[User:NKF|NKF]] <br />
<br />
-----<br />
<br />
== "Invisible Muton" bug ==<br />
<br />
Upon shooting repeatedly a Muton, it sometimes plays its "death" animation without sound (as if falling unconscious) and it is no longer displayed in the screen, while remaining visible to my soldiers (I can center the screen and the cursor appears yellow over them). Under this state, they cannot be targeted by Stun Rods. They may play their death animation anytime they get shot, until they truly die, when they emit their characteristic sound and leave a corpse (along with any items carried).<br />
<br />
I'm quite fond of laser weapons, maybe this happens more often with those.<br />
<br />
Also, though I remember experiencing this quite often fighting Mutons, it may happen to any other high health race.--[[User:Trotsky|Trotsky]] 02:59, 2 July 2006 (PDT)<br />
<br />
-----<br />
<br />
Never seen that one myself. Another "unpatched game" thing maybe?<br />
<br />
There's a (very rare) bug that allows your soldiers to live if they become stunned by an explosion that happens to kill them. Sometimes the game will register their death, and THEN register that they've been stunned. In every case I've seen this happen, however, the unit will have such a low amount of health that a single fatal wound will render it dead (again) on the next turn. I have a vague memory that other players may have been able to get a medkit to the scene on time...<br />
<br />
I dunno if that's related to your issue at all (I doubt it, but... meh). I'd advise using a Mind Probe on the alien the next time it happens so you can check the aliens stun/health levels.<br />
<br />
- [[User:Bomb_Bloke|Bomb Bloke]]<br />
<br />
----<br />
<br />
I'm pretty sure I've seen this with Mutons. Possibly Chrysallids as well, another high health, high armor creature. They were still readily killed by shooting the place they are. Good thought on the MP, BB<br />
<br />
---[[User:MikeTheRed|MikeTheRed]] 08:51, 2 July 2006 (PDT)<br />
<br />
----<br />
<br />
<br />
<br />
I've been known to have a dying muton(in fire) to spin around and then switch to the female civilian death animation. With the scream and everything. Even got a civilian death registered at the end of the mission. And this didn't just happen once, but on another separate occasion.<br />
<br />
Hmm. shape-shifting reptilians in the game! LOL! Happens alot [[User:EsTeR|EsTeR]]<br />
<br />
<br />
Unusually enough, I once had a sectopod die and then drop a tank corpse. I was using the Lightning at the time for my troop carrier, so you can imagine my surprise. <br />
<br />
Then there was one occasion where a floater dropped a snakeman corpse. Let's not even get into the sort of things the aliens like to stuff themselves with. <br />
<br />
Your invisible alien bug is quite common, although there appears to be many causes for it. I think one involves a full object table when it comes to invisible aliens in bases. But it can also happen in ordinary missions as well. I'm guessing the game may have tried to do something in the wrong order, and sprite information for the unit may have been lost or corrupted along the way. <br />
<br />
Having had an experience where all the chryssalids become invisible in one base defence mission was quite a shocker. I fixed this by saving the game, quitting and then restarting the game. If you ever get an invisible alien again, try this and see if it helps. If it doesn't, well, just keep a careful watch on your map and any alerts that pop up as you play. <br />
<br />
There's a similar but less severe bug where a dead alien will still leave its centre-on-unit alert button, but this goes away shortly after you move or turn. <br />
<br />
- [[User:NKF|NKF]]<br />
<br />
----<br />
<br />
That last bug happens when exploding Cyberdiscs kill nearby Sectoids, doesn't it?--[[User:Trotsky|Trotsky]] 23:56, 2 July 2006 (PDT)<br />
<br />
----<br />
<br />
This is a pretty easy one. I guess this bug occured on UFO recovery on a battleship, an alien base assault or a base defense mission? As soon as there are too many items on the map, the game saves some item slots for the equipment to be displayed (since it is more valuable and more important to research). This would also make stun weapons lethal if the stunned aliens would vanish. therefore the game has a failsafe if an alien is stunned (or badly wounded and becoming uncontious). The downed alien's stun level is set exactly on its left health points therefore resurrecting it instantly. This cycle is broken when the alien is finally killed. This means if you want to stun an alien in such a situation you have to destroy some items first.<br />
<br />
- by tequilachef (April 4th 2007)<br />
<br />
== Vanishing snakemen ==<br />
<br />
I've known snakemen to become invisible when standing on a hay bale. On the first occassion I had a poor tank getting shot while spending numerous turns looking for it. On the second occasion I had an alien under Psi-control, left it on the hay bale, and couldn't find it next turn. - Egor<br />
<br />
---<br />
<br />
This is not limited to snakemen. Hay bale block visibility quite much when a unit is standing on it. Two possible solutions:<br />
- Destroy the hay before entering<br />
- Shoot at the hay. If it is destroyed any unit on it will become visible (as long as no other bales are blocking the line of sight). You might also hit the enemy directly.<br />
<br />
I Dnt know if the aliens are affected by this diminished sight, too. My guess would be no.<br />
<br />
- By tequilachef (April 4th, 2007)<br />
<br />
== Blaster Bomb Bug ==<br />
<br />
I'm currently playing through X-com UFO Defense, I have the collectors edition version. I'm in the process of trying to catch a live alien commander and the blaster bomb bug is making this very difficult. If i remember correctly a commander is always in the command center of the the alien bases. The problem is anytime i get close there is always a dude with a blaster launcher up there that tries to kill my troops. When they try to fire it down at me the bug kicks in and they blow up the whole command room and all the aliens in it because they can't figure out how to get the blaster bomb down the grav lift thing in there. This is making it very dificult to actually catch a live commander. Anyone have any ideas for tactics or anything to breach that room without the aliens trying to fire a blaster launcher up there? - eL Hector<br />
<br />
: I can suggest two possible solutions. The first is to wait outside the command room for the alien to move closer to you. If it comes out of the room or if you know it has moved down the lift, you then burst in and stand right next to it to stop it from firing the blaster. This is risky because there could very well be a heavy plasma toting alien in there. The other is to use a small launcher and launch it up at the ceiling near where you think the alien with the blaster is standing. -[[User:NKF|NKF]]<br />
<br />
== Disappearing Ammunition ==<br />
<br />
I have observed that problem with X-COM 1.2, modded with XCOMUTIL. My stun bombs and heavy rocket missiles, along with clips for the auto cannon went missing.<br />
[[User:Vagabond|Vagabond]]<br />
<br />
------<br />
<br />
Just run a test using my 1.4 DOS version with XComUtil but my stun bombs didn't disappear: 30 + 1 back in the base they came from, same number after I went tactical and I dusted-off immediately. Are you running XComUtil with Runxcom.bat or did you simply run Xcusetup?<br />
<br />
[[User:Hobbes|Hobbes]] 22:12, 22 February 2007 (PST)<br />
<br />
:Is it a case of hitting the 80-item limit?--[[User:Ethereal Cereal|Ethereal Cereal]] 12:28, 23 February 2007 (PST)<br />
<br />
------<br />
With runxcomw.bat, as everytime. Apologies, I retested and it seems like I was mistakened, but I could have sworn that I lost them dang stunbombs. Had to manufacture some. I will test some more, using four heavy weapons and seeing whether their ammunition disappears at all. Thanks. [[User:Vagabond|Vagabond]]<br />
<br />
==MC at end = MIA?==<br />
<br />
I am sure I have seen this again recently, where I won a mission with no casualties (I thought), but the last thing I killed was a Commander that had been chain MC'ing a psi-attack-magnet trooper, and that trooper was listed as MIA at the end (presumably because he was on the enemy side at the end of combat). Is this a bug, or is there another way to get MIA's on a completed mission that I might have missed?<br />
<br />
Since then I have been waiting for the leaders to panic at the end before killing them (or waiting for a rare resist), so I can safely exit, but am I being overcautious?<br />
<br />
--[[User:Sfnhltb|Sfnhltb]] 13:45, 27 February 2007 (PST)<br />
<br />
If the trooper was mind controlled on the turn you killed the last alien it will be listed as MIA. No bug there :) <br />
<br />
[[User:Hobbes|Hobbes]] 18:16, 1 March 2007 (PST)<br />
<br />
Huh, why would that happen - your soldier should recover the very next round, why would he go MIA?<br />
<br />
--[[User:Sfnhltb|Sfnhltb]] 18:20, 1 March 2007 (PST)<br />
<br />
Doesn't make sense to me as well but that's how the game works. <br />
<br />
[[User:Hobbes|Hobbes]] 15:05, 2 March 2007 (PST)<br />
<br />
----<br />
<br />
It seems that regaining control of units under enemy mind control works different for alien and human players. My guess: aliens under human MC are reverted to alien control AFTER THE ALIEN AND BEFORE THE HUMAN TURN while human units under alien control are reverted RIGHT AT THE BEGINNING OF THE HUMAN TURN. This explains three different phenomenons:<br />
<br />
- The discussed MIA "bug" (he unit would be returned in the next human turn, but since it never starts it is lost. The mission is still won since no unit with a "genuine alien" marking is left)<br />
<br />
- The fact that a mission is lost when the last human falls under MC while it is not won when this happens to the last standing alien (the aliens get their unit back before their turn starts and therefore have a unit left to pass the "anyone alive?" check, the humans would have no unit left to start a turn with. They WOULD have as soon as the turn starts, but no unit left before turn means bust)<br />
<br />
- The fact that aliens still can see all an MCed human saw at the end of the human turn that follows the MC while this is not vice versa (The MCed human can give information to the alien side before reverted while an MCed alien is reverted too early). The result is that aliens can control a human indefinitely without having any alien seeing him until the MC is disrupted for one turn.<br />
<br />
All confused? Then I did a good job! No seriously, this must be the explanation, I couldn't think of any other way.<br />
<br />
- By tequilachef (April 4th, 2007)<br />
<br />
: You're absolutely correct on the first two points. It's a sequence issue - you never get round to recovering the unit before the new turn starts, so you end without any units whatsoever. Makes senses too since the aliens would continue to continue to mind control that same unit over and over indefinitely. <br />
<br />
: The third point however: The aliens don't need to know the location of the last MC'd unit. They know the location of all your troops whether they've seen them or not from the very start. They appear to give you a few turns of grace where they won't attack you outright (unless, from my observation, all your soldiers are incredibly weak). This is evident because all of the aliens will eventually make their way towards the nearest soldier even though their movement pattern may seem semi-random. Also, they know where you are because they can initiate psionic attacks without having seen any of your troops. They generally go after the weakest troops first. <br />
<br />
: Just to add a semi-related point, but from the alien's perspective. If an MC'd alien unit is in the exits when you abort the mission, this alien is not recovered and in fact simply vanishes. Any equipment it was carrying is recovered, unknown artefacts or otherwise. You could possibly think of this as their version of MIA. However, the aliens differ ever so slightly in that if it's the last alien standing and under temporary mind control by the player, the mission doesn't end straight away. But I guess this is only because the player has everything under control, whereas in the other scenario, the Ai is in control. <br />
<br />
: -[[User:NKF|NKF]]<br />
<br />
== Crash Site in the atlantic ocean ==<br />
<br />
That's right, my game generated a crash site on water. Here are the details:<br />
<br />
- Crash Site a bit southeast of the USA (which was infiltrated a few days before by sectoids, resulting base had already been taken out), but certainly not on land.<br />
<br />
- UFO: battleship, floater, alien harvest<br />
<br />
- Geoscape: 8 X-Com Bases, 1 (known) Alien base, 2 other crash sites, 1 other (known) flying UFO (though almost worldwide decoder coverage), 3 X-Com Crafts out, 1 waypoint<br />
<br />
- Date: January 2000<br />
<br />
- Most Interesting: The Craft that downed the ship was a recently finished Firestorm (first human-alien hybrid craft I had built, I know this is lame for that date. Limited myself on 25 Scientists to improve the challenge) equipped with twin plasma. I had it built and equipped in Antarctica and then transferred to Europe. This base had no Elerium, a fact that enabled me to use the infinite fuel exploit which was in effect when downing the UFO. My craft was only slightly damaged when doing so. The battleship was the first target assigned to the craft, it came directly from my base. <br />
<br />
- When shot down, the UFO was not targetted by any other craft.<br />
<br />
- I had not lost or sold a single craft to that point.<br />
<br />
- When sending a squad to the crash site the game didn't crash but generated a farm land ground combat terrain.<br />
<br />
- I was not able to reproduce the bug from the savegame dated 2 hours before downing the UFO<br />
<br />
Well guys, any intelligent guesses? I still have the savegames (before and after downing)! If you want to have a look, write here.<br />
<br />
- By tequilachef (April 5th 2007)<br />
----<br />
: Well I'm sure you know about crash sites that are near land can sometimes actually be on water, so I'm going to assume that this site is well far away from any land mass. Could it be a weird entry in GEODATA\WORLD.DAT that has a land mass out in the ocean? Also are you sure the game didn't crash? Sometimes when it does it will load the previous mission (and usually 90% are at farm terrain). Are you sure it generated a new map and not load the last one?<br />
:No real guesses but maybe some starting points to look at. I've probably stated some obvious situations you know about and have accounted for, but it never hurts to double check :D<br />
- [[User:Pi Masta|Pi Masta]] 14:23, 5 April 2007 (PDT)<br />
<br />
== Inconsistencies in MCing Cyberdiscs and Sectopods ==<br />
<br />
I experienced, that when MCing one quadrant of a large terror unit any action it does only affects this quadrant (especially use of time units). That means, when TUs are up for one part, MC another one and continue firing. This however does not work out when moving the unit while it is not under complete control. The TUs used up by the resulting reaction fire from the rest of the unit is also deducted from the TUs "your" part has left (making it impossible for the controlled parts to return fire). This however only happens under reaction fire, not if "your" part fires on it's own. I don't know if this comes up when uncontrolled parts shoot by themselves in the alien turn, since this is hard to find out.<br />
<br />
: That's because large units literally are made up of four separate units. They only share the same set of general stats (in unitref.dat). Unfortunately the 'under mind control flag' is unique to the four units, not the shared stats! So you in effect have multiple units under different control sharing the same stats. So if you move and it results in a reaction from the unit, it will spend the TUs you're using. <br />
: Successful mind control automatically fills up the unit's TUs, so each mind controlled sector gets to move or attack again until there are no more sectors to mind control. Useful way of turning reapers into long range scouts! <br />
: In TFTD, they attempted to fix this bug, but in fact made it much-much worse! The only way to mind control the unit properly is to control the upper left quadrant. Only! Any other quadrant will result in a partial (clockwise) control, and you may gain control of units other than that unit, or may even get into situations where you gain permanent 'partial control' of a large unit you haven't even sited. Wackiness all around! <br />
<br />
:- [[User:NKF|NKF]]<br />
<br />
== Facility Dismantle Bug ==<br />
<br />
Boba: I've never experienced this bug myself in all my games in the Collectors Edition. It may very well vary from computer to computer. <br />
<br />
-[[User:NKF|NKF]]<br />
:I, however, have experienced it. I lost an entire month's worth of playtime because I couldn't solve it. [[User:Arrow Quivershaft|Arrow Quivershaft]]<br />
<br />
::Anyone, any ideas on why it might vary from PC to PC? -[[User:MikeTheRed|MikeTheRed]]<br />
<br />
:::I'd check other factors before blaming a given system. Assuming no mods are being used the most obvious is the order in which you initiated the construction of the modules. Then we've got which one was due to be completed first, and I'm sure there's a few other things to test out. Usually, a player won't cancel in-progress modules on a regular basis, so you wouldn't expect this bug to turn up often. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)<br />
<br />
:Easy way to reproduce: build 2 General Stores. Now delete the "second one" (see offset 16-39 in [[BASE.DAT]] for the order). Wait for the first one to complete. It'll crash immediately after the "end of construction" dialog. A fix is available [[User:Seb76#Bug_Fixes | here]]. [[User:Seb76|Seb76]] 15:52, 22 July 2008 (PDT)<br />
<br />
== Manufacturing Limit Bug ==<br />
<br />
Unfortunately, Mike, no you did not get it correct. It is the raw number of hours needed to complete the project, not the projected hours. I discussed this on the X-Com Forums a few months back at the following link: http://www.xcomufo.com/forums/index.php?showtopic=242027760&st=0&#entry164411<br />
<br />
I did tests at the time in regard to the accuracy of the data given there, but I've lost the results. I'll quickly redo the tests in the next hour or so. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:00, 8 June 2007 (PDT)<br />
<br />
:Tests complete. The breakpoints for every item were exactly where I predicted, regardless of number of engineers assigned. (I ran up a huge queue of items at my dedicated factory base on an old game, and then assigned whatever engineers would fit onto one project at a time, canceling projects as data was confirmed. This is only semi-random, but it serves our purposes.) I did run into a single issue, though. It appears that despite having 5 empty hangars at a (different!) base, the workshop there could not queue up more than 3 of any one craft at a time, thus making this bug impossible to replicate with the Firestorm or Lightning, as you must be producing more than three for the bug to occur. However, it still works with the Avenger. Later, I shall see about constructing a dedicated Hangar base with 7 hangars in order to attempt to replicate the bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:33, 8 June 2007 (PDT)<br />
<br />
::Sounds great, Arrow. Why not post a simple example that shows how the problem works. As in, "with 1 Eng and 2 Avengers you might think X, but no, it's Y". And please delete my example. And it's a fine pleasure to meet you! Cool - [[User:MikeTheRed|MikeTheRed]]<br />
<br />
:::When you say the usual resources are used by the "lost" resources, that includes cash, right? It sounds like if you're willing to foot the extra bill [[Buying/Selling/Transferring#Manufacturable_Prices|money/component-wise]], this could be used to build Avengers slightly faster then normal.<br />
<br />
::: The usual time is 34000 hours. Double that and subtract 65535 and you're left with a paltry 2465 hours. Even a single workshop squad of 10 engineers will pull that off in a little over ten days. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)<br />
<br />
::::Sadly, this exploit doesn't work, because the high bit is stored SOMEWHERE. I lack a hex reader and have no code reading skills to speak of, so I'm a bit limited here. If you set up a Workshop as you described, the game would take all the time for 2 Avengers, all the resources for the same, but in the end only produce 1 Avenger. Meanwhile, I'll run more tests on the resources thing. I could swear it consumes the resources, but I'll double check.<br />
<br />
:::::There is no need to store the high bits if the actual completion condition (assuming adequate money) is "number made is number ordered", which wouldn't reference the hours remaining at all. - [[User:Zaimoni|Zaimoni]] 01:49, 9 Oct 2007 (CDT)<br />
<br />
::::Tests done; I was unable to replicate the 'disappearing item' trick,(Which I didn't test for last night) even with Avengers! It appears I was wrong; this still counts as a bug, though, because the wraparound is a problem.<br />
<br />
::::Ironic that so much of this discussion centers around Avengers, because that's where I discovered this in the first place! [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:48, 9 June 2007 (PDT)<br />
<br />
----<br />
<br />
I'm revisiting XCOM and was working on [[Manufacturing Profitability]]... Arrow, can you (or anyone else) say a little bit more on the Known Bugs page about this [[Known_Bugs#Manufacturing_Limit_Bug]]? It's not clear to me exactly what the bug does, except that it understates hours. Is that all?... does it still take the (non-buggy) amount of time, still use all the same resources, still make the same number, etc.? It sounds like it could be a drastic bug - or is it only a very superficial one, a display bug for the hours? It sounds like you're leaning toward this latter.<br />
<br />
Also on a semi-related note... I could swear I saw much more detailed info on the [[Known_Bugs#Facility_Maintenance_Costs]] issue... IIRC, the incorrect amount that's charged for maintenance, depends on exactly where a facility is in the base. IOW, different "rows" of the base cost different amounts. Could somebody provide a link there, and/or flesh the bug out better?<br />
<br />
Thanks! - [[User:MikeTheRed|MikeTheRed]] 11:22, 8 October 2007 (PDT)<br />
<br />
:I've actually seen the bug work both ways, but I've only been able to actually replicate the more superficial version of the bug. So the bug report up is about a superficial bug that drastically understates production time. If you wish to make this clearer, you have my blessings. As well, that 'different charging based on location' is dealt with here: http://ufopaedia.org/index.php?title=Talk:Base_Facilities ; however, the table has been broken with the Wikiupgrade, and I lack sufficient knowledge of HTML table code to fix it. But it should be of use to you. [[User:Arrow Quivershaft|Arrow Quivershaft]] 11:26, 8 October 2007 (PDT)<br />
<br />
::Cool, I fixed [[Talk:Base Facilities]] but also re-organized and expanded [[Base Facilities]] so that it includes that bug in detail, as per Talk... this is an important issue that should be up front. I see that there's a separate [[Maintenance costs]] page, but I can't see having something so important (the maintenance bug explanation) all on its own page (which makes for a rather short page) rather than together with all the rest of the base facility info. If others agree (or don't care), I'll move anything remaining on Maintenance Costs to the Base Facilities page, then delete Maintenance Costs and re-route links. And if somebody does care, then please move my new section to Maintenance Costs, and move all the links, etc. Oh also I put in more words on your Manufacturing Limit Bug - how does it look? - [[User:MikeTheRed|MikeTheRed]] 16:37, 8 October 2007 (PDT)<br />
<br />
:Looks pretty good, although it'll wrap fully; if you ask for 120000 hours, it won't be displaying 'almost no' time. The way I discovered it was when building two Avengers; I ordered two, paid for two, waited for two...and got one. But as said, haven't managed to repeat it, so until I do, we'll leave it like that. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:00, 8 October 2007 (PDT)<br />
<br />
::I just revised and put in your specific example, because it's certainly possible some of us die-hard players will order up more than 1 Avenger at a time - and it's guaranteed it'd be a pain if 1 of them disappeared, laugh. I wasn't sure how concrete you were on that example but now I hear you say, you are sure it happened at least once. - [[User:MikeTheRed|MikeTheRed]] 18:33, 8 October 2007 (PDT)<br />
<br />
:I have a question concerning the manufacturing "bug" which eats a craft in production due to wrap-over of the byte. Arrow (or whoever did the test), did you have a large quantity of craft already built at your bases? If so, I think this bug has more to deal with clogging up [[CRAFT.DAT]]. See, that file has a limit of 50 entries. Each craft takes up one record and each base you have built also consumes one spot. 8 bases allows 42 craft to be housed, while 6 bases allow 44. If you try to buy or manufacture craft once the file is full, nothing shows up in the game even if you have hangar space available. --[[User:Zombie|Zombie]] 19:00, 8 October 2007 (PDT)<br />
<br />
::Huh, I never knew that. I don't see it listed on the Bugs page... I'll stick it in there. I've never approached that number, but some folks might. - [[User:MikeTheRed|MikeTheRed]] 19:07, 8 October 2007 (PDT)<br />
<br />
:I was able to continue building other Avengers after that project, and they appeared correctly, so I do not believe that is the issue. In any event, I have a very bad case of 'archivism' and probably still have the save game and the CRAFT.DAT file around on my system; in fact, I think I was playing it a few days ago. I can see if I can find it and upload it; it created a 'hole' in the Avenger fleet numbers, where Avenger's x and x+2 were built, but x+1 was not. I'll look for it tonight and tomorrow and upload it to the wiki if I find it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:10, 8 October 2007 (PDT) EDIT: I found the file; I have 28 Avengers and 1 Skyranger in my employ. All Avenger numbers EXCEPT #2(Avenger-2) are accounted for, and I have not sacked or lost any Avengers. So this is where the hole and 'eaten' Avenger is. If anyone wants the CRAFT.DAT file from this game, I'd be happy to forward it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:20, 8 October 2007 (PDT)<br />
<br />
::Sure, send it my way and I'll take a look at it. (Might as well send me the whole saved game as I may want to look at the other files too). I have tried to recreate this bug by manufacturing 1, 2 and 3 Avengers at a clip but all of them always show up. Don't know what else I could do to get this problem to crop up. --[[User:Zombie|Zombie]] 21:32, 8 October 2007 (PDT)<br />
<br />
:File emailed. On the side, I've tried the same thing, and never been able to repeat the bug. It's been months since the first discovery, so I can't recall whether it was the first or the second Avenger that didn't appear. So maybe it was just a fluke. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:57, 8 October 2007 (PDT)<br />
<br />
== Unconscious Enemy in Equipment Screen ==<br />
<br />
The following happened to me repeatedly over the last few days.<br />
<br />
In the last tactical Mission a live alien has been captured. When now beginning an UFO crash recovery mission this type of alien (same race and rank) appears in the equipment screen before the mission starts, meaning I can give it to any of my soldiers.<br />
If I do so I can store the alien in the skyranger for the duration of the mission and, if it gains consciousness, kill or stun it at the end of it. A pile of equipment without a corpse will be in the UFO, indicating that the stunned alien is not some kind of duplicate but instead has been taken from the aliens of this mission. This is supported by the fact that in those missions the maximum number of crew members has not been surpassed.<br />
If I do not do so the Alien will be placed in the crashed UFO. Whether it is unconscious or not I do not know, but the fact that it is completely disarmed when encountered in the battle suggests that it is.<br />
<br />
So far it seems the following is necessary for the bug to occur:<br />
# An alien has to be captured alive in the last tactical combat<br />
# It has to be of the same race and rank as one of the aliens in the new tactical combat<br />
<br />
So far this only worked...:<br />
# If the new tactical combat was an UFO crash recovery of a medium scout.<br />
# For floaters and mutons<br />
# For soldiers and navigators<br />
# If the alien in the last mission was stunned by normal weapon fire (although I do not think this is important) and not picked up (again, not likely to be important) or destroyed (which would mean it has to be actually captured)<br />
<br />
It seems NOT to depend on the following:<br />
# The type of the last mission (were, so far: Ground assault battleship, crash recovery large scout, base defense)<br />
# Which squad or vessel was involved capturing the alien<br />
# Where it is locked up<br />
# If it has been transferred since capture or not<br />
<br />
Would be interesting to know:<br />
# What happens if the alien in the inventory screen is the only survivor<br />
# If the alien in the invenory screen is one of the aliens randomly killed in the crash or not (it is likely to be one of the killed aliens, so far the equipment piles were always within the UFO)<br />
# If this is not limited on crashed medium scouts: Does this work with terror units? What about large ones?<br />
<br />
Maybe this is related to the proximity grenade bug (transfer of item properties to next tactical combat).<br />
<br />
Additionally, in one of those mission a part of the terrain was not generated correctly. It was in farm terrain (The house on the right square, or north east square, in [[Image:Terrain-cult.gif|this pic]]). The outer wall right to the right window of the southern wall (1st Floor) was missing. Directly outside of the hole was a floor tile. I could walk a soldier through the wall, but he fell right through the tile. Dunno if this has to do with the stunned alien bug.<br />
<br />
Version is collectors edition (the one from abandonia.com).<br />
<br />
----------------<br />
<br />
When a mission starts, the GeoScape engine generates the unit and object tables (in MissDat's [[OBPOSREF.DAT]], [[UNIPOS.DAT]], and [[UNIREF.DAT]]) before "shutting down". The Tactical engine then generates the maps, places the aliens on it, and blows up the UFO (if need be). Whether or not map generation and the subsequent events happen before you equip your soldiers I don't yet know.<br />
<br />
The test would be to check the aforementioned files to see if they contain an unconcious alien, and/or the body.<br />
<br />
Note that you can't see the bodies of large units on the ground (they count as four seperate objects covering four seperate tiles, so allowing the user to pick one up would essentially let you rip them apart).<br />
<br />
- [[User:Bomb Bloke|Bomb Bloke]] 06:35, 5 August 2007 (PDT)<br />
<br />
----------------<br />
<br />
I honestly have no idea of how all those files work. But I still have a savegame in battlescape that is in one of those missions. So if anyone wants to have a look at those files...<br />
<br />
I forgot to mention: I reloaded a geoscape savegame shortly before the battle to recreate the bug, but it seems that reloading in geoscape before the buggy battle eliminates the bug. I guess his should narrow down the possible reasons...<br />
<br />
--------<br />
<br />
Next time it happens, backup the aforementioned files before you start another mission. I'm afraid a savegame wouldn't be of much help.<br />
<br />
- [[User:Bomb Bloke|Bomb Bloke]] 00:54, 7 August 2007 (PDT)<br />
<br />
== Soldiers moved to outside of combat screen ==<br />
<br />
Hi, I've got a DOS version of UFO:EU, and I've encountered a bug in the tactical combat. Sometimes (rarely) a X-COM soldier changes its location on the map on player's turn start and is placed on outside of the map, one tile north from the (north) border of the field. AFAIR the unit is then selectable (you get the flashing highlight when cursor is above), but is stuck outside of the field. Has anybody encountered this bug? It seems to happen randomly, but more frequently during the terror missions and on early turns (so maybe it's caused by high number of player/alien/civilian units?). --[[User:Maquina|Maquina]] 08:16, 3 September 2007 (PDT)<br />
<br />
:I've never encountered this bug in CE of UFO. Presuming AFAIR means "As Far As I Recall," what exactly was the soldier doing? Any equipment data, location, or stat info might help us pin it down. Were afflicted soldiers always carrying a specific equipment set or weapon? Where were they on the map before they got moved? Did they get bumped a few spaces, or teleported halfway across the Battlescape? Does it happen more often on a specific difficulty?(Your theory would suggest this would happen most commonly on Superhuman) Against a certain type of alien? Best of all, if you can recreate the situation in a game, save the game and then you could upload the save file to the forums or this wiki, and the rest of us could take a look for ourselves and the code divers could root around for the cause. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:03, 3 September 2007 (PDT)<br />
<br />
:: I've had this happen to me several times in UFO and TFTD. I don't know if it's specific to the Dos version or if it can happen in the CE as well. Sometimes the soldier ends up beyond the boundary of the map right at the start of the mission, at other times it happens after you load a game. This game is glitchy, which is the source for so many of its bugs, so your soldier's coordinates are probably getting corrupted to the point where they are -1 on either the X or Y axis of the maps's normal boundaries. For me it's commonly along the top edge of the map. I don't ever recall it happening mid-mission, only at the start or after a load. I cannot faithfully say whether it happened with or without XComutil, but that could be one of the possibly many causes for this. - [[User:NKF|NKF]]<br />
<br />
:: I don't play UFO often, so I rely on just several campaigns played. This happens rarely (I've encountered this bug twice in my last campaign with ~80 missions played), but if you haven't seen this happen then it probably doesn't show up in the CE edition. In my experience the soldier is moved always beyond the north/top map border. I think (but I'm not sure) that this affects the first soldier from the team more commonly than others (or maybe even exclusevily?). The equipment/armor carried is probably not relevant, since the units moved this way don't have any special stuff, and this bug shows up on different stages of the gameplay (ie. sometimes when you have ordinary rifles, sometimes when all your units got heavy plasmas and power suits). --[[User:Maquina|Maquina]] 04:12, 4 September 2007 (PDT)<br />
<br />
'''MY ramblings have been moved to my discussion page''' [[User:EsTeR|EsTeR]]<br />
<br />
==Great Circle Route==<br />
<br />
Should we have the Great Circle Route bug noted on this page at all? [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:33, 6 October 2007 (PDT)<br />
<br />
: what is the great circle route? [[User:Jasonred|Jasonred]] 07:56, 31 March 2009 (EDT)<br />
<br />
:: Pick two points on a globe, then hold a thread or string taut at those two points. That practically minimizes the length of the thread/string on the globe. You're now looking at a great circle arc (or route), the shortest distance between two points on a globe. -- [[User:Zaimoni|Zaimoni]] 11:15 March 2009 (CDT)<br />
<br />
: Just as a line is the shortest distance between 2 points on a flat plane, a great circle is the shortest distance between 2 points on the surface of a sphere. The bug, by the way, is that aircraft in the game ''don't'' follow this shortest, "great circle" route. [[User:Spike|Spike]] 12:38, 31 March 2009 (EDT)<br />
<br />
:: What a grand sounding name, for something so simple, lol. ... I thought you were talking about when you tell your soldiers to go from point A to point B, and for some reason they figure that Zone A and Zone B are really far apart, despite actually being side by side. (I shot a hole through a wall, clicked to walk to the other side, and my idiot soldier walked one big circle... to use the door! And got ambushed and killed by an alien. ... dum dum DUMB DUMB.)<br />
:: Even the more modern games have problems with their pathfinding algorythms. Admittedly, games like Baldur's Gate had to do it in realtime.<br />
:: On a semi-related note, I remember this guy called E-man, he was chasing a guided laser beam that was going to kill his girl, around the world, but he couldn't outrun it since he couldn't break the speed of light, only equal it by changing into a Laser himself. So... inspiration! He turned into a very powerful laser, and made a shortcut THROUGH THE EARTH... the straight line beats the great circle route, lol.<br />
:: Thanks for the reply guys [[User:Jasonred|Jasonred]] 15:56, 31 March 2009 (EDT)<br />
<br />
Added to article. [[User:Spike|Spike]] 16:41, 3 September 2012 (EDT)<br />
<br />
==Bug not listed: Missing soldiers during base defense==<br />
<br />
I encountered an interesting bug concerning base defense missions:<br />
My base got attacked while about 30 soldiers and 10 HWPs were present. The usual equipment assignment screen was skipped and the mission started instantly with only the HWPs spawned at the map. Not even a single soldier bothered to show up... *sigh*<br />
Although this turned out to be in my favor (you should have seen the puzzled Ethereals trying to panic my tanks) I´d like to avoid this bug if possible. I was able to reproduce this bug several times and with different bases. <br />
Can anyone explain this bug and/or tell me how to avoid it?<br />
<br />
Game version: Collectors edition. - [[User:NewJoker|NewJoker]]<br />
<br />
-----<br />
<br />
Well, ideally, we need to know what your base's construction was to be sure of this, but I think the most likely circumstance is that the HWPs took up all the spawn points. HWPs have maximum priority for spawning(followed by Soldiers, and then Aliens), so if you have enough of them garrisoning a base, it's entirely possible that soldiers and aliens won't spawn. However, this doesn't explain why the soldiers didn't start stealing the Alien spawn points...in any event, you might want to take the save game file, zip it up, and get ready to email it. I'm sure [[User:Zombie|Zombie]] would be quite interested. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:28, 13 November 2007 (PST)<br />
<br />
-----<br />
<br />
It's not the spawn points, it's a [[UNITPOS.DAT]] limitation. A maximum of forty records (out of the total of eighty) are allocated for your units, and tanks (which take up four records each) get first pick. Having ten tanks means there's no room left for anything else.<br />
<br />
Ditch one HWP and you should see four units take it's place. - [[User:Bomb Bloke|Bomb Bloke]] 16:42, 13 November 2007 (PST)<br />
<br />
-----<br />
<br />
I´ll try with a decreasing number of tanks and report the results. As I wrote above having only HWPs isn´t too bad dependent on what enemy is attacking. [[User:NewJoker|NewJoker]]<br />
<br />
----<br />
<br />
This should be mentioned in the [[ExploitsE#Base Defence Mission Spawning Issues]] section. The Bugs/Exploits really need to be sorted and consolidated. - [[User:NinthRank|NinthRank]] 16:57, 13 November 2007 (PST)<br />
<br />
-----<br />
<br />
The limitation to 40 records seems to be the case; each tank I dumped got replaced by four soldiers. <br />
So this can be used to effectively manage unit combination. Thanks for the quick replies! [[User:NewJoker|NewJoker]]<br />
<br />
==Bug not listed: Ufo Gold (Windows Vers. abandonia.com) crashing when plasma defense is finished==<br />
<br />
I recordnized this bug a few times now. (with hacked AND unhacked game)<br />
If i place a plasma defense in 7 bases at the same Time and they are finished at the same Time, the game crashes sometimes.<br />
In hacked game, it seems to crash even more when Alien containment is finished, plasma defense, shield defense...etc.<br />
couldnt find it here...greetz<br />
<br />
: I somehow doubt the sourcing is the issue. [You may want to fund the next XCOM series game with a Take2 re-release of UFO :)] More generally: the game only reports the construction of a given type of facility <b>once</b>, no matter how many bases it completes at simultaneously. I've only tested this <i>in vivo</i> with three-of-a-kind at once across six bases, however. It does seem reasonable that some sort of counter of undisplayed completions would "overflow" (attaining crash). -- [[User:Zaimoni|Zaimoni]] 10:05, Feb. 28 2008 CST<br />
<br />
::I've encountered this bug myself with General Stores, actually, not just Plasma Defense(which I never build). EDIT: Some quick tests seem to show that there's a chance the game will crash any time two base facilities are done at the same time, regardless of whether they're in the same base or not or if they're the same facility.(although it seems to happen MUCH more in the event they're in different bases.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:13, 28 February 2008 (PST)<br />
<br />
== Soldier Recruiting Bugs Tested ==<br />
<br />
Just to note that I have positively tested and replicated the bugs listed under the new(ish) section [[Known Bugs#Soldier Recruiting Bugs|Soldier Recruiting Bugs]]. [[User:Spike|Spike]] 18:08, 19 March 2008 (PDT)<br />
<br />
<br />
==Floater Medic Bug==<br />
<br />
I have not thus far encountered the Floater Medic Bug; in fact, Floater Medics are often used to fill up my Rogue Gallery with interrogations. [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:50, 24 April 2008 (PDT)<br />
<br />
Strange, it would always occur in my version. I don't remember where I got it from, but I<br />
know it was a download from the internet. Using the XCom Hack v2.5, I viewed the alien in<br />
the Alien Containment edit. I now have Type (race):____, and a Rank: Soldier for the <br />
Floater Medic. It might just be corruption, but I do not have the resources to look into<br />
it. [[User:Muton commander|Muton commander]] 19:24, 12 May 2008 (Pacific Time Zone)<br />
<br />
I've never encountered it either. [[User:Magic9mushroom|Magic9mushroom]] 07:47, 23 July 2009 (EDT)<br />
<br />
==Strength Overflow==<br />
<br />
During one of my games with TFTD I noticed a really annoying thing happen during battles.<br />
As my troops rose up the 'stat.' ladder they got better and better (as you'd expect), until they hit about 50 strentgh and completely lost the ability to throw anything.<br />
Even trying to throw something tiny like a grenade or flare into the adjacent tile resulted in the 'Out of Range' message being displayed.<br />
<br />
Anyone come across this before?<br />
This was in TFTD CE.<br />
[[User:Tifi|Tifi]] 07:55, 27 April 2008 (PDT)<br />
<br />
:This is fairly well documented. The pathfinding algorithm for throwing objects will balk if anything is in the way of the throw and refuse to allow you to throw. What's happening is that your soldiers have become so strong that their throws are intercepting the 'ceiling' of the Battlescape(the top of L3), and as such the game thinks that the throw is blocked(because in order for the throw to complete, the object would have to be tossed up to the nonexistant L4). There's two ways around this:<br />
<br />
:The Normal Way: Try shorter throws, throwing from lower heights, or throwing while kneeling. Beyond that, possibly get some new troops.<br />
<br />
:The Sneaky Way: Manually edit the Strength scores of your soldiers in [[SOLDIER.DAT]] so that they're back to a usable strength level. If you set "Initial Strength" (offset 46 decimal or 2E hex) to 0 and "Strength Improvement" (offset 57 decimal or 39 hex) to a value of 50, you can permanently lock the soldiers at 50 strength. (You can lock them higher than that if you so choose, but not lower.<br />
<br />
:Other than this, there's no workarounds I can think of offhand. [[User:Arrow Quivershaft|Arrow Quivershaft]] 08:10, 27 April 2008 (PDT)<br />
<br />
:: There's normally no problem with the max level of 70 in open settings. However TFTD has a lot of low ceilings such as in the shipping lane missions and colonies, and the lower ceilings impairs your throwing quite a bit. In addition to shorter throws/kneeling, try moving out from under any overhangs if there is one just above you. - [[User:NKF|NKF]] 12:33, 27 April 2008 (PDT)<br />
<br />
== Bug not listed: Sticking your head through the ceiling ==<br />
This is something I just discovered: When you step on a small object inside of a building your soldier sticks his/her head through the ceiling and can see what's upstairs. You can even see the soldiers head coming out of the floor and that soldiers can shoot aliens upstairs. When I did this the alien I saw/shot was facing the other way, but I guess you could get shot if the alien was facing you. [[User:RedNifre|RedNifre]] 17:34, 11 May 2008 (PDT)<br />
<br />
:That's not listed under "Bugs" because it's covered under "Exploits", right here: [[Exploiting_Collison_Detection#See_Through_A_Ceiling]] [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:26, 11 May 2008 (PDT)<br />
<br />
:: I don't know if it was ever covered anywhere, but there's this neat trick that might sound similar to the walk-through-'wall object'-wall trick except that it involves your unit climbing slopes. They'll appear as though they've gone up a level, but are actually not on that level. They only visually appear to be there, but are really still on the bottom level. <br />
<br />
:: It happens a lot when walking up the desert or forest slopes. I think the trick involves standing on ground level, and then ordering the unit to 'move' into the hill rather than setting the waypoint while on level 1. The soldier will move up the slope and perhaps stop on the slope or even reach the top of the slope, but will still appear when you're only viewing the ground map layer. The soldier is really still on the ground level, but will have elevation offset. <br />
<br />
:: One really interesting way of using this trick is in the mountain region. If you can find a cliff face and a low hill nearby, you can literally have your soldier scale the cliff by standing the soldier on the hill, and then walking towards the cliff. It's ridiculous, but your soldier never quite reaches the top of the cliff tiles, so ends up walking up a slope. <br />
<br />
:: On a side note, standing at the top of the ramp of the Skyranger is the same as standing on ground level - you're only offset a bit. This means that smoke on level 1 and the sides of the Skyranger will not provide protection when you're at the top of the ramp. <br />
<br />
:: On another related note in relation: In TFTD (doesn't happen a lot in UFO), you might find it difficult to toss grenades onto underwater slopes. To remedy this, raise the level up by one. It might look like you're tossing at air(and you are), but it'll get the grenade where you want it. Odd, but true. I must remember to put this in the grenade explanation section. -[[User:NKF|NKF]] 23:11, 11 May 2008 (PDT)<br />
<br />
== Base Defence bug that causes a crash? ==<br />
<br />
Does anyone know about a bug in a base defence mission that causes the game to crash? The game keeps crashing on the 4th or 5th alien turn.<br />
<br />
:I've encountered that myself, but it should be noted that overall, X-COM is not the most stable game and is prone to crashing often at anytime. The differences between the hardware it was designed for and the hardware we're running it on cannot be helping matters at all; it's really a small miracle it even runs without an emulator in the first place(I've got games from 1999 that will bluescreen my machine instantly). As such, I'm not sure it's worth noting as a bug, since it's a 'game feature'(albeit a detrimental one). In any case, what're you doing letting the aliens attack you anyways? ;) [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:33, 18 July 2008 (PDT)<br />
<br />
== Sources for a DOS4GW transplant ==<br />
<br />
I was specifically thinking of the LucasArts Dark Forces demo, but I half-recall the actual source I used when testing that ~1999 was Id's DOOM. -- [[User:Zaimoni|Zaimoni]] 16:03, 7 August 2008 (CDT)<br />
<br />
== Phantom Carried Casualty ==<br />
<br />
You are carrying an unconscious soldier in one hand, and the soldier dies of his/her wounds. The dead soldier remains visible on the "left hand / right hand object" battlescape display, but is no longer visible in the inventory display. The problem can be fixed by moving another object into the same hand. <br />
<br />
I've seen this bug with UFO Extender by [[User:Seb76|Seb76]] - possibly might be something to do with his manipulation of the inventory screen, rather than a general bug. I believe I've also seen this with other objects that were being carried in the hands, disappearing from the Inventory screen, but I'm not sure. I don't think it's an item limit bug, as XcomUtil shows 40 item slots free. [[User:Spike|Spike]] 08:58, 21 September 2008 (PDT)<br />
<br />
== Civilians As Enemies to MC'd Aliens ==<br />
<br />
I ran across this issue a few times and just wondered if you guys experienced this. I MC'd a part of a Reaper (I always do the lower left for large aliens) on a Terror Site, then moved it a few squares. It suddenly stopped dead in it's tracks and then the alien spotted indicator increased by 1. When I clicked on the indicator to see where the enemy unit was, it brought me to L2 of the large apartment complex. However, nothing was there. When I sent a Flying-Suited soldier up there to peek in the window (eeek! A peeping tom!) he saw a female civilian standing there. This type of problem has happened numerous times to me so it's not a once-off thing. Maybe it's a LOS issue? Or maybe an alien indicator problem? Or a combination of the two? Don't know, but I'm curious if you guys have seen it. --[[User:Zombie|Zombie]] 23:40, 19 December 2008 (CST)<br />
<br />
:There are a lot of major issues with MC'ing 4 square aliens. One of them being that you could accidentally MC an alien far off in the corner of the map, IIRC? Anyhow, maybe you should have tried MC'ing all 4 squares of the reaper and see if that changed things. -[[User:Jasonred|Jasonred]]<br />
<br />
The long-range MC of other aliens when Mind-Controlling large aliens is only present in Terror From The Deep, due to a workaround to try and resolve the earlier bugs(and exploits) associated with controlling one square of a large unit at the time. In TFTD, successfully MC'ing part of a Large unit will also grant you control of the next three units in UNITPOS.DAT, in order. If you didn't MC the upper left portion of the large unit(the first UNITPOS entry for any large unit), you can potentially wind up in control of other aliens. So this doesn't apply to UFO. As for Zombie's issue, never seen it. And finally...Jasonred, on Talk pages, please indent your statement with colons so it differentiates from other people's comments, and sign your posts with 4 ~'s, like I will now do. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)<br />
<br />
==Elerium Base Bug==<br />
<br />
Jasonred: This bug has long since been known about. Elerium units on the Battlescape can be picked up by shooting away the power source; this one item counts as 50 units, and as such ANY elerium item spawned on any Battlescape counts as 50 Elerium. This issue with your own Elerium spawning as collectable loot in a Base Defense mission only occurs in older DOS versions, and is at the whim of the 80 item limit. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:55, 18 February 2009 (CST)<br />
<br />
:Base defense does not seem to follow the 80 item limit in that DOS version. There are a lot of bugs that have long been known about. However this one was not included in the ufopedia for some reason.<br />
:Also, the main thing about this bug is that it does not potentially double your elerium stores. It potentially multiplies them 50 times.<br />
:... First time this happened to me, I was pretty flabbergasted. Here I was being conservative with my limited Elerium, refraining from blowing up UFOs when possible, when I perform a base defense and gain 3000 Elerium from it. Holy spit. -[[User:Jasonred|Jasonred]]<br />
<br />
Alright, my error. Thanks for clarifying. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)<br />
<br />
==HWP Fusion Bomb and SWS PWT Displacer Ammo Manufacturing Cost Bug==<br />
<br />
At a cost of $15000, 400 Tech hours, 5 Zrbite, and 8 Aqua Plastics, this is the exact same cost as the HWP Fusion Bomb from X-COM EU, converted over to the equivalent TFTD resources. As such, it shouldn't be counted as a bug, since it is clearly what Mythos intended. [[User:Arrow Quivershaft|Arrow Quivershaft]] 09:55, 15 November 2008 (CST)<br />
<br />
:Hmm, in that case maybe it should be treated as a generic game engine issue and not a TFTD specific issue - but I still think it's a design error. Can you think of any logical reason why the SWS/HWP version of the ammo should be more expensive (in cost and in materials) than both the craft ammo and the (more powerful) personal ammo? It makes no logical sense. Hence I think it's a design error. Nothing can be inferred from the fact it's unchanged from XCOM-EU, that doesn't imply any deliberate decision. It could just be the replication of an original error in XCOM-EU. [[User:Spike|Spike]] 11:17, 15 November 2008 (CST)<br />
<br />
:: I can think of a logical reason to justify this: X-Com doesn't understand the technology as well as the aliens do (which is obvious, given the length of time each side has known the tech). Handheld Blaster/Blaster Bombs are just a copy of the alien design and therefor relatively cheap and efficient, but that can't be mounted on a turret. So X-Com has to make a new design, and they obviously didn't do that good a job as the aliens would have done. This explains Tank/Plasma being weaker than Heavy Plasma too. (Why is FBL Craft ammo cheaper than the tank ammo though? Maybe X-Com gave up on/simplified the guidance system and made it just a "dumb" cannon shell/torpedo instead which doesn't have multiple waypoints? Or maybe they just did a better job there?). [[User:Cesium|Cesium]] 04:07, 25 November 2009 (EST)<br />
<br />
:Whilst we discuss it, I'll park my original text in here:<br />
<br />
* ''Displacer/PWT ammo cost bug - at over $100,000 total cost per round, the ammunition for this SWS weapon is far more expensive to manufacture (both in money and rare materials) than the equivalent ammo for the Aquanaut-carried Disruptor Pulse Launcher, or the craft-based Pulse Wave Torpedo, despite being less powerful than either. This would seem to be a design mistake.''<br />
<br />
See Also [[Talk:Displacer/PWT]]<br />
<br />
:: I don't like the higher cost either, but I think it's a tradeoff of expense and quality for the convenience of portability. Sort of like an MP3 player to the gramophone... or maybe that's not a good comparison. -[[User:NKF|NKF]] 13:43, 15 November 2008 (CST)<br />
<br />
A better comparison might be a desktop computer to a laptop. As a general rule, laptops are more expensive, but a similarly priced desktop gives you more power. Desktops are cheaper and offer power, laptops are more expensive and offer portability(though the gap is rapidly narrowing). [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:49, 15 November 2008 (CST)<br />
<br />
:I think those are good analogies. But they don't apply in this case. To continue your analogies: We are paying mainframe prices for a clunky desktop that has only laptop processing power, and we're buying a mainframe for desktop prices. The vehicle version ("desktop") - is ''less'' portable and ''less'' powerful than the personal version (DPL = "laptop"), ''less'' capable than the craft version ("mainframe") - and costs ''more'' than either of the others in total cash and in materials. In particular, it makes no sense that the small missiles on the SWS use up ''more'' of both Zrbite and Aqua Plastics than the Craft version. Do we really think it's logical that a tactical battlefield round, less powerful than its man-carried equivalent, takes more explosive and structural material to produce than both the more powerful man-carried version and also more than the air-to-air round that has 60km range and can take down a major alien combat craft? There is a clearly perverse bang-per-buck here, on every measure. My sincere belief is that this was an original mistake in the XCOM-EU engine that got copied into TFTD as well. The craft round should have the higher base price, but the material requirements that are currently assigned to the SWS/HWP round. It's debatable whether the SWS/HWP rounds should be more expensive than the man-carried rounds. But what I don't think is debatable is that is not logical for the SWS/HWP rounds to be more expensive than the craft rounds. It's clearly a mistake. Even in game balance terms, the only thing the HWP/SWS rounds have going for them is conserving "80-Item Limit" space, which I severely doubt was ever a game design consideration since it's just an awkward programming compromise. Any advantage inherent in the HWP/SWS is already reflected in the very high platform cost - there is no need to inflate the ammo costs as well. The bottom line is that a round for a (mini-)tank does not cost more, does not use more materials, than the same type of round for a long range anti-aircraft weapon that has much greater damage capacity and penetrating capacity. [[User:Spike|Spike]] 14:35, 15 November 2008 (CST)<br />
<br />
I'm going to add this to the bug list now. [[User:Spike|Spike]] 16:06, 25 February 2009 (CST)<br />
<br />
:Still don't think this is a bug though. Just because it's more expensive to manufacture than the hand-held or craft-mounted ammo, it doesn't mean the stats are wrong. Perhaps the programmers wanted to balance the tactical portion of the game a little more by making the ammo cost more for tanks. It doesn't have to be logical to be intended. Now if you had proof which said that the ammo was supposed to cost less but the stats were wrong, then yes, I'd agree. So if you boil it all down it comes to a disparate logic issue, not a bug.--[[User:Zombie|Zombie]] 21:31, 25 February 2009 (CST)<br />
<br />
::I have to side with Zombie here. While the ammo may be disproportionately expensive, by the definition used on the rest of the page for bug, it doesn't fit. All the other bugs are errors in program logic or function or routines that are unintentional problems with the game, most of which are not warned of ahead of time. The ammo for the tank costs exactly what is listed and operates entirely as intended, whereas the rest of the bugs are not intended game features. Even if the numbers were entered wrong, that would be a data entry error, not a program bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:28, 26 February 2009 (CST)<br />
<br />
:If it was a data entry error, I'd consider that a type of bug... assuming we had proof of the goof so to speak. LOL. --[[User:Zombie|Zombie]] 00:49, 26 February 2009 (CST)<br />
<br />
:: It feels too specific an entry to be a data entry error. <br />
<br />
:: I'm reminded of the high explosive. I know, I know - it's not an exact parallel to the FBL issue. A High Explosive is practically two grenades. Double weight, double bulk. Slightly above two times the damage. However, it costs five times the price of a standard grenade. Even though you're paying more for not-as-much, I don't think that could be considered a bug. A rip off, yes, but not a bug. <br />
<br />
:: Here's a thought: Think about the immediate benefits each of the two controversial ammo types give back to you. Aircraft ammo = activity points. Tank ammo = loot. Yes, I know that aircraft ammo also generate crash sites, but you still have the ground combat to contend with. <br />
<br />
:: One other thought: With careful management of your ammo, you'll probably never spend any elerium on the handheld version's ammo. Could it be the handheld that's really at issue here rather than the others? In the end I feel that it doesn't really matter. -[[User:NKF|NKF]] 03:38, 26 February 2009 (CST)<br />
<br />
: I'm with Zombie that a data entry error is a bug (we have other examples), but also agree some proof is probably needed. And I agree with NKF that in the scheme of things, it doesn't really matter much. I don't think the HE pack is a good comparison (though the HE pack should be heavier) as it's reasonable to pay disprortionately more to get additional power at the same tech level. The fusion weapons are a case of paying more to actually get ''less'' power. I am not bothered by the handheld vs vehicle balance, not least because the game generally makes handheld weapons better than their vehicle equivalents, so I can accept that as an across-the-board design decision. <br />
<br />
: I can also see a game balance argument ''if'' we believe that Fusion Tank ammo is more of an overall game-winning weapon than craft Fusion Bombs. But I'm not sure I agree with that statement. And even if it's true, and there's a game balance argument (in which case it would apply equally to handheld Fusion launchers), it's still illogical. The less powerful, battlefield warhead should not cost massively more in exotic materials than the much more powerful air to air warhead that brings down Battleships. I agree though that just because it's illogical does not prove it's a bug (i.e. unintended). [[User:Spike|Spike]] 07:48, 26 February 2009 (CST)<br />
<br />
Ok we more or less seem to be in agreement that this isn't a bug, but it is very confusing/illogical. Maybe we can shift the "bug" text from the article page and roll that into the [[Hovertank/Launcher]] and [[Displacer /P. W. T.]] pages now. Feel free to combine any text from the discussion above if necessary. --[[User:Zombie|Zombie]] 09:22, 26 February 2009 (CST)<br />
<br />
: Unless we can ''prove'' it's a data entry error (unlikely), how about calling it an "Anomaly" instead of a bug? [[User:Spike|Spike]] 10:59, 26 February 2009 (CST)<br />
<br />
Looks like plain old game imbalance to me.<br />
The way I see it, Hovertank Plasma and Launcher were meant to be stronger. Much much stronger. Let's look at Tank Cannon, Launcher and Laser. The logic is that it's a tank mounted weapon, so the tank can carry a much larger and more powerful version of the same weapon, right?<br />
It's pretty stupid that a Hovertank Plasma is weaker than the Heavy Plasma... you could just mount a Heavy Plasma on a Hovertank and get them exactly equal. In fact, I suspect that the hovertanks were ALSO meant to have more powerful weapons than the man-portable versions.<br />
Unfortunatly, the game designers then realised that this made the hovertanks far too powerful. So... the programmers nerfed the power of the hovertank weapons. BUT they forgot to lower the ammo costs. [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 11:20, 26 February 2009 (CST)<br />
<br />
: Well you are opening up a much larger issue there. The Fusion weapons are an anomaly, an inconsistency. But handheld weapons are more powerful than equivalent vehicle weapons across the board, consistently. So that looks like a deliberate design decision, not a mistake. [[User:Spike|Spike]] 17:33, 26 February 2009 (CST)<br />
<br />
:: There are two exceptions to the rule: Tank/Cannon: 60AP vs. Heavy Cannon 56AP. Tank/Laser: 110 Laser vs. Heavy Laser: 85 Laser. The hovertank\plasma only differs by a measly 5 (an extra 0 - 10 damage, which means a lot vs. UFO inner hull armour). I guess the trend here was to moderate the area effect tank strengths. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST) <br />
<br />
I'd have to agree with you there Spike. This wasn't a mistake, however odd it may seem. It was a deliberate attempt to try and balance the game. Below is a table I created ages ago for my (now defunct) strategy guide detailing the HWP's and what handheld weapon corresponds to it. When you stick them side-by-side, it really becomes apparent that the programmers were trying to base the HWP weapons off the handheld weapons somewhat. The only thing that doesn't follow a nice and distinct scheme is the damage. That's what is the clincher. --[[User:Zombie|Zombie]] 20:26, 26 February 2009 (CST)<br />
<br><br />
<table {{StdCenterTable}} class="sortable"><br />
<tr {{StdDescTable_Heading}}><th align="left" width="150">Tank Type</th><th width="70">DAM</th><th width="80">Snap</th><th width="90">Aimed</th><th width="90">Aimed</th><th width="80">Snap</th><th width="70">DAM</th><th align="right" width="140">Handheld</th></tr><br />
<tr><th align="left">Tank/Cannon</th><td>60</td><td>60%</td><td>90%</td><td>90%</td><td>60%</td><td>56<sup>1</sup></td><th align="right">Heavy Cannon</th></tr><br />
<tr><th align="left">Rocket Launcher</th><td>85</td><td>55%</td><td>115%</td><td>115%</td><td>55%</td><td>87.5<sup>2</sup></td><th align="right">Rocket Launcher</th></tr><br />
<tr><th align="left">Laser Cannon</th><td>110</td><td>50%</td><td>85%</td><td>84%</td><td>50%</td><td>85</td><th align="right">Heavy Laser</th></tr><br />
<tr><th align="left">Hovertank/Plasma</th><td>110</td><td>85%</td><td>100%</td><td>100%</td><td>86%</td><td>80</td><th align="right">Plasma Rifle</th></tr><br />
<tr><th align="left">Hovertank/Launch</th><td>140</td><td>--%</td><td>120%</td><td>120%</td><td>--%</td><td>200</td><th align="right">Blaster Launcher</th></tr> <br />
</table><br />
<sup>1</sup>AP rounds.<br><br />
<sup>2</sup>Average between the Small and Large Rocket.<br />
<br />
<br />
: Hold up! Tank rounds do 60AP. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)<br />
<br />
So what's wrong? The table says 60 for the Tank/Cannon and 56 for HC-AP. Those are correct, no? --[[User:Zombie|Zombie]] 23:41, 26 February 2009 (CST)<br />
<br />
: Sorry, didn't realise it was two tables side by side (or rather mirrored). Eyes only noticed the left side of the table. -[[User:NKF|NKF]] 23:53, 26 February 2009 (CST)<br />
<br />
:: If the Hovertank Launcher did 200 damage, or worse if the Hovertank Launcher did EVEN MORE damage than the Blaster Launcher... that would make them easily the most deadly things on the map. As it is, the hovertank launcher is already pretty overpowered, even with 140 power.<br />
<br />
== DOS4GW - What the heck is it? ==<br />
<br />
It's been ages since I had to remember this stuff, so those who remember clearer than I do, forgive me if my descriptions aren't accurate. Hopefully the general idea will come across. <br />
<br />
Back in ye olde days of computere gamynge - and where there were more E's to go around, memory handling was a tricky beast to handle. Computer memory is divided into several different categories. Conventional, extended and I think expanded. I might be jumbling the terminologies for the last two a bit. Doesn't matter - memory was just cut up into small segments. The two most common memory types to PCs at the time were pretty small but were readily available. The third one - the most expandable (aka the chip with its massive 4 Megs of RAM you just spent your whole month's allowance on!), wasn't as easy to get at. <br />
<br />
To get access to the higher memory that was available to the computer, special memory handlers had to be used. Drivers like HIMEM, emm386, etc were used. <br />
<br />
DOS4GW is one such handler that lets the game access the computer's available expanded memory. Lots of games that came out at the time use this. Doom, Duke Nukem 3d, Syndicate, Ultima Underworld, X-Com UFO/TFTD, etc. LOTS of games. Any time you ran a game from the dos console and you saw the Dos4GW message flash by briefly it would be assisted by it (well, it stayed on the screen for ages back when processors were slower!). <br />
<br />
It took the hassle out of memory handling and let the game access the available memory on the computer as one big flat block of memory to play with. <br />
<br />
So what was meant in the article was to simply replace the dos4gw.exe with a more up-to-date version from another game. I think the way to tell its version was just in the message that it displayed. You can just run the dos4gw.exe file in a console window. It'll give an error, but the message it shows will indicate its version. UFO 1.4 uses Dos4gw 1.95, for example. <br />
<br />
-[[User:NKF|NKF]] 01:22, 6 March 2009 (CST)<br />
:DOS4GW also switched the processor from 16bit to 32bit mode. [[User:Seb76|Seb76]] 13:58, 6 March 2009 (CST)<br />
<br />
== Clipping ==<br />
I have a new bug. Its harmless. I have a savegame (EU CE - modified game) which has a sectoid within another sectoid. In the alien turn, one secturd walked off the roof and dropped down <s>onto</s> into another. (I guess there DNA is indentical afterall, so they 'become one' with the world). If you want the savegame (superhuman edited using UFOloader, UFO Mod v1, xcomed, Khor Chin WeapEdit v0.1) drop me a request on the my page somewhere. [[User:EsTeR|EsTeR]] 01:40, 18 September 2009 (EDT)<br />
<br />
: Not something many would encounter, but definitely something that can happen. Units can occupy the same physical space, but the game cannot display them all. It'll only draw one of them. Actually saw this effect happen back in the early days of XComutil when it gained the ability to manually add new aliens into a battlescape. It did this by slotting them into the same spaces occupied by existing aliens. Then the fun would happen when you saw a couple of Mutons suddenly walk out of a sectoid. Not sure how the game determines who gets hurt when struck by a bullet. May very well depend on the order they are stored in the unitpos.dat file. <br />
<br />
: There are a couple of ways you can replicate this in-game, but I can only provide theories on how you could do it. Such as shooting the ceiling above you and letting the unit drop through, or moving a tank off a ledge and getting its non-primary segments land directly on top of another unit. By the way, the rear end of tanks get stuck in walls if you attempt to move north or east off any ledges. -[[User:NKF|NKF]] 02:18, 18 September 2009 (EDT)<br />
<br />
: Ok, so as long as others know about this, then all is good. I had never seen it and was doing alot of head scratching until I shot the alien.<br />
<br />
== Berserk HWP crashes the game ==<br />
In the article page it mentions that aliens which go berserk with their integrated weapons will crash the game. This is only true for Mind Controlled aliens (or units under X-COM control) - alien controlled units which go berserk do not crash the game. I tested an MC'd Celatid just now and it doesn't crash the game either, though it doesn't immediately go berserk - it waits another turn for some odd reason. Someone want to check this to verify my results? --[[User:Zombie|Zombie]] 20:31, 27 December 2009 (EST)<br />
<br />
==HWP Morale Loss==<br />
<br />
HWPs have 110 Bravery, which [[Morale#Effect_of_Bravery|normally prevents morale loss]], but I wonder if they can still lose morale due to loss of units with a morale-loss modifier. It'd depend on how the math is done. If, for, example, the -20 to morale for a dead unit is static, then multiplied by any [[Morale#Officers|morale loss modifier]], then reduced by 2 for every ten point of bravery, any officer death without another officer on the field will necessarily reduce HWP Morale. <br />
<br />
It all depends on how the equation plays out and when modifiers are added. For sake of this post, I propose the following as the morale-loss equation: 20*(rank death modifier)-((Bravery-10)/5)*(1.00-Leadership bonus)=Morale Lost. (Rather than using 22 as a base, I'm going to assume Bravery is internally decremented by 10 for this equation as 0 Bravery is impossible without editing and it makes the math easier for the purpose of the example.)<br />
<br />
It makes sense to me that rather than having 110 bravery hard-coded as an exception to "No morale lost", it simply works the same way in the normal equation, but is high enough that it negates most morale loss events, as even if an officer is killed, another officer is usually left on the field to help negate the penalty. That said, if a large portion of the team is wiped out at once, any surviving officers may not be able to negate it all, allowing tanks to start having noticeable morale loss.<br />
<br />
So with the death multipliers, we can determine that every XCOM officer killed has a set death value. Rookies and Squaddies are -20, Sergeants are -24, Captains are -26, Colonels -30, and Commanders -35.<br />
<br />
For example, under this theory, if a Sergeant is killed with no other ranked units on the field, a Squaddie with 50 Bravery would lose 16 Morale. (20*1.2-(50-10)/5*1.00=16). A HWP would, at the same time, lose 4 morale. The Sergeant's death is worth -24 Morale, and without another officer on the field to ameliorate the loss, the Tank's bravery only can 'absorb' 20 points of the morale lost. If it was instead the Commander lost, with no other officers on the field, the HWP would lose instead 15 points of morale, given that a Commander's death (20*1.75) is worth a whopping 35 points of morale loss if no other officers are present.<br />
<br />
And if you have, say, four colonels and the Commander on rear/psi duty, and some alien flings a grenade or a blaster bomb into the back of the Skyranger and blows all three of them up and they were the only officers, the HWP has now lost 55 morale, which gives it a 10% chance of panicking/berserking on the next turn!<br />
<br />
In the end this'll probably need to be tested for accuracy, but those are my thoughts right now.<br />
<br />
Also, for the record, most units that berserk go to 255 TUs while still using the original TU-expenditure calculations; it's part of what makes berserk units so dangerous. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:34, 11 January 2012 (EST)<br />
<br />
:Tested it under vanilla CE. Took a squad out containing just about every rank there is (commander + colonel + captions + sergeants), plus a tank. Blew up and killed all soldiers with a single blaster bomb shell, leaving just the tank, which lost no morale (sorry).<br />
<br />
:I also brought a group of rookies along with a single commander + tank, and killed just the ranked unit. Tank lost no morale. A rookie with 60 bravery lost 17 (which matches the loss predicted by the formula currently on the morale page), whereas under your formula he should've lost 25.<br />
<br />
:Still, you're on the right track. I've long had my own theory as to why tanks have been known to lose morale. Take a look at [[UNITREF.DAT#42|UNITREF.DAT[42]]] - this is the offset that stores a unit's rank. Notice something? The value gets higher as the X-COM unit's rank gets higher. Works in ''reverse'' for aliens, for whatever reason. I sorta figure it's so killing a mind controlled alien commander doesn't mess with your morale too badly, but there's a big problem with that theory and you can probably tell what it is...<br />
<br />
:If the highest this figure gets for an X-COM unit is 5 (commander rank), then a killing a mind controlled alien ''terrorist'' with a rank value of ''7'' should net an even higher morale loss penalty. And indeed it does - I took a rookie and a tank to a terror mission, mind controlled and killed a terrorist, and the tank lost 10 morale. Guess it would've lost six if I'd taken a commander instead of a rookie, but that's still something.<br />
<br />
:Note that the formula on the morale page does ''not'' account for this - it states that at bravery 110 the alien's death loss multiplier would always be applied to a base morale loss of 0, but that's obviously wrong. You're spot on in saying that the base morale loss figures are not totally dependant on bravery, and the "death loss" penalty is applied first. Would probably require a few more trials to determine what that penalty ''is'' for alien soldiers and terrorists though. <br />
<br />
:Just for kicks, I edited a plasma tank to have 0 morale. It panicked in the normal way (either sitting still or charging off to the SE). When it berserked, the game crashed as soon as I dismissed the status message. - <span style="font-size:xx-small">&nbsp;[[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 18:54, 12 January 2012 (EST)<br />
<br />
:: Thought I'd give it a spin. I sent a laser tank in with a squad and had it start shooting at team members. Each time it killed an ally, it would lose morale. Once it was under 50 morale, I waited until it panicked. Since I was playing the dos version, the game didn't crash but I suspect a memory leak of some sort may have occurred that would normally shut down the CE version. What would happen in CE if a soldier were to be edited and granted a tank turret, and then made to panic? Would the game crash? I'm just wondering if it's related to the weapon as opposed to the fact the tank is a treated as a large unit. -[[User:NKF|NKF]] 00:43, 13 January 2012 (EST)<br />
<br />
::: Ah, friendly fire! Thought I'd tested for that, but obviously not...<br />
<br />
::: Oddly enough, now that I try it, I see that the twenty point hit for killing a unit on the same side can be adjusted by the leadership bonus of the victim. Eg, kill a lone commander and his 35% penalty reduction takes the extra morale lost from 20 down to 13 (which is exactly how much a tank will lose, given that it otherwise wouldn't lose any at all).<br />
<br />
::: Of course, this completely messes up my theory about alien soldier/terrorist ranks overriding the 110 bravery score. It doesn't. My tank "only" lost 10 morale because the alien's rank acted as a 50% leadership bonus... Though I suppose that's still interesting to know, because it suggests that keeping a simple alien soldier under mind control is more effective then risking your own commander in the field.<br />
<br />
::: I took an otherwise unarmed rookie and assigned him a tank cannon + ammo. He could manually fire this weapon in much the same way a tank can. Forcing him to berserk crashed CE, under DOS he just spun around. - <span style="font-size:xx-small">&nbsp;[[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 21:20, 13 January 2012 (EST)<br />
<br />
== 80-items limit on CE edition ==<br />
<br />
I have the feeling that the 80-items limit does not apply to the CE edition and is instead a 110-items limit (at least during base defence). Can anyone confirm? [[User:Seb76|Seb76]] 16:24, 24 February 2010 (EST)<br />
<br />
:I believe this limit was increased for TFTD. Maybe it was also increased for the CE edition of UFO, and only ever applied to the DOS edition of UFO?? [[User:Spike|Spike]] 20:03, 11 March 2010 (EST)<br />
<br />
== Paying for Dirt in TFTD ==<br />
<br />
I have the steam version of TFTD and am unable to replicate this bug. Testing with the starting base, I dismantled a few modules, added up my income and expenses, and it reconciled with my cash at the beginning of the next month. I even tried again, dismantling every module except the access lift, and once again saw no income discrepancy. Am I missing something, or is it possible this bug was actually fixed in TFTD? --[[User:Jewcifer|Jewcifer]] 12:18, 16 March 2012 (EDT)<br />
<br />
:'twas probably fixed. It would indeed be helpful to add a small note to bugs on this page which are EU-specific but not obviously so (like this one). - <span style="font-size:xx-small">&nbsp;[[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 17:14, 16 March 2012 (EDT)<br />
<br />
::Every now and then I get the urge to test some of the more important bugs myself in my steam version of TFTD. Perhaps I will make a more complete effort and record the results somewhere on the wiki. --[[User:Jewcifer|Jewcifer]] 12:08, 21 March 2012 (EDT)<br />
<br />
== Minimized Interceptor Bug (Ufo CE) ==<br />
<br />
Maybe this bug is not just related to saving, because I had a similar problem last night. The game didn't crash, but it kept restarting the same Battlescape mission.<br />
One Avenger (A-3) was pacing a Battleship, while another Avenger (A-1) was sent to pick up the pieces of a Terror Ship that had been shot down by an Interceptor. Despite having no weapons (oversight on my part), A-3 wanted to attack the Battleship, but I minimized the screen, hoping it would land.<br />
While the screen was minimized, A-1 landed at the Crash Site from the Terror Ship and started this mission. Right after finishing it, I got the message that A-3 was ready to land next to the Battleship. Happy that I'd get the loot, I started the mission.<br />
After cleaning it out, I got the usual Loot and Promotion screens and went back to the Geoscape. A few seconds later, I was back in the equipment screen and the Battleship Mission started again. I played it once more, because - hey - additional loot, right? Err... no. At the end, I got the correct Loot screen for this attempt and the very same promotion I had gotten in the first attempt (A Rookie from another base promoted to Sergeant).<br />
Got back to Geoscape and a few seconds later back to the Equipment screen. I aborted this mission (same Battleship again), got back to Geoscape and - you guessed it - back to the Equipment screen. After aborting this mission as well and getting back to Geoscape, I used the few seconds I had to go to 'Options' and 'Abort Game'. Maybe I could have made A-3 disengage from the Battleship since I think I saw them both on the Geoscape, a yellow diamond and a red plus, but it was pretty late by that time.<br />
--[[User:Matzebrei|Matzebrei]] 15:06, 15 May 2012 (EDT)<br />
<br />
== Activity Overflow Bug ==<br />
<br />
This is a potentially campaign-ending bug. This was seen in the Steam distribution, DOS version (on Windows 2003 Server EE). Not sure if UFO Extender was being used - probably it was. End of Jan 1999 turn shows an extreme negative/underflow Monthly Rating score, which in turn is caused by extreme overflow of UFO Activity levels. Note that that funding "score" - the increased funding by countries - was very positive at the same time!:<br />
<br />
<br />
[[File:dissatisfied customers.png]]<br />
<br />
<br />
UFO Activity, by Areas and by Countries, is literally off the chart. Clearly some kind of integer overflow: <br />
<br />
[[File:ufo-areas.png]]<br />
[[File:ufo-countries.png]]<br />
<br />
X-Com activity is also off the chart:<br />
<br />
[[File:xcom-areas.png]]<br />
[[File:xcom-countries.png]]<br />
<br />
<br />
In addition to the likely outcome that I will lose the game in Feb 1999, it means I can't use the graphs to detect UFO activity outside of my radar coverage. <br />
<br />
I have only seen this bug once, and (probably very unusually) I am running under Windows 2003 Server EE (!!). My hunch would be that's the cause, Windows 2003 Server is not the best games platform. :)<br />
<br />
[[User:Spike|Spike]] 07:22, 3 September 2012 (EDT)<br />
<br />
Further information:<br />
<br />
I don't necessarily lose the game in Feb or March 1999. The Monthly Ratings from Feb onward are just based on the current month, not historical score to-date. However it still greatly increases the risk of suffering from the [[Known_Bugs#Losing_My_Favourite_Game|Losing My Favourite Game]] bug - which also greatly complicates doing too many controlled experiments on this Activity Overflow bug, because a few restores of the saved game quickly leads to X-Com Project termination (and humanity's doom).<br />
<br />
Possibly the Activity Overflow bug is caused by an initial value of the score (or an array of score values) not being correctly zeroed at the start of the game. See this graph, which shows a negative score in May 1998, prior to the start of the game in Jan 1999.<br />
<br />
[[File:Prehistoric_negative_score.png]]<br />
<br />
[[User:Spike|Spike]] 08:48, 3 September 2012 (EDT)<br />
<br />
I encountered the same Activity Overflow Bug in Windows 7 using Steam version, Windows option with UFOExtender latest version.<br />
<br />
[[User:Humbe|humbe]] 2012.10.04 09:05 UTC<br />
<br />
I encountered the same bug at end of january with latest xcomutil patched CE version (with only bug fixes patched) with ufo extender newest version running (close to default options). Got many saves from that first month. Even if loading very early save where I had done no missions yet, and just did stuff in base, graphs still show negative for various periods in 1998. Sounds more like corruption than something actually overflowing to me.<br />
<br />
[[User:Archlight|Archlight]] 18:34, 24 September 2012 (EDT)<br />
<br />
== Bad Paths Bug ==<br />
<br />
I suggest to add bad paths on UFOs maps to the article, as another bug in the game.<br />
<br />
[[User:Sherlock|Sherlock]] 09:25, 26 December 2012 (EST)<br />
:That sounds reasonable to me. [[User:Spike|Spike]] 10:03, 26 December 2012 (EST)<br />
<br />
=Cleanup needed=<br />
Hmm this whole Talk page needs a cleanup. A lot of the Not Listed bugs, should be listed, or are listed. [[User:Spike|Spike]] 10:03, 26 December 2012 (EST)</div>
Spike
https://www.ufopaedia.org/index.php?title=Wish_List_(EU)&diff=42231
Wish List (EU)
2012-11-29T21:51:45Z
<p>Spike: /* Geoscape and Strategic */ grouped up some suggestions and +1 recent suggestions</p>
<hr />
<div>X-Com is a great game and as evidence just look to the fact this wiki exists even though the game pre-dates the internet. In all it's greatness X-Com has some elements and behaviors players wish they could change. This is a repository of those desires. Some day a fan mod may make your wish come true...<br />
<br />
= I Wish... =<br />
State what you want AND what X-com does normally. Sign your name if you think "Oh man! That would be great!"<br />
<br />
== Geoscape and Strategic ==<br />
<br />
=== Aircraft ===<br />
<br />
==== Smarter Aircraft Movement Around Globe ====<br />
I wish all craft understood the shortest distance between two points on a globe is a curved path towards the poles. Normally a craft goes in the opposite direction than it should (towards the equator). Pain in the ass when the base in the UK sends a craft to Siberia.<br />
--[[User:Brunpal|Brunpal]]<br />
<br />
<br />
==== Smart Interception ====<br />
<br />
Aircraft intercepting a UFO just head straight toward the UFOs current position at all times. Unless the UFO is already on a head-on course, this results in the interceptor travelling through a closing parabolic spiral path, and often missing the UFO and ending up in a tail-chase, and then just falling further behind unless the UFO stops or reverses course. This is pretty basic stuff, fighter pilots have known how to do this better for nearly a hundred years. It is particularly important if the aircraft you are trying to intercept is moving faster than you (eg if you are flying an Interceptor). <br />
<br />
What is needed is to plot the UFO's current course and speed (which X-Com has from radar data), and plot an intercept course. The maths for this is pretty easy (the intersection of 2 vectors) and can be implemented in a few lines of code, if we can find out where the current interception algorithm is, and patch it. <br />
<br />
Actually the radar bearing shown on screen is only accurate to within 45 degrees. I presume that X-Com does actually know the UFO's bearing, since it can clearly track the UFO's movements. Finding where that variable is located might be different. <br />
<br />
While we're at it, it would be nice if the UFO detection information displayed the actual bearing in degrees, rather than just the compass direction (North East, South, etc). <br />
<br />
Even if the improved intercept algorithm only used a bearing accurate to within 45 degrees, that would still be better for remote UFOs. You might need to switch to "head straight for it" once you get to very close range. [[User:Spike|Spike]]<br />
<br />
<br />
==== All Aircraft Weapons Useful ====<br />
<br />
In a balanced game, all weapons should have their uses, or at least a niche, but sadly this is not so:<br />
<br />
The Cannon is only useful for shooting down Small Scouts, and even that is practically impossible, due to the difficulty in closing to 10km range with any UFO, particularly the fast-accelerating Small Scout. The fact that its ammo takes 96 hours to arrive, when all other craft ammo types only take 48 hours, is a bizarre anomaly making the Cannon marginally even less useful - particularly since the time you would use it most is at the beginning of the game, when you do not have enough ammunition even to deploy the Cannon you already given. <br />
<br />
The Stingray is only really useful for forcing down Small Scouts (it usually avoids destroying them) and otherwise the Avalanche is better in every meaningful way. The Stingray also takes twice as long to rearm for some odd reason, making it operationally much worse than the Avalanche.<br />
<br />
The (unmodified) Laser Cannon is inferior to the Avalanche for more or less everything, apart from running cost. It does have a higher payload but this is hardly relevant (except perhaps in allowing the aircraft to remain on station longer, performing multiple engagements before entering the time-consuming refuel/re-arm cycle). If attacking a UFO that you would struggle to kill with Avalanches, you are unlikely to own an aircraft that would survive long enough to inflict more damage than an Avalanche when mounting Laser Cannon instead. <br />
<br />
The Fusion Ball Launcher has a [[Talk:Craft_Armaments#Fusion_Balls_better_than_Plasma_Beams.3F|possible niche]] in fighting Battleships when mounted on Interceptors. Even then, it is difficult and expensive to have aircraft configured to fight only one enemy. <br />
<br />
Unfortunately, the optimum path for craft weapon development is all-Avalanche followed by all-Plasma Beam. This is a shame. <br />
<br />
Suggestions to 'tune up' the other weapons (see link below for latest suggestions/detail):<br />
<br />
*Cannon - Increase the damage to 15 and 50% hit. So at least there is a pay-off if you manage to get in close. <br />
*Stingray - Raise Stingray accuracy to 80% but drop Avalanche to 60%. Double the rearm rate so it can be reloaded as fast as an Avalanche launcher.<br />
*Laser Cannon - increase accuracy to 50% and damage to 100. <br />
*FBL - increase the ammo from 2 to 3. <br />
<br />
It might be worth considering 'tune down' the Plasma Beam as well, particularly its stand-off range. It seems odd that humans copy alien plasma weapons and right away improve the range. It would be reasonable if the human plasma cannon had shorter range than the UFO plasma cannons, and more consistent with the ranges of other cannon weapons. (One could ask how X-Com even developed a targeting system that is accurate for direct fire at or beyond the extreme range of self-homing missiles - even if the plasma cannon itself is that accurate, how do you exploit that accuracy by aiming it?).<br />
<br />
[[User:Spike|Spike]] 04:02, 20 September 2012 (EDT)<br />
<br />
An alternative to tweaking the stats, is to tweak the costs. Realistic costs such as $386K for an Avalanche and $125K for a Stingray will put some pressure to use weapons that are cheaper to operate. And XComUtil has an option that substantially increases the effective build costs of Plasma Beams, making them less optimal.<br />
<br />
See also: [[User:Spike#Balancing_Aircraft_Weapons]]<br />
<br />
<br />
<br />
===Score for retaliation Battleships===<br />
<br />
When a Battleship on retaliation attacks your base and is shot down, you get no score for it. This is completely illogical and it discourages any use of base defences. You should get normal 700 (or even 1400) points for it.<br />
--[[User:Kyrub|Kyrub]] 14:05, 30 August 2008 (PDT)<br />
<br />
: I'm not sure about this. Yes it's illogical, but it could also be a licence to get a huge score if you have a strong enough base. [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)<br />
<br />
:: The impenetrable base setup would turn into a cheat. As the aliens will keep hammering the base with a battleship until one breaks through, you'll have a steady supply of points without having to really do anything. Some balancing, such as paying to rearm your defence modules, ought to be thrown in to balance things out. -[[User:NKF|NKF]] 23:13, 13 September 2008 (PDT)<br />
::: A better fix would be to remove the retaliation flag when a battleship is destroyed. If someone can post a savegame with a never-ending flow of base attacks, I may have a look at the fix. [[User:Seb76|Seb76]] 01:05, 15 September 2008 (PDT)<br />
<br />
:::: Ummm, it seems the best solution (I, for one, can't think of any better), but wouldn't it assume that only the BattleShip really locates the player's base? All those scouts for nothing? [Still the best solution, though] [[User:N|n]] 15:01, 16 August 2010 (GMT+1)<br />
<br />
=== Tougher UFOs ===<br />
<br />
==== The Problem ====<br />
<br />
So let me get this straight. The first hybrid airborne weapon that humans ever build, and it immediately outclasses every weapon the aliens ever built, including their Battleship weapon? After all the Aliens have only been building plasma weapons for a few million years, us humans have been doing it for ''months''!<br />
<br />
More to the point, once you get Plasma Beams, downing UFOs is like shooting fish in a barrel. Even Battleships aren't that exciting if you show up with enough ships. <br />
<br />
What is needed is to push up the range, damage, and rate of fire of all the UFO weapons, particularly the UFOs you will be fighting by the time you have plasma beams. At a minimum, the weapon on a Battleship should be at least as powerful as, say, 2 Plasma Beams (as found on the XCom craft it is fighting)? Instead of slightly less than half as powerful? Compared to a single Plasma Beam, only the Battleship weapon has better range. It has double the accuracy, slightly higher damage, but half the fire rate. Net 5.7% more firepower than one Plasma Beam, but no match for 2. And the Battleship weapon of course is the most powerful in the alien arsenal. <br />
<br />
Possible tune ups for UFOs:<br />
<br />
*Battleship - increase to 255 weapon power, improve reload rate to 12 (from 24). Now roughly equivalent to 4 Plasma Beams in total firepower (on Beginner difficulty). Increase range to 69km, so that the Battleship commences fire as soon as an XCom craft begins its attack run. Or better, increase range to 70+km, the limit of the interception window, so that the Battleship starts firing immediately the XCom craft enters air combat range. This would disrupt XCom aircrafts' ability to form up into a flight of 4, prior to commencing their attack. Overall, this would make it much harder to down Battleships. Increasing weapon range to 70+km would also make it much harder to tail a Battleship - manual control in the Geoscape would be needed to hold off outside of combat range. Really, the Battleship should not sit there like a sitting duck. Does it think XCom are friendly?<br />
*Terror Ship - increase range to 52 (or decrease Plasma Beam range to 42), so stand-off kills are not possible with Plasma Beams?<br />
*Actually maybe all the larger UFOs should have weapon range 69-70+km, so they behave very aggressively toward XCom craft. <br />
<br />
NB: Strange effects occur if weapon range goes over 70km so it's probably best to leave it at 70km rather than 75km.<br />
<br />
NB: Also, changes to rate of fire need to be looked at carefully though because Difficulty Level also reduces reload rate for UFOs. Between Beginner (Difficulty 0) and Superhuman (Difficulty 4), rate of fire (and thus firepower) for Battleships, Terror Ships and Supply Ships increases by 24/(24-4x2=16) or 50%. But if the base reload rate for these weapons was reduced to 12, the transition from Beginner to Advanced would increase firepower '''three''' times for these 3 UFOs (less so for the smaller UFOs). It is less risky to increase the weapon power. Unfortunately there are only 2 firepower variables to play with - damage and reload rate - so there are not a lot of options, especially for the Battleship which already has weapon strength 148 out of a probable maximum of 255.<br />
<br />
:More detail on this. For Medium Scout, Large Scout and Abductor, with nominal reload rate 48gs, the rate of fire improves +20% between Beginner and Superhuman. For Harvester (32gs) it improves one third. For Large UFOs (Terror Ship, Supply Ship, Battleship - 24gs) the improvement is +50%. [[User:Spike|Spike]] 20:28, 14 February 2010 (EST)<br />
<br />
I think we should assume that the Battleship, which is bigger than the entire XCom base, is engaging XCom craft with its secondary weapons rather than its main armament, which could probably destroy Manhattan with a glancing hit. <br />
<br />
I would really like to see the hypothetical Mega-Battleship go up against XCom's finest - a flight of 4 Avengers armed with dual Plasma Cannon or dual Fusion Ball Launchers. With the Battleship having 70+km range, 255 weapon power, and an effective fire rate on Superhuman triple that of the PB, it would have the firepower of 11 Plasma Beams - 36% more firepower than the whole attacking XCom force combined. To be honest I think that would be carnage, not sure XCom could win. So that would be tuning the Battleship up too much. The 3-fold increase in rate of fire when on Superhuman is just too much. Maybe just max out the damage to 255 and range to 75. This gives a 72% increase in firepower, and a challenging tactical problem for XCom (forming up and approaching under fire).<br />
<br />
The smaller UFOs can probably stay as they are. It is not until later in the game that XCom advances so that even large UFOs are easy pickings. What is the crossover point? Maybe the medium UFOs. So it might be good to reduce the reload times of the medium UFOs from 48 / 32 to 24, a good increase in firepower. <br />
<br />
In general I think all UFOs energy weapons should have at least as good range as the XCom energy weapons, even the Medium Scout. Again, they have been using these weapons for millions of years and we only just figured out how to copy them from the aliens, how could our weapons be better than the aliens? How did our first plasma weapon out-range and out-perform all but the hugest UFO plasma beam? And on an airframe the size of a Small Scout we mount ''two'' such weapons? On the battlefield we only are able to replicate alien weapons; how is it that in the air we are able to improve on them ''masssively''?<br />
<br />
Perhaps there should never be a stand-off advantage, except possibly with missiles -which should be less accurate with longer range. The XCom stand off advantage is really unfair because as far as I have seen the UFOs never attempt to close to effective range, even when they are getting killed. They don't break off much, either, though I think I have seen that happen on occasion. <br />
<br />
==== Specific Proposals ==== <br />
<br />
===== No Standoff Beam Attacks =====<br />
<br />
Increase ''all'' UFO plasma weapon ranges to at least 55km (compared to 52km for the XCom plasma weapon). Now only launched XCom weapons (Avalanche and Fusion Ball) have standoff advantage. Probably also reduce the accuracy of the Avalanche to 60% and buff Stingray accuracy to 80%, providing both weapons with a useful niche role.<br />
<br />
===== No Standoff Attacks =====<br />
<br />
Increase ''all'' UFO plasma weapon ranges to 66km (compared to 52km for the XCom plasma weapon). Now ''no'' XCom weapon has standoff advantage. (The benefit of a longer range weapon is simply spending less time being fired on by the UFO.)<br />
<br />
===== Twitchy Aliens =====<br />
<br />
Increase all UFO ranges to 69km. They will attack as soon as XCom aircraft commence any attack run.<br />
<br />
===== Hostile Aliens =====<br />
<br />
Increase all UFO ranges to 70km. They will attack as soon as XCom aircraft enter intercept range. UFOs now fire first, and tailing them unchallenged is impossible. <br />
<br />
===== Improved Medium UFOs =====<br />
<br />
Reduce (improve) the nominal reload time of Medium UFOs, Abductors and Harvesters, from 48gs and 32gs to 24gs. This increases the challenge in the early-mid game, when XCom might first be deploying advanced weapons.<br />
<br />
===== Improved Battleships =====<br />
<br />
Increase damage to 255. They're firing (bigger) Fusion Balls! A Battleship now has the same firepower as one XCom Craft with dual Plasma Beams (gosh wow!). It's a start, but what if we...<br />
<br />
===== Super Battleships =====<br />
<br />
... also reduce nominal reload time to 18gs. Giving a further one-third extra firepower on Beginner, 60% more on Superhuman.<br />
<br />
===== Mega Battleships =====<br />
<br />
... or for a real challenge, reduce reload time to 12gs. A further doubling of the firepower on Beginner - a further ''four'' times increase on Superhuman. Now Superhuman Battleships out-gun the biggest fleet XCom can throw at them!<br />
<br />
[[User:Spike|Spike]] 00:25, 19 February 2010 (EST)<br />
<br />
: the flip side of this is weakening Xcom craft - apart from firepower issues there is also the issue of range: the ranges of the transport craft are such that really no more than 1 manned base is necessary to cover the globe for terror site defense. Setting e.g. the fuel capacity of the Skyranger to 500 results in roughly 1 base per continent required. This has interesting strategic consequences: need for more bases makes the ecomics more challenging (and thus slows down research). [[User:Emphyrio|Emphyrio]] 08:43, 9 August 2010 (EDT)<br />
<br />
===Enforced Variant Games===<br />
<br />
Various people like to play various variant games, such as No Alien Technology, or No Detection, or No Lethal Weapons - see for example Scott Jones' notes to XComUtil. It would be nice to have options on the game executable to enforce these scenarios. Self restraint is hard! [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)<br />
<br />
Some of these variant scenarios have been implemented in [[UFO Extender]] by [[User:Seb76#Mods|Seb76]].<br />
<br />
<br />
===Recruit Certain Alien Types===<br />
<br />
Consider that not all aliens are loyal to their master (most TFTD alien has a device lodged to its brain), it would be interesting (or at least cool) if we could recuit such aliens to the XCOM cause. Maybe we can remove the controling devices from captive aliens after research on that species. Or convince the head of the Snakemen that it would be far more benefit to his race to help us instead of the Ethereals [[User:L-Zwei|L-Zwei]] 23:25, 12 September 2008 (PDT).<br />
<br />
Only certain alien types should be recruitable. Ones that should NOT be include Mutons (as they are directly controlled by Ethereals), Chrysallids (unbalancing), etc. It would be nice to be able to reverse-engineer Cyberdiscs or Sectopods, or make it that a Cyberdisc must be researched to build hovertanks/etc.<br />
[[User:MagicJuggler|MagicJuggler]] 13:32, 18 September 2008 (PDT)<br />
: It's pretty obvious which ones should be recruitable: non-robotic terror units that are captured alive. Chryssalids should simply do melee damage instead of impregnating (as the resulting spawn would not be mind-controlled and therefore XCOM wouldn't do it). Silacoids would be pretty ineffectual, and reapers slightly less so, but both would be disposable scouts. Celatids might actually have some use (eating through hulls with acid, and arcing over walls) but are fragile. All of these would require capturing a terror alien alive after researching Psi Amp. The two robotic units should require a live alien Engineer researched as well as UFO Construction, and the materials for building one would be one corpse of the appropriate type, Alien alloys and Elerium (to repair and refuel the husk). The Sectopod should probably be nerfed somewhat, so that it isn't quite so invincible to Heavy Plasma shots - after all, it was probably a twisted and melted modern art piece by the time it finally went down). [[User:Stubbs|Stubbs]]<br />
<br />
=== Research ===<br />
<br />
==== Game option: sell only researched items ====<br />
<br />
The fact that you may sell the alien items for the best price once you get them, without any research, is illogical. Such staff would never get on the market, being top secret and potentially dangerous to the humanity.<br />
<br />
Selling without proper research does not help the replay value of the game either: once you know the "right path" to get the best items, you simply sell anything else immediately and ignore the unnecessary research. Too easy.<br />
<br />
Therefore I wish for this game option: unknown items are sold for 0 (including the alien corpses), the known ones for their full price. This makes the sustainable economics much harder to develop and it gives sense to the "useless" research. Last but not least, it adds a lot of depth to the gameplay: will you choose research of a new weapon you need on the field, or of a mind probe that will earn you millions in sales? --[[User:Kyrub|Kyrub]] 15:55, 6 April 2009 (EDT)<br />
<br />
: I really like this option, it's a great idea. Makes the game harder and makes it more interesting, more varied. Gives extra value to the otherwise "useless" research paths. Good thinking! [[User:Spike|Spike]] 15:06, 24 August 2009 (EDT)<br />
<br />
: I'd prefer that unresearched artifacts/corpses sold for a fraction of their original value (no more than 25%). It makes no sense that nobody would pay to research them for themselves. Additionally, Laser Cannon sell price needs to be nerfed. [[User:Stubbs|Stubbs]]<br />
<br />
: This would have the added benefit that you would know if it was 'safe' or not to sell an item research wise. Coloring the un-researched items differently on the Sell/Sack screen would be good too ~ [[User:Renegrade|Renegrade]] 13:30, 19 August 2010 (EDT)<br />
<br />
==== New Research Mechanics ====<br />
<br />
The above comments spurred some ideas to make the research more realistic and the path to victory less obvious. <br />
<br />
For flavor reasons, give research options vague names instead of exact names. This already exists in some research topics, such as "New Fighter Craft" instead of "Firestorm". So, research topics might read "Alien Hovertank Wreck" instead of "Cyberdisc Corpse", "Grey Alien Corpse" instead of "Sectoid Corpse" or "Alien Pistol" instead of "Plasma Pistol". The names would be revealed in the UFOpaedia entry, and certain items would then be renamed as per common sense.<br />
<br />
Hide the ranks of aliens in captivity until they are researched (so you'd see Live Grey Alien #1, Live Grey Alien #2 if you had two Sectoids available for research). However, if you happened to have two Soldier ranks in containment, you'd only see one topic. The same rank/race combination would never appear again, but you might have to research several specimens of the same species to get the useful one you want. The alternative would be to have researched Mind Probe, which would tell you exactly what you had in containment (just as it does on the battlefield).<br />
<br />
Once an alien or its corpse is researched, then all other instances of that alien or its body are renamed appropriately. For example, research a live Muton and Muton corpses become obvious, and vice versa. "Live Green Humanoid Alien" is also renamed to "Live Muton".<br />
<br />
Finally, there should be a few more prerequisites in place to make less useful research more necessary. As someone else has mentioned, you should need a Cyberdisc Corpse to research Hovertanks. I'd also suggest that Psi Amp and Mind Shield require the research of Mind Probe (seeing as both entail scanning for minds as a logical first step), and that Flying Suits require Floater Corpse, Cyberdisc Corpse or a live Floater researched as an additional prerequisite (not Ethereals, as they fly with the power of their huge brains). [[User:Stubbs|Stubbs]]<br />
<br />
:These are all good suggestions and make a lot of sense. An alternative explanation of the names (seen in some fan fiction) is that these names are not the real names, but are made up by XCom troops based on some limited battlefield experience of them. But revealing the "real" alien race names through Research is a fun idea. [[User:Spike|Spike]] 08:44, 1 September 2009 (EDT)<br />
<br />
[[TFTDextender|TFTD Extender]] now provides options for improvements to the TFTD Research tree, to make research more logical (and less buggy). A similar exercise is possible with UFO Extender now that the location of the Research tree in the code is known. [[User:Spike|Spike]] 03:48, 20 September 2012 (EDT)<br />
<br />
==== Dismantle researched items ====<br />
<br />
Beginning a research project on an item should immediately remove that item from your storage. Currently it's possible to begin research on Heavy Plasma and Sectoid Corpse, then immediately sell those items, which makes no sense. Instead, we should assume that the eggheads need to dismantle an item to study it, thereby making it useless.<br />
<br />
Completing a research topic on a live alien should create an appropriate corpse in storage, but this is less noticeable. Or do X-Com give all researched aliens diplomatic immunity and $20 for a cab fare?<br />
<br />
:+1 to these suggestions. [[User:Spike|Spike]] 16:51, 29 November 2012 (EST)<br />
<br />
<br />
=== Base Managemet ===<br />
<br />
==== Inventory management ====<br />
<br />
I only want to keep 1 (or 0) sectoid corpse. If I have any more, sell them immediately and automatically. Sometimes having to sell all the stuff you've captured is just a chore.<br />
<br />
Also, let me automatically repurchase goods when my stores get too low.[[User:Lobster Dan|Lobster Dan]] 13:18, 25 January 2011 (EST)<br />
<br />
==== Monthly maintenance fees ====<br />
<br />
Later in the game, when you are way beyond what the sponsor nations are paying you and are instead selling captured/manufactured items to fund your operation, the end of the month can be a real PITA, because you need to build up a reserve of cash to avoid being shut down for financial problems. (This was worse with the misreported funding bug.) At the least, show us in one place exactly how much we need to raise at that time.<br />
<br />
Or make payments be done on a weekly/daily/hourly/continuously basis. This also means that I don't have to pay a same salary to someone who I hire on the 2nd or I hire on the 27th.<br />
<br />
Oh, and the cheat of "soldiers/scientists/engineers in flight don't need to be paid" needs to be squashed while we're at it. (But watch out fixing this one without making salary payments continuous; my current strategy is to hire most people just before the end of the month, which I would need to modify to hiring just after the start of the month.)[[User:Lobster Dan|Lobster Dan]] 13:18, 25 January 2011 (EST)<br />
<br />
==== Day Rates ====<br />
<br />
Financial planning in the game is distorted by the fact that Engineers, Scientists and Soldiers receive a full month's pay for their first month, even if they only work one day in that month. This leads to bursts of hiring at the beginning of each month, and worsens the cash squeeze at the beginning of each month. <br />
<br />
It would be nice if you could hire personnel at any time during the month, and they would only cost you their hiring fee (one month's salary in full), plus only as much of the first month's salary as they actually worked during that first month. [[User:Spike|Spike]] 06:48, 20 September 2012 (EDT)<br />
<br />
=== Change date ===<br />
<br />
1999 looks quite silly now, 13 years later and I don't think mankind has even laser weapons now. So if it's not hardcoded for some alien actions in further years, I'd move game at least to year 2020, more likely even later. [[User:mikiqex|mikiqex]] 10:30, 12 January 2012 (CET)<br />
<br />
=== Active Alien Bases ===<br />
<br />
Right now, alien bases don't do anything aside from increasing alien presence in a region and attracting Supply Ships. This should be remedied and I know just how to do it.<br />
<br />
* All alien bases have a "readiness level". Initially, this is at 100% but can be reduced via base assaults. Every alien killed and certain equipment destroyed decreases this level but if the base isn't destroyed (the mission fails or gets aborted) and subsequent Supply Ships aren't intercepted/attacked on the ground, then 24 hours after a successful resupply the base's readiness level will be back at maximum. Then and only then will killed aliens respawn and destroyed/taken equipment get replaced, not before. This reduces the profitability of "base milking" smash-and-grab operations but is not the primary purpose of the mod.<br />
* Like the name indicates, alien bases should have a more active role. That is, alien bases will frequently dispatch Small and Medium Scouts on Research and Abduction missions, crewed by the same race the base belongs to. How often this happens depends on the base's readiness level, ie. a busted-up base will be barely hanging on but a fully-functional one will be a real beehive.<br />
* Optional: if a base is present in a country, it significantly increases the chance of the country being successfully infiltrated.<br />
* If a base goes unmolested for too long, it will become fortified and spawn two or even three times as many aliens (as many as the tileset allows) plus it takes on a more aggressive role:<br />
** Launches Infiltration missions into nearby areas.<br />
** ''"Leave us the [PRESUMED ALIEN EXPLETIVE] alone!!!"'': if attacked several times in rapid succession (depending on difficulty level; happens after a single invasion attempt on Superhuman), it sends out Retaliation scouts in the general direction the attacks are coming from, looking farther and farther away after every attack.<br />
** ''"Oh no, you don't!"'': if it had been attacked at least once, the base will attempt to intercept X-Com craft passing nearby. It does so by dispatching a scout that follows the intruder at top speed and, once within a certain distance, forces it to engage the UFO in Aggressive mode. If the UFO is faster, all other modes and the Disengage button will be disabled as well. Even if the X-Com craft can run away, the UFO will follow it everywhere unless shot down or the craft lands, in which case the aliens dispatch Retaliation scouts to find the intruder's homebase.<br />
** The above three options all make the base more dangerous but will also increase the payoff and provide an alternative to the nerfed "base milking" tactic.<br />
<br />
I have NO idea if these are even possible but they would be highly interesting.--[[User:Amitakartok|amitakartok]] 17:44, 19 September 2012 (EDT)<br />
<br />
: +1. This is a great set of suggestions. I think the necessary manipulations of [[MISSION.DAT]] are fairly well understood. [[User:Spike|Spike]] 03:48, 20 September 2012 (EDT)<br />
<br />
== Battlescape and Tactical ==<br />
<br />
===Equipment Management===<br />
<br />
All wishes are currently implemented!<br />
<br />
===Fog of War Improvements===<br />
<br />
I'm sure most of these would be an absolute PAIN to implement, but I figured I'd toss the ideas out here.<br />
<br />
====Prior Recon of Battlefield====<br />
One thing that has always irked me is X-COM has no terrain knowledge when it lands, despite having probably circled the place two or three times before landing and thus they should know at least some of the area. This would be nice, but isn't too important. Probably would be a pain to implement so X-COM would have all knowledge of external features but no knowledge of building interiors, anyways. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)<br />
<br />
:Yes at the very least, when you splash the UFO, it could tell you (via some miracle technology such as "satellite reconnaisance") what the terrain type is of the landing zone area. Then you could adjust equipment accordingly. And adjust your uniform camouflage (if using one of the uniform mods). [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)<br />
<br />
:: Geoscape: center on the site, then maximum zoom. Aside from having to disambiguate forest from jungle, this works fine for knowing the exact terrain you're getting into. -- [[User:Zaimoni|Zaimoni]] 10:17, 4 Sept 2008 (CDT)<br />
<br />
:::This is already present in the game. To center the Geoscape on a specific location, right-click on the target spot. To do maximum zoom in, right click on the Zoom-In button(and the same works for Zoom-Out). Also, Jungle and Forest use the same display algorithm, but are easy to differentiate; Forest occurs NORTH of the equator, and Jungle occurs SOUTH. [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:23, 4 September 2008 (PDT)<br />
<br />
:Returning to AQ's original suggestion, it wouldn't be too hard would it for the dropship to "radar map" the target, and then have the basic map show up on your scanner on Turn 1? [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)<br />
<br />
====Dynamic Fog====<br />
<br />
The Fog of War in X-COM is clumsily implemented, compared to modern expectations. Everything starts out black, but after exploring, is shown...and it's kept in the same showing, regardless of whether you actually have LoS to that area anymore. It would be nice if when you no longer had Line of Sight to a particular map area, it would be cloaked in a way so that you knew the terrain, but not the units there. Since I've sometimes spent over half an hour trying to hunt down that last alien hiding in area I'd already explored. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)<br />
<br />
:Maybe greyscale explored but out-of-LOS areas?--[[User:Amitakartok|amitakartok]] 17:45, 19 September 2012 (EDT)<br />
<br />
====Deactivate Object Radar====<br />
<br />
Currently, in X-COM, any objects dropped in a given square show on your Battlescape, regardless of whether you have Line of Sight to the square or not. In regards to dropped weapons/grenades/equipment/dead soldiers/dead aliens, this doesn't make a large difference. But in the case of STUNNED aliens, a quick scan across the Battlescape can tell you whether the alien you stunned 10 turns ago is still down, or stood back up(the stunned alien object will disappear from the stack). Of course, since aliens which have revived from stun are almost always disarmed(and the ones that aren't probably should've been killed instead), the usefulness of this 'exploit' is reduced mainly to finding out that the last alien you're looking for is just wandering aimlessly and unarmed. Perhaps leave stacks showing the same until you regain LoS to that area? [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)<br />
<br />
====Crushed Buildings====<br />
<br />
Why don't we see any crushed or destroyed buildings? Does a UFO always fall like a rock, perpendicular to the ground? No marks on the ground? Such impact would do massive damage to the land (a small meteor can do much if it has a high speed...). (Also, at the [debatedly] "real" UFO crash zones UFO parts were scattered over miles)<br />
<br />
I'd like to see chopped buildings, entering UFO's through a barns; entering an abductor from a immediate house's roof if I have plasma and no flying suits yet. - [[User:N|n]] 15:01, 16 August 2010 (GMT+1)<br />
<br />
: The Pocket PC remake of the game did this, though it seems the site it concern has vanished off the face of the net. Could probably find a copy if you're interested.<br />
<br />
: By the way, you can generate a time/date stamped signature by typing four tildes (<nowiki>~~~~</nowiki>). - [[User:Bomb Bloke|Bomb Bloke]] 23:04, 16 August 2010 (EDT)<br />
<br />
:: Amazingly enough (is it Truman Show of me or just a coincidence :)?), my GF found a low-tech palmtop (with/in a case)... on the pavement. With no personal data and means to find the owner; when I laid my hands on it, I actually found and installed Ufo:EU there, but it wouldn't run :(. [And thanks! again for the 4 tildes name/timestamp trick] - [[User:N|n]] 19:18, 18 August 2010 (EDT)<br />
<br />
===Restore Game from Battlescape===<br />
<br />
It would be nice to be able to reload a saved game directly from the Battlescape "?" screen, rather than having to go through the process of Abandoning to the Geoscape. Would you need to check it was a Battlescape save and not a Geoscape save? Maybe, maybe not. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)<br />
<br />
===Stun Grenades===<br />
<br />
I want flashbangs.--[[User:Brunpal|Brunpal]] 22:59, 11 September 2008 (PDT)<br />
:Instead of stunning, I'd see more effect if it would remove some TUs to units having line of sight (to be fare it should affect xcom units too). It would help against reaction fire (which is the point of flashbangs). Given that grenades detonate at the end turns, it would require a good coordination to have the grenade detonate exactly at the end of the alien turn, and just before your attack. Being able to open doors à la xcom2 would also help to throw flashbangs just before a craft assault... [[User:Seb76|Seb76]] 22:03, 12 September 2008 (PDT)<br />
::That would be good. Hard to program, potentially extremely unbalancing, but good. I considered a "debuff" kind of ability (as you suggest) for flashbangs, vs the more obvious substitution of [[stun]] for [[Explosions|HE]] damage. In the end, I picked "I want flashbangs."--[[User:Brunpal|Brunpal]] 03:32, 13 September 2008 (PDT)<br />
: Maybe flashbangs dont' work on Aliens - otherwise, XCom would use them, right? :) But seriously, I too would like flashbangs, and stun grenades / concussion grenades. Both of these would make the game easier, though. With flashbangs, you might have to compensate by just giving the aliens more TUs. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)<br />
::More options for the player is going to make it easier for any kind of game. Particularly of games like XCOM where the computer can't take advantage of the changes. However I don't believe a weak stun grenade (like 44 stun damage, comparable to AC-HE) would change the game much because the 80 item limit remains.--[[User:Brunpal|Brunpal]] 22:21, 13 September 2008 (PDT)<br />
<br />
===Night Vision===<br />
<br />
I '''don't''' want to add night vision equipment to the game. I assume that either (1) all XCom units already have night vision gear as standard, but it's not as good as alien night vision, and the visibility that XCom units have at night is based on their standard-issue night vision gear, or (2) night vision gear does not work on Aliens. Either they do not appear on night vision, or maybe worse - maybe the aliens can manipulate night vision equipment, causing worse than normal vision, or hallucinations, and even tricking XCom units into firing on each other. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)<br />
<br />
:Wouldn't it be nice though if it had gradients other than "day: 20 squares" "night: 9 squares" ? Like.. "early morning/late evening: 10-19 squares" ? I find the cut off from full daylight to full night kinda disturbing. ~ [[User:Renegrade|Renegrade]] 10:41, 19 August 2010 (EDT)<br />
<br />
:: I originally thought of this when dreaming of a Stargate-themed patch for X-COM -- but what about enemies that are invisible unless you are facing them while wielding a certain weapon designed to spot them? (Stargate fans: I'm thinking of the TERs.) [[User:Lobster Dan|Lobster Dan]] 13:18, 25 January 2011 (EST)<br />
<br />
===Throwing over stuff===<br />
'''(Moved to Talk, as this is not a bug and so does not need fixing.)'''<br />
<br />
<br />
<br />
===Assault Time Limit===<br />
<br />
One of the cool things about UFO Defence is there are no time limits on the scenarios. This is great as it allows for a totally different kind of tactics and much more flexibility. <br />
It's more of a "thinking man's game" as a result. But... arguably this is not very realistic for UFO Assault missions. If the Aliens are getting creamed, they should try to make a getaway if they can (just like XCom would). A simple way to implement this would be a hard time limit (say 20 turns?) on a UFO Assault. Another way would be to base it on Alien Morale. At a certain Morale level the aliens decide to dust off. Give the player say 3 turns warning while they rev up the engines. Then if there is still a Navigator or Engineer in the Control Room alive, the ship takes off. Any XCom troops still aboard are MIA. <br />
<br />
You might run into problems if the UFO took off but then landed again or was shot down, generating another ground mission with potentially '''more''' Aliens than were still alive at the end of the Assault. (Still, maybe they hatch some more clones if they get time to....) [[User:Spike|Spike]] 09:51, 4 September 2008 (PDT)<br />
<br />
: It strikes me as justified they don't do that. Troops loose in the vessel could be seriously bad. It would be nice if they dusted off on the condition that their morale was low enough or 3 X-com soldiers had the door in their sights without aliens alive outside in the latter case and no X-com soldiers on board in either case. also, if the UFO has a hole in either the command or engine room, it would have to set down before leaving the atmosphere. [[User:(name here)|(name here)]]<br />
<br />
Taking off with troops onboard would be perfectly safe (for the aliens) and justifiable if one assumes that alien ships in flight are inherently inhospitable for humans. This is easily done by saying that they undergo accelerations that humans can't withstand (splat), can't withstand for any length of time (pass out), or that they intentionally make rapid accelerations in different directions, either normally or just if they're trying to bash some intruders around. Naturally, the aliens themselves would either be immune to these (tough physique / their built-in antigrav devices?), or be in acceleration chairs, safe from all this.<br />
<br />
Alternatively, when you get the warning that the UFO is going to take off, you've got a certain amount of time to either get everyone '''off''' the UFO, or to get everyone '''on''' it (or as many as you can). There could be a follow-up mission that takes place in "sky" terrain, where the outdoors is either impassable (the easy way) or else instantly withdraws units from combat (flying suits / parachutes). The soldiers' goals would be to either take out the aliens and presumably safely land and salvage the UFO, or take out the UFO's means of flying (power cores / navigator?). In the latter case, they might have a certain number of turns to withdraw or be caught in the crash, with possible casualties just like the aliens, mitigated to some degree by their armour and maybe where inside the UFO they are.<br />
<br />
In the case of a crash, there could be a final mission to finish off the surviving aliens, using the X-COM soldiers that survive the crash, and no landing craft (it's still back at the old landing site). Alternatively, you could say that there '''is''' an X-COM landing craft parked outside (with all remaining members of the original landing party), since the in-flight time / distance was presumably low and the original X-COM craft quickly packed up and flew to the new landing site. &mdash; [[User:Wisq|Wisq]] 17:11, 18 April 2010 (EDT)<br />
<br />
Either side could try bringing in reinforcements -- if I can bring two interceptors to a fight in the sky, why can't I bring two troop transports? This starts to get complicated, but it's come up in discussion of making X-COM into an onlime multiplayer game... :) [[User:Lobster Dan|Lobster Dan]] 13:18, 25 January 2011 (EST)<br />
<br />
===Alien AI===<br />
<br />
====Attempts to rearm====<br />
Aliens cannot pick up items, but I wish they would. If an alien has no useful weapons in inventory they should either head for cover or head for a plasma weapon. Panicked aliens drop their weapons but never seem to pick them up when they managed to pull themselves together. It would be nice if they tried to arm themselves again. --[[User:Brunpal|Brunpal]] 13:55, 19 September 2008 (PDT)<br />
<br />
:Even if it's too hard to make aliens head towards weapons (is it safe?, could it be used to trap them, not to mention the complexities of route finding) - it would still be good if an unarmed alien checked for usable weapons in every square it moved through, and at least picked up one loaded weapon or grenade per turn. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)<br />
<br />
Fixing the AI for this could be really hard. Apart from all the possible exploits by XCom, the AI is probably a really hard part of the game to reverse engineer. You could say that an unarmed alien is no threat anyway (we are only concerned about aliens without psi or built in weapons). So nothing is lost even with an exploitable method of re-arming. By exploitable I mean the XCom player can manipulate re-arming, e.g. by leaving weapons out in the open as bait for traps. <br />
<br />
Maybe the simplest modification would be to ''not'' drop weapons when the alien panics? This does not require delving in to the AI, just intercepting the panic effects. Dont make aliens drop any weapons when they panic. It would be reasonable to return the weapon in hand to inventory, so there is a TU cost for the alien to bring the weapon back into play again. <br />
<br />
This would not work for aliens who were stunned and wake up, or who were mind controlled by XCom and made to drop their weapons. But it would probably catch 80% of cases. <br />
<br />
Another cheat, short of fixing the AI, is just to pick up weapons that the alien walks over. It could also pick up "spare" weapons from adjacent aliens (cheating on TUs - basically just teleporting the items to the unarmed alien). Spare alien weapons are almost invariably grenades. I have not had a lot of success in getting unarmed aliens to use grenades, so more research is needed here. Maybe only certain types of aliens use grenades, or only in certain circumstances?<br />
<br />
Really, really cheating would be to teleport any weapon laying around the battlefield into the alien's inventory. But I think it is more fair just to say panicked aliens dont drop their equipment. [[User:Spike|Spike]] 16:13, 13 February 2010 (EST)<br />
<br />
:Interesting research! [[User:Volutar |Volutar ]] found a disabled function in the code that makes aliens pick up items! [[Talk:OBDATA.DAT#Field_0x2D]]<br />
<br />
==== End Psi Bullying and Psi Baiting ====<br />
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? <br />
<br />
: Not a bad idea to randomise this a bit, because while initially this tactic helps the aliens, it becomes so predictable that it can be used against them by deploying unarmed "Psi Bait" soldiers to draw off all the attacks. (Or make aliens avoid controlling/panicking soldiers who have no loaded weapons. But then folks would just give them pea shooters and wear armour.) [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)<br />
<br />
=== 80 Item Limit on Base Defense Mission ===<br />
: Well you get the 80 item limit on every mission, but it hurts more on a Base Defence as you have more limited ability, or sometimes no ability, to manage what goes into those 80 items. I was thinking about a couple of (theoretical) ways to fix this and I hit on a new one (new for me anyway): Why not take the 80 items from the Transport(s), first Transport then second Transport until you run out of items or hit 80. This has a few benefits:<br />
:* Ready made interface to manage the 80-item limit, the Stores <> Craft (Equip Craft) Screen.<br />
:* If you have no warning at all, the 80 items will probably make good tactical sense in general terms, even if they are are not totally optimised for Base Defence (no proximity mines, etc).<br />
: I think that copying the Transport inventory into the Battlescape inventory would be relatively to implement (though what do I know?). As a simplification, you could move only the inventory in the ''first available'' Transport that is present in the Base, into the Battlescape, and not bother looking in more than one place (other Transports, Base Stores) to get up to 80. It would then be a bit of a drag if your Transports are all out on a mission when your Base gets attacked though. Or perhaps inspect the inventory of Transport 1 (wherever it is in the world), and then attempt to copy its inventory, using equipment present in the Base?<br />
: Another way of doing it which has been mentioned elsewhere is to try to reverse the order of the items in the Stores list. This has the effect of putting the more advanced weapons first, rather than the more basic weapons. There could be all kinds of unwanted side effects of this, depending on various programming issues.<br />
: Actually there is already a fix for the 80-item limit in XComUtil. XComUtil records a standard assign weapon set for each of your troops, and then teleports those weapons to the Battlescape from your Base Stores, regardless of the 80-item limit (but still subject to the Battlescape's 170-item limit). Not 100% sure if this works for Base Defence missions though. <br />
:[[User:Spike|Spike]] 13:22, 24 November 2008 (CST)<br />
<br />
=== Collision Detection Bugs ===<br />
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! <br />
<br />
=== Base Defence Systems Cause Alien Casualties ===<br />
<br />
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). <br />
<br />
: The general view is probably that Base Defence missions are a boon to XCOM already, so why make them any easier. At very least there would need to be more damage to the loot than there was to the Alien's combat effectiveness, otherwise this unbalances the game in favour of XCOM. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)<br />
<br />
=== Alien vs Alien ===<br />
This one is way out there. Alien v Alien battles out with main game, just random battlescape maps. Sectoid and their terrorists against Floaters and theirs etc. One side human controlled the other computer. Choice of ships involved etc. <br />
<br />
:I actually love this idea. It might just about be possible using XComUtil, if someone is a total XComUtil guru.<br />
<br />
----<br />
<br />
There was a utility to do this from Devisraad. it has long since been removed from his site, but someone may still have it. The basics was you renamed unit and it automatically replaced graphics flag to swap out the units. Didn't work on the Large Aliens but still was a fun mod --[[User:BladeFireLight|BladeFireLight]] 02:20, 6 January 2010 (EST)<br />
<br />
=== Aircraft in Base Defence Battlescape ===<br />
<br />
New graphics for the Interceptor and Firestorm on the battlescape. All your ships could remain in their hangers when the aliens attack your base. Don’t understand why Mythos did not do this originally.<br />
<br />
----<br />
<br />
Simply for one reason: the limit on the size of the battlescape. UFO maps are usually limited to 10000 tiles (50x50x4), on Bases you have 9600 (60x60x3), the last level one being dirt. You need 3 levels to display X-COM craft. [[User:Hobbes|Hobbes]] 14:28, 23 September 2008 (PDT)<br />
<br />
----<br />
<br />
Could you not do it but clip off the top level of the craft - leaving the ground level and 'deck' level? It would be a cool terrain area to fight in. I like the fact that in TFTD you can still see your subs during a base defence. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)<br />
<br />
----<br />
<br />
It is possible to edit the map files to include the Skyranger, but you'll have to use Xcomutil to play with that terrain and I think it would never launch during base defense missions (but I'm not sure on that - never tried editing the X-COM base terrain). [[User:Hobbes|Hobbes]] 19:25, 4 December 2009 (EST)<br />
<br />
----<br />
<br />
This could be done by creating new "hangar" map modules, each containing one of the five possible X-COM craft. Bung the modules into [[GEODATA.DAT]] at index 0C, and you're done. The catch is you can't have all craft or the MCD array will overflow. The base terrain uses ~160 tiles as it is (out of the max of 256), while the craft use about 60 each (on average). Putting them all in would take the table above 300 entries (that is to say, the game'd crash).<br />
<br />
'Cause XcomUtil already provides us with an Intercepter design made up of SkyRanger parts, I suppose the way to go would be to only implement those two craft. If you have any alien technology ships, they could either be left out ("they were fast enough to escape") or rendered as SkyRangers.<br />
<br />
It should also be noted that bases are made up of two levels, not three. Luckily, all the craft are only three levels high, so cutting out the landing gear still works. - [[User:Bomb Bloke|Bomb Bloke]] 19:56, 4 December 2009 (EST)<br />
<br />
----<br />
<br />
Very true about the MCD limit, that's why I only mentioned the Skyranger but the Interceptor could be added as well (and would not make much sense to have your first defense mission with a nice Avenger parked on the hangar while your Interceptors are being blow to bits by Battleships). The bases are 3 levels but you can only modify two of them. The game engine automatically adds a layer of 'dirt modules' either at top or bottom. Hmmm, this just gave me an idea for the wish list... [[User:Hobbes|Hobbes]] 20:29, 4 December 2009 (EST)<br />
<br />
----<br />
<br />
Both alien and X-Com bases ''are'' only two levels. There must be something screwy in your game; XcomUtil maybe?<br />
<br />
It occurs to me that removing landing gear and stuff might make it ''just'' possible to jam in the Lightning tiles as well (as the MCD requirements would also shrink slightly). That'd make it possible to add the Firestorm, too. Seems a shame to get that far then leave out the Avenger, though...<br />
<br />
- [[User:Bomb Bloke|Bomb Bloke]] 21:30, 4 December 2009 (EST)<br />
<br />
----<br />
<br />
Nevermind, I completely misread your previous post. Yes, they are two levels only, could be Xcomutil that adds the 3rd level.<br />
<br />
- [[User:Hobbes|Hobbes]] 22:30, 4 December 2009 (EST)<br />
<br />
<br />
----<br />
You may be able to get 3 levels in an X-Com Base but not 4. EU has a smaller amount of memory alocated. I dont know the limit but 60x60x4 will crash EU. TFTD has no problem --[[User:BladeFireLight|BladeFireLight]] 02:25, 6 January 2010 (EST)<br />
<br />
----<br />
<br />
I got partway through this and then decided to change my methods entirely and start from scratch. So I thought I might as well post my progress anyways, as it's already about on par with the crude TFTD implementation: You always have the same craft appear in your hanger regardless of what is (or isn't!) there.<br />
<br />
[[Image:Skyranger In Hanger.rar]]<br />
<br />
- [[User:Bomb Bloke|Bomb Bloke]] 05:40, 17 December 2009 (EST)<br />
<br />
----<br />
<br />
Hey BB, a while ago I have modded the plane terrain files so that the Skyranger appears facing east instead of south. If you want to use that one (to make it a little different) let me know. [[User:Hobbes|Hobbes]] 08:23, 17 December 2009 (EST)<br />
<br />
----<br />
<br />
Thanks, but don't worry about it for now: it'll make the MCD arrays larger still, so I'll consider it when I get all the other stuff done. <br />
<br />
- [[User:Bomb Bloke|Bomb Bloke]] 17:01, 19 December 2009 (EST)<br />
<br />
----<br />
<br />
The completed mod is now included in my toolpack. As usual, I've only done cursory testing on it, but I'm pretty sure it's stable enough. <br />
<br />
- [[User:Bomb Bloke|Bomb Bloke]] 06:40, 20 January 2010 (EST)<br />
<br />
=== Fixed firing TUs ===<br />
<br />
Something that always bugged me was how the weapons used percentages for firing TUs. It doesn't make sense that the faster a soldier got, the longer it would take to fire a weapon.<br />
: This is because you can't fire an automatic weapon any faster than it will shoot. However, it otherwise makes minimal sense, as you point out. I suggest two alternative solutions. Firstly, that only automatic fire modes use a fixed percentage of a soldier's time units, and other modes use a fixed number of TUs. This would entail the newer soldiers spraying and your most elite taking fast, selective single shots. The alternative is that each firing mode for each weapon entails its own formula (revealed in the UFOpaedia but essentially hidden during the battlescape) along the lines of "X% of TUs + Y TUs". Snap fire would be a low % of total plus a low fixed cost, Aimed would be a low % of total with a high fixed cost, and Auto would be a high % of total with a low fixed cost. While this is somewhat complex, in-game you wouldn't have to worry, and it accounts for what can be reduced (i.e. aiming speed) and what can never be improved by a soldier (i.e. cyclic rate of fire or time for a missile to lock). [[User:Stubbs|Stubbs]]<br />
:: These observations are very sensible. However we also need to consider the impact on game balance. If you implement this in an even-handed way, alien rates of fire will increase as they have high TUs. Or, if you fudge it so that alien rates of fire remain the same, then X-Com's advantage will increase as the game progresses. Neither of these are desirable. It would be extremely hard to implement this and still maintain game balance. [[User:Spike|Spike]] 08:41, 1 September 2009 (EDT)<br />
:::Each turn has the exact same duration, but is divided into TUs separately for each soldier. That's a simplification that works well in a turn-based game and reflects the fact that a soldier is fast or slow. However, weapons need to be aimed and will not fire faster than normal, thus they require a fixed percentage of the turn duration. In other words, soldiers gain movement speed, but fire at the same rate. This is both desirable and logical, just not self-explanatory. Thus, I would definitely stick to how TUs consumption is solved currently. [[User:mingos|mingos]]<br />
<br />
=== In-flight Interception ===<br />
<br />
Yes, I know that this idea is nigh-impossible, but I was thinking, wouldn't it be awesome to infiltrate a battleship, kill the aliens inside and escape, with the geoscape being shown zooming past underneath? Also, in a similar vein to the "aliens dust off after 3 turns" idea, after killing the aliens ( or blowing up the power cores, maybe?)you would have to get as many troops as possible to the drop ship in 3 turns(in retrospect I guess that you could only do this with the Lightning because of the doors) or the ship crashes and all troops not in the dropship are missing in action. Yes, this idea is impractical and would be really hard to program, but the idea of blowing a UFO up from the inside just seems epic to me. [[User:WolfenMage|WolfenMage]]<br />
<br />
=== Impose cost to using Psionic attacks===<br />
<br />
I think everyone agrees Psi attacks are too powerful. I would propose to impose a cost to using Psionic attacks. This could take the form of decreasing the physical stats after using a PSi attack (after all all: the psionic races are physically weak). This could for example lead to a soldier becoming a weakling or even fainting or dying from using psi-attack. Another possibility is to decrease mental stats (in this case the ratio would be that humans are not really being adapted to psi: you could be expected to go crazy playing mind games) leading to a decrease in psionic powers or maybe panicking or beserking the soldier using psi. Together with limiting psi attacks of MCed units proposed elsewhere this would rebalance the later game somewhat... [[User:Emphyrio|Emphyrio]] 07:22, 9 August 2010 (EDT)<br />
<br />
: [[UFO Extender]] implements some limitations on X-Com use of Psi, making attacks Line of Sight based. [[User:Spike|Spike]] 03:48, 20 September 2012 (EDT)<br />
<br />
=== Make losing a base less costly ===<br />
<br />
My friends would often quit and reload after losing a base because it was so costly. It should definitely be a kick in the teeth, but even the game text suggests some ways you can recover:<br />
1. Scientists and engineers have already been evacuated -- on a defense loss, let me transfer them to bases with open living quarters.<br />
2. Likewise, move any ships at that location to another open hangar. (Maybe doing this requires that I have gotten advanced warning of the attack.)<br />
<br />
: You can do all of this immediately prior to the attack, which is a small trade off if you win and a great benefit if you lose. I'm not sure you should be able to do it for free, at the instant of losing, and keep your options open until the last second. I think the game is fair and balanced as is. Well OK, maybe an option to do transfers after seeing the Base Attack screen, but before combat, would be user-friendly - it is sometimes hard to get to the Base screen fast enough to perform an evacuation before the base assault starts. [[User:Spike|Spike]] 03:48, 20 September 2012 (EDT)<br />
<br />
=== Have captured aliens be present in base defense ===<br />
<br />
The alien containment unit could have all my captured aliens present in jail cells. But this requires other things to happen first.<br />
<br />
On one hand, I think it would be cool if the attackers can rescue their friends and bring them into battle. So aliens would need to be able to pick up weapons. Psi powers would suck -- it would seem nuts if a captured ethereal suddenly started brainwashing my crew right away. Maybe they all start with -50 stun, or maybe (can we do this?) psi-powered enemies have it disabled if they start the game captured.<br />
<br />
Another issue is that each containment supposedly holds 10 aliens according to the game text, but there is no real limit in the game. Maybe we fix that 10-limit bug (which would mean that we would need to be able to kill overflow aliens), maybe we only take the first 10. And it definitely runs into tile issues.<br />
<br />
Would the enemies in containment need to be killed/re-stunned to end the mission? Maybe being in a locked jail cell automatically counts as captured.<br />
<br />
:The problem here is that Alien Containment works entirely differently from how it's stated. Alien Containment is instead a file of aliens captured with, IIRC, 50 slots, and it is shared across ALL bases. So you'd have to figure out some way to change the file to flag aliens as 'belonging' to a specific base. And of course, on higher difficulty modes, the aliens and their terror units already spawn most or all of their UNITPOS.DAT slots anyways. [[User:Arrow Quivershaft|Arrow Quivershaft]] 08:19, 12 January 2012 (EST)<br />
<br />
=== Grenade Launchers ===<br />
Is the US army being obstructive? Why can't we buy M79s or M203s? Shooting a grenade through a wiindow/gap is sorely missing, because of the need to arc. There is the small launcher, but that stuns. 30mm grenades come in HE, WP, Smoke, Incendary, AP and flechette (think shotgun with a 30mm bore!)<br />
<br />
:They're not being obstructive, in fact they gave us automatic and semi-automatic grenade launchers, which we call the Auto Cannon and Heavy Cannon. See [[Realistic Equivalents#Weapons]]. [[User:Spike|Spike]] 17:46, 20 March 2011 (EDT)<br />
<br />
=== 80 item limit ===<br />
The space available should be treated more logically; using the system base stores does. At the moment craft treat 1 heavy weapon as the same size as 1 grenade.<br />
<br />
== Miscellaneous ==<br />
<br />
===Fix All Bugs===<br />
<br />
Oh no [[User:Seb76#Bug Fixes|Seb76]] already did this! :) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)<br />
<br />
= I Wished (And My Wish Came True)... =<br />
<br />
== Geoscape and Strategic ==<br />
<br />
=== Fuel Ready always ===<br />
[[User:Seb76#Mods|Implemented - here]]<br />
<br />
I wish that I could send out craft at any fuel or ammo level. Normally craft can only leave a base if fully "ready". Craft is only "ready" at 100% fuel (or 0% fuel using an exploit) but there's no logical reason why a full tank and full ammo is required. Fully repaired... that's fine. I can live with pilots refusing to fly a plane missing a wing even if it means England is lost to aliens. 15 hours to fill a tank? Retarded but I can live with that too if I can send out a craft at 20% fuel.<br />
--[[User:Brunpal|Brunpal]]<br />
<br />
:Actually, many modern aircraft '''do''' require the fuel tanks to be full on takeoff, and fairly empty on landing. The weight of the fuel is figured into the takeoff aerodynamics, and the tank being full prevents fuel 'sloshing' in the tanks and not actually making it to the engine. (Conversely, many aircraft need to have dispensed of much of that fuel weight before landing.) This holds for most runway-takeoff craft, but may not apply to anything with VTOL capacity; I'm unsure there.<br />
<br />
:I do agree that non-full weapons aren't as critical, though. But from a logical standpoint, most modern aircraft should not be launched on an empty fuel tank. I also should noted that an Elerium-fueled craft with [[Known_Bugs#Elerium-fueled_Craft_Bug|50% fuel or less remaining]] will automatically return to base, regardless of distance from base. Of course, given that such craft fuel up quickly, its less of an issue there. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:05, 7 August 2008 (PDT)<br />
<br />
:Hum, maybe you can try [[User:Seb76#Mods|this]]? [[User:Seb76|Seb76]] 13:01, 8 August 2008 (PDT)<br />
::Thanks! But I can't try it. I've not been able to get my copy of Xcom to run properly except on a Win98 install. VC2008 requires a more modern OS. I'm sure I could ''eventually'' figure out a way to get it running, but I tried once and wasted too much time before giving up.--[[User:Brunpal|Brunpal]] 14:45, 8 August 2008 (PDT)<br />
:AFAIK VC2008 binaries should run OK on Win98 as long as the runtime is deployed. Anyway, the loader uses CreateRemoteThread API which is not available in Win98 so don't even bother. '''However''', you can manually patch the binary if you want ;-) Data to patch (all in hexadecimal):<br />
offset 0x41752: 2A0075 -> 18207C<br />
:HTH. [[User:Seb76|Seb76]] 14:56, 8 August 2008 (PDT)<br />
<br />
<br />
<br />
===Base Build Stacking===<br />
[[User:Seb76#Base Building Stacking|Implemented - here]]<br />
<br />
At the moment you are only allowed to build next to a finished module, and you aren't allowed to plan ahead in your base construction. It would be nice to at least be able to plan more than one phase of construction in advance. This would be pretty easy to implement. There is no need to code any new "queuing system". Just place the new module next to an existing under-construction module, but increment the build time to the normal build time + the time remaining on the under-construction module (the lowest time remaining that would make the square you are building in, a legal square to build in). As a premium for build stacking, you have to pay the costs up-front. As with normal construction, all costs are non-refundable if you change your mind. (There would probably need to be some on-screen feedback for how long the module would take to build, before you were committed to building it.) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)<br />
<br />
See also: Discussion on [[Talk:Wish List|Talk page]].<br />
<br />
=== Keyboard shortcuts at bases ===<br />
<br />
I wish we had (customised, maybe?) keyboard shortcuts at the base screen. Numbers (at the "base information" screen as well) would switch bases, R for research, E for equip craft, T for transfer, M for manufacture, S for soldiers, B for build new base, P for purchase+recruit (or "B" for "buy" - let people double-bind if they need it), I for base information. The doubles (soldiers/sell+sack) could be solved by using the key under the primary one (x for sell+sack). - n (16:26, 16 Aug 2010 (GMT+1))<br />
<br />
:Keyboard shortcuts are implemented in [[UFO Extender]]. [[User:Spike|Spike]] 03:48, 20 September 2012 (EDT)<br />
<br />
<br />
=== Soldier table ===<br />
<br />
Soldiers should be listed in a sortable table, so I can sort them based on rank, ship order, firing accuracy, psi skills, in psi training, etc. If I want to find out my best shooters, it should be a very fast operation.<br />
<br />
At a more advanced level: do it across bases; have filter options; sort based on formula (so I can find the soldiers with the best reaction+firing, or the best psi strength + psi skill).[[User:Lobster Dan|Lobster Dan]] 13:18, 25 January 2011 (EST)<br />
<br />
:Sortable soldier list is implemented in UFO Extender and XComUtil. [[User:Spike|Spike]] 03:48, 20 September 2012 (EDT)<br />
<br />
<br />
== Battlescape and Tactical ==<br />
<br />
=== Equipment Management ===<br />
<br />
==== Soldiers remembers THEIR equipment ====<br />
[[XcomUtil|Implemented - here]]<br />
<br />
I wish soldiers remembered what equipment they LAST used and start with that gear when they land. Normally soldiers grab various gear and put lots of crap on their belt. I put most things on the shoulder slots, and keep many things spare things on the ship just in case I need them. (I only want IN rounds if it's night. Stop picking them up before I shoot you in the back!) Takes forever to sort out the gear so the weakling isn't carrying all the rockets etc.<br />
--[[User:Brunpal|Brunpal]]<br />
<br />
:This is already available in [[XcomUtil]]. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:07, 7 August 2008 (PDT)<br />
<br />
====Access to Stats screens during equipment allocation====<br />
[[User:Seb76#Equipment Screen|Mostly implemented - here]]<br />
<br />
In Battlescape you can get to Stats screens by right clicking on one of the unit's status bars. However you can't do this in the Equipment screen. Things like Statstrings and (even more so) [[User:Seb76|Seb76]]'s modified Equipment screen with actual/max weight help. But it would be nice to be able to see exact stats. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)<br />
<br />
<br />
===Decrease Accuracy for targets out of sight===<br />
[[User:Seb76#Range_Based_Accuracy|Brilliantly implemented - here]]<br />
<br />
How come you can easily shoot on something you do not see?<br />
I find the over-used scout-sniper tactic is a cheap exploit of the X-COM. The tactical game should describe a combat, not a cowardly shooting practice. It would turn into a nice feature, if there would be a penalty of (let us say) -20% to the accuracy of anybody who is firing on a target out of his current sight. This can greatly enhance the tactical depth of the game. (Seb around? ;-) --[[User:Kyrub|Kyrub]] 14:20, 30 August 2008 (PDT)<br />
<br />
...discussed [http://www.ufopaedia.org/index.php?title=Talk:Wish_list here]<br />
<br />
===Enough Smoke===<br />
[[User:Seb76#Mods|Implemented - here]]<br />
<br />
It would be nice to increase the current limit on smoke/fire hexes. This is due to their locations being stored in a small, fixed length array. In effect you can only get about 3-4 smoke grenades worth of smoke or fire on the map at the same time. Being able to use smoke liberally would really open up new tactics. At the moment all you can really do is cover the LZ in smoke when you exit the transport, and maybe cover one advance over open ground. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)<br />
:I did something for that on my loader. Heavy testing is required because it is hard to be make sure smoke still works as before (testing is the hardest part actually). [[User:Seb76|Seb76]] 14:09, 18 September 2008 (PDT)<br />
<br />
<br />
=== Alien AI ===<br />
<br />
====Aliens better with explosions====<br />
Partly implemented [[User:Seb76#Bug Fixes|here (waypoint bug fix)]] and [[User:Seb76#Mods|here (Blaster drift)]]. ''(Possibly move this to talk, as notwithstanding these 2 bugs, apparently the Aliens are fairly safe with lethal explosives.)''<br />
<br />
<br />
I wish that aliens using grenades or blaster bombs or stun bombs (anything that goes boom) would use more sense. They should not want to use items that go boom when they are guaranteed to be caught in the blast radius. The alien can use grenades and blaster bombs by going out of line of sight before the explosion goes off. That may not save them if the explosion blows out the walls. At least it would be less stupid then firing a point blank blaster bomb vs taking 5 steps and setting up another waypoint. Units with morale above 100 or mind controlled should still be suicidal as normal.--[[User:Brunpal|Brunpal]] 13:55, 19 September 2008 (PDT)<br />
<br />
: Actually, the aliens are quite careful with their explosives, they just seem to be prone to the occasional accident. They're not likely to fire off a blaster or grenade too close to them - as evident by the strategy where if you see an alien with a BB but can't shoot back, the safest place is to stand next to it. The blaster bomb vertical waypoint fix in the loader also eliminates the 'oops' moments where they plot a vertical right angle too close to themselves and there just happens to be a wall to the south. However, they do need more care with stun bombs as you often get to see an alien fire a stun bomb point blank into a HWP parked next to it. But I guess we are talking about three different weapon types here, so they may not be as careful with a standard firearm as they are with grenades and the BB. Wish the Apocalypse aliens at least had as much sense as the UFO/TFTD aliens. In that game, they're utterly psychotic with explosives and ignore nearby allies. -[[User:NKF|NKF]] 14:34, 19 September 2008 (PDT)<br />
<br />
<br />
<br />
=== Mind Controlled then Hostile ===<br />
If you mind control a human (civilians) 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.<br />
: Now fixed by the Seb76 loader [[User:Spike|Spike]] 19:13, 11 December 2009 (EST)<br />
<br />
=== Mind Controlled then MIA ===<br />
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).<br />
: I believe XComUtil fixes this MIA issue. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)<br />
:: XcomUtil 9.6 also restores all DOA if you win to. Not what was intended. This feature has been removed as of 9.7 until I can fix it. --[[User:BladeFireLight|BladeFireLight]] 02:27, 6 January 2010 (EST)<br />
: Now also fixed by the Seb76 loader [[User:Spike|Spike]] 19:13, 11 December 2009 (EST)<br />
<br />
=== Open Doors But Don't Enter/Exit ===<br />
<br />
Open doors like they do in TFTD (I know this is mentioned above with the good stun grenades idea).<br />
: Now fixed by the Seb76 loader [[User:Spike|Spike]] 19:13, 11 December 2009 (EST)<br />
<br />
=== Warm Grenades===<br />
<br />
Currently when you set the timer on a grenade (or HE pack), the timer runs down every turn regardless of whether the grenade is worn, held, or dropped. Then, when the timer runs out, it explodes unless it is held or worn. There is no real grenade or explosive that works this way. Once the timer (fuse) starts running, they explode regardless. However for most hand grenades, the timer (fuse) doesn't start until after you throw/drop the grenade. It would be nice to have both of these real world behaviours, and lose the game's default behaviour. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)<br />
<br />
: Technically the way the game implements grenades, they don't have a timer. At least, not as such. When you set a grenade, the game just assigns it a turn to blow up on. Once the turn has passed, the game checks to see that it's on the ground and blows it up if it is, otherwise it doesn't. I believe Seb76 has already addressed this in his patches where there's an option to make grenade blow up regardless whether they are in inventory or otherwise the moment the timer is set. X-Com Apocalypse does a good job of this. The moment the grenade is so much as moved after the timer is set, it counts down. - [[User:NKF|NKF]] 23:01, 13 September 2008 (PDT)<br />
<br />
:: To simulate an actual timer, you would need to do something like: Every turn that a primed grenade is being held by a unit during the "explode" check, increment by +1 the turn when that grenade is going to explode. [[User:Spike|Spike]] 19:10, 14 September 2008 (PDT)<br />
:::I think I would change quantity2 ([[OBPOS.DAT]]) to a countdown instead of a turn, and use quantity3 as a flag indicating if the count has started. This flag is set any time a turn ends and the grenade has no owner. Taking it back in your hand once the timer has started won't help and the thing must be thrown... quantity2 is decreased if quantity3 is set, and the grenade blows up as usual. [[User:Seb76|Seb76]] 01:35, 15 September 2008 (PDT)<br />
<br />
: That would be great. It would be exactly consistent with a 'spoon' type hand grenade. The timer only starts when you release the grenade, but after that it explodes at a definite time regardless of whether you pick it up or not. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)<br />
<br />
Implemented in [[UFO Extender]]. [[User:Spike|Spike]] 03:48, 20 September 2012 (EDT)<br />
<br />
<br />
<br />
= Category =<br />
The page needs to be listed in various categories, which ones I don't know. Also links on other pages to this one would aid people finding it.<br />
<br />
: OK how about this one: [[User:Spike|Spike]] 12:21, 3 September 2008 (PDT)<br />
<br />
[[Category:Oddities and bugs]]</div>
Spike
https://www.ufopaedia.org/index.php?title=Talk:TFTDextender&diff=40396
Talk:TFTDextender
2012-10-26T21:13:07Z
<p>Spike: /* Items on transport floor lost on Abort */ Object table size difference?</p>
<hr />
<div>=Questions or Comments=<br />
'''A place to provide feedback or ask questions:'''<br />
<br />
The zip archive does not seem to include an .ini file. Where do I get the .ini file from? <br />
:: Oh hang on. It looks like the latest version of the zip file does not include the .ini file. When I go back to the previous version of the zip file, I can see the .ini file. [[User:Spike|Spike]] 17:45, 6 September 2012 (EDT)<br />
<br />
:::''The latest release is a patch, which means there are no new additions to the INI. I don't include it in patches usually so that those who already have the prior release don't have to reconfigure their current INI. It may not seem like a big deal now but earlier, I was releasing fixes almost on a weekly basis and so I still continue with that idea.''[[User:Morgan525|Tycho]]<br />
<br />
== Bug Reports ==<br />
<br />
=== Crash when starting a landed/crashed USO battle ===<br />
<br />
:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."<br />
<br />
''Interesting. I had someone report a similar thing when they were starting their first instance of the battlescape on a new install of the game. I looked into it and the game generated some bad data. When he let the UFO take off and land again, the battle started with no problems..''<br />
<br />
:It's [[Known_Bugs_(TFTD)#Geoscape_Bugs|a bug I've reported before]] (before TFTD Extender even existed), so it's not specific to TFTDExtender / UFOExtender. What is happening is the Alien Sub is landing on land, and the Triton is also attempting to land on land. Probably the game crashes when it fails to generate the appropriate terrain type? So the GEOSCAPE map/terrain data must be corrupted. I've seen three examples of this. In a couple of cases the landing site is clearly inland, by hundreds of kilometres. In some cases it's right on the sea/land boundary and hard to tell. I have two save games that reproduce the bug now. From memory, the previous cases all happened around North Africa, like these present cases. [[User:Spike|Spike]] 08:31, 9 September 2012 (EDT)<br />
<br />
:''I think the problem is that there is no database to reference what type of terrain to load. EU would reference this based on map coordinates. Since USO aren't usually engaged over land, the map generator can't get an appropriate tileset for the location in these cases.-[[User:Morgan525|Tycho]]''<br />
<br />
=== Cannot build Leviathan ===<br />
<br />
Hi Tycho. I've just researched Leviathan in my TFDExtender game but cannot manufacture it! I have enough resources (Plastics, IBA, ManNav), 3 workshops, more than 100 technicans and one empty sub pen. But when starting the Leviathan manufacture task I cannot assign any technicans to it. I press the "up" button, and there are no reaction to this. I can build Manta, but not Leviathan. Don't you know what is it? [[User:PavelB|PavelB]] 06:55, 2 October 2012 (EDT)<br />
<br />
: Double check that you have sufficient cash to start the project, iirc $600K or so. That matches this symptom. Also that you have enough workshop space available (Leviathan needs a lot of space). Failing that, cancel all existing manufacturing projects, then retry. Failing that you could try reducing Technicians below 100 but that's taking us into Bug territory. [[User:Spike|Spike]] 07:17, 2 October 2012 (EDT)<br />
<br />
:: Resources are 100% enough. I've launched "Terror from the Deep.exe", loaded this saved game and started manufacturing Lev without any problems. I've saved this variant with Lev being manufactured and then loaded it from "TFTDextender.exe". As a result the process was okey, but I could only decrease the number of technicans working on it, not increase (even after decreasing!). That is: with 64 technicans had been assigned, I've pressed the "down" button, and the number changed to 63. But then I was unable to revert it to 64 by pressing "up" button: it didn't work! [[User:PavelB|PavelB]] 07:57, 2 October 2012 (EDT)<br />
:''I'll check into it. Although, I can't understand how changes to the research tree would affect production. Unless it has something to do with the autoproduce feature?''<br />
:'''This problem may be fixed with the same patch that fixed the production materials being deducted from the wrong base. Can anyone confirm?'''- - [[User:Morgan525|Tycho]] 23:12, 17 October 2012 (EDT)<br />
:: If I try to replicate PavelB's situation, I am able to build a Leviathan with no problems using the latest build. However I am also able to build a Leviathan using the 1.05p1.1 build. So I'm not able to replicate his original problem unfortunately. [[User:Spike|Spike]] 19:18, 19 October 2012 (EDT)<br />
<br />
== Minor Bugs ==<br />
<br />
=== Weightless Ammo Bug ===<br />
<br />
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)<br />
<br />
''From what I understand right now, I am pretty sure I can arrange it so that weapons are not automatically loaded and soldiers would be given an extra clip. Feedback?''<br />
: By an extra clip, you mean the clip/ammo that would have been loaded into the weapon is instead carried by the soldier? And for carried clips, the encumbrance effects are correct. For me anyway, in order of most benefit, the options would be<br />
:# Fix the root cause of the bug (ensure all relevant object locations and "contains/contained in" pointers are set during automatic clip loading) so that automatically loaded clips correctly affect encumbrance <br />
:# As a workaround, don't load ammo for multi-ammotype weapons (Heavy Cannon/Gas Cannon, Auto-Cannon/Hydrojet Cannon, Rocket Launcher / Torpedo Launcher). These are the weapons for which the bug has the greatest impact, since it imposes a 'cost' of switching away from the automatically-loaded ammo (usually AP or Small Rocket/Torp). With single-ammotype weapons, there's never any need to change the clips before combat. <br />
:# As a workaround, don't load ammo for any weapons. This avoids the 'switching cost' issue but does impose a fairly significant logistics overhead on each combat, to go through and manually load all clips. Plus the risk that you forget to load a weapon and only find out at a critical moment. :) This is for the "purist" who wants to make the game harder.<br />
:If it's tricky to fix the root cause, any of the other two options would be helpful. Suggested text:<br />
:* [Multi Ammo Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. Weapons using multiple ammo types (Heavy Cannon, Auto-Cannon, Rocket Launcher / Gas Cannon, Hydrojet Cannon, Torpedo Launcher) will not be pre-loaded before combat. You will need to load these weapons manually during the pre-combat Equip phase. This will significantly affect the heavy weapons ammunition load your squad can carry into combat without suffering encumbrance penalties, thus making the early game harder.<br />
:* [All Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. This option overrides the previous option. No weapons will be pre-loaded before combat. You will need to load all ammo manually during the pre-combat Equip phase. This will significantly affect the ammunition load your squad can carry into combat without suffering encumbrance penalties, making the early game harder.<br />
:[[User:Spike|Spike]] 05:10, 21 September 2012 (EDT)<br />
::''I found the source of the problem: None of the subroutines for inventory consider the clips in weapons so their entries in OBPOS.DAT are never updated. So when clips are autoloaded at the beginning of each battle, they have no owner. I've got the code to sync the ownership of clips with the weapon they are loaded into at the beginning of each battle and to update the clips when changed in inventory management.-''[[User:Morgan525|Tycho]] 19:00, 19 October 2012 (EDT)<br />
::: That is just awesome! :D [[User:Spike|Spike]] 22:36, 19 October 2012 (EDT)<br />
<br />
=== MIA Bugs ===<br />
<br />
==== Supernumary MIA on Abort ====<br />
<br />
I Abort a mission with 8 Aquanauts and get the confirmation message "8 Aquanauts inside craft, 2 outside". No one has been stunned or MCd. I did have two aquanauts, only, outside, but they have moved back inside the transport. Very odd. Saved Equipment was enabled. [[User:Spike|Spike]] 11:06, 5 October 2012 (EDT)<br />
<br />
:''How many Aquanauts did you have in total?- -''[[User:Morgan525|Tycho]] 02:54, 11 October 2012 (EDT)<br />
:: I started the mission with only 8 Aquanauts and they all survived. Only two had even been outside the transport (quite an unusual situation). However I can't reproduce this bug, so please ignore it unless/until I can reproduce it. :) [[User:Spike|Spike]] 06:48, 17 October 2012 (EDT)<br />
<br />
==== Crewed Flying Sub Lost on Abort ====<br />
<br />
Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)<br />
<br />
:Presumably the 3 aquanauts in the craft were not stunned or mind controlled on the Abort turn? [[User:Spike|Spike]] 16:37, 21 October 2012 (EDT)<br />
:Right, they are not stunned (or dead) and they are under your control. And they are definitely in the sub. OK this is similar to a minor bug I have seen before - see [[#Supernumary MIA on Abort|preceding item]]. On your pre-abort confirmation screen it says "3 units in craft, 9 units outside". I've had a similar issue before. It's double counting your aquanauts as being both inside and outside the craft on the confirm screen, since you only have 9 units (8 and 1 tank) in total. On actual abort you incorrectly get 9 MIAs (including the tank presumably) and I guess that's why you lose the sub. Interestingly, the 3 affected aquanauts look like they never moved from their original positions, is that true? I believe when I've had similar problems before, it related to aquanauts who had never left the sub / never left their initial positions. We will have to see if Tycho can get to the bottom of this one. [[User:Spike|Spike]] 16:51, 21 October 2012 (EDT)<br />
::Yes, that's true - those 3 haven't moved from their original positions. --[[User:Player701|Player701]] 17:19, 21 October 2012 (EDT)<br />
<br />
:''I found the nature of the issue here: On one hand, all parts of the tank are being counted separately but then the End of Battle routine calculates the correct number of units but when it goes to locate the units on the battlefield, the three other parts of the tank are being tallied and thus the last three aquanauts are not checked since the 4 areas of the tank are first in the UNITPOS.DAT file.-[[User:Morgan525|Tycho]] 09:47, 24 October 2012 (EDT)''<br />
<br />
==== Stunned Carried Aquanauts MIA on Abort ====<br />
<br />
While you are looking the EOB script, I noticed one more anomaly. I'm not sure if this is an original bug or an Extender bug. If you are carrying a stunned Aquanaut in the transport at the time of Abort, the stunned Aquanaut is lost (MIA). You have to drop the stunned Aquanaut on the floor. Probably this is because the position of the Aquanaut has not been updated and is still pointing to where they were stunned, not to the location of the carrying Aquanaut. [[User:Spike|Spike]] 04:49, 27 September 2012 (EDT)<br />
<br />
:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. At least it is manageable: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)<br />
<br />
=== Items on transport floor lost on Abort ===<br />
<br />
I went in to a mission with ten Sonic Cannons and came back with 3, despite retrieving them from the battlefield and dumping them on the transport floor. I only had 3 aquanauts on the transport armed with Sonic Cannon at the time of abort. The rest were stunned or unarmed. I also dumped half a dozen corpses and some alien items on the transport floor and I don't think those made it back to my base either. The transport was operating from base 2 rather than base 1, in case that's a factor. This may be an original bug of course. I just read through the multiplayer TFTD LP on StrategyCore, and they reported missing equipment on a lot of missions. I can go back and check if the missing equipment was on abort missions rather than victory missions. Sorry not to provide more specifics at this time but it was a hard mission and not exactly a controlled experiment. ;) [[User:Spike|Spike]] 21:35, 23 October 2012 (EDT)<br />
: I tried to reproduce this in the unmodified game without success, controlling for aquanauts being stunned/not stunned, inside/outside transport, stunned inside/outside transport. I didn't control for reloading the game, that sometimes causes glitches. I will retry with the Extender next and see if that reproduces anything. [[User:Spike|Spike]] 21:06, 24 October 2012 (EDT)<br />
Here's another thought. The problematic game was a Colony Assault which has a lot of objects in the object table. As the missing objects were created (corpses) or dropped (weapons) after the game started, they could be a long way down the object table. Now, doesn't TFTD have a bigger object table than EU? Maybe the TFTDextender is only recovering items from a sub-section of the TFTD object table? [[User:Spike|Spike]] 17:13, 26 October 2012 (EDT)<br />
<br />
=== Weight Display in Inventory not Localised ===<br />
<br />
At least when I run the game in German, it comes up as "Weight" and not something like "Gewicht". Reactions comes up ok as "Zeitwerte". [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
<br />
:''There is no entry in the text DAT files for "weight". Seb had to add the text string for it into his subroutine. Thanks for pointing it out.'' [[User:Morgan525|Tycho]]<br />
<br />
== Save Equipment not working? ==<br />
<br />
With "Save Equipment" option enabled, the soldiers' loadout at first was always like this: grenade in leg slot, clip in backpack - and it didn't change on the next mission, despite the fact that I re-equipped the soldiers correctly (grenades and clips on the belt). When I manufactured Gauss Rifles and issued them to my soldiers, it got even worse - none of the soldiers got clips, and two of the rifles were unloaded. Next I upgraded to Sonic-Blasta Rifles and now nothing, except some grenades (still in leg slots), is issued to the soldiers at all. "Save Equipment" was known to work in UFOExtender, did something get broken? --[[User:Player701|Player701]] 09:18, 21 October 2012 (EDT)<br />
<br />
:''Yes. Something is broken but not by the Extender. I haven't modified anything in the save equipment code, except datapoints and offsets that were necessary to match it to the executable and changes in the DAT files. Many subroutines, their order of execution, or the variables were modified in the TFTD game code. Problems resulting from this are difficult to resolve since it requires finding what changed in the game code and then determining what changes are needed to get the UFOextender code to work. See the discussion on problems with the OBDATA mod about the final source of the problem and its solution.-[[User:Morgan525|Tycho]] 20:03, 21 October 2012 (EDT)''<br />
<br />
:: Would you suggest that everyone disables Save Equipment for the time being, in TFTDextender? [[User:Spike|Spike]] 07:44, 24 October 2012 (EDT)<br />
<br />
:''It couldn't hurt. I believe that TFTD has its own form of autoequip and part of the solution will probably require that I disable it. Something similar happened to the "stunned units are KIA" mod from UFOextender: TFTD has its own version that conflicted but, since it worked well, I only needed to add code to update the unit's location so the corpse would appear in the right place.-[[User:Morgan525|Tycho]] 22:38, 24 October 2012 (EDT)''<br />
<br />
:: I just did a few tests in raw TFTD (Steam CE) and the auto equip function is pretty basic: Give everyone a loaded weapon in what is probably reverse OBDATA.DAT order, then dish out any extra clips, grenades etc. Are you thinking that the Save Equipment efforts of TFTDextender are then being overwritten or partly overwritten by the existing TFTD auto equip function? I guess that would make sense. [[User:Spike|Spike]] 11:01, 25 October 2012 (EDT)<br />
<br />
=Resolved Problems=<br />
<br />
===<s> Executable directive </s>===<br />
''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)<br />
<br />
=== <s>Extra Artefacts Reported</s> ===<br />
''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)<br />
''This will be fixed in the next release.-''[[User:Morgan525|Tycho]] 03:00, 13 October 2012 (EDT)<br />
: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
===<s>Manufacturing Projects Minimum Production</s> ===<br />
<br />
In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''<br />
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)<br />
<br />
Tested - If I reduce the production quantity of a current production run to less than what as already been produced, the display completion time changes (incorrectly) to 'Indefinite', but production ends after completion of the next unit. So if I start by producing 10 units, wait until I have produced 2, then reduce the quantity to 2 (or probably 1), production stops after 3 units. Thies basically replicates the pre-existing behaviour when using the down arrow on the Quantity, so there has been no loss of functionality with your Mod. Also, Autosell and Autoproduce work normally when applied as changes to an existing production run. The only thing is I can't distinguish them on the Manufacturing display - both say 'unlimited' quantity and 'indefinite' period - is that intended? I suppose it makes sense, but it would be good to be able to tell which kind of production it is, *** Autoproduce or $$$ Autosell. [[User:Spike|Spike]] 08:57, 2 October 2012 (EDT)<br />
<br />
:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''<br />
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)<br />
:::''OK. Changed the output to display "$unlimited$".[[User:Morgan525|Tycho]]<br />
<br />
===<s>Stunned MC'd Aquanauts MIA on Abort </s> ===<br />
<br />
This is a subset of MC'd Aquanauts go MIA [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]. In this case Aquanauts are MC'd by the aliens, then stunned (by friendlies), then the mission is Aborted with the stunned X-Com Aquanauts aboard the transport. The Aquanauts then disappear from the roster forever. I'm not sure if it's due to Abort rather than Victory, or due to them being stunned first. <br />
::''I now have the code in place to uncontrol any creature that has been rendered unconscious. - -''[[User:Morgan525|Tycho]] 02:47, 11 October 2012 (EDT)<br />
This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
=== <s>Grenade Resistance in INI file </s> ===<br />
:''I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]<br />
<br />
<br />
===<s> Materials deducted from wrong base </s>===<br />
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''<br />
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)<br />
<br />
===<s> OBDATA / Dye Grenade mod not working? </s>===<br />
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)<br />
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
== <s>Displacer/Sonic damage fix</s> ==<br />
<br />
'' I changed the damage to be 130, same as the UFOpaedia entry.-''[[User:Morgan525|Tycho]] 03:52, 13 October 2012 (EDT)<br />
<br />
<br />
== Things that TFTDextender does not fix ==<br />
<br />
Just more or less as a note to the reader, TFTDextender does not fix some of the following things that are sometimes thought of as needing fixing (and this is probably deliberate?):<br />
<br />
* Does not fix the apparent swap of the ground map for the VERY SMALL Survey Ship (1 occupant) with the SMALL Escort (half-dozen or more occupants). So you get the VERY SMALL sub occupying about 25 squares of usable area on the Battlescape, and the supposedly larger SMALL sub occupying one square of usable area on the Battlescape, begging the question of how all those aliens got inside there in the first place. XcomUtil will fix this, as will the original patches that XcomUtil incorporates.<br />
* Does not fix the incorrect pictures for the large USO in the interception window. <br />
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]<br />
* Does not fix the Dart Gun to make it any less utterly useless. Though you can do this yourself via the OBDATA.DAT section of TFTDextender. (Suggestion: don't fix it. The useless Dart Gun is all part of the "oh no we're all gonna die" experience of the beginning of TFTD.)<br />
* Does not improve the armour and effectiveness of the basic Aqua-Jet and Gas Cannon Coelecanths (it does upgrade the Coelecanth/Gauss). (Again, suggestion: this is a good thing - XCOM should start the game hopelessly outclassed, and scramble to catch up).<br />
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.<br />
* Does not allow you to have 360 degree vision out of your sub before exiting it. (What kind of coward would want that?). XComUtil does this.<br />
<br />
= Feature Requests and Suggestions =<br />
<br />
== Useful alien species research ==<br />
<br />
Tycho, I really like this idea you proposed in the StrategyCore forum:<br />
<br />
:I'm thinking about giving a hp bonus to all aliens until Xcom performs an autopsy on the species to learn the location of their vital organs (like in the movie "Battle of LA"). This would give more importance to performing autopsies rather than just as a stepping stone to new tech.<br />
<br />
Definite +1. It would be equally valid to add to UFO Extender. I suppose it could also be implemented using Vulnerabilities (no Vulnerabilities are in effect until the Autopsy is completed), or Resistances (across-the-board increased Resistances until Autopsy is completed). If that's easier. <br />
<br />
:''The bonus to hp was an initial thought. Later, I decided against it since it would make aliens more resistant to HE and stun, which don't rely on hitting the right locations. Increasing resistances would be the most appropriate but the damage routine code is very tight and adding anything new that won't break the existing variable stack pointers is tough.'' [[User:Morgan525|Tycho]]<br />
::''A new idea for this that I recently have been toying with, would be on the damage generation routine: Most direct fire damage is 0-200%, with anything over 100% considered a "critical hit". If autopsy hasn't been preformed, then the base damage would be 0-100% and a small chance (maybe 25%) of another 0-100% for that lucky shot. With autopsy done, the game reverts back to the usual 0-200% on any hit.''<br />
<br />
::: That works. And it makes doing Alien Autopsies a no-brainer, as it should be. It is pretty much inconceivable that XCom wouldn't prioritise the autopsy of any newly encountered alien. And any player playing the game for the first time would do autopsies too. This mod will help experienced players to stop playing as if they've "seen it all before". [[User:Spike|Spike]] 10:35, 15 September 2012 (EDT)<br />
<br />
Would it also be worth adding some kind of bonus for Live Alien research? Maybe the negation of some kind of Morale penalty and/or Psi penalty? Fear of the unknown, know your enemy, that kind of thing?<br />
<br />
:''I thought about that but the game doesn't record live aliens that have been researched. When you finish research on a live alien, it only follows the routine to unlock the appropriate UFOpaedia articles and then checks to see if the finished research can unlock other topics.'' [[User:Morgan525|Tycho]]<br />
<br />
I had a further thought on this while trying to guess what your new pre-requisites are for the various armours. For now it's really cool to be guessing but once people have figured it out, well, it will be more logical but still will have 'replay fatigue'. Would it be possible to randomise the pre-requisites for a lot of the key research topics, from out of a plausible list of items (or even randomise pre-requisite topics)? That would make every game fresh in terms of the research sequence, and make the research aspect of the game more challenging and less dry & predictable. As ever, just a suggestion. :) Cheers, [[User:Spike|Spike]] 16:01, 19 October 2012 (EDT)<br />
<br />
== All Units Can "Fly" In Water ==<br />
<br />
It's very illogical that most units are stuck on the seabed in underwater missions. Please provide the option to set all units (X-Com and alien) to have "flying" (i.e. swimming) ability when underwater. This is unlikely to cause an outbreak of 3D combat, since there is no cover except at seabed level, so anyone swimming excessively or incautiously is going to get shot. It might disadvantage the aliens if their tactical map waypoints are all set on the surface. But as some of them can "fly", there is hopefully a mechanism to deal with that in the code already. For me it will just solve the frustration of being unable to swim over small obstacles or swim up a level, and being stuck or tactically limited for no sensible reason. Mag-Ion Armour remains useful as an important step in Sub Research and (if using the Everything Works on Land mod) for land use. [[User:Spike|Spike]] 11:36, 9 September 2012 (EDT)<br />
: This requires setting [[UNITREF.DAT]] byte 0x78 bit 2 for the unit (e.g. for all units on both sides). Or the in-memory equivalent of UNITREF.DAT. [[User:Spike|Spike]] 10:19, 5 October 2012 (EDT)<br />
<br />
== Aliens Pick Up Weapons ==<br />
<br />
Related to Improved Alien AI. This makes the game tougher as stunned / panicked bipedal-type aliens are no longer permanently disarmed. This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. A fix for this would be a very helpful rebalancing of both games that eliminates one of the aliens' weak spots. The existing (but unused) routine looks pretty smart and not immediately exploitable to ambush aliens using weapons as traps. <br />
<br />
: I noticed the UFO Extender source code has a 'get' keyword under the OBDATA.DAT directive that populates this field 0x2D. Is that working? [[User:Spike|Spike]] 21:03, 16 October 2012 (EDT)<br />
:''It should be. I haven't tested it out but it should work like any other OBDATA change, in theory. As long as the code in the AI routine handles this byte, it should work. I believe someone mentioned under the Geoscape.exe page that the AI routine ignores any value under 5.-[[User:Morgan525|Tycho]] 00:58, 25 October 2012 (EDT)''<br />
<br />
== General Tank Modding ==<br />
<br />
I see you are interested in modding tanks (HWPs/SWPs) and that's partly what got you into updating UFO Extender. I made some suggestions for Tank Modding myself, including some of the mechanics required to make it work via a config file such as the UFO / TFD Extender config file. For example you could have cargo carrier / ambulance / casevac tanks, you could have demolition tanks, mine thrower tanks, and of course tanks with custom weapons including dual weapons. Could you have a look here: [[User:Spike#Tank_mods]] and see if any of that makes you feel like getting creative?<br />
<br />
Thanks,<br />
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)<br />
<br />
== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==<br />
<br />
Hook the right and left weapon menus on mind controlled aliens to add in actions for their built in melee attacks (if they have them) and built in Psi/MC attacks (if they have Psi/MC Skill). Ideally add these actions to the menu, and pop up a menu, even if the alien isn't holding any weapons.<br />
<br />
This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.<br />
<br />
== Fix Interception and Navigation Course Algorithms ==<br />
<br />
Or just find the algorithms and I volunteer to fix them!<br />
<br />
=== Use Great Circle Routes ===<br />
<br />
Travel toward the target on the shortest Great Circle, rather than always travelling along lines of latitude first (like they are some kind of main bus route!). <br />
<br />
=== Use Predictive Interception ===<br />
<br />
For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.<br />
<br />
=== Show Degree Headings ===<br />
<br />
The game only ever reports alien headings as North, South, East, West, but clearly alien craft move in other directions than just these four, and clearly XCOM detection equipment is capable of resolving these finer-grained headings, since the crafts' tracks are shown correctly in the Geoscope. <br />
As a first step towards predictive interceptions, it would be great to display the alien craft's heading in degrees, eg 135 degrees for South-East. Maybe rounded to the nearest 5 or 10 degrees.<br />
<br />
== Interception Craft vs Touched Down Alien Craft == <br />
<br />
If an alien craft is touched down and an XCOM interception craft (not touched down) is at the same X/Y position, if the alien craft begins to move, immediately open the Interception window at minimum range (8km/nm), presumably with the alien attempting to get away / break off. Currently the Interception window only happens if the XCom craft is faster, which is dumb, ''even if'' the alien craft could accelerate instantly to its maximum speed. <br />
<br />
For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach. <br />
<br />
== Fun, not Funky, Fire ==<br />
<br />
An alternative option for incendiaries/phosphorous damage processing: Do process the so called 'impact' damage of an incendiary on every shot, not just at the end of the turn. But only apply it to those in the area of affect of this specific shell burst, not to all units who are standing in smoke or fire anywhere on the map. This will please fans of incendiaries/phosphorous. It's probably a balancing, rather than unbalancing, change in the relative strengths of the ammo types. Makes incendiaries/phosphorous useful for more than just illumination or desperation. Gives some use to the research topics that advise use of incendiaries/phosphorous, and the damage modifiers aliens have been assigned.<br />
<br />
== Rearming Rates ==<br />
<br />
<br />
From [[Known_Bugs_(TFTD)#Geoscape_Bugs]]:<br />
<br />
=== Craft Gauss Cannon Rearming Rate ===<br />
<br />
This weapon rearms at 10/hr but probably should be 50/hr or at least 25/hr, otherwise it is far slower to rearm than any other cannon weapon in either game. In fact it's the second slowest weapon system to rearm, slower only than AJAX...<br />
<br />
=== AJAX Rearming Rate ===<br />
<br />
An AJAX system takes twice as long to fully reload as a D.U.P. system, as a result AJAX-armed Craft have much worse operational tempo and readiness than D.U.P. armed Craft. Like we needed yet another reason to always use D.U.Ps. This is probably a design error rather than a bug, but it would be good to fix it - anything to give a more balanced set of craft weapon choices. The rearming rate should be raised from 1/hr to 2/hr. The AJAX system will then have the same operational tempo as the D.U.P. system. <br />
<br />
Could also be applied to Stingray missiles in EU 1994, as the same analysis applies to Stingray vs Avalanche.<br />
<br />
== Retaliate for Colony Assault ==<br />
<br />
See this discussion [[Talk:Alien_Retaliation#Retaliation_Triggers]]. Colony raids are a good way for the alien to lose badly, so it would be a good balancing move to create severe consequences for raiding. It is at least as sensible as retaliation for USO Assaults.</div>
Spike
https://www.ufopaedia.org/index.php?title=Talk:TFTDextender&diff=40349
Talk:TFTDextender
2012-10-25T15:02:17Z
<p>Spike: /* Save Equipment not working? */</p>
<hr />
<div>=Questions or Comments=<br />
'''A place to provide feedback or ask questions:'''<br />
<br />
The zip archive does not seem to include an .ini file. Where do I get the .ini file from? <br />
:: Oh hang on. It looks like the latest version of the zip file does not include the .ini file. When I go back to the previous version of the zip file, I can see the .ini file. [[User:Spike|Spike]] 17:45, 6 September 2012 (EDT)<br />
<br />
:::''The latest release is a patch, which means there are no new additions to the INI. I don't include it in patches usually so that those who already have the prior release don't have to reconfigure their current INI. It may not seem like a big deal now but earlier, I was releasing fixes almost on a weekly basis and so I still continue with that idea.''[[User:Morgan525|Tycho]]<br />
<br />
== Bug Reports ==<br />
<br />
=== Crash when starting a landed/crashed USO battle ===<br />
<br />
:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."<br />
<br />
''Interesting. I had someone report a similar thing when they were starting their first instance of the battlescape on a new install of the game. I looked into it and the game generated some bad data. When he let the UFO take off and land again, the battle started with no problems..''<br />
<br />
:It's [[Known_Bugs_(TFTD)#Geoscape_Bugs|a bug I've reported before]] (before TFTD Extender even existed), so it's not specific to TFTDExtender / UFOExtender. What is happening is the Alien Sub is landing on land, and the Triton is also attempting to land on land. Probably the game crashes when it fails to generate the appropriate terrain type? So the GEOSCAPE map/terrain data must be corrupted. I've seen three examples of this. In a couple of cases the landing site is clearly inland, by hundreds of kilometres. In some cases it's right on the sea/land boundary and hard to tell. I have two save games that reproduce the bug now. From memory, the previous cases all happened around North Africa, like these present cases. [[User:Spike|Spike]] 08:31, 9 September 2012 (EDT)<br />
<br />
:''I think the problem is that there is no database to reference what type of terrain to load. EU would reference this based on map coordinates. Since USO aren't usually engaged over land, the map generator can't get an appropriate tileset for the location in these cases.-[[User:Morgan525|Tycho]]''<br />
<br />
=== Cannot build Leviathan ===<br />
<br />
Hi Tycho. I've just researched Leviathan in my TFDExtender game but cannot manufacture it! I have enough resources (Plastics, IBA, ManNav), 3 workshops, more than 100 technicans and one empty sub pen. But when starting the Leviathan manufacture task I cannot assign any technicans to it. I press the "up" button, and there are no reaction to this. I can build Manta, but not Leviathan. Don't you know what is it? [[User:PavelB|PavelB]] 06:55, 2 October 2012 (EDT)<br />
<br />
: Double check that you have sufficient cash to start the project, iirc $600K or so. That matches this symptom. Also that you have enough workshop space available (Leviathan needs a lot of space). Failing that, cancel all existing manufacturing projects, then retry. Failing that you could try reducing Technicians below 100 but that's taking us into Bug territory. [[User:Spike|Spike]] 07:17, 2 October 2012 (EDT)<br />
<br />
:: Resources are 100% enough. I've launched "Terror from the Deep.exe", loaded this saved game and started manufacturing Lev without any problems. I've saved this variant with Lev being manufactured and then loaded it from "TFTDextender.exe". As a result the process was okey, but I could only decrease the number of technicans working on it, not increase (even after decreasing!). That is: with 64 technicans had been assigned, I've pressed the "down" button, and the number changed to 63. But then I was unable to revert it to 64 by pressing "up" button: it didn't work! [[User:PavelB|PavelB]] 07:57, 2 October 2012 (EDT)<br />
:''I'll check into it. Although, I can't understand how changes to the research tree would affect production. Unless it has something to do with the autoproduce feature?''<br />
:'''This problem may be fixed with the same patch that fixed the production materials being deducted from the wrong base. Can anyone confirm?'''- - [[User:Morgan525|Tycho]] 23:12, 17 October 2012 (EDT)<br />
:: If I try to replicate PavelB's situation, I am able to build a Leviathan with no problems using the latest build. However I am also able to build a Leviathan using the 1.05p1.1 build. So I'm not able to replicate his original problem unfortunately. [[User:Spike|Spike]] 19:18, 19 October 2012 (EDT)<br />
<br />
== Minor Bugs ==<br />
<br />
=== Weightless Ammo Bug ===<br />
<br />
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)<br />
<br />
''From what I understand right now, I am pretty sure I can arrange it so that weapons are not automatically loaded and soldiers would be given an extra clip. Feedback?''<br />
: By an extra clip, you mean the clip/ammo that would have been loaded into the weapon is instead carried by the soldier? And for carried clips, the encumbrance effects are correct. For me anyway, in order of most benefit, the options would be<br />
:# Fix the root cause of the bug (ensure all relevant object locations and "contains/contained in" pointers are set during automatic clip loading) so that automatically loaded clips correctly affect encumbrance <br />
:# As a workaround, don't load ammo for multi-ammotype weapons (Heavy Cannon/Gas Cannon, Auto-Cannon/Hydrojet Cannon, Rocket Launcher / Torpedo Launcher). These are the weapons for which the bug has the greatest impact, since it imposes a 'cost' of switching away from the automatically-loaded ammo (usually AP or Small Rocket/Torp). With single-ammotype weapons, there's never any need to change the clips before combat. <br />
:# As a workaround, don't load ammo for any weapons. This avoids the 'switching cost' issue but does impose a fairly significant logistics overhead on each combat, to go through and manually load all clips. Plus the risk that you forget to load a weapon and only find out at a critical moment. :) This is for the "purist" who wants to make the game harder.<br />
:If it's tricky to fix the root cause, any of the other two options would be helpful. Suggested text:<br />
:* [Multi Ammo Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. Weapons using multiple ammo types (Heavy Cannon, Auto-Cannon, Rocket Launcher / Gas Cannon, Hydrojet Cannon, Torpedo Launcher) will not be pre-loaded before combat. You will need to load these weapons manually during the pre-combat Equip phase. This will significantly affect the heavy weapons ammunition load your squad can carry into combat without suffering encumbrance penalties, thus making the early game harder.<br />
:* [All Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. This option overrides the previous option. No weapons will be pre-loaded before combat. You will need to load all ammo manually during the pre-combat Equip phase. This will significantly affect the ammunition load your squad can carry into combat without suffering encumbrance penalties, making the early game harder.<br />
:[[User:Spike|Spike]] 05:10, 21 September 2012 (EDT)<br />
::''I found the source of the problem: None of the subroutines for inventory consider the clips in weapons so their entries in OBPOS.DAT are never updated. So when clips are autoloaded at the beginning of each battle, they have no owner. I've got the code to sync the ownership of clips with the weapon they are loaded into at the beginning of each battle and to update the clips when changed in inventory management.-''[[User:Morgan525|Tycho]] 19:00, 19 October 2012 (EDT)<br />
::: That is just awesome! :D [[User:Spike|Spike]] 22:36, 19 October 2012 (EDT)<br />
<br />
=== MIA Bugs ===<br />
<br />
==== Supernumary MIA on Abort ====<br />
<br />
I Abort a mission with 8 Aquanauts and get the confirmation message "8 Aquanauts inside craft, 2 outside". No one has been stunned or MCd. I did have two aquanauts, only, outside, but they have moved back inside the transport. Very odd. Saved Equipment was enabled. [[User:Spike|Spike]] 11:06, 5 October 2012 (EDT)<br />
<br />
:''How many Aquanauts did you have in total?- -''[[User:Morgan525|Tycho]] 02:54, 11 October 2012 (EDT)<br />
:: I started the mission with only 8 Aquanauts and they all survived. Only two had even been outside the transport (quite an unusual situation). However I can't reproduce this bug, so please ignore it unless/until I can reproduce it. :) [[User:Spike|Spike]] 06:48, 17 October 2012 (EDT)<br />
<br />
==== Crewed Flying Sub Lost on Abort ====<br />
<br />
Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)<br />
<br />
:Presumably the 3 aquanauts in the craft were not stunned or mind controlled on the Abort turn? [[User:Spike|Spike]] 16:37, 21 October 2012 (EDT)<br />
:Right, they are not stunned (or dead) and they are under your control. And they are definitely in the sub. OK this is similar to a minor bug I have seen before - see [[#Supernumary MIA on Abort|preceding item]]. On your pre-abort confirmation screen it says "3 units in craft, 9 units outside". I've had a similar issue before. It's double counting your aquanauts as being both inside and outside the craft on the confirm screen, since you only have 9 units (8 and 1 tank) in total. On actual abort you incorrectly get 9 MIAs (including the tank presumably) and I guess that's why you lose the sub. Interestingly, the 3 affected aquanauts look like they never moved from their original positions, is that true? I believe when I've had similar problems before, it related to aquanauts who had never left the sub / never left their initial positions. We will have to see if Tycho can get to the bottom of this one. [[User:Spike|Spike]] 16:51, 21 October 2012 (EDT)<br />
::Yes, that's true - those 3 haven't moved from their original positions. --[[User:Player701|Player701]] 17:19, 21 October 2012 (EDT)<br />
<br />
:''I found the nature of the issue here: On one hand, all parts of the tank are being counted separately but then the End of Battle routine calculates the correct number of units but when it goes to locate the units on the battlefield, the three other parts of the tank are being tallied and thus the last three aquanauts are not checked since the 4 areas of the tank are first in the UNITPOS.DAT file.-[[User:Morgan525|Tycho]] 09:47, 24 October 2012 (EDT)''<br />
<br />
==== Stunned Carried Aquanauts MIA on Abort ====<br />
<br />
While you are looking the EOB script, I noticed one more anomaly. I'm not sure if this is an original bug or an Extender bug. If you are carrying a stunned Aquanaut in the transport at the time of Abort, the stunned Aquanaut is lost (MIA). You have to drop the stunned Aquanaut on the floor. Probably this is because the position of the Aquanaut has not been updated and is still pointing to where they were stunned, not to the location of the carrying Aquanaut. [[User:Spike|Spike]] 04:49, 27 September 2012 (EDT)<br />
<br />
:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. At least it is manageable: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)<br />
<br />
=== Items on transport floor lost on Abort ===<br />
<br />
I went in to a mission with ten Sonic Cannons and came back with 3, despite retrieving them from the battlefield and dumping them on the transport floor. I only had 3 aquanauts on the transport armed with Sonic Cannon at the time of abort. The rest were stunned or unarmed. I also dumped half a dozen corpses and some alien items on the transport floor and I don't think those made it back to my base either. The transport was operating from base 2 rather than base 1, in case that's a factor. This may be an original bug of course. I just read through the multiplayer TFTD LP on StrategyCore, and they reported missing equipment on a lot of missions. I can go back and check if the missing equipment was on abort missions rather than victory missions. Sorry not to provide more specifics at this time but it was a hard mission and not exactly a controlled experiment. ;) [[User:Spike|Spike]] 21:35, 23 October 2012 (EDT)<br />
: I tried to reproduce this in the unmodified game without success, controlling for aquanauts being stunned/not stunned, inside/outside transport, stunned inside/outside transport. I didn't control for reloading the game, that sometimes causes glitches. I will retry with the Extender next and see if that reproduces anything. [[User:Spike|Spike]] 21:06, 24 October 2012 (EDT)<br />
<br />
=== Weight Display in Inventory not Localised ===<br />
<br />
At least when I run the game in German, it comes up as "Weight" and not something like "Gewicht". Reactions comes up ok as "Zeitwerte". [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
<br />
:''There is no entry in the text DAT files for "weight". Seb had to add the text string for it into his subroutine. Thanks for pointing it out.'' [[User:Morgan525|Tycho]]<br />
<br />
== Save Equipment not working? ==<br />
<br />
With "Save Equipment" option enabled, the soldiers' loadout at first was always like this: grenade in leg slot, clip in backpack - and it didn't change on the next mission, despite the fact that I re-equipped the soldiers correctly (grenades and clips on the belt). When I manufactured Gauss Rifles and issued them to my soldiers, it got even worse - none of the soldiers got clips, and two of the rifles were unloaded. Next I upgraded to Sonic-Blasta Rifles and now nothing, except some grenades (still in leg slots), is issued to the soldiers at all. "Save Equipment" was known to work in UFOExtender, did something get broken? --[[User:Player701|Player701]] 09:18, 21 October 2012 (EDT)<br />
<br />
:''Yes. Something is broken but not by the Extender. I haven't modified anything in the save equipment code, except datapoints and offsets that were necessary to match it to the executable and changes in the DAT files. Many subroutines, their order of execution, or the variables were modified in the TFTD game code. Problems resulting from this are difficult to resolve since it requires finding what changed in the game code and then determining what changes are needed to get the UFOextender code to work. See the discussion on problems with the OBDATA mod about the final source of the problem and its solution.-[[User:Morgan525|Tycho]] 20:03, 21 October 2012 (EDT)''<br />
<br />
:: Would you suggest that everyone disables Save Equipment for the time being, in TFTDextender? [[User:Spike|Spike]] 07:44, 24 October 2012 (EDT)<br />
<br />
:''It couldn't hurt. I believe that TFTD has its own form of autoequip and part of the solution will require that I disable it. Something similar happened to the stunned units are KIA mod from UFOextender: TFTD has its own version so I removed the UFOextender code and only added code to update the unit's location so the corpse would appear in the right place.-[[User:Morgan525|Tycho]] 22:38, 24 October 2012 (EDT)''<br />
<br />
:: I just did a few tests in raw TFTD (Steam CE) and the auto equip function is pretty basic: Give everyone a loaded weapon in what is probably reverse OBDATA.DAT order, then dish out any extra clips, grenades etc. Are you thinking that the Save Equipment efforts of TFTDextender are then being overwritten or partly overwritten by the existing TFTD auto equip function? I guess that would make sense. [[User:Spike|Spike]] 11:01, 25 October 2012 (EDT)<br />
<br />
=Resolved Problems=<br />
<br />
===<s> Executable directive </s>===<br />
''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)<br />
<br />
=== <s>Extra Artefacts Reported</s> ===<br />
''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)<br />
''This will be fixed in the next release.-''[[User:Morgan525|Tycho]] 03:00, 13 October 2012 (EDT)<br />
: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
===<s>Manufacturing Projects Minimum Production</s> ===<br />
<br />
In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''<br />
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)<br />
<br />
Tested - If I reduce the production quantity of a current production run to less than what as already been produced, the display completion time changes (incorrectly) to 'Indefinite', but production ends after completion of the next unit. So if I start by producing 10 units, wait until I have produced 2, then reduce the quantity to 2 (or probably 1), production stops after 3 units. Thies basically replicates the pre-existing behaviour when using the down arrow on the Quantity, so there has been no loss of functionality with your Mod. Also, Autosell and Autoproduce work normally when applied as changes to an existing production run. The only thing is I can't distinguish them on the Manufacturing display - both say 'unlimited' quantity and 'indefinite' period - is that intended? I suppose it makes sense, but it would be good to be able to tell which kind of production it is, *** Autoproduce or $$$ Autosell. [[User:Spike|Spike]] 08:57, 2 October 2012 (EDT)<br />
<br />
:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''<br />
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)<br />
:::''OK. Changed the output to display "$unlimited$".[[User:Morgan525|Tycho]]<br />
<br />
===<s>Stunned MC'd Aquanauts MIA on Abort </s> ===<br />
<br />
This is a subset of MC'd Aquanauts go MIA [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]. In this case Aquanauts are MC'd by the aliens, then stunned (by friendlies), then the mission is Aborted with the stunned X-Com Aquanauts aboard the transport. The Aquanauts then disappear from the roster forever. I'm not sure if it's due to Abort rather than Victory, or due to them being stunned first. <br />
::''I now have the code in place to uncontrol any creature that has been rendered unconscious. - -''[[User:Morgan525|Tycho]] 02:47, 11 October 2012 (EDT)<br />
This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
=== <s>Grenade Resistance in INI file </s> ===<br />
:''I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]<br />
<br />
<br />
===<s> Materials deducted from wrong base </s>===<br />
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''<br />
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)<br />
<br />
===<s> OBDATA / Dye Grenade mod not working? </s>===<br />
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)<br />
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
== <s>Displacer/Sonic damage fix</s> ==<br />
<br />
'' I changed the damage to be 130, same as the UFOpaedia entry.-''[[User:Morgan525|Tycho]] 03:52, 13 October 2012 (EDT)<br />
<br />
<br />
== Things that TFTDextender does not fix ==<br />
<br />
Just more or less as a note to the reader, TFTDextender does not fix some of the following things that are sometimes thought of as needing fixing (and this is probably deliberate?):<br />
<br />
* Does not fix the apparent swap of the ground map for the VERY SMALL Survey Ship (1 occupant) with the SMALL Escort (half-dozen or more occupants). So you get the VERY SMALL sub occupying about 25 squares of usable area on the Battlescape, and the supposedly larger SMALL sub occupying one square of usable area on the Battlescape, begging the question of how all those aliens got inside there in the first place. XcomUtil will fix this, as will the original patches that XcomUtil incorporates.<br />
* Does not fix the incorrect pictures for the large USO in the interception window. <br />
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]<br />
* Does not fix the Dart Gun to make it any less utterly useless. Though you can do this yourself via the OBDATA.DAT section of TFTDextender. (Suggestion: don't fix it. The useless Dart Gun is all part of the "oh no we're all gonna die" experience of the beginning of TFTD.)<br />
* Does not improve the armour and effectiveness of the basic Aqua-Jet and Gas Cannon Coelecanths (it does upgrade the Coelecanth/Gauss). (Again, suggestion: this is a good thing - XCOM should start the game hopelessly outclassed, and scramble to catch up).<br />
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.<br />
* Does not allow you to have 360 degree vision out of your sub before exiting it. (What kind of coward would want that?). XComUtil does this.<br />
<br />
= Feature Requests and Suggestions =<br />
<br />
== Useful alien species research ==<br />
<br />
Tycho, I really like this idea you proposed in the StrategyCore forum:<br />
<br />
:I'm thinking about giving a hp bonus to all aliens until Xcom performs an autopsy on the species to learn the location of their vital organs (like in the movie "Battle of LA"). This would give more importance to performing autopsies rather than just as a stepping stone to new tech.<br />
<br />
Definite +1. It would be equally valid to add to UFO Extender. I suppose it could also be implemented using Vulnerabilities (no Vulnerabilities are in effect until the Autopsy is completed), or Resistances (across-the-board increased Resistances until Autopsy is completed). If that's easier. <br />
<br />
:''The bonus to hp was an initial thought. Later, I decided against it since it would make aliens more resistant to HE and stun, which don't rely on hitting the right locations. Increasing resistances would be the most appropriate but the damage routine code is very tight and adding anything new that won't break the existing variable stack pointers is tough.'' [[User:Morgan525|Tycho]]<br />
::''A new idea for this that I recently have been toying with, would be on the damage generation routine: Most direct fire damage is 0-200%, with anything over 100% considered a "critical hit". If autopsy hasn't been preformed, then the base damage would be 0-100% and a small chance (maybe 25%) of another 0-100% for that lucky shot. With autopsy done, the game reverts back to the usual 0-200% on any hit.''<br />
<br />
::: That works. And it makes doing Alien Autopsies a no-brainer, as it should be. It is pretty much inconceivable that XCom wouldn't prioritise the autopsy of any newly encountered alien. And any player playing the game for the first time would do autopsies too. This mod will help experienced players to stop playing as if they've "seen it all before". [[User:Spike|Spike]] 10:35, 15 September 2012 (EDT)<br />
<br />
Would it also be worth adding some kind of bonus for Live Alien research? Maybe the negation of some kind of Morale penalty and/or Psi penalty? Fear of the unknown, know your enemy, that kind of thing?<br />
<br />
:''I thought about that but the game doesn't record live aliens that have been researched. When you finish research on a live alien, it only follows the routine to unlock the appropriate UFOpaedia articles and then checks to see if the finished research can unlock other topics.'' [[User:Morgan525|Tycho]]<br />
<br />
I had a further thought on this while trying to guess what your new pre-requisites are for the various armours. For now it's really cool to be guessing but once people have figured it out, well, it will be more logical but still will have 'replay fatigue'. Would it be possible to randomise the pre-requisites for a lot of the key research topics, from out of a plausible list of items (or even randomise pre-requisite topics)? That would make every game fresh in terms of the research sequence, and make the research aspect of the game more challenging and less dry & predictable. As ever, just a suggestion. :) Cheers, [[User:Spike|Spike]] 16:01, 19 October 2012 (EDT)<br />
<br />
== All Units Can "Fly" In Water ==<br />
<br />
It's very illogical that most units are stuck on the seabed in underwater missions. Please provide the option to set all units (X-Com and alien) to have "flying" (i.e. swimming) ability when underwater. This is unlikely to cause an outbreak of 3D combat, since there is no cover except at seabed level, so anyone swimming excessively or incautiously is going to get shot. It might disadvantage the aliens if their tactical map waypoints are all set on the surface. But as some of them can "fly", there is hopefully a mechanism to deal with that in the code already. For me it will just solve the frustration of being unable to swim over small obstacles or swim up a level, and being stuck or tactically limited for no sensible reason. Mag-Ion Armour remains useful as an important step in Sub Research and (if using the Everything Works on Land mod) for land use. [[User:Spike|Spike]] 11:36, 9 September 2012 (EDT)<br />
: This requires setting [[UNITREF.DAT]] byte 0x78 bit 2 for the unit (e.g. for all units on both sides). Or the in-memory equivalent of UNITREF.DAT. [[User:Spike|Spike]] 10:19, 5 October 2012 (EDT)<br />
<br />
== Aliens Pick Up Weapons ==<br />
<br />
Related to Improved Alien AI. This makes the game tougher as stunned / panicked bipedal-type aliens are no longer permanently disarmed. This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. A fix for this would be a very helpful rebalancing of both games that eliminates one of the aliens' weak spots. The existing (but unused) routine looks pretty smart and not immediately exploitable to ambush aliens using weapons as traps. <br />
<br />
: I noticed the UFO Extender source code has a 'get' keyword under the OBDATA.DAT directive that populates this field 0x2D. Is that working? [[User:Spike|Spike]] 21:03, 16 October 2012 (EDT)<br />
:''It should be. I haven't tested it out but it should work like any other OBDATA change, in theory. As long as the code in the AI routine handles this byte, it should work. I believe someone mentioned under the Geoscape.exe page that the AI routine ignores any value under 5.-[[User:Morgan525|Tycho]] 00:58, 25 October 2012 (EDT)''<br />
<br />
== General Tank Modding ==<br />
<br />
I see you are interested in modding tanks (HWPs/SWPs) and that's partly what got you into updating UFO Extender. I made some suggestions for Tank Modding myself, including some of the mechanics required to make it work via a config file such as the UFO / TFD Extender config file. For example you could have cargo carrier / ambulance / casevac tanks, you could have demolition tanks, mine thrower tanks, and of course tanks with custom weapons including dual weapons. Could you have a look here: [[User:Spike#Tank_mods]] and see if any of that makes you feel like getting creative?<br />
<br />
Thanks,<br />
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)<br />
<br />
== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==<br />
<br />
Hook the right and left weapon menus on mind controlled aliens to add in actions for their built in melee attacks (if they have them) and built in Psi/MC attacks (if they have Psi/MC Skill). Ideally add these actions to the menu, and pop up a menu, even if the alien isn't holding any weapons.<br />
<br />
This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.<br />
<br />
== Fix Interception and Navigation Course Algorithms ==<br />
<br />
Or just find the algorithms and I volunteer to fix them!<br />
<br />
=== Use Great Circle Routes ===<br />
<br />
Travel toward the target on the shortest Great Circle, rather than always travelling along lines of latitude first (like they are some kind of main bus route!). <br />
<br />
=== Use Predictive Interception ===<br />
<br />
For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.<br />
<br />
=== Show Degree Headings ===<br />
<br />
The game only ever reports alien headings as North, South, East, West, but clearly alien craft move in other directions than just these four, and clearly XCOM detection equipment is capable of resolving these finer-grained headings, since the crafts' tracks are shown correctly in the Geoscope. <br />
As a first step towards predictive interceptions, it would be great to display the alien craft's heading in degrees, eg 135 degrees for South-East. Maybe rounded to the nearest 5 or 10 degrees.<br />
<br />
== Interception Craft vs Touched Down Alien Craft == <br />
<br />
If an alien craft is touched down and an XCOM interception craft (not touched down) is at the same X/Y position, if the alien craft begins to move, immediately open the Interception window at minimum range (8km/nm), presumably with the alien attempting to get away / break off. Currently the Interception window only happens if the XCom craft is faster, which is dumb, ''even if'' the alien craft could accelerate instantly to its maximum speed. <br />
<br />
For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach. <br />
<br />
== Fun, not Funky, Fire ==<br />
<br />
An alternative option for incendiaries/phosphorous damage processing: Do process the so called 'impact' damage of an incendiary on every shot, not just at the end of the turn. But only apply it to those in the area of affect of this specific shell burst, not to all units who are standing in smoke or fire anywhere on the map. This will please fans of incendiaries/phosphorous. It's probably a balancing, rather than unbalancing, change in the relative strengths of the ammo types. Makes incendiaries/phosphorous useful for more than just illumination or desperation. Gives some use to the research topics that advise use of incendiaries/phosphorous, and the damage modifiers aliens have been assigned.<br />
<br />
== Rearming Rates ==<br />
<br />
<br />
From [[Known_Bugs_(TFTD)#Geoscape_Bugs]]:<br />
<br />
=== Craft Gauss Cannon Rearming Rate ===<br />
<br />
This weapon rearms at 10/hr but probably should be 50/hr or at least 25/hr, otherwise it is far slower to rearm than any other cannon weapon in either game. In fact it's the second slowest weapon system to rearm, slower only than AJAX...<br />
<br />
=== AJAX Rearming Rate ===<br />
<br />
An AJAX system takes twice as long to fully reload as a D.U.P. system, as a result AJAX-armed Craft have much worse operational tempo and readiness than D.U.P. armed Craft. Like we needed yet another reason to always use D.U.Ps. This is probably a design error rather than a bug, but it would be good to fix it - anything to give a more balanced set of craft weapon choices. The rearming rate should be raised from 1/hr to 2/hr. The AJAX system will then have the same operational tempo as the D.U.P. system. <br />
<br />
Could also be applied to Stingray missiles in EU 1994, as the same analysis applies to Stingray vs Avalanche.<br />
<br />
== Retaliate for Colony Assault ==<br />
<br />
See this discussion [[Talk:Alien_Retaliation#Retaliation_Triggers]]. Colony raids are a good way for the alien to lose badly, so it would be a good balancing move to create severe consequences for raiding. It is at least as sensible as retaliation for USO Assaults.</div>
Spike
https://www.ufopaedia.org/index.php?title=Talk:TFTDextender&diff=40348
Talk:TFTDextender
2012-10-25T15:01:43Z
<p>Spike: /* Save Equipment not working? */</p>
<hr />
<div>=Questions or Comments=<br />
'''A place to provide feedback or ask questions:'''<br />
<br />
The zip archive does not seem to include an .ini file. Where do I get the .ini file from? <br />
:: Oh hang on. It looks like the latest version of the zip file does not include the .ini file. When I go back to the previous version of the zip file, I can see the .ini file. [[User:Spike|Spike]] 17:45, 6 September 2012 (EDT)<br />
<br />
:::''The latest release is a patch, which means there are no new additions to the INI. I don't include it in patches usually so that those who already have the prior release don't have to reconfigure their current INI. It may not seem like a big deal now but earlier, I was releasing fixes almost on a weekly basis and so I still continue with that idea.''[[User:Morgan525|Tycho]]<br />
<br />
== Bug Reports ==<br />
<br />
=== Crash when starting a landed/crashed USO battle ===<br />
<br />
:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."<br />
<br />
''Interesting. I had someone report a similar thing when they were starting their first instance of the battlescape on a new install of the game. I looked into it and the game generated some bad data. When he let the UFO take off and land again, the battle started with no problems..''<br />
<br />
:It's [[Known_Bugs_(TFTD)#Geoscape_Bugs|a bug I've reported before]] (before TFTD Extender even existed), so it's not specific to TFTDExtender / UFOExtender. What is happening is the Alien Sub is landing on land, and the Triton is also attempting to land on land. Probably the game crashes when it fails to generate the appropriate terrain type? So the GEOSCAPE map/terrain data must be corrupted. I've seen three examples of this. In a couple of cases the landing site is clearly inland, by hundreds of kilometres. In some cases it's right on the sea/land boundary and hard to tell. I have two save games that reproduce the bug now. From memory, the previous cases all happened around North Africa, like these present cases. [[User:Spike|Spike]] 08:31, 9 September 2012 (EDT)<br />
<br />
:''I think the problem is that there is no database to reference what type of terrain to load. EU would reference this based on map coordinates. Since USO aren't usually engaged over land, the map generator can't get an appropriate tileset for the location in these cases.-[[User:Morgan525|Tycho]]''<br />
<br />
=== Cannot build Leviathan ===<br />
<br />
Hi Tycho. I've just researched Leviathan in my TFDExtender game but cannot manufacture it! I have enough resources (Plastics, IBA, ManNav), 3 workshops, more than 100 technicans and one empty sub pen. But when starting the Leviathan manufacture task I cannot assign any technicans to it. I press the "up" button, and there are no reaction to this. I can build Manta, but not Leviathan. Don't you know what is it? [[User:PavelB|PavelB]] 06:55, 2 October 2012 (EDT)<br />
<br />
: Double check that you have sufficient cash to start the project, iirc $600K or so. That matches this symptom. Also that you have enough workshop space available (Leviathan needs a lot of space). Failing that, cancel all existing manufacturing projects, then retry. Failing that you could try reducing Technicians below 100 but that's taking us into Bug territory. [[User:Spike|Spike]] 07:17, 2 October 2012 (EDT)<br />
<br />
:: Resources are 100% enough. I've launched "Terror from the Deep.exe", loaded this saved game and started manufacturing Lev without any problems. I've saved this variant with Lev being manufactured and then loaded it from "TFTDextender.exe". As a result the process was okey, but I could only decrease the number of technicans working on it, not increase (even after decreasing!). That is: with 64 technicans had been assigned, I've pressed the "down" button, and the number changed to 63. But then I was unable to revert it to 64 by pressing "up" button: it didn't work! [[User:PavelB|PavelB]] 07:57, 2 October 2012 (EDT)<br />
:''I'll check into it. Although, I can't understand how changes to the research tree would affect production. Unless it has something to do with the autoproduce feature?''<br />
:'''This problem may be fixed with the same patch that fixed the production materials being deducted from the wrong base. Can anyone confirm?'''- - [[User:Morgan525|Tycho]] 23:12, 17 October 2012 (EDT)<br />
:: If I try to replicate PavelB's situation, I am able to build a Leviathan with no problems using the latest build. However I am also able to build a Leviathan using the 1.05p1.1 build. So I'm not able to replicate his original problem unfortunately. [[User:Spike|Spike]] 19:18, 19 October 2012 (EDT)<br />
<br />
== Minor Bugs ==<br />
<br />
=== Weightless Ammo Bug ===<br />
<br />
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)<br />
<br />
''From what I understand right now, I am pretty sure I can arrange it so that weapons are not automatically loaded and soldiers would be given an extra clip. Feedback?''<br />
: By an extra clip, you mean the clip/ammo that would have been loaded into the weapon is instead carried by the soldier? And for carried clips, the encumbrance effects are correct. For me anyway, in order of most benefit, the options would be<br />
:# Fix the root cause of the bug (ensure all relevant object locations and "contains/contained in" pointers are set during automatic clip loading) so that automatically loaded clips correctly affect encumbrance <br />
:# As a workaround, don't load ammo for multi-ammotype weapons (Heavy Cannon/Gas Cannon, Auto-Cannon/Hydrojet Cannon, Rocket Launcher / Torpedo Launcher). These are the weapons for which the bug has the greatest impact, since it imposes a 'cost' of switching away from the automatically-loaded ammo (usually AP or Small Rocket/Torp). With single-ammotype weapons, there's never any need to change the clips before combat. <br />
:# As a workaround, don't load ammo for any weapons. This avoids the 'switching cost' issue but does impose a fairly significant logistics overhead on each combat, to go through and manually load all clips. Plus the risk that you forget to load a weapon and only find out at a critical moment. :) This is for the "purist" who wants to make the game harder.<br />
:If it's tricky to fix the root cause, any of the other two options would be helpful. Suggested text:<br />
:* [Multi Ammo Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. Weapons using multiple ammo types (Heavy Cannon, Auto-Cannon, Rocket Launcher / Gas Cannon, Hydrojet Cannon, Torpedo Launcher) will not be pre-loaded before combat. You will need to load these weapons manually during the pre-combat Equip phase. This will significantly affect the heavy weapons ammunition load your squad can carry into combat without suffering encumbrance penalties, thus making the early game harder.<br />
:* [All Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. This option overrides the previous option. No weapons will be pre-loaded before combat. You will need to load all ammo manually during the pre-combat Equip phase. This will significantly affect the ammunition load your squad can carry into combat without suffering encumbrance penalties, making the early game harder.<br />
:[[User:Spike|Spike]] 05:10, 21 September 2012 (EDT)<br />
::''I found the source of the problem: None of the subroutines for inventory consider the clips in weapons so their entries in OBPOS.DAT are never updated. So when clips are autoloaded at the beginning of each battle, they have no owner. I've got the code to sync the ownership of clips with the weapon they are loaded into at the beginning of each battle and to update the clips when changed in inventory management.-''[[User:Morgan525|Tycho]] 19:00, 19 October 2012 (EDT)<br />
::: That is just awesome! :D [[User:Spike|Spike]] 22:36, 19 October 2012 (EDT)<br />
<br />
=== MIA Bugs ===<br />
<br />
==== Supernumary MIA on Abort ====<br />
<br />
I Abort a mission with 8 Aquanauts and get the confirmation message "8 Aquanauts inside craft, 2 outside". No one has been stunned or MCd. I did have two aquanauts, only, outside, but they have moved back inside the transport. Very odd. Saved Equipment was enabled. [[User:Spike|Spike]] 11:06, 5 October 2012 (EDT)<br />
<br />
:''How many Aquanauts did you have in total?- -''[[User:Morgan525|Tycho]] 02:54, 11 October 2012 (EDT)<br />
:: I started the mission with only 8 Aquanauts and they all survived. Only two had even been outside the transport (quite an unusual situation). However I can't reproduce this bug, so please ignore it unless/until I can reproduce it. :) [[User:Spike|Spike]] 06:48, 17 October 2012 (EDT)<br />
<br />
==== Crewed Flying Sub Lost on Abort ====<br />
<br />
Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)<br />
<br />
:Presumably the 3 aquanauts in the craft were not stunned or mind controlled on the Abort turn? [[User:Spike|Spike]] 16:37, 21 October 2012 (EDT)<br />
:Right, they are not stunned (or dead) and they are under your control. And they are definitely in the sub. OK this is similar to a minor bug I have seen before - see [[#Supernumary MIA on Abort|preceding item]]. On your pre-abort confirmation screen it says "3 units in craft, 9 units outside". I've had a similar issue before. It's double counting your aquanauts as being both inside and outside the craft on the confirm screen, since you only have 9 units (8 and 1 tank) in total. On actual abort you incorrectly get 9 MIAs (including the tank presumably) and I guess that's why you lose the sub. Interestingly, the 3 affected aquanauts look like they never moved from their original positions, is that true? I believe when I've had similar problems before, it related to aquanauts who had never left the sub / never left their initial positions. We will have to see if Tycho can get to the bottom of this one. [[User:Spike|Spike]] 16:51, 21 October 2012 (EDT)<br />
::Yes, that's true - those 3 haven't moved from their original positions. --[[User:Player701|Player701]] 17:19, 21 October 2012 (EDT)<br />
<br />
:''I found the nature of the issue here: On one hand, all parts of the tank are being counted separately but then the End of Battle routine calculates the correct number of units but when it goes to locate the units on the battlefield, the three other parts of the tank are being tallied and thus the last three aquanauts are not checked since the 4 areas of the tank are first in the UNITPOS.DAT file.-[[User:Morgan525|Tycho]] 09:47, 24 October 2012 (EDT)''<br />
<br />
==== Stunned Carried Aquanauts MIA on Abort ====<br />
<br />
While you are looking the EOB script, I noticed one more anomaly. I'm not sure if this is an original bug or an Extender bug. If you are carrying a stunned Aquanaut in the transport at the time of Abort, the stunned Aquanaut is lost (MIA). You have to drop the stunned Aquanaut on the floor. Probably this is because the position of the Aquanaut has not been updated and is still pointing to where they were stunned, not to the location of the carrying Aquanaut. [[User:Spike|Spike]] 04:49, 27 September 2012 (EDT)<br />
<br />
:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. At least it is manageable: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)<br />
<br />
=== Items on transport floor lost on Abort ===<br />
<br />
I went in to a mission with ten Sonic Cannons and came back with 3, despite retrieving them from the battlefield and dumping them on the transport floor. I only had 3 aquanauts on the transport armed with Sonic Cannon at the time of abort. The rest were stunned or unarmed. I also dumped half a dozen corpses and some alien items on the transport floor and I don't think those made it back to my base either. The transport was operating from base 2 rather than base 1, in case that's a factor. This may be an original bug of course. I just read through the multiplayer TFTD LP on StrategyCore, and they reported missing equipment on a lot of missions. I can go back and check if the missing equipment was on abort missions rather than victory missions. Sorry not to provide more specifics at this time but it was a hard mission and not exactly a controlled experiment. ;) [[User:Spike|Spike]] 21:35, 23 October 2012 (EDT)<br />
: I tried to reproduce this in the unmodified game without success, controlling for aquanauts being stunned/not stunned, inside/outside transport, stunned inside/outside transport. I didn't control for reloading the game, that sometimes causes glitches. I will retry with the Extender next and see if that reproduces anything. [[User:Spike|Spike]] 21:06, 24 October 2012 (EDT)<br />
<br />
=== Weight Display in Inventory not Localised ===<br />
<br />
At least when I run the game in German, it comes up as "Weight" and not something like "Gewicht". Reactions comes up ok as "Zeitwerte". [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
<br />
:''There is no entry in the text DAT files for "weight". Seb had to add the text string for it into his subroutine. Thanks for pointing it out.'' [[User:Morgan525|Tycho]]<br />
<br />
== Save Equipment not working? ==<br />
<br />
With "Save Equipment" option enabled, the soldiers' loadout at first was always like this: grenade in leg slot, clip in backpack - and it didn't change on the next mission, despite the fact that I re-equipped the soldiers correctly (grenades and clips on the belt). When I manufactured Gauss Rifles and issued them to my soldiers, it got even worse - none of the soldiers got clips, and two of the rifles were unloaded. Next I upgraded to Sonic-Blasta Rifles and now nothing, except some grenades (still in leg slots), is issued to the soldiers at all. "Save Equipment" was known to work in UFOExtender, did something get broken? --[[User:Player701|Player701]] 09:18, 21 October 2012 (EDT)<br />
<br />
:''Yes. Something is broken but not by the Extender. I haven't modified anything in the save equipment code, except datapoints and offsets that were necessary to match it to the executable and changes in the DAT files. Many subroutines, their order of execution, or the variables were modified in the TFTD game code. Problems resulting from this are difficult to resolve since it requires finding what changed in the game code and then determining what changes are needed to get the UFOextender code to work. See the discussion on problems with the OBDATA mod about the final source of the problem and its solution.-[[User:Morgan525|Tycho]] 20:03, 21 October 2012 (EDT)''<br />
<br />
:: Would you suggest that everyone disables Save Equipment for the time being, in TFTDextender? [[User:Spike|Spike]] 07:44, 24 October 2012 (EDT)<br />
<br />
:''It couldn't hurt. I believe that TFTD has its own form of autoequip and part of the solution will require that I disable it. Something similar happened to the stunned units are KIA mod from UFOextender: TFTD has its own version so I removed the UFOextender code and only added code to update the unit's location so the corpse would appear in the right place.-[[User:Morgan525|Tycho]] 22:38, 24 October 2012 (EDT)''<br />
<br />
:: I just did a few tests in raw TFTD (Steam CE) and the auto equip function is pretty basic.<br />
: Give everyone a loaded weapon in what is probably reverse OBDATA.DAT order, then dish out any extra clips, grenades etc. Are you thinking that the Save Equipment efforts of TFTDextender are then being overwritten or partly overwritten by the existing TFTD auto equip function? I guess that would make sense. [[User:Spike|Spike]] 11:01, 25 October 2012 (EDT)<br />
<br />
=Resolved Problems=<br />
<br />
===<s> Executable directive </s>===<br />
''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)<br />
<br />
=== <s>Extra Artefacts Reported</s> ===<br />
''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)<br />
''This will be fixed in the next release.-''[[User:Morgan525|Tycho]] 03:00, 13 October 2012 (EDT)<br />
: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
===<s>Manufacturing Projects Minimum Production</s> ===<br />
<br />
In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''<br />
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)<br />
<br />
Tested - If I reduce the production quantity of a current production run to less than what as already been produced, the display completion time changes (incorrectly) to 'Indefinite', but production ends after completion of the next unit. So if I start by producing 10 units, wait until I have produced 2, then reduce the quantity to 2 (or probably 1), production stops after 3 units. Thies basically replicates the pre-existing behaviour when using the down arrow on the Quantity, so there has been no loss of functionality with your Mod. Also, Autosell and Autoproduce work normally when applied as changes to an existing production run. The only thing is I can't distinguish them on the Manufacturing display - both say 'unlimited' quantity and 'indefinite' period - is that intended? I suppose it makes sense, but it would be good to be able to tell which kind of production it is, *** Autoproduce or $$$ Autosell. [[User:Spike|Spike]] 08:57, 2 October 2012 (EDT)<br />
<br />
:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''<br />
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)<br />
:::''OK. Changed the output to display "$unlimited$".[[User:Morgan525|Tycho]]<br />
<br />
===<s>Stunned MC'd Aquanauts MIA on Abort </s> ===<br />
<br />
This is a subset of MC'd Aquanauts go MIA [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]. In this case Aquanauts are MC'd by the aliens, then stunned (by friendlies), then the mission is Aborted with the stunned X-Com Aquanauts aboard the transport. The Aquanauts then disappear from the roster forever. I'm not sure if it's due to Abort rather than Victory, or due to them being stunned first. <br />
::''I now have the code in place to uncontrol any creature that has been rendered unconscious. - -''[[User:Morgan525|Tycho]] 02:47, 11 October 2012 (EDT)<br />
This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
=== <s>Grenade Resistance in INI file </s> ===<br />
:''I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]<br />
<br />
<br />
===<s> Materials deducted from wrong base </s>===<br />
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''<br />
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)<br />
<br />
===<s> OBDATA / Dye Grenade mod not working? </s>===<br />
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)<br />
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
== <s>Displacer/Sonic damage fix</s> ==<br />
<br />
'' I changed the damage to be 130, same as the UFOpaedia entry.-''[[User:Morgan525|Tycho]] 03:52, 13 October 2012 (EDT)<br />
<br />
<br />
== Things that TFTDextender does not fix ==<br />
<br />
Just more or less as a note to the reader, TFTDextender does not fix some of the following things that are sometimes thought of as needing fixing (and this is probably deliberate?):<br />
<br />
* Does not fix the apparent swap of the ground map for the VERY SMALL Survey Ship (1 occupant) with the SMALL Escort (half-dozen or more occupants). So you get the VERY SMALL sub occupying about 25 squares of usable area on the Battlescape, and the supposedly larger SMALL sub occupying one square of usable area on the Battlescape, begging the question of how all those aliens got inside there in the first place. XcomUtil will fix this, as will the original patches that XcomUtil incorporates.<br />
* Does not fix the incorrect pictures for the large USO in the interception window. <br />
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]<br />
* Does not fix the Dart Gun to make it any less utterly useless. Though you can do this yourself via the OBDATA.DAT section of TFTDextender. (Suggestion: don't fix it. The useless Dart Gun is all part of the "oh no we're all gonna die" experience of the beginning of TFTD.)<br />
* Does not improve the armour and effectiveness of the basic Aqua-Jet and Gas Cannon Coelecanths (it does upgrade the Coelecanth/Gauss). (Again, suggestion: this is a good thing - XCOM should start the game hopelessly outclassed, and scramble to catch up).<br />
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.<br />
* Does not allow you to have 360 degree vision out of your sub before exiting it. (What kind of coward would want that?). XComUtil does this.<br />
<br />
= Feature Requests and Suggestions =<br />
<br />
== Useful alien species research ==<br />
<br />
Tycho, I really like this idea you proposed in the StrategyCore forum:<br />
<br />
:I'm thinking about giving a hp bonus to all aliens until Xcom performs an autopsy on the species to learn the location of their vital organs (like in the movie "Battle of LA"). This would give more importance to performing autopsies rather than just as a stepping stone to new tech.<br />
<br />
Definite +1. It would be equally valid to add to UFO Extender. I suppose it could also be implemented using Vulnerabilities (no Vulnerabilities are in effect until the Autopsy is completed), or Resistances (across-the-board increased Resistances until Autopsy is completed). If that's easier. <br />
<br />
:''The bonus to hp was an initial thought. Later, I decided against it since it would make aliens more resistant to HE and stun, which don't rely on hitting the right locations. Increasing resistances would be the most appropriate but the damage routine code is very tight and adding anything new that won't break the existing variable stack pointers is tough.'' [[User:Morgan525|Tycho]]<br />
::''A new idea for this that I recently have been toying with, would be on the damage generation routine: Most direct fire damage is 0-200%, with anything over 100% considered a "critical hit". If autopsy hasn't been preformed, then the base damage would be 0-100% and a small chance (maybe 25%) of another 0-100% for that lucky shot. With autopsy done, the game reverts back to the usual 0-200% on any hit.''<br />
<br />
::: That works. And it makes doing Alien Autopsies a no-brainer, as it should be. It is pretty much inconceivable that XCom wouldn't prioritise the autopsy of any newly encountered alien. And any player playing the game for the first time would do autopsies too. This mod will help experienced players to stop playing as if they've "seen it all before". [[User:Spike|Spike]] 10:35, 15 September 2012 (EDT)<br />
<br />
Would it also be worth adding some kind of bonus for Live Alien research? Maybe the negation of some kind of Morale penalty and/or Psi penalty? Fear of the unknown, know your enemy, that kind of thing?<br />
<br />
:''I thought about that but the game doesn't record live aliens that have been researched. When you finish research on a live alien, it only follows the routine to unlock the appropriate UFOpaedia articles and then checks to see if the finished research can unlock other topics.'' [[User:Morgan525|Tycho]]<br />
<br />
I had a further thought on this while trying to guess what your new pre-requisites are for the various armours. For now it's really cool to be guessing but once people have figured it out, well, it will be more logical but still will have 'replay fatigue'. Would it be possible to randomise the pre-requisites for a lot of the key research topics, from out of a plausible list of items (or even randomise pre-requisite topics)? That would make every game fresh in terms of the research sequence, and make the research aspect of the game more challenging and less dry & predictable. As ever, just a suggestion. :) Cheers, [[User:Spike|Spike]] 16:01, 19 October 2012 (EDT)<br />
<br />
== All Units Can "Fly" In Water ==<br />
<br />
It's very illogical that most units are stuck on the seabed in underwater missions. Please provide the option to set all units (X-Com and alien) to have "flying" (i.e. swimming) ability when underwater. This is unlikely to cause an outbreak of 3D combat, since there is no cover except at seabed level, so anyone swimming excessively or incautiously is going to get shot. It might disadvantage the aliens if their tactical map waypoints are all set on the surface. But as some of them can "fly", there is hopefully a mechanism to deal with that in the code already. For me it will just solve the frustration of being unable to swim over small obstacles or swim up a level, and being stuck or tactically limited for no sensible reason. Mag-Ion Armour remains useful as an important step in Sub Research and (if using the Everything Works on Land mod) for land use. [[User:Spike|Spike]] 11:36, 9 September 2012 (EDT)<br />
: This requires setting [[UNITREF.DAT]] byte 0x78 bit 2 for the unit (e.g. for all units on both sides). Or the in-memory equivalent of UNITREF.DAT. [[User:Spike|Spike]] 10:19, 5 October 2012 (EDT)<br />
<br />
== Aliens Pick Up Weapons ==<br />
<br />
Related to Improved Alien AI. This makes the game tougher as stunned / panicked bipedal-type aliens are no longer permanently disarmed. This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. A fix for this would be a very helpful rebalancing of both games that eliminates one of the aliens' weak spots. The existing (but unused) routine looks pretty smart and not immediately exploitable to ambush aliens using weapons as traps. <br />
<br />
: I noticed the UFO Extender source code has a 'get' keyword under the OBDATA.DAT directive that populates this field 0x2D. Is that working? [[User:Spike|Spike]] 21:03, 16 October 2012 (EDT)<br />
:''It should be. I haven't tested it out but it should work like any other OBDATA change, in theory. As long as the code in the AI routine handles this byte, it should work. I believe someone mentioned under the Geoscape.exe page that the AI routine ignores any value under 5.-[[User:Morgan525|Tycho]] 00:58, 25 October 2012 (EDT)''<br />
<br />
== General Tank Modding ==<br />
<br />
I see you are interested in modding tanks (HWPs/SWPs) and that's partly what got you into updating UFO Extender. I made some suggestions for Tank Modding myself, including some of the mechanics required to make it work via a config file such as the UFO / TFD Extender config file. For example you could have cargo carrier / ambulance / casevac tanks, you could have demolition tanks, mine thrower tanks, and of course tanks with custom weapons including dual weapons. Could you have a look here: [[User:Spike#Tank_mods]] and see if any of that makes you feel like getting creative?<br />
<br />
Thanks,<br />
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)<br />
<br />
== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==<br />
<br />
Hook the right and left weapon menus on mind controlled aliens to add in actions for their built in melee attacks (if they have them) and built in Psi/MC attacks (if they have Psi/MC Skill). Ideally add these actions to the menu, and pop up a menu, even if the alien isn't holding any weapons.<br />
<br />
This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.<br />
<br />
== Fix Interception and Navigation Course Algorithms ==<br />
<br />
Or just find the algorithms and I volunteer to fix them!<br />
<br />
=== Use Great Circle Routes ===<br />
<br />
Travel toward the target on the shortest Great Circle, rather than always travelling along lines of latitude first (like they are some kind of main bus route!). <br />
<br />
=== Use Predictive Interception ===<br />
<br />
For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.<br />
<br />
=== Show Degree Headings ===<br />
<br />
The game only ever reports alien headings as North, South, East, West, but clearly alien craft move in other directions than just these four, and clearly XCOM detection equipment is capable of resolving these finer-grained headings, since the crafts' tracks are shown correctly in the Geoscope. <br />
As a first step towards predictive interceptions, it would be great to display the alien craft's heading in degrees, eg 135 degrees for South-East. Maybe rounded to the nearest 5 or 10 degrees.<br />
<br />
== Interception Craft vs Touched Down Alien Craft == <br />
<br />
If an alien craft is touched down and an XCOM interception craft (not touched down) is at the same X/Y position, if the alien craft begins to move, immediately open the Interception window at minimum range (8km/nm), presumably with the alien attempting to get away / break off. Currently the Interception window only happens if the XCom craft is faster, which is dumb, ''even if'' the alien craft could accelerate instantly to its maximum speed. <br />
<br />
For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach. <br />
<br />
== Fun, not Funky, Fire ==<br />
<br />
An alternative option for incendiaries/phosphorous damage processing: Do process the so called 'impact' damage of an incendiary on every shot, not just at the end of the turn. But only apply it to those in the area of affect of this specific shell burst, not to all units who are standing in smoke or fire anywhere on the map. This will please fans of incendiaries/phosphorous. It's probably a balancing, rather than unbalancing, change in the relative strengths of the ammo types. Makes incendiaries/phosphorous useful for more than just illumination or desperation. Gives some use to the research topics that advise use of incendiaries/phosphorous, and the damage modifiers aliens have been assigned.<br />
<br />
== Rearming Rates ==<br />
<br />
<br />
From [[Known_Bugs_(TFTD)#Geoscape_Bugs]]:<br />
<br />
=== Craft Gauss Cannon Rearming Rate ===<br />
<br />
This weapon rearms at 10/hr but probably should be 50/hr or at least 25/hr, otherwise it is far slower to rearm than any other cannon weapon in either game. In fact it's the second slowest weapon system to rearm, slower only than AJAX...<br />
<br />
=== AJAX Rearming Rate ===<br />
<br />
An AJAX system takes twice as long to fully reload as a D.U.P. system, as a result AJAX-armed Craft have much worse operational tempo and readiness than D.U.P. armed Craft. Like we needed yet another reason to always use D.U.Ps. This is probably a design error rather than a bug, but it would be good to fix it - anything to give a more balanced set of craft weapon choices. The rearming rate should be raised from 1/hr to 2/hr. The AJAX system will then have the same operational tempo as the D.U.P. system. <br />
<br />
Could also be applied to Stingray missiles in EU 1994, as the same analysis applies to Stingray vs Avalanche.<br />
<br />
== Retaliate for Colony Assault ==<br />
<br />
See this discussion [[Talk:Alien_Retaliation#Retaliation_Triggers]]. Colony raids are a good way for the alien to lose badly, so it would be a good balancing move to create severe consequences for raiding. It is at least as sensible as retaliation for USO Assaults.</div>
Spike
https://www.ufopaedia.org/index.php?title=Talk:TFTDextender&diff=40339
Talk:TFTDextender
2012-10-25T01:06:04Z
<p>Spike: /* Items on transport floor lost */ testing - negative</p>
<hr />
<div>=Questions or Comments=<br />
'''A place to provide feedback or ask questions:'''<br />
<br />
The zip archive does not seem to include an .ini file. Where do I get the .ini file from? <br />
:: Oh hang on. It looks like the latest version of the zip file does not include the .ini file. When I go back to the previous version of the zip file, I can see the .ini file. [[User:Spike|Spike]] 17:45, 6 September 2012 (EDT)<br />
<br />
:::''The latest release is a patch, which means there are no new additions to the INI. I don't include it in patches usually so that those who already have the prior release don't have to reconfigure their current INI. It may not seem like a big deal now but earlier, I was releasing fixes almost on a weekly basis and so I still continue with that idea.''[[User:Morgan525|Tycho]]<br />
<br />
== Bug Reports ==<br />
<br />
=== Crash when starting a landed/crashed USO battle ===<br />
<br />
:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."<br />
<br />
''Interesting. I had someone report a similar thing when they were starting their first instance of the battlescape on a new install of the game. I looked into it and the game generated some bad data. When he let the UFO take off and land again, the battle started with no problems..''<br />
<br />
:It's [[Known_Bugs_(TFTD)#Geoscape_Bugs|a bug I've reported before]] (before TFTD Extender even existed), so it's not specific to TFTDExtender / UFOExtender. What is happening is the Alien Sub is landing on land, and the Triton is also attempting to land on land. Probably the game crashes when it fails to generate the appropriate terrain type? So the GEOSCAPE map/terrain data must be corrupted. I've seen three examples of this. In a couple of cases the landing site is clearly inland, by hundreds of kilometres. In some cases it's right on the sea/land boundary and hard to tell. I have two save games that reproduce the bug now. From memory, the previous cases all happened around North Africa, like these present cases. [[User:Spike|Spike]] 08:31, 9 September 2012 (EDT)<br />
<br />
:''I think the problem is that there is no database to reference what type of terrain to load. EU would reference this based on map coordinates. Since USO aren't usually engaged over land, the map generator can't get an appropriate tileset for the location in these cases.-[[User:Morgan525|Tycho]]''<br />
<br />
=== Cannot build Leviathan ===<br />
<br />
Hi Tycho. I've just researched Leviathan in my TFDExtender game but cannot manufacture it! I have enough resources (Plastics, IBA, ManNav), 3 workshops, more than 100 technicans and one empty sub pen. But when starting the Leviathan manufacture task I cannot assign any technicans to it. I press the "up" button, and there are no reaction to this. I can build Manta, but not Leviathan. Don't you know what is it? [[User:PavelB|PavelB]] 06:55, 2 October 2012 (EDT)<br />
<br />
: Double check that you have sufficient cash to start the project, iirc $600K or so. That matches this symptom. Also that you have enough workshop space available (Leviathan needs a lot of space). Failing that, cancel all existing manufacturing projects, then retry. Failing that you could try reducing Technicians below 100 but that's taking us into Bug territory. [[User:Spike|Spike]] 07:17, 2 October 2012 (EDT)<br />
<br />
:: Resources are 100% enough. I've launched "Terror from the Deep.exe", loaded this saved game and started manufacturing Lev without any problems. I've saved this variant with Lev being manufactured and then loaded it from "TFTDextender.exe". As a result the process was okey, but I could only decrease the number of technicans working on it, not increase (even after decreasing!). That is: with 64 technicans had been assigned, I've pressed the "down" button, and the number changed to 63. But then I was unable to revert it to 64 by pressing "up" button: it didn't work! [[User:PavelB|PavelB]] 07:57, 2 October 2012 (EDT)<br />
:''I'll check into it. Although, I can't understand how changes to the research tree would affect production. Unless it has something to do with the autoproduce feature?''<br />
:'''This problem may be fixed with the same patch that fixed the production materials being deducted from the wrong base. Can anyone confirm?'''- - [[User:Morgan525|Tycho]] 23:12, 17 October 2012 (EDT)<br />
:: If I try to replicate PavelB's situation, I am able to build a Leviathan with no problems using the latest build. However I am also able to build a Leviathan using the 1.05p1.1 build. So I'm not able to replicate his original problem unfortunately. [[User:Spike|Spike]] 19:18, 19 October 2012 (EDT)<br />
<br />
== Minor Bugs ==<br />
<br />
=== Weightless Ammo Bug ===<br />
<br />
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)<br />
<br />
''From what I understand right now, I am pretty sure I can arrange it so that weapons are not automatically loaded and soldiers would be given an extra clip. Feedback?''<br />
: By an extra clip, you mean the clip/ammo that would have been loaded into the weapon is instead carried by the soldier? And for carried clips, the encumbrance effects are correct. For me anyway, in order of most benefit, the options would be<br />
:# Fix the root cause of the bug (ensure all relevant object locations and "contains/contained in" pointers are set during automatic clip loading) so that automatically loaded clips correctly affect encumbrance <br />
:# As a workaround, don't load ammo for multi-ammotype weapons (Heavy Cannon/Gas Cannon, Auto-Cannon/Hydrojet Cannon, Rocket Launcher / Torpedo Launcher). These are the weapons for which the bug has the greatest impact, since it imposes a 'cost' of switching away from the automatically-loaded ammo (usually AP or Small Rocket/Torp). With single-ammotype weapons, there's never any need to change the clips before combat. <br />
:# As a workaround, don't load ammo for any weapons. This avoids the 'switching cost' issue but does impose a fairly significant logistics overhead on each combat, to go through and manually load all clips. Plus the risk that you forget to load a weapon and only find out at a critical moment. :) This is for the "purist" who wants to make the game harder.<br />
:If it's tricky to fix the root cause, any of the other two options would be helpful. Suggested text:<br />
:* [Multi Ammo Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. Weapons using multiple ammo types (Heavy Cannon, Auto-Cannon, Rocket Launcher / Gas Cannon, Hydrojet Cannon, Torpedo Launcher) will not be pre-loaded before combat. You will need to load these weapons manually during the pre-combat Equip phase. This will significantly affect the heavy weapons ammunition load your squad can carry into combat without suffering encumbrance penalties, thus making the early game harder.<br />
:* [All Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. This option overrides the previous option. No weapons will be pre-loaded before combat. You will need to load all ammo manually during the pre-combat Equip phase. This will significantly affect the ammunition load your squad can carry into combat without suffering encumbrance penalties, making the early game harder.<br />
:[[User:Spike|Spike]] 05:10, 21 September 2012 (EDT)<br />
::''I found the source of the problem: None of the subroutines for inventory consider the clips in weapons so their entries in OBPOS.DAT are never updated. So when clips are autoloaded at the beginning of each battle, they have no owner. I've got the code to sync the ownership of clips with the weapon they are loaded into at the beginning of each battle and to update the clips when changed in inventory management.-''[[User:Morgan525|Tycho]] 19:00, 19 October 2012 (EDT)<br />
::: That is just awesome! :D [[User:Spike|Spike]] 22:36, 19 October 2012 (EDT)<br />
<br />
=== MIA Bugs ===<br />
<br />
==== Supernumary MIA on Abort ====<br />
<br />
I Abort a mission with 8 Aquanauts and get the confirmation message "8 Aquanauts inside craft, 2 outside". No one has been stunned or MCd. I did have two aquanauts, only, outside, but they have moved back inside the transport. Very odd. Saved Equipment was enabled. [[User:Spike|Spike]] 11:06, 5 October 2012 (EDT)<br />
<br />
:''How many Aquanauts did you have in total?- -''[[User:Morgan525|Tycho]] 02:54, 11 October 2012 (EDT)<br />
:: I started the mission with only 8 Aquanauts and they all survived. Only two had even been outside the transport (quite an unusual situation). However I can't reproduce this bug, so please ignore it unless/until I can reproduce it. :) [[User:Spike|Spike]] 06:48, 17 October 2012 (EDT)<br />
<br />
==== Crewed Flying Sub Lost on Abort ====<br />
<br />
Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)<br />
<br />
:Presumably the 3 aquanauts in the craft were not stunned or mind controlled on the Abort turn? [[User:Spike|Spike]] 16:37, 21 October 2012 (EDT)<br />
:Right, they are not stunned (or dead) and they are under your control. And they are definitely in the sub. OK this is similar to a minor bug I have seen before - see [[#Supernumary MIA on Abort|preceding item]]. On your pre-abort confirmation screen it says "3 units in craft, 9 units outside". I've had a similar issue before. It's double counting your aquanauts as being both inside and outside the craft on the confirm screen, since you only have 9 units (8 and 1 tank) in total. On actual abort you incorrectly get 9 MIAs (including the tank presumably) and I guess that's why you lose the sub. Interestingly, the 3 affected aquanauts look like they never moved from their original positions, is that true? I believe when I've had similar problems before, it related to aquanauts who had never left the sub / never left their initial positions. We will have to see if Tycho can get to the bottom of this one. [[User:Spike|Spike]] 16:51, 21 October 2012 (EDT)<br />
::Yes, that's true - those 3 haven't moved from their original positions. --[[User:Player701|Player701]] 17:19, 21 October 2012 (EDT)<br />
<br />
:''I found the nature of the issue here: On one hand, all parts of the tank are being counted separately but then the End of Battle routine calculates the correct number of units but when it goes to locate the units on the battlefield, the three other parts of the tank are being tallied and thus the last three aquanauts are not checked since the 4 areas of the tank are first in the UNITPOS.DAT file.-[[User:Morgan525|Tycho]] 09:47, 24 October 2012 (EDT)''<br />
<br />
==== Stunned Carried Aquanauts MIA on Abort ====<br />
<br />
While you are looking the EOB script, I noticed one more anomaly. I'm not sure if this is an original bug or an Extender bug. If you are carrying a stunned Aquanaut in the transport at the time of Abort, the stunned Aquanaut is lost (MIA). You have to drop the stunned Aquanaut on the floor. Probably this is because the position of the Aquanaut has not been updated and is still pointing to where they were stunned, not to the location of the carrying Aquanaut. [[User:Spike|Spike]] 04:49, 27 September 2012 (EDT)<br />
<br />
:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. At least it is manageable: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)<br />
<br />
=== Items on transport floor lost on Abort ===<br />
<br />
I went in to a mission with ten Sonic Cannons and came back with 3, despite retrieving them from the battlefield and dumping them on the transport floor. I only had 3 aquanauts on the transport armed with Sonic Cannon at the time of abort. The rest were stunned or unarmed. I also dumped half a dozen corpses and some alien items on the transport floor and I don't think those made it back to my base either. The transport was operating from base 2 rather than base 1, in case that's a factor. This may be an original bug of course. I just read through the multiplayer TFTD LP on StrategyCore, and they reported missing equipment on a lot of missions. I can go back and check if the missing equipment was on abort missions rather than victory missions. Sorry not to provide more specifics at this time but it was a hard mission and not exactly a controlled experiment. ;) [[User:Spike|Spike]] 21:35, 23 October 2012 (EDT)<br />
: I tried to reproduce this in the unmodified game without success, controlling for aquanauts being stunned/not stunned, inside/outside transport, stunned inside/outside transport. I didn't control for reloading the game, that sometimes causes glitches. I will retry with the Extender next and see if that reproduces anything. [[User:Spike|Spike]] 21:06, 24 October 2012 (EDT)<br />
<br />
=== Weight Display in Inventory not Localised ===<br />
<br />
At least when I run the game in German, it comes up as "Weight" and not something like "Gewicht". Reactions comes up ok as "Zeitwerte". [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
<br />
:''There is no entry in the text DAT files for "weight". Seb had to add the text string for it into his subroutine. Thanks for pointing it out.'' [[User:Morgan525|Tycho]]<br />
<br />
== Save Equipment not working? ==<br />
<br />
With "Save Equipment" option enabled, the soldiers' loadout at first was always like this: grenade in leg slot, clip in backpack - and it didn't change on the next mission, despite the fact that I re-equipped the soldiers correctly (grenades and clips on the belt). When I manufactured Gauss Rifles and issued them to my soldiers, it got even worse - none of the soldiers got clips, and two of the rifles were unloaded. Next I upgraded to Sonic-Blasta Rifles and now nothing, except some grenades (still in leg slots), is issued to the soldiers at all. "Save Equipment" was known to work in UFOExtender, did something get broken? --[[User:Player701|Player701]] 09:18, 21 October 2012 (EDT)<br />
<br />
:''Yes. Something is broken but not by the Extender. Many subroutines, their order of execution, or variable were modified in the TFTD game code. Problems like these are deducing what changed in the game code and what changes are needed to get the UFOextender code to work. See the discussion on problems with the OBDATA mod about the final source of the problem and its solution.-[[User:Morgan525|Tycho]] 20:03, 21 October 2012 (EDT)''<br />
<br />
:: Would you suggest that everyone disables Save Equipment for the time being, in TFTDextender? [[User:Spike|Spike]] 07:44, 24 October 2012 (EDT)<br />
<br />
=Resolved Problems=<br />
<br />
===<s> Executable directive </s>===<br />
''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)<br />
<br />
=== <s>Extra Artefacts Reported</s> ===<br />
''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)<br />
''This will be fixed in the next release.-''[[User:Morgan525|Tycho]] 03:00, 13 October 2012 (EDT)<br />
: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
===<s>Manufacturing Projects Minimum Production</s> ===<br />
<br />
In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''<br />
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)<br />
<br />
Tested - If I reduce the production quantity of a current production run to less than what as already been produced, the display completion time changes (incorrectly) to 'Indefinite', but production ends after completion of the next unit. So if I start by producing 10 units, wait until I have produced 2, then reduce the quantity to 2 (or probably 1), production stops after 3 units. Thies basically replicates the pre-existing behaviour when using the down arrow on the Quantity, so there has been no loss of functionality with your Mod. Also, Autosell and Autoproduce work normally when applied as changes to an existing production run. The only thing is I can't distinguish them on the Manufacturing display - both say 'unlimited' quantity and 'indefinite' period - is that intended? I suppose it makes sense, but it would be good to be able to tell which kind of production it is, *** Autoproduce or $$$ Autosell. [[User:Spike|Spike]] 08:57, 2 October 2012 (EDT)<br />
<br />
:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''<br />
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)<br />
:::''OK. Changed the output to display "$unlimited$".[[User:Morgan525|Tycho]]<br />
<br />
===<s>Stunned MC'd Aquanauts MIA on Abort </s> ===<br />
<br />
This is a subset of MC'd Aquanauts go MIA [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]. In this case Aquanauts are MC'd by the aliens, then stunned (by friendlies), then the mission is Aborted with the stunned X-Com Aquanauts aboard the transport. The Aquanauts then disappear from the roster forever. I'm not sure if it's due to Abort rather than Victory, or due to them being stunned first. <br />
::''I now have the code in place to uncontrol any creature that has been rendered unconscious. - -''[[User:Morgan525|Tycho]] 02:47, 11 October 2012 (EDT)<br />
This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
=== <s>Grenade Resistance in INI file </s> ===<br />
:''I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]<br />
<br />
<br />
===<s> Materials deducted from wrong base </s>===<br />
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''<br />
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)<br />
<br />
===<s> OBDATA / Dye Grenade mod not working? </s>===<br />
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)<br />
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
== <s>Displacer/Sonic damage fix</s> ==<br />
<br />
'' I changed the damage to be 130, same as the UFOpaedia entry.-''[[User:Morgan525|Tycho]] 03:52, 13 October 2012 (EDT)<br />
<br />
<br />
== Things that TFTDextender does not fix ==<br />
<br />
Just more or less as a note to the reader, TFTDextender does not fix some of the following things that are sometimes thought of as needing fixing (and this is probably deliberate?):<br />
<br />
* Does not fix the apparent swap of the ground map for the VERY SMALL Survey Ship (1 occupant) with the SMALL Escort (half-dozen or more occupants). So you get the VERY SMALL sub occupying about 25 squares of usable area on the Battlescape, and the supposedly larger SMALL sub occupying one square of usable area on the Battlescape, begging the question of how all those aliens got inside there in the first place. XcomUtil will fix this, as will the original patches that XcomUtil incorporates.<br />
* Does not fix the incorrect pictures for the large USO in the interception window. <br />
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]<br />
* Does not fix the Dart Gun to make it any less utterly useless. Though you can do this yourself via the OBDATA.DAT section of TFTDextender. (Suggestion: don't fix it. The useless Dart Gun is all part of the "oh no we're all gonna die" experience of the beginning of TFTD.)<br />
* Does not improve the armour and effectiveness of the basic Aqua-Jet and Gas Cannon Coelecanths (it does upgrade the Coelecanth/Gauss). (Again, suggestion: this is a good thing - XCOM should start the game hopelessly outclassed, and scramble to catch up).<br />
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.<br />
* Does not allow you to have 360 degree vision out of your sub before exiting it. (What kind of coward would want that?). XComUtil does this.<br />
<br />
= Feature Requests and Suggestions =<br />
<br />
== Useful alien species research ==<br />
<br />
Tycho, I really like this idea you proposed in the StrategyCore forum:<br />
<br />
:I'm thinking about giving a hp bonus to all aliens until Xcom performs an autopsy on the species to learn the location of their vital organs (like in the movie "Battle of LA"). This would give more importance to performing autopsies rather than just as a stepping stone to new tech.<br />
<br />
Definite +1. It would be equally valid to add to UFO Extender. I suppose it could also be implemented using Vulnerabilities (no Vulnerabilities are in effect until the Autopsy is completed), or Resistances (across-the-board increased Resistances until Autopsy is completed). If that's easier. <br />
<br />
:''The bonus to hp was an initial thought. Later, I decided against it since it would make aliens more resistant to HE and stun, which don't rely on hitting the right locations. Increasing resistances would be the most appropriate but the damage routine code is very tight and adding anything new that won't break the existing variable stack pointers is tough.'' [[User:Morgan525|Tycho]]<br />
::''A new idea for this that I recently have been toying with, would be on the damage generation routine: Most direct fire damage is 0-200%, with anything over 100% considered a "critical hit". If autopsy hasn't been preformed, then the base damage would be 0-100% and a small chance (maybe 25%) of another 0-100% for that lucky shot. With autopsy done, the game reverts back to the usual 0-200% on any hit.''<br />
<br />
::: That works. And it makes doing Alien Autopsies a no-brainer, as it should be. It is pretty much inconceivable that XCom wouldn't prioritise the autopsy of any newly encountered alien. And any player playing the game for the first time would do autopsies too. This mod will help experienced players to stop playing as if they've "seen it all before". [[User:Spike|Spike]] 10:35, 15 September 2012 (EDT)<br />
<br />
Would it also be worth adding some kind of bonus for Live Alien research? Maybe the negation of some kind of Morale penalty and/or Psi penalty? Fear of the unknown, know your enemy, that kind of thing?<br />
<br />
:''I thought about that but the game doesn't record live aliens that have been researched. When you finish research on a live alien, it only follows the routine to unlock the appropriate UFOpaedia articles and then checks to see if the finished research can unlock other topics.'' [[User:Morgan525|Tycho]]<br />
<br />
I had a further thought on this while trying to guess what your new pre-requisites are for the various armours. For now it's really cool to be guessing but once people have figured it out, well, it will be more logical but still will have 'replay fatigue'. Would it be possible to randomise the pre-requisites for a lot of the key research topics, from out of a plausible list of items (or even randomise pre-requisite topics)? That would make every game fresh in terms of the research sequence, and make the research aspect of the game more challenging and less dry & predictable. As ever, just a suggestion. :) Cheers, [[User:Spike|Spike]] 16:01, 19 October 2012 (EDT)<br />
<br />
== All Units Can "Fly" In Water ==<br />
<br />
It's very illogical that most units are stuck on the seabed in underwater missions. Please provide the option to set all units (X-Com and alien) to have "flying" (i.e. swimming) ability when underwater. This is unlikely to cause an outbreak of 3D combat, since there is no cover except at seabed level, so anyone swimming excessively or incautiously is going to get shot. It might disadvantage the aliens if their tactical map waypoints are all set on the surface. But as some of them can "fly", there is hopefully a mechanism to deal with that in the code already. For me it will just solve the frustration of being unable to swim over small obstacles or swim up a level, and being stuck or tactically limited for no sensible reason. Mag-Ion Armour remains useful as an important step in Sub Research and (if using the Everything Works on Land mod) for land use. [[User:Spike|Spike]] 11:36, 9 September 2012 (EDT)<br />
: This requires setting [[UNITREF.DAT]] byte 0x78 bit 2 for the unit (e.g. for all units on both sides). Or the in-memory equivalent of UNITREF.DAT. [[User:Spike|Spike]] 10:19, 5 October 2012 (EDT)<br />
<br />
== Aliens Pick Up Weapons ==<br />
<br />
Related to Improved Alien AI. This makes the game tougher as stunned / panicked bipedal-type aliens are no longer permanently disarmed. This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. A fix for this would be a very helpful rebalancing of both games that eliminates one of the aliens' weak spots. The existing (but unused) routine looks pretty smart and not immediately exploitable to ambush aliens using weapons as traps. <br />
<br />
: I noticed the UFO Extender source code has a 'get' keyword under the OBDATA.DAT directive that populates this field 0x2D. Is that working? [[User:Spike|Spike]] 21:03, 16 October 2012 (EDT)<br />
<br />
== General Tank Modding ==<br />
<br />
I see you are interested in modding tanks (HWPs/SWPs) and that's partly what got you into updating UFO Extender. I made some suggestions for Tank Modding myself, including some of the mechanics required to make it work via a config file such as the UFO / TFD Extender config file. For example you could have cargo carrier / ambulance / casevac tanks, you could have demolition tanks, mine thrower tanks, and of course tanks with custom weapons including dual weapons. Could you have a look here: [[User:Spike#Tank_mods]] and see if any of that makes you feel like getting creative?<br />
<br />
Thanks,<br />
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)<br />
<br />
== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==<br />
<br />
Hook the right and left weapon menus on mind controlled aliens to add in actions for their built in melee attacks (if they have them) and built in Psi/MC attacks (if they have Psi/MC Skill). Ideally add these actions to the menu, and pop up a menu, even if the alien isn't holding any weapons.<br />
<br />
This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.<br />
<br />
== Fix Interception and Navigation Course Algorithms ==<br />
<br />
Or just find the algorithms and I volunteer to fix them!<br />
<br />
=== Use Great Circle Routes ===<br />
<br />
Travel toward the target on the shortest Great Circle, rather than always travelling along lines of latitude first (like they are some kind of main bus route!). <br />
<br />
=== Use Predictive Interception ===<br />
<br />
For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.<br />
<br />
=== Show Degree Headings ===<br />
<br />
The game only ever reports alien headings as North, South, East, West, but clearly alien craft move in other directions than just these four, and clearly XCOM detection equipment is capable of resolving these finer-grained headings, since the crafts' tracks are shown correctly in the Geoscope. <br />
As a first step towards predictive interceptions, it would be great to display the alien craft's heading in degrees, eg 135 degrees for South-East. Maybe rounded to the nearest 5 or 10 degrees.<br />
<br />
== Interception Craft vs Touched Down Alien Craft == <br />
<br />
If an alien craft is touched down and an XCOM interception craft (not touched down) is at the same X/Y position, if the alien craft begins to move, immediately open the Interception window at minimum range (8km/nm), presumably with the alien attempting to get away / break off. Currently the Interception window only happens if the XCom craft is faster, which is dumb, ''even if'' the alien craft could accelerate instantly to its maximum speed. <br />
<br />
For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach. <br />
<br />
== Fun, not Funky, Fire ==<br />
<br />
An alternative option for incendiaries/phosphorous damage processing: Do process the so called 'impact' damage of an incendiary on every shot, not just at the end of the turn. But only apply it to those in the area of affect of this specific shell burst, not to all units who are standing in smoke or fire anywhere on the map. This will please fans of incendiaries/phosphorous. It's probably a balancing, rather than unbalancing, change in the relative strengths of the ammo types. Makes incendiaries/phosphorous useful for more than just illumination or desperation. Gives some use to the research topics that advise use of incendiaries/phosphorous, and the damage modifiers aliens have been assigned.<br />
<br />
== Rearming Rates ==<br />
<br />
<br />
From [[Known_Bugs_(TFTD)#Geoscape_Bugs]]:<br />
<br />
=== Craft Gauss Cannon Rearming Rate ===<br />
<br />
This weapon rearms at 10/hr but probably should be 50/hr or at least 25/hr, otherwise it is far slower to rearm than any other cannon weapon in either game. In fact it's the second slowest weapon system to rearm, slower only than AJAX...<br />
<br />
=== AJAX Rearming Rate ===<br />
<br />
An AJAX system takes twice as long to fully reload as a D.U.P. system, as a result AJAX-armed Craft have much worse operational tempo and readiness than D.U.P. armed Craft. Like we needed yet another reason to always use D.U.Ps. This is probably a design error rather than a bug, but it would be good to fix it - anything to give a more balanced set of craft weapon choices. The rearming rate should be raised from 1/hr to 2/hr. The AJAX system will then have the same operational tempo as the D.U.P. system. <br />
<br />
Could also be applied to Stingray missiles in EU 1994, as the same analysis applies to Stingray vs Avalanche.<br />
<br />
== Retaliate for Colony Assault ==<br />
<br />
See this discussion [[Talk:Alien_Retaliation#Retaliation_Triggers]]. Colony raids are a good way for the alien to lose badly, so it would be a good balancing move to create severe consequences for raiding. It is at least as sensible as retaliation for USO Assaults.</div>
Spike
https://www.ufopaedia.org/index.php?title=Talk:TFTDextender&diff=40333
Talk:TFTDextender
2012-10-24T12:25:43Z
<p>Spike: /* Retaliate for Colony Assault = */</p>
<hr />
<div>=Questions or Comments=<br />
'''A place to provide feedback or ask questions:'''<br />
<br />
The zip archive does not seem to include an .ini file. Where do I get the .ini file from? <br />
:: Oh hang on. It looks like the latest version of the zip file does not include the .ini file. When I go back to the previous version of the zip file, I can see the .ini file. [[User:Spike|Spike]] 17:45, 6 September 2012 (EDT)<br />
<br />
:::''The latest release is a patch, which means there are no new additions to the INI. I don't include it in patches usually so that those who already have the prior release don't have to reconfigure their current INI. It may not seem like a big deal now but earlier, I was releasing fixes almost on a weekly basis and so I still continue with that idea.''[[User:Morgan525|Tycho]]<br />
<br />
== Bug Reports ==<br />
<br />
=== Crash when starting a landed/crashed USO battle ===<br />
<br />
:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."<br />
<br />
''Interesting. I had someone report a similar thing when they were starting their first instance of the battlescape on a new install of the game. I looked into it and the game generated some bad data. When he let the UFO take off and land again, the battle started with no problems..''<br />
<br />
:It's [[Known_Bugs_(TFTD)#Geoscape_Bugs|a bug I've reported before]] (before TFTD Extender even existed), so it's not specific to TFTDExtender / UFOExtender. What is happening is the Alien Sub is landing on land, and the Triton is also attempting to land on land. Probably the game crashes when it fails to generate the appropriate terrain type? So the GEOSCAPE map/terrain data must be corrupted. I've seen three examples of this. In a couple of cases the landing site is clearly inland, by hundreds of kilometres. In some cases it's right on the sea/land boundary and hard to tell. I have two save games that reproduce the bug now. From memory, the previous cases all happened around North Africa, like these present cases. [[User:Spike|Spike]] 08:31, 9 September 2012 (EDT)<br />
<br />
:''I think the problem is that there is no database to reference what type of terrain to load. EU would reference this based on map coordinates. Since USO aren't usually engaged over land, the map generator can't get an appropriate tileset for the location in these cases.-[[User:Morgan525|Tycho]]''<br />
<br />
=== Cannot build Leviathan ===<br />
<br />
Hi Tycho. I've just researched Leviathan in my TFDExtender game but cannot manufacture it! I have enough resources (Plastics, IBA, ManNav), 3 workshops, more than 100 technicans and one empty sub pen. But when starting the Leviathan manufacture task I cannot assign any technicans to it. I press the "up" button, and there are no reaction to this. I can build Manta, but not Leviathan. Don't you know what is it? [[User:PavelB|PavelB]] 06:55, 2 October 2012 (EDT)<br />
<br />
: Double check that you have sufficient cash to start the project, iirc $600K or so. That matches this symptom. Also that you have enough workshop space available (Leviathan needs a lot of space). Failing that, cancel all existing manufacturing projects, then retry. Failing that you could try reducing Technicians below 100 but that's taking us into Bug territory. [[User:Spike|Spike]] 07:17, 2 October 2012 (EDT)<br />
<br />
:: Resources are 100% enough. I've launched "Terror from the Deep.exe", loaded this saved game and started manufacturing Lev without any problems. I've saved this variant with Lev being manufactured and then loaded it from "TFTDextender.exe". As a result the process was okey, but I could only decrease the number of technicans working on it, not increase (even after decreasing!). That is: with 64 technicans had been assigned, I've pressed the "down" button, and the number changed to 63. But then I was unable to revert it to 64 by pressing "up" button: it didn't work! [[User:PavelB|PavelB]] 07:57, 2 October 2012 (EDT)<br />
:''I'll check into it. Although, I can't understand how changes to the research tree would affect production. Unless it has something to do with the autoproduce feature?''<br />
:'''This problem may be fixed with the same patch that fixed the production materials being deducted from the wrong base. Can anyone confirm?'''- - [[User:Morgan525|Tycho]] 23:12, 17 October 2012 (EDT)<br />
:: If I try to replicate PavelB's situation, I am able to build a Leviathan with no problems using the latest build. However I am also able to build a Leviathan using the 1.05p1.1 build. So I'm not able to replicate his original problem unfortunately. [[User:Spike|Spike]] 19:18, 19 October 2012 (EDT)<br />
<br />
== Minor Bugs ==<br />
<br />
=== Weightless Ammo Bug ===<br />
<br />
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)<br />
<br />
''From what I understand right now, I am pretty sure I can arrange it so that weapons are not automatically loaded and soldiers would be given an extra clip. Feedback?''<br />
: By an extra clip, you mean the clip/ammo that would have been loaded into the weapon is instead carried by the soldier? And for carried clips, the encumbrance effects are correct. For me anyway, in order of most benefit, the options would be<br />
:# Fix the root cause of the bug (ensure all relevant object locations and "contains/contained in" pointers are set during automatic clip loading) so that automatically loaded clips correctly affect encumbrance <br />
:# As a workaround, don't load ammo for multi-ammotype weapons (Heavy Cannon/Gas Cannon, Auto-Cannon/Hydrojet Cannon, Rocket Launcher / Torpedo Launcher). These are the weapons for which the bug has the greatest impact, since it imposes a 'cost' of switching away from the automatically-loaded ammo (usually AP or Small Rocket/Torp). With single-ammotype weapons, there's never any need to change the clips before combat. <br />
:# As a workaround, don't load ammo for any weapons. This avoids the 'switching cost' issue but does impose a fairly significant logistics overhead on each combat, to go through and manually load all clips. Plus the risk that you forget to load a weapon and only find out at a critical moment. :) This is for the "purist" who wants to make the game harder.<br />
:If it's tricky to fix the root cause, any of the other two options would be helpful. Suggested text:<br />
:* [Multi Ammo Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. Weapons using multiple ammo types (Heavy Cannon, Auto-Cannon, Rocket Launcher / Gas Cannon, Hydrojet Cannon, Torpedo Launcher) will not be pre-loaded before combat. You will need to load these weapons manually during the pre-combat Equip phase. This will significantly affect the heavy weapons ammunition load your squad can carry into combat without suffering encumbrance penalties, thus making the early game harder.<br />
:* [All Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. This option overrides the previous option. No weapons will be pre-loaded before combat. You will need to load all ammo manually during the pre-combat Equip phase. This will significantly affect the ammunition load your squad can carry into combat without suffering encumbrance penalties, making the early game harder.<br />
:[[User:Spike|Spike]] 05:10, 21 September 2012 (EDT)<br />
::''I found the source of the problem: None of the subroutines for inventory consider the clips in weapons so their entries in OBPOS.DAT are never updated. So when clips are autoloaded at the beginning of each battle, they have no owner. I've got the code to sync the ownership of clips with the weapon they are loaded into at the beginning of each battle and to update the clips when changed in inventory management.-''[[User:Morgan525|Tycho]] 19:00, 19 October 2012 (EDT)<br />
::: That is just awesome! :D [[User:Spike|Spike]] 22:36, 19 October 2012 (EDT)<br />
<br />
=== MIA Bugs ===<br />
<br />
==== Supernumary MIA on Abort ====<br />
<br />
I Abort a mission with 8 Aquanauts and get the confirmation message "8 Aquanauts inside craft, 2 outside". No one has been stunned or MCd. I did have two aquanauts, only, outside, but they have moved back inside the transport. Very odd. Saved Equipment was enabled. [[User:Spike|Spike]] 11:06, 5 October 2012 (EDT)<br />
<br />
:''How many Aquanauts did you have in total?- -''[[User:Morgan525|Tycho]] 02:54, 11 October 2012 (EDT)<br />
:: I started the mission with only 8 Aquanauts and they all survived. Only two had even been outside the transport (quite an unusual situation). However I can't reproduce this bug, so please ignore it unless/until I can reproduce it. :) [[User:Spike|Spike]] 06:48, 17 October 2012 (EDT)<br />
<br />
==== Stunned Carried Aquanauts MIA on Abort ====<br />
<br />
While you are looking the EOB script, I noticed one more anomaly. I'm not sure if this is an original bug or an Extender bug. If you are carrying a stunned Aquanaut in the transport at the time of Abort, the stunned Aquanaut is lost (MIA). You have to drop the stunned Aquanaut on the floor. Probably this is because the position of the Aquanaut has not been updated and is still pointing to where they were stunned, not to the location of the carrying Aquanaut. [[User:Spike|Spike]] 04:49, 27 September 2012 (EDT)<br />
<br />
:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. At least it is manageable: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)<br />
<br />
==== Crewed Flying Sub Lost on Abort ====<br />
<br />
Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)<br />
<br />
:Presumably the 3 aquanauts in the craft were not stunned or mind controlled on the Abort turn? [[User:Spike|Spike]] 16:37, 21 October 2012 (EDT)<br />
:Right, they are not stunned (or dead) and they are under your control. And they are definitely in the sub. OK this is similar to a minor bug I have seen before - see [[#Supernumary MIA on Abort|preceding item]]. On your pre-abort confirmation screen it says "3 units in craft, 9 units outside". I've had a similar issue before. It's double counting your aquanauts as being both inside and outside the craft on the confirm screen, since you only have 9 units (8 and 1 tank) in total. On actual abort you incorrectly get 9 MIAs (including the tank presumably) and I guess that's why you lose the sub. Interestingly, the 3 affected aquanauts look like they never moved from their original positions, is that true? I believe when I've had similar problems before, it related to aquanauts who had never left the sub / never left their initial positions. We will have to see if Tycho can get to the bottom of this one. [[User:Spike|Spike]] 16:51, 21 October 2012 (EDT)<br />
::Yes, that's true - those 3 haven't moved from their original positions. --[[User:Player701|Player701]] 17:19, 21 October 2012 (EDT)<br />
<br />
=== Items on transport floor lost ===<br />
<br />
I went in to a mission with ten Sonic Cannons and came back with 3, despite retrieving them from the battlefield and dumping them on the transport floor. I only had 3 aquanauts on the transport armed with Sonic Cannon at the time of abort. The rest were stunned or unarmed. I also dumped half a dozen corpses and some alien items on the transport floor and I don't think those made it back to my base either. The transport was operating from base 2 rather than base 1, in case that's a factor. This may be an original bug of course. I just read through the multiplayer TFTD LP on StrategyCore, and they reported missing equipment on a lot of missions. I can go back and check if the missing equipment was on abort missions rather than victory missions. Sorry not to provide more specifics at this time but it was a hard mission and not exactly a controlled experiment. ;) [[User:Spike|Spike]] 21:35, 23 October 2012 (EDT)<br />
<br />
<br />
=== Weight Display in Inventory not Localised ===<br />
<br />
At least when I run the game in German, it comes up as "Weight" and not something like "Gewicht". Reactions comes up ok as "Zeitwerte". [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
<br />
:''There is no entry in the text DAT files for "weight". Seb had to add the text string for it into his subroutine. Thanks for pointing it out.'' [[User:Morgan525|Tycho]]<br />
<br />
== Save Equipment not working? ==<br />
<br />
With "Save Equipment" option enabled, the soldiers' loadout at first was always like this: grenade in leg slot, clip in backpack - and it didn't change on the next mission, despite the fact that I re-equipped the soldiers correctly (grenades and clips on the belt). When I manufactured Gauss Rifles and issued them to my soldiers, it got even worse - none of the soldiers got clips, and two of the rifles were unloaded. Next I upgraded to Sonic-Blasta Rifles and now nothing, except some grenades (still in leg slots), is issued to the soldiers at all. "Save Equipment" was known to work in UFOExtender, did something get broken? --[[User:Player701|Player701]] 09:18, 21 October 2012 (EDT)<br />
<br />
:''Yes. Something is broken but not by the Extender. Many subroutines, their order of execution, or variable were modified in the TFTD game code. Problems like these are deducing what changed in the game code and what changes are needed to get the UFOextender code to work. See the discussion on problems with the OBDATA mod about the final source of the problem and its solution.-[[User:Morgan525|Tycho]] 20:03, 21 October 2012 (EDT)''<br />
<br />
:: Would you suggest that everyone disables Save Equipment for the time being, in TFTDextender? [[User:Spike|Spike]] 07:44, 24 October 2012 (EDT)<br />
<br />
=Resolved Problems=<br />
<br />
===<s> Executable directive </s>===<br />
''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)<br />
<br />
=== <s>Extra Artefacts Reported</s> ===<br />
''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)<br />
''This will be fixed in the next release.-''[[User:Morgan525|Tycho]] 03:00, 13 October 2012 (EDT)<br />
: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
===<s>Manufacturing Projects Minimum Production</s> ===<br />
<br />
In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''<br />
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)<br />
<br />
Tested - If I reduce the production quantity of a current production run to less than what as already been produced, the display completion time changes (incorrectly) to 'Indefinite', but production ends after completion of the next unit. So if I start by producing 10 units, wait until I have produced 2, then reduce the quantity to 2 (or probably 1), production stops after 3 units. Thies basically replicates the pre-existing behaviour when using the down arrow on the Quantity, so there has been no loss of functionality with your Mod. Also, Autosell and Autoproduce work normally when applied as changes to an existing production run. The only thing is I can't distinguish them on the Manufacturing display - both say 'unlimited' quantity and 'indefinite' period - is that intended? I suppose it makes sense, but it would be good to be able to tell which kind of production it is, *** Autoproduce or $$$ Autosell. [[User:Spike|Spike]] 08:57, 2 October 2012 (EDT)<br />
<br />
:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''<br />
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)<br />
:::''OK. Changed the output to display "$unlimited$".[[User:Morgan525|Tycho]]<br />
<br />
===<s>Stunned MC'd Aquanauts MIA on Abort </s> ===<br />
<br />
This is a subset of MC'd Aquanauts go MIA [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]. In this case Aquanauts are MC'd by the aliens, then stunned (by friendlies), then the mission is Aborted with the stunned X-Com Aquanauts aboard the transport. The Aquanauts then disappear from the roster forever. I'm not sure if it's due to Abort rather than Victory, or due to them being stunned first. <br />
::''I now have the code in place to uncontrol any creature that has been rendered unconscious. - -''[[User:Morgan525|Tycho]] 02:47, 11 October 2012 (EDT)<br />
This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
=== <s>Grenade Resistance in INI file </s> ===<br />
:''I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]<br />
<br />
<br />
===<s> Materials deducted from wrong base </s>===<br />
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''<br />
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)<br />
<br />
===<s> OBDATA / Dye Grenade mod not working? </s>===<br />
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)<br />
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
== <s>Displacer/Sonic damage fix</s> ==<br />
<br />
'' I changed the damage to be 130, same as the UFOpaedia entry.-''[[User:Morgan525|Tycho]] 03:52, 13 October 2012 (EDT)<br />
<br />
<br />
== Things that TFTDextender does not fix ==<br />
<br />
Just more or less as a note to the reader, TFTDextender does not fix some of the following things that are sometimes thought of as needing fixing (and this is probably deliberate?):<br />
<br />
* Does not fix the apparent swap of the ground map for the VERY SMALL Survey Ship (1 occupant) with the SMALL Escort (half-dozen or more occupants). So you get the VERY SMALL sub occupying about 25 squares of usable area on the Battlescape, and the supposedly larger SMALL sub occupying one square of usable area on the Battlescape, begging the question of how all those aliens got inside there in the first place. XcomUtil will fix this, as will the original patches that XcomUtil incorporates.<br />
* Does not fix the incorrect pictures for the large USO in the interception window. <br />
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]<br />
* Does not fix the Dart Gun to make it any less utterly useless. Though you can do this yourself via the OBDATA.DAT section of TFTDextender. (Suggestion: don't fix it. The useless Dart Gun is all part of the "oh no we're all gonna die" experience of the beginning of TFTD.)<br />
* Does not improve the armour and effectiveness of the basic Aqua-Jet and Gas Cannon Coelecanths (it does upgrade the Coelecanth/Gauss). (Again, suggestion: this is a good thing - XCOM should start the game hopelessly outclassed, and scramble to catch up).<br />
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.<br />
* Does not allow you to have 360 degree vision out of your sub before exiting it. (What kind of coward would want that?). XComUtil does this.<br />
<br />
= Feature Requests and Suggestions =<br />
<br />
== Useful alien species research ==<br />
<br />
Tycho, I really like this idea you proposed in the StrategyCore forum:<br />
<br />
:I'm thinking about giving a hp bonus to all aliens until Xcom performs an autopsy on the species to learn the location of their vital organs (like in the movie "Battle of LA"). This would give more importance to performing autopsies rather than just as a stepping stone to new tech.<br />
<br />
Definite +1. It would be equally valid to add to UFO Extender. I suppose it could also be implemented using Vulnerabilities (no Vulnerabilities are in effect until the Autopsy is completed), or Resistances (across-the-board increased Resistances until Autopsy is completed). If that's easier. <br />
<br />
:''The bonus to hp was an initial thought. Later, I decided against it since it would make aliens more resistant to HE and stun, which don't rely on hitting the right locations. Increasing resistances would be the most appropriate but the damage routine code is very tight and adding anything new that won't break the existing variable stack pointers is tough.'' [[User:Morgan525|Tycho]]<br />
::''A new idea for this that I recently have been toying with, would be on the damage generation routine: Most direct fire damage is 0-200%, with anything over 100% considered a "critical hit". If autopsy hasn't been preformed, then the base damage would be 0-100% and a small chance (maybe 25%) of another 0-100% for that lucky shot. With autopsy done, the game reverts back to the usual 0-200% on any hit.''<br />
<br />
::: That works. And it makes doing Alien Autopsies a no-brainer, as it should be. It is pretty much inconceivable that XCom wouldn't prioritise the autopsy of any newly encountered alien. And any player playing the game for the first time would do autopsies too. This mod will help experienced players to stop playing as if they've "seen it all before". [[User:Spike|Spike]] 10:35, 15 September 2012 (EDT)<br />
<br />
Would it also be worth adding some kind of bonus for Live Alien research? Maybe the negation of some kind of Morale penalty and/or Psi penalty? Fear of the unknown, know your enemy, that kind of thing?<br />
<br />
:''I thought about that but the game doesn't record live aliens that have been researched. When you finish research on a live alien, it only follows the routine to unlock the appropriate UFOpaedia articles and then checks to see if the finished research can unlock other topics.'' [[User:Morgan525|Tycho]]<br />
<br />
I had a further thought on this while trying to guess what your new pre-requisites are for the various armours. For now it's really cool to be guessing but once people have figured it out, well, it will be more logical but still will have 'replay fatigue'. Would it be possible to randomise the pre-requisites for a lot of the key research topics, from out of a plausible list of items (or even randomise pre-requisite topics)? That would make every game fresh in terms of the research sequence, and make the research aspect of the game more challenging and less dry & predictable. As ever, just a suggestion. :) Cheers, [[User:Spike|Spike]] 16:01, 19 October 2012 (EDT)<br />
<br />
== All Units Can "Fly" In Water ==<br />
<br />
It's very illogical that most units are stuck on the seabed in underwater missions. Please provide the option to set all units (X-Com and alien) to have "flying" (i.e. swimming) ability when underwater. This is unlikely to cause an outbreak of 3D combat, since there is no cover except at seabed level, so anyone swimming excessively or incautiously is going to get shot. It might disadvantage the aliens if their tactical map waypoints are all set on the surface. But as some of them can "fly", there is hopefully a mechanism to deal with that in the code already. For me it will just solve the frustration of being unable to swim over small obstacles or swim up a level, and being stuck or tactically limited for no sensible reason. Mag-Ion Armour remains useful as an important step in Sub Research and (if using the Everything Works on Land mod) for land use. [[User:Spike|Spike]] 11:36, 9 September 2012 (EDT)<br />
: This requires setting [[UNITREF.DAT]] byte 0x78 bit 2 for the unit (e.g. for all units on both sides). Or the in-memory equivalent of UNITREF.DAT. [[User:Spike|Spike]] 10:19, 5 October 2012 (EDT)<br />
<br />
== Aliens Pick Up Weapons ==<br />
<br />
Related to Improved Alien AI. This makes the game tougher as stunned / panicked bipedal-type aliens are no longer permanently disarmed. This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. A fix for this would be a very helpful rebalancing of both games that eliminates one of the aliens' weak spots. The existing (but unused) routine looks pretty smart and not immediately exploitable to ambush aliens using weapons as traps. <br />
<br />
: I noticed the UFO Extender source code has a 'get' keyword under the OBDATA.DAT directive that populates this field 0x2D. Is that working? [[User:Spike|Spike]] 21:03, 16 October 2012 (EDT)<br />
<br />
== General Tank Modding ==<br />
<br />
I see you are interested in modding tanks (HWPs/SWPs) and that's partly what got you into updating UFO Extender. I made some suggestions for Tank Modding myself, including some of the mechanics required to make it work via a config file such as the UFO / TFD Extender config file. For example you could have cargo carrier / ambulance / casevac tanks, you could have demolition tanks, mine thrower tanks, and of course tanks with custom weapons including dual weapons. Could you have a look here: [[User:Spike#Tank_mods]] and see if any of that makes you feel like getting creative?<br />
<br />
Thanks,<br />
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)<br />
<br />
== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==<br />
<br />
Hook the right and left weapon menus on mind controlled aliens to add in actions for their built in melee attacks (if they have them) and built in Psi/MC attacks (if they have Psi/MC Skill). Ideally add these actions to the menu, and pop up a menu, even if the alien isn't holding any weapons.<br />
<br />
This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.<br />
<br />
== Fix Interception and Navigation Course Algorithms ==<br />
<br />
Or just find the algorithms and I volunteer to fix them!<br />
<br />
=== Use Great Circle Routes ===<br />
<br />
Travel toward the target on the shortest Great Circle, rather than always travelling along lines of latitude first (like they are some kind of main bus route!). <br />
<br />
=== Use Predictive Interception ===<br />
<br />
For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.<br />
<br />
=== Show Degree Headings ===<br />
<br />
The game only ever reports alien headings as North, South, East, West, but clearly alien craft move in other directions than just these four, and clearly XCOM detection equipment is capable of resolving these finer-grained headings, since the crafts' tracks are shown correctly in the Geoscope. <br />
As a first step towards predictive interceptions, it would be great to display the alien craft's heading in degrees, eg 135 degrees for South-East. Maybe rounded to the nearest 5 or 10 degrees.<br />
<br />
== Interception Craft vs Touched Down Alien Craft == <br />
<br />
If an alien craft is touched down and an XCOM interception craft (not touched down) is at the same X/Y position, if the alien craft begins to move, immediately open the Interception window at minimum range (8km/nm), presumably with the alien attempting to get away / break off. Currently the Interception window only happens if the XCom craft is faster, which is dumb, ''even if'' the alien craft could accelerate instantly to its maximum speed. <br />
<br />
For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach. <br />
<br />
== Fun, not Funky, Fire ==<br />
<br />
An alternative option for incendiaries/phosphorous damage processing: Do process the so called 'impact' damage of an incendiary on every shot, not just at the end of the turn. But only apply it to those in the area of affect of this specific shell burst, not to all units who are standing in smoke or fire anywhere on the map. This will please fans of incendiaries/phosphorous. It's probably a balancing, rather than unbalancing, change in the relative strengths of the ammo types. Makes incendiaries/phosphorous useful for more than just illumination or desperation. Gives some use to the research topics that advise use of incendiaries/phosphorous, and the damage modifiers aliens have been assigned.<br />
<br />
== Rearming Rates ==<br />
<br />
<br />
From [[Known_Bugs_(TFTD)#Geoscape_Bugs]]:<br />
<br />
=== Craft Gauss Cannon Rearming Rate ===<br />
<br />
This weapon rearms at 10/hr but probably should be 50/hr or at least 25/hr, otherwise it is far slower to rearm than any other cannon weapon in either game. In fact it's the second slowest weapon system to rearm, slower only than AJAX...<br />
<br />
=== AJAX Rearming Rate ===<br />
<br />
An AJAX system takes twice as long to fully reload as a D.U.P. system, as a result AJAX-armed Craft have much worse operational tempo and readiness than D.U.P. armed Craft. Like we needed yet another reason to always use D.U.Ps. This is probably a design error rather than a bug, but it would be good to fix it - anything to give a more balanced set of craft weapon choices. The rearming rate should be raised from 1/hr to 2/hr. The AJAX system will then have the same operational tempo as the D.U.P. system. <br />
<br />
Could also be applied to Stingray missiles in EU 1994, as the same analysis applies to Stingray vs Avalanche.<br />
<br />
== Retaliate for Colony Assault ==<br />
<br />
See this discussion [[Talk:Alien_Retaliation#Retaliation_Triggers]]. Colony raids are a good way for the alien to lose badly, so it would be a good balancing move to create severe consequences for raiding. It is at least as sensible as retaliation for USO Assaults.</div>
Spike
https://www.ufopaedia.org/index.php?title=Talk:TFTDextender&diff=40332
Talk:TFTDextender
2012-10-24T12:24:49Z
<p>Spike: /* Feature Requests and Suggestions */</p>
<hr />
<div>=Questions or Comments=<br />
'''A place to provide feedback or ask questions:'''<br />
<br />
The zip archive does not seem to include an .ini file. Where do I get the .ini file from? <br />
:: Oh hang on. It looks like the latest version of the zip file does not include the .ini file. When I go back to the previous version of the zip file, I can see the .ini file. [[User:Spike|Spike]] 17:45, 6 September 2012 (EDT)<br />
<br />
:::''The latest release is a patch, which means there are no new additions to the INI. I don't include it in patches usually so that those who already have the prior release don't have to reconfigure their current INI. It may not seem like a big deal now but earlier, I was releasing fixes almost on a weekly basis and so I still continue with that idea.''[[User:Morgan525|Tycho]]<br />
<br />
== Bug Reports ==<br />
<br />
=== Crash when starting a landed/crashed USO battle ===<br />
<br />
:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."<br />
<br />
''Interesting. I had someone report a similar thing when they were starting their first instance of the battlescape on a new install of the game. I looked into it and the game generated some bad data. When he let the UFO take off and land again, the battle started with no problems..''<br />
<br />
:It's [[Known_Bugs_(TFTD)#Geoscape_Bugs|a bug I've reported before]] (before TFTD Extender even existed), so it's not specific to TFTDExtender / UFOExtender. What is happening is the Alien Sub is landing on land, and the Triton is also attempting to land on land. Probably the game crashes when it fails to generate the appropriate terrain type? So the GEOSCAPE map/terrain data must be corrupted. I've seen three examples of this. In a couple of cases the landing site is clearly inland, by hundreds of kilometres. In some cases it's right on the sea/land boundary and hard to tell. I have two save games that reproduce the bug now. From memory, the previous cases all happened around North Africa, like these present cases. [[User:Spike|Spike]] 08:31, 9 September 2012 (EDT)<br />
<br />
:''I think the problem is that there is no database to reference what type of terrain to load. EU would reference this based on map coordinates. Since USO aren't usually engaged over land, the map generator can't get an appropriate tileset for the location in these cases.-[[User:Morgan525|Tycho]]''<br />
<br />
=== Cannot build Leviathan ===<br />
<br />
Hi Tycho. I've just researched Leviathan in my TFDExtender game but cannot manufacture it! I have enough resources (Plastics, IBA, ManNav), 3 workshops, more than 100 technicans and one empty sub pen. But when starting the Leviathan manufacture task I cannot assign any technicans to it. I press the "up" button, and there are no reaction to this. I can build Manta, but not Leviathan. Don't you know what is it? [[User:PavelB|PavelB]] 06:55, 2 October 2012 (EDT)<br />
<br />
: Double check that you have sufficient cash to start the project, iirc $600K or so. That matches this symptom. Also that you have enough workshop space available (Leviathan needs a lot of space). Failing that, cancel all existing manufacturing projects, then retry. Failing that you could try reducing Technicians below 100 but that's taking us into Bug territory. [[User:Spike|Spike]] 07:17, 2 October 2012 (EDT)<br />
<br />
:: Resources are 100% enough. I've launched "Terror from the Deep.exe", loaded this saved game and started manufacturing Lev without any problems. I've saved this variant with Lev being manufactured and then loaded it from "TFTDextender.exe". As a result the process was okey, but I could only decrease the number of technicans working on it, not increase (even after decreasing!). That is: with 64 technicans had been assigned, I've pressed the "down" button, and the number changed to 63. But then I was unable to revert it to 64 by pressing "up" button: it didn't work! [[User:PavelB|PavelB]] 07:57, 2 October 2012 (EDT)<br />
:''I'll check into it. Although, I can't understand how changes to the research tree would affect production. Unless it has something to do with the autoproduce feature?''<br />
:'''This problem may be fixed with the same patch that fixed the production materials being deducted from the wrong base. Can anyone confirm?'''- - [[User:Morgan525|Tycho]] 23:12, 17 October 2012 (EDT)<br />
:: If I try to replicate PavelB's situation, I am able to build a Leviathan with no problems using the latest build. However I am also able to build a Leviathan using the 1.05p1.1 build. So I'm not able to replicate his original problem unfortunately. [[User:Spike|Spike]] 19:18, 19 October 2012 (EDT)<br />
<br />
== Minor Bugs ==<br />
<br />
=== Weightless Ammo Bug ===<br />
<br />
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)<br />
<br />
''From what I understand right now, I am pretty sure I can arrange it so that weapons are not automatically loaded and soldiers would be given an extra clip. Feedback?''<br />
: By an extra clip, you mean the clip/ammo that would have been loaded into the weapon is instead carried by the soldier? And for carried clips, the encumbrance effects are correct. For me anyway, in order of most benefit, the options would be<br />
:# Fix the root cause of the bug (ensure all relevant object locations and "contains/contained in" pointers are set during automatic clip loading) so that automatically loaded clips correctly affect encumbrance <br />
:# As a workaround, don't load ammo for multi-ammotype weapons (Heavy Cannon/Gas Cannon, Auto-Cannon/Hydrojet Cannon, Rocket Launcher / Torpedo Launcher). These are the weapons for which the bug has the greatest impact, since it imposes a 'cost' of switching away from the automatically-loaded ammo (usually AP or Small Rocket/Torp). With single-ammotype weapons, there's never any need to change the clips before combat. <br />
:# As a workaround, don't load ammo for any weapons. This avoids the 'switching cost' issue but does impose a fairly significant logistics overhead on each combat, to go through and manually load all clips. Plus the risk that you forget to load a weapon and only find out at a critical moment. :) This is for the "purist" who wants to make the game harder.<br />
:If it's tricky to fix the root cause, any of the other two options would be helpful. Suggested text:<br />
:* [Multi Ammo Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. Weapons using multiple ammo types (Heavy Cannon, Auto-Cannon, Rocket Launcher / Gas Cannon, Hydrojet Cannon, Torpedo Launcher) will not be pre-loaded before combat. You will need to load these weapons manually during the pre-combat Equip phase. This will significantly affect the heavy weapons ammunition load your squad can carry into combat without suffering encumbrance penalties, thus making the early game harder.<br />
:* [All Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. This option overrides the previous option. No weapons will be pre-loaded before combat. You will need to load all ammo manually during the pre-combat Equip phase. This will significantly affect the ammunition load your squad can carry into combat without suffering encumbrance penalties, making the early game harder.<br />
:[[User:Spike|Spike]] 05:10, 21 September 2012 (EDT)<br />
::''I found the source of the problem: None of the subroutines for inventory consider the clips in weapons so their entries in OBPOS.DAT are never updated. So when clips are autoloaded at the beginning of each battle, they have no owner. I've got the code to sync the ownership of clips with the weapon they are loaded into at the beginning of each battle and to update the clips when changed in inventory management.-''[[User:Morgan525|Tycho]] 19:00, 19 October 2012 (EDT)<br />
::: That is just awesome! :D [[User:Spike|Spike]] 22:36, 19 October 2012 (EDT)<br />
<br />
=== MIA Bugs ===<br />
<br />
==== Supernumary MIA on Abort ====<br />
<br />
I Abort a mission with 8 Aquanauts and get the confirmation message "8 Aquanauts inside craft, 2 outside". No one has been stunned or MCd. I did have two aquanauts, only, outside, but they have moved back inside the transport. Very odd. Saved Equipment was enabled. [[User:Spike|Spike]] 11:06, 5 October 2012 (EDT)<br />
<br />
:''How many Aquanauts did you have in total?- -''[[User:Morgan525|Tycho]] 02:54, 11 October 2012 (EDT)<br />
:: I started the mission with only 8 Aquanauts and they all survived. Only two had even been outside the transport (quite an unusual situation). However I can't reproduce this bug, so please ignore it unless/until I can reproduce it. :) [[User:Spike|Spike]] 06:48, 17 October 2012 (EDT)<br />
<br />
==== Stunned Carried Aquanauts MIA on Abort ====<br />
<br />
While you are looking the EOB script, I noticed one more anomaly. I'm not sure if this is an original bug or an Extender bug. If you are carrying a stunned Aquanaut in the transport at the time of Abort, the stunned Aquanaut is lost (MIA). You have to drop the stunned Aquanaut on the floor. Probably this is because the position of the Aquanaut has not been updated and is still pointing to where they were stunned, not to the location of the carrying Aquanaut. [[User:Spike|Spike]] 04:49, 27 September 2012 (EDT)<br />
<br />
:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. At least it is manageable: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)<br />
<br />
==== Crewed Flying Sub Lost on Abort ====<br />
<br />
Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)<br />
<br />
:Presumably the 3 aquanauts in the craft were not stunned or mind controlled on the Abort turn? [[User:Spike|Spike]] 16:37, 21 October 2012 (EDT)<br />
:Right, they are not stunned (or dead) and they are under your control. And they are definitely in the sub. OK this is similar to a minor bug I have seen before - see [[#Supernumary MIA on Abort|preceding item]]. On your pre-abort confirmation screen it says "3 units in craft, 9 units outside". I've had a similar issue before. It's double counting your aquanauts as being both inside and outside the craft on the confirm screen, since you only have 9 units (8 and 1 tank) in total. On actual abort you incorrectly get 9 MIAs (including the tank presumably) and I guess that's why you lose the sub. Interestingly, the 3 affected aquanauts look like they never moved from their original positions, is that true? I believe when I've had similar problems before, it related to aquanauts who had never left the sub / never left their initial positions. We will have to see if Tycho can get to the bottom of this one. [[User:Spike|Spike]] 16:51, 21 October 2012 (EDT)<br />
::Yes, that's true - those 3 haven't moved from their original positions. --[[User:Player701|Player701]] 17:19, 21 October 2012 (EDT)<br />
<br />
=== Items on transport floor lost ===<br />
<br />
I went in to a mission with ten Sonic Cannons and came back with 3, despite retrieving them from the battlefield and dumping them on the transport floor. I only had 3 aquanauts on the transport armed with Sonic Cannon at the time of abort. The rest were stunned or unarmed. I also dumped half a dozen corpses and some alien items on the transport floor and I don't think those made it back to my base either. The transport was operating from base 2 rather than base 1, in case that's a factor. This may be an original bug of course. I just read through the multiplayer TFTD LP on StrategyCore, and they reported missing equipment on a lot of missions. I can go back and check if the missing equipment was on abort missions rather than victory missions. Sorry not to provide more specifics at this time but it was a hard mission and not exactly a controlled experiment. ;) [[User:Spike|Spike]] 21:35, 23 October 2012 (EDT)<br />
<br />
<br />
=== Weight Display in Inventory not Localised ===<br />
<br />
At least when I run the game in German, it comes up as "Weight" and not something like "Gewicht". Reactions comes up ok as "Zeitwerte". [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
<br />
:''There is no entry in the text DAT files for "weight". Seb had to add the text string for it into his subroutine. Thanks for pointing it out.'' [[User:Morgan525|Tycho]]<br />
<br />
== Save Equipment not working? ==<br />
<br />
With "Save Equipment" option enabled, the soldiers' loadout at first was always like this: grenade in leg slot, clip in backpack - and it didn't change on the next mission, despite the fact that I re-equipped the soldiers correctly (grenades and clips on the belt). When I manufactured Gauss Rifles and issued them to my soldiers, it got even worse - none of the soldiers got clips, and two of the rifles were unloaded. Next I upgraded to Sonic-Blasta Rifles and now nothing, except some grenades (still in leg slots), is issued to the soldiers at all. "Save Equipment" was known to work in UFOExtender, did something get broken? --[[User:Player701|Player701]] 09:18, 21 October 2012 (EDT)<br />
<br />
:''Yes. Something is broken but not by the Extender. Many subroutines, their order of execution, or variable were modified in the TFTD game code. Problems like these are deducing what changed in the game code and what changes are needed to get the UFOextender code to work. See the discussion on problems with the OBDATA mod about the final source of the problem and its solution.-[[User:Morgan525|Tycho]] 20:03, 21 October 2012 (EDT)''<br />
<br />
:: Would you suggest that everyone disables Save Equipment for the time being, in TFTDextender? [[User:Spike|Spike]] 07:44, 24 October 2012 (EDT)<br />
<br />
=Resolved Problems=<br />
<br />
===<s> Executable directive </s>===<br />
''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)<br />
<br />
=== <s>Extra Artefacts Reported</s> ===<br />
''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)<br />
''This will be fixed in the next release.-''[[User:Morgan525|Tycho]] 03:00, 13 October 2012 (EDT)<br />
: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
===<s>Manufacturing Projects Minimum Production</s> ===<br />
<br />
In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''<br />
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)<br />
<br />
Tested - If I reduce the production quantity of a current production run to less than what as already been produced, the display completion time changes (incorrectly) to 'Indefinite', but production ends after completion of the next unit. So if I start by producing 10 units, wait until I have produced 2, then reduce the quantity to 2 (or probably 1), production stops after 3 units. Thies basically replicates the pre-existing behaviour when using the down arrow on the Quantity, so there has been no loss of functionality with your Mod. Also, Autosell and Autoproduce work normally when applied as changes to an existing production run. The only thing is I can't distinguish them on the Manufacturing display - both say 'unlimited' quantity and 'indefinite' period - is that intended? I suppose it makes sense, but it would be good to be able to tell which kind of production it is, *** Autoproduce or $$$ Autosell. [[User:Spike|Spike]] 08:57, 2 October 2012 (EDT)<br />
<br />
:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''<br />
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)<br />
:::''OK. Changed the output to display "$unlimited$".[[User:Morgan525|Tycho]]<br />
<br />
===<s>Stunned MC'd Aquanauts MIA on Abort </s> ===<br />
<br />
This is a subset of MC'd Aquanauts go MIA [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]. In this case Aquanauts are MC'd by the aliens, then stunned (by friendlies), then the mission is Aborted with the stunned X-Com Aquanauts aboard the transport. The Aquanauts then disappear from the roster forever. I'm not sure if it's due to Abort rather than Victory, or due to them being stunned first. <br />
::''I now have the code in place to uncontrol any creature that has been rendered unconscious. - -''[[User:Morgan525|Tycho]] 02:47, 11 October 2012 (EDT)<br />
This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
=== <s>Grenade Resistance in INI file </s> ===<br />
:''I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]<br />
<br />
<br />
===<s> Materials deducted from wrong base </s>===<br />
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''<br />
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)<br />
<br />
===<s> OBDATA / Dye Grenade mod not working? </s>===<br />
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)<br />
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
== <s>Displacer/Sonic damage fix</s> ==<br />
<br />
'' I changed the damage to be 130, same as the UFOpaedia entry.-''[[User:Morgan525|Tycho]] 03:52, 13 October 2012 (EDT)<br />
<br />
<br />
== Things that TFTDextender does not fix ==<br />
<br />
Just more or less as a note to the reader, TFTDextender does not fix some of the following things that are sometimes thought of as needing fixing (and this is probably deliberate?):<br />
<br />
* Does not fix the apparent swap of the ground map for the VERY SMALL Survey Ship (1 occupant) with the SMALL Escort (half-dozen or more occupants). So you get the VERY SMALL sub occupying about 25 squares of usable area on the Battlescape, and the supposedly larger SMALL sub occupying one square of usable area on the Battlescape, begging the question of how all those aliens got inside there in the first place. XcomUtil will fix this, as will the original patches that XcomUtil incorporates.<br />
* Does not fix the incorrect pictures for the large USO in the interception window. <br />
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]<br />
* Does not fix the Dart Gun to make it any less utterly useless. Though you can do this yourself via the OBDATA.DAT section of TFTDextender. (Suggestion: don't fix it. The useless Dart Gun is all part of the "oh no we're all gonna die" experience of the beginning of TFTD.)<br />
* Does not improve the armour and effectiveness of the basic Aqua-Jet and Gas Cannon Coelecanths (it does upgrade the Coelecanth/Gauss). (Again, suggestion: this is a good thing - XCOM should start the game hopelessly outclassed, and scramble to catch up).<br />
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.<br />
* Does not allow you to have 360 degree vision out of your sub before exiting it. (What kind of coward would want that?). XComUtil does this.<br />
<br />
= Feature Requests and Suggestions =<br />
<br />
== Useful alien species research ==<br />
<br />
Tycho, I really like this idea you proposed in the StrategyCore forum:<br />
<br />
:I'm thinking about giving a hp bonus to all aliens until Xcom performs an autopsy on the species to learn the location of their vital organs (like in the movie "Battle of LA"). This would give more importance to performing autopsies rather than just as a stepping stone to new tech.<br />
<br />
Definite +1. It would be equally valid to add to UFO Extender. I suppose it could also be implemented using Vulnerabilities (no Vulnerabilities are in effect until the Autopsy is completed), or Resistances (across-the-board increased Resistances until Autopsy is completed). If that's easier. <br />
<br />
:''The bonus to hp was an initial thought. Later, I decided against it since it would make aliens more resistant to HE and stun, which don't rely on hitting the right locations. Increasing resistances would be the most appropriate but the damage routine code is very tight and adding anything new that won't break the existing variable stack pointers is tough.'' [[User:Morgan525|Tycho]]<br />
::''A new idea for this that I recently have been toying with, would be on the damage generation routine: Most direct fire damage is 0-200%, with anything over 100% considered a "critical hit". If autopsy hasn't been preformed, then the base damage would be 0-100% and a small chance (maybe 25%) of another 0-100% for that lucky shot. With autopsy done, the game reverts back to the usual 0-200% on any hit.''<br />
<br />
::: That works. And it makes doing Alien Autopsies a no-brainer, as it should be. It is pretty much inconceivable that XCom wouldn't prioritise the autopsy of any newly encountered alien. And any player playing the game for the first time would do autopsies too. This mod will help experienced players to stop playing as if they've "seen it all before". [[User:Spike|Spike]] 10:35, 15 September 2012 (EDT)<br />
<br />
Would it also be worth adding some kind of bonus for Live Alien research? Maybe the negation of some kind of Morale penalty and/or Psi penalty? Fear of the unknown, know your enemy, that kind of thing?<br />
<br />
:''I thought about that but the game doesn't record live aliens that have been researched. When you finish research on a live alien, it only follows the routine to unlock the appropriate UFOpaedia articles and then checks to see if the finished research can unlock other topics.'' [[User:Morgan525|Tycho]]<br />
<br />
I had a further thought on this while trying to guess what your new pre-requisites are for the various armours. For now it's really cool to be guessing but once people have figured it out, well, it will be more logical but still will have 'replay fatigue'. Would it be possible to randomise the pre-requisites for a lot of the key research topics, from out of a plausible list of items (or even randomise pre-requisite topics)? That would make every game fresh in terms of the research sequence, and make the research aspect of the game more challenging and less dry & predictable. As ever, just a suggestion. :) Cheers, [[User:Spike|Spike]] 16:01, 19 October 2012 (EDT)<br />
<br />
== All Units Can "Fly" In Water ==<br />
<br />
It's very illogical that most units are stuck on the seabed in underwater missions. Please provide the option to set all units (X-Com and alien) to have "flying" (i.e. swimming) ability when underwater. This is unlikely to cause an outbreak of 3D combat, since there is no cover except at seabed level, so anyone swimming excessively or incautiously is going to get shot. It might disadvantage the aliens if their tactical map waypoints are all set on the surface. But as some of them can "fly", there is hopefully a mechanism to deal with that in the code already. For me it will just solve the frustration of being unable to swim over small obstacles or swim up a level, and being stuck or tactically limited for no sensible reason. Mag-Ion Armour remains useful as an important step in Sub Research and (if using the Everything Works on Land mod) for land use. [[User:Spike|Spike]] 11:36, 9 September 2012 (EDT)<br />
: This requires setting [[UNITREF.DAT]] byte 0x78 bit 2 for the unit (e.g. for all units on both sides). Or the in-memory equivalent of UNITREF.DAT. [[User:Spike|Spike]] 10:19, 5 October 2012 (EDT)<br />
<br />
== Aliens Pick Up Weapons ==<br />
<br />
Related to Improved Alien AI. This makes the game tougher as stunned / panicked bipedal-type aliens are no longer permanently disarmed. This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. A fix for this would be a very helpful rebalancing of both games that eliminates one of the aliens' weak spots. The existing (but unused) routine looks pretty smart and not immediately exploitable to ambush aliens using weapons as traps. <br />
<br />
: I noticed the UFO Extender source code has a 'get' keyword under the OBDATA.DAT directive that populates this field 0x2D. Is that working? [[User:Spike|Spike]] 21:03, 16 October 2012 (EDT)<br />
<br />
== General Tank Modding ==<br />
<br />
I see you are interested in modding tanks (HWPs/SWPs) and that's partly what got you into updating UFO Extender. I made some suggestions for Tank Modding myself, including some of the mechanics required to make it work via a config file such as the UFO / TFD Extender config file. For example you could have cargo carrier / ambulance / casevac tanks, you could have demolition tanks, mine thrower tanks, and of course tanks with custom weapons including dual weapons. Could you have a look here: [[User:Spike#Tank_mods]] and see if any of that makes you feel like getting creative?<br />
<br />
Thanks,<br />
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)<br />
<br />
== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==<br />
<br />
Hook the right and left weapon menus on mind controlled aliens to add in actions for their built in melee attacks (if they have them) and built in Psi/MC attacks (if they have Psi/MC Skill). Ideally add these actions to the menu, and pop up a menu, even if the alien isn't holding any weapons.<br />
<br />
This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.<br />
<br />
== Fix Interception and Navigation Course Algorithms ==<br />
<br />
Or just find the algorithms and I volunteer to fix them!<br />
<br />
=== Use Great Circle Routes ===<br />
<br />
Travel toward the target on the shortest Great Circle, rather than always travelling along lines of latitude first (like they are some kind of main bus route!). <br />
<br />
=== Use Predictive Interception ===<br />
<br />
For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.<br />
<br />
=== Show Degree Headings ===<br />
<br />
The game only ever reports alien headings as North, South, East, West, but clearly alien craft move in other directions than just these four, and clearly XCOM detection equipment is capable of resolving these finer-grained headings, since the crafts' tracks are shown correctly in the Geoscope. <br />
As a first step towards predictive interceptions, it would be great to display the alien craft's heading in degrees, eg 135 degrees for South-East. Maybe rounded to the nearest 5 or 10 degrees.<br />
<br />
== Interception Craft vs Touched Down Alien Craft == <br />
<br />
If an alien craft is touched down and an XCOM interception craft (not touched down) is at the same X/Y position, if the alien craft begins to move, immediately open the Interception window at minimum range (8km/nm), presumably with the alien attempting to get away / break off. Currently the Interception window only happens if the XCom craft is faster, which is dumb, ''even if'' the alien craft could accelerate instantly to its maximum speed. <br />
<br />
For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach. <br />
<br />
== Fun, not Funky, Fire ==<br />
<br />
An alternative option for incendiaries/phosphorous damage processing: Do process the so called 'impact' damage of an incendiary on every shot, not just at the end of the turn. But only apply it to those in the area of affect of this specific shell burst, not to all units who are standing in smoke or fire anywhere on the map. This will please fans of incendiaries/phosphorous. It's probably a balancing, rather than unbalancing, change in the relative strengths of the ammo types. Makes incendiaries/phosphorous useful for more than just illumination or desperation. Gives some use to the research topics that advise use of incendiaries/phosphorous, and the damage modifiers aliens have been assigned.<br />
<br />
== Rearming Rates ==<br />
<br />
<br />
From [[Known_Bugs_(TFTD)#Geoscape_Bugs]]:<br />
<br />
=== Craft Gauss Cannon Rearming Rate ===<br />
<br />
This weapon rearms at 10/hr but probably should be 50/hr or at least 25/hr, otherwise it is far slower to rearm than any other cannon weapon in either game. In fact it's the second slowest weapon system to rearm, slower only than AJAX...<br />
<br />
=== AJAX Rearming Rate ===<br />
<br />
An AJAX system takes twice as long to fully reload as a D.U.P. system, as a result AJAX-armed Craft have much worse operational tempo and readiness than D.U.P. armed Craft. Like we needed yet another reason to always use D.U.Ps. This is probably a design error rather than a bug, but it would be good to fix it - anything to give a more balanced set of craft weapon choices. The rearming rate should be raised from 1/hr to 2/hr. The AJAX system will then have the same operational tempo as the D.U.P. system. <br />
<br />
Could also be applied to Stingray missiles in EU 1994, as the same analysis applies to Stingray vs Avalanche.<br />
<br />
== Retaliate for Colony Assault ===<br />
<br />
See this discussion [[Talk:Alien_Retaliation#Retaliation_Triggers]]. Colony raids are a good way for the alien to lose badly, so it would be a good balancing move to create severe consequences for raiding. It is at least as sensible as retaliation for USO Assaults.</div>
Spike
https://www.ufopaedia.org/index.php?title=Talk:Alien_Retaliation&diff=40328
Talk:Alien Retaliation
2012-10-24T11:54:23Z
<p>Spike: /* Retaliation Triggers */ new section</p>
<hr />
<div>== Re: Conclusions ==<br />
<br />
Just a thought about the last edit in the conclusions, you don't get any points or loot from destroying the Battleship with base defenses, so an impenetrable base isn't going to provide the same rewards as a supply ship farm raid (done via a Skyranger to work around elerium shortages). I suppose there's always shooting the battleship down before it strikes the base and then raiding it, but I don't recall if this stops the raids. Worth a ponder anyhow. -[[User:NKF|NKF]] 03:12, 30 July 2009 (EDT)<br />
<br />
Indeed, I was referring to an "intercept all the BBs for fun and profit" strategy (after all, they almost always have at least 1 power source left, and there's a TON of valuable loot). The repair time of Avengers, however, means you need a fallback if too many of your Avengers are in the shop, hence why the base defences. Generally I'd only do this with 1 base at a time, as you're limited by repair time anyway.<br />
<br />
By the way, shooting down the BB does NOT unset the flag. So this IS a valid "unlimited Elerium" method.[[User:Magic9mushroom|Magic9mushroom]] 05:27, 31 July 2009 (EDT)<br />
<br />
== Retaliation Triggers ==<br />
<br />
I understand that UFO Assaults / USO Assaults don't trigger Retaliation missions, hence the Mod in UFOextender / TFTDextender. <br />
<br />
Do Alien Base Assaults / Alien Colony Assaults trigger Retaliation missions? They really should, even more so than successful shoot-downs. Both raids, and actual destruction, should be responded to. Base milking (through legitimate combat, not through exploits) is a legitimate tactic for X-COM but a real vulnerability for the aliens, so they should respond in massive force. [[User:Spike|Spike]] 07:54, 24 October 2012 (EDT)</div>
Spike
https://www.ufopaedia.org/index.php?title=Talk:TFTDextender&diff=40327
Talk:TFTDextender
2012-10-24T11:44:54Z
<p>Spike: /* Save Equipment not working? */ Should we disable it?</p>
<hr />
<div>=Questions or Comments=<br />
'''A place to provide feedback or ask questions:'''<br />
<br />
The zip archive does not seem to include an .ini file. Where do I get the .ini file from? <br />
:: Oh hang on. It looks like the latest version of the zip file does not include the .ini file. When I go back to the previous version of the zip file, I can see the .ini file. [[User:Spike|Spike]] 17:45, 6 September 2012 (EDT)<br />
<br />
:::''The latest release is a patch, which means there are no new additions to the INI. I don't include it in patches usually so that those who already have the prior release don't have to reconfigure their current INI. It may not seem like a big deal now but earlier, I was releasing fixes almost on a weekly basis and so I still continue with that idea.''[[User:Morgan525|Tycho]]<br />
<br />
== Bug Reports ==<br />
<br />
=== Crash when starting a landed/crashed USO battle ===<br />
<br />
:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."<br />
<br />
''Interesting. I had someone report a similar thing when they were starting their first instance of the battlescape on a new install of the game. I looked into it and the game generated some bad data. When he let the UFO take off and land again, the battle started with no problems..''<br />
<br />
:It's [[Known_Bugs_(TFTD)#Geoscape_Bugs|a bug I've reported before]] (before TFTD Extender even existed), so it's not specific to TFTDExtender / UFOExtender. What is happening is the Alien Sub is landing on land, and the Triton is also attempting to land on land. Probably the game crashes when it fails to generate the appropriate terrain type? So the GEOSCAPE map/terrain data must be corrupted. I've seen three examples of this. In a couple of cases the landing site is clearly inland, by hundreds of kilometres. In some cases it's right on the sea/land boundary and hard to tell. I have two save games that reproduce the bug now. From memory, the previous cases all happened around North Africa, like these present cases. [[User:Spike|Spike]] 08:31, 9 September 2012 (EDT)<br />
<br />
:''I think the problem is that there is no database to reference what type of terrain to load. EU would reference this based on map coordinates. Since USO aren't usually engaged over land, the map generator can't get an appropriate tileset for the location in these cases.-[[User:Morgan525|Tycho]]''<br />
<br />
=== Cannot build Leviathan ===<br />
<br />
Hi Tycho. I've just researched Leviathan in my TFDExtender game but cannot manufacture it! I have enough resources (Plastics, IBA, ManNav), 3 workshops, more than 100 technicans and one empty sub pen. But when starting the Leviathan manufacture task I cannot assign any technicans to it. I press the "up" button, and there are no reaction to this. I can build Manta, but not Leviathan. Don't you know what is it? [[User:PavelB|PavelB]] 06:55, 2 October 2012 (EDT)<br />
<br />
: Double check that you have sufficient cash to start the project, iirc $600K or so. That matches this symptom. Also that you have enough workshop space available (Leviathan needs a lot of space). Failing that, cancel all existing manufacturing projects, then retry. Failing that you could try reducing Technicians below 100 but that's taking us into Bug territory. [[User:Spike|Spike]] 07:17, 2 October 2012 (EDT)<br />
<br />
:: Resources are 100% enough. I've launched "Terror from the Deep.exe", loaded this saved game and started manufacturing Lev without any problems. I've saved this variant with Lev being manufactured and then loaded it from "TFTDextender.exe". As a result the process was okey, but I could only decrease the number of technicans working on it, not increase (even after decreasing!). That is: with 64 technicans had been assigned, I've pressed the "down" button, and the number changed to 63. But then I was unable to revert it to 64 by pressing "up" button: it didn't work! [[User:PavelB|PavelB]] 07:57, 2 October 2012 (EDT)<br />
:''I'll check into it. Although, I can't understand how changes to the research tree would affect production. Unless it has something to do with the autoproduce feature?''<br />
:'''This problem may be fixed with the same patch that fixed the production materials being deducted from the wrong base. Can anyone confirm?'''- - [[User:Morgan525|Tycho]] 23:12, 17 October 2012 (EDT)<br />
:: If I try to replicate PavelB's situation, I am able to build a Leviathan with no problems using the latest build. However I am also able to build a Leviathan using the 1.05p1.1 build. So I'm not able to replicate his original problem unfortunately. [[User:Spike|Spike]] 19:18, 19 October 2012 (EDT)<br />
<br />
== Minor Bugs ==<br />
<br />
=== Weightless Ammo Bug ===<br />
<br />
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)<br />
<br />
''From what I understand right now, I am pretty sure I can arrange it so that weapons are not automatically loaded and soldiers would be given an extra clip. Feedback?''<br />
: By an extra clip, you mean the clip/ammo that would have been loaded into the weapon is instead carried by the soldier? And for carried clips, the encumbrance effects are correct. For me anyway, in order of most benefit, the options would be<br />
:# Fix the root cause of the bug (ensure all relevant object locations and "contains/contained in" pointers are set during automatic clip loading) so that automatically loaded clips correctly affect encumbrance <br />
:# As a workaround, don't load ammo for multi-ammotype weapons (Heavy Cannon/Gas Cannon, Auto-Cannon/Hydrojet Cannon, Rocket Launcher / Torpedo Launcher). These are the weapons for which the bug has the greatest impact, since it imposes a 'cost' of switching away from the automatically-loaded ammo (usually AP or Small Rocket/Torp). With single-ammotype weapons, there's never any need to change the clips before combat. <br />
:# As a workaround, don't load ammo for any weapons. This avoids the 'switching cost' issue but does impose a fairly significant logistics overhead on each combat, to go through and manually load all clips. Plus the risk that you forget to load a weapon and only find out at a critical moment. :) This is for the "purist" who wants to make the game harder.<br />
:If it's tricky to fix the root cause, any of the other two options would be helpful. Suggested text:<br />
:* [Multi Ammo Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. Weapons using multiple ammo types (Heavy Cannon, Auto-Cannon, Rocket Launcher / Gas Cannon, Hydrojet Cannon, Torpedo Launcher) will not be pre-loaded before combat. You will need to load these weapons manually during the pre-combat Equip phase. This will significantly affect the heavy weapons ammunition load your squad can carry into combat without suffering encumbrance penalties, thus making the early game harder.<br />
:* [All Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. This option overrides the previous option. No weapons will be pre-loaded before combat. You will need to load all ammo manually during the pre-combat Equip phase. This will significantly affect the ammunition load your squad can carry into combat without suffering encumbrance penalties, making the early game harder.<br />
:[[User:Spike|Spike]] 05:10, 21 September 2012 (EDT)<br />
::''I found the source of the problem: None of the subroutines for inventory consider the clips in weapons so their entries in OBPOS.DAT are never updated. So when clips are autoloaded at the beginning of each battle, they have no owner. I've got the code to sync the ownership of clips with the weapon they are loaded into at the beginning of each battle and to update the clips when changed in inventory management.-''[[User:Morgan525|Tycho]] 19:00, 19 October 2012 (EDT)<br />
::: That is just awesome! :D [[User:Spike|Spike]] 22:36, 19 October 2012 (EDT)<br />
<br />
=== MIA Bugs ===<br />
<br />
==== Supernumary MIA on Abort ====<br />
<br />
I Abort a mission with 8 Aquanauts and get the confirmation message "8 Aquanauts inside craft, 2 outside". No one has been stunned or MCd. I did have two aquanauts, only, outside, but they have moved back inside the transport. Very odd. Saved Equipment was enabled. [[User:Spike|Spike]] 11:06, 5 October 2012 (EDT)<br />
<br />
:''How many Aquanauts did you have in total?- -''[[User:Morgan525|Tycho]] 02:54, 11 October 2012 (EDT)<br />
:: I started the mission with only 8 Aquanauts and they all survived. Only two had even been outside the transport (quite an unusual situation). However I can't reproduce this bug, so please ignore it unless/until I can reproduce it. :) [[User:Spike|Spike]] 06:48, 17 October 2012 (EDT)<br />
<br />
==== Stunned Carried Aquanauts MIA on Abort ====<br />
<br />
While you are looking the EOB script, I noticed one more anomaly. I'm not sure if this is an original bug or an Extender bug. If you are carrying a stunned Aquanaut in the transport at the time of Abort, the stunned Aquanaut is lost (MIA). You have to drop the stunned Aquanaut on the floor. Probably this is because the position of the Aquanaut has not been updated and is still pointing to where they were stunned, not to the location of the carrying Aquanaut. [[User:Spike|Spike]] 04:49, 27 September 2012 (EDT)<br />
<br />
:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. At least it is manageable: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)<br />
<br />
==== Crewed Flying Sub Lost on Abort ====<br />
<br />
Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)<br />
<br />
:Presumably the 3 aquanauts in the craft were not stunned or mind controlled on the Abort turn? [[User:Spike|Spike]] 16:37, 21 October 2012 (EDT)<br />
:Right, they are not stunned (or dead) and they are under your control. And they are definitely in the sub. OK this is similar to a minor bug I have seen before - see [[#Supernumary MIA on Abort|preceding item]]. On your pre-abort confirmation screen it says "3 units in craft, 9 units outside". I've had a similar issue before. It's double counting your aquanauts as being both inside and outside the craft on the confirm screen, since you only have 9 units (8 and 1 tank) in total. On actual abort you incorrectly get 9 MIAs (including the tank presumably) and I guess that's why you lose the sub. Interestingly, the 3 affected aquanauts look like they never moved from their original positions, is that true? I believe when I've had similar problems before, it related to aquanauts who had never left the sub / never left their initial positions. We will have to see if Tycho can get to the bottom of this one. [[User:Spike|Spike]] 16:51, 21 October 2012 (EDT)<br />
::Yes, that's true - those 3 haven't moved from their original positions. --[[User:Player701|Player701]] 17:19, 21 October 2012 (EDT)<br />
<br />
=== Items on transport floor lost ===<br />
<br />
I went in to a mission with ten Sonic Cannons and came back with 3, despite retrieving them from the battlefield and dumping them on the transport floor. I only had 3 aquanauts on the transport armed with Sonic Cannon at the time of abort. The rest were stunned or unarmed. I also dumped half a dozen corpses and some alien items on the transport floor and I don't think those made it back to my base either. The transport was operating from base 2 rather than base 1, in case that's a factor. This may be an original bug of course. I just read through the multiplayer TFTD LP on StrategyCore, and they reported missing equipment on a lot of missions. I can go back and check if the missing equipment was on abort missions rather than victory missions. Sorry not to provide more specifics at this time but it was a hard mission and not exactly a controlled experiment. ;) [[User:Spike|Spike]] 21:35, 23 October 2012 (EDT)<br />
<br />
<br />
=== Weight Display in Inventory not Localised ===<br />
<br />
At least when I run the game in German, it comes up as "Weight" and not something like "Gewicht". Reactions comes up ok as "Zeitwerte". [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
<br />
:''There is no entry in the text DAT files for "weight". Seb had to add the text string for it into his subroutine. Thanks for pointing it out.'' [[User:Morgan525|Tycho]]<br />
<br />
== Displacer/Sonic damage fix ==<br />
<br />
If I understand this fix correctly, the Displacer/Sonic weapon damage has been increased to 150 from the previous in-code value of 110, and vs the previous UFOPedia entry of 130? SWS Sonic weapon damage has been increased to 150 because this matches the craft-mounted Sonic Oscillator?<br />
<br />
I don't think this is the right idea. Increasing damage to 150 gives Displacer/Sonic a higher damage level than Displacer/PWT. That removes some of the distinctiveness of Displacer/PWT, and more importantly it is inconsistent with the general principle in the game that PWT weapons (of a given class) do more damage than Sonic (which in turn do more than Gauss). That is true for infantry weapons, SWS weapons (unless you create this exception), and Craft weapons. <br />
<br />
Also, there is no reason why SWS weapon damage should be equated to Craft weapon damage. I'm pretty sure that Battlescape damage values and Craft combat (Geoscape Interception) damage values are completely different, they are not meant to be compared to each other in any way. There is only one SWS weapon that has the same damage as its equivalent Craft weapon, and that is the Coelacanth/Gauss = Gauss Cannon. I think this is a coincidence, as the other equivalent weapons are all different between the SWS version and the Craft version (this applies to Gas Cannon, PWT, Sonic, and also Aqua Jet vs torpedos). <br />
<br />
Clearly there ''is'' an inconsistency between the code and the UFOPedia, and that should be fixed. It's hard to say if the "right" value is 110 or 130. Is the code wrong or is the UFOPedia wrong? It could be either way. But I would correct this inconsistency either to 110 or to 130, not increase it to 150. <br />
<br />
[[User:Spike|Spike]] 08:02, 7 September 2012 (EDT)<br />
<br />
: Or make it an option: Displacer Sonic Fix={0|110|130|150} [[User:Spike|Spike]] 09:50, 9 September 2012 (EDT)<br />
'' I changed the damage to be 125, similar to the ratio for the hovertank turrent to plasma cannon.-''[[User:Morgan525|Tycho]] 03:52, 13 October 2012 (EDT)<br />
<br />
== Save Equipment not working? ==<br />
<br />
With "Save Equipment" option enabled, the soldiers' loadout at first was always like this: grenade in leg slot, clip in backpack - and it didn't change on the next mission, despite the fact that I re-equipped the soldiers correctly (grenades and clips on the belt). When I manufactured Gauss Rifles and issued them to my soldiers, it got even worse - none of the soldiers got clips, and two of the rifles were unloaded. Next I upgraded to Sonic-Blasta Rifles and now nothing, except some grenades (still in leg slots), is issued to the soldiers at all. "Save Equipment" was known to work in UFOExtender, did something get broken? --[[User:Player701|Player701]] 09:18, 21 October 2012 (EDT)<br />
<br />
:''Yes. Something is broken but not by the Extender. Many subroutines, their order of execution, or variable were modified in the TFTD game code. Problems like these are deducing what changed in the game code and what changes are needed to get the UFOextender code to work. See the discussion on problems with the OBDATA mod about the final source of the problem and its solution.-[[User:Morgan525|Tycho]] 20:03, 21 October 2012 (EDT)''<br />
<br />
:: Would you suggest that everyone disables Save Equipment for the time being, in TFTDextender? [[User:Spike|Spike]] 07:44, 24 October 2012 (EDT)<br />
<br />
=Resolved Problems=<br />
<br />
===<s> Executable directive </s>===<br />
''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should. This will be available in the next full release-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)<br />
<br />
=== <s>Extra Artefacts Reported</s> ===<br />
''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)<br />
''This will be fixed in the next release.-''[[User:Morgan525|Tycho]] 03:00, 13 October 2012 (EDT)<br />
: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
===<s>Manufacturing Projects Minimum Production</s> ===<br />
<br />
In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''<br />
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)<br />
<br />
Tested - If I reduce the production quantity of a current production run to less than what as already been produced, the display completion time changes (incorrectly) to 'Indefinite', but production ends after completion of the next unit. So if I start by producing 10 units, wait until I have produced 2, then reduce the quantity to 2 (or probably 1), production stops after 3 units. Thies basically replicates the pre-existing behaviour when using the down arrow on the Quantity, so there has been no loss of functionality with your Mod. Also, Autosell and Autoproduce work normally when applied as changes to an existing production run. The only thing is I can't distinguish them on the Manufacturing display - both say 'unlimited' quantity and 'indefinite' period - is that intended? I suppose it makes sense, but it would be good to be able to tell which kind of production it is, *** Autoproduce or $$$ Autosell. [[User:Spike|Spike]] 08:57, 2 October 2012 (EDT)<br />
<br />
:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''<br />
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)<br />
:::''OK. Changed the output to display "$unlimited$".[[User:Morgan525|Tycho]]<br />
<br />
===<s>Stunned MC'd Aquanauts MIA on Abort </s> ===<br />
<br />
This is a subset of MC'd Aquanauts go MIA [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]. In this case Aquanauts are MC'd by the aliens, then stunned (by friendlies), then the mission is Aborted with the stunned X-Com Aquanauts aboard the transport. The Aquanauts then disappear from the roster forever. I'm not sure if it's due to Abort rather than Victory, or due to them being stunned first. <br />
::''I now have the code in place to uncontrol any creature that has been rendered unconscious. - -''[[User:Morgan525|Tycho]] 02:47, 11 October 2012 (EDT)<br />
This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
=== <s>Grenade Resistance in INI file </s> ===<br />
:''I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]<br />
<br />
<br />
===<s> Materials deducted from wrong base </s>===<br />
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''<br />
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)<br />
<br />
===<s> OBDATA / Dye Grenade mod not working? </s>===<br />
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)<br />
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
<br />
== Things that TFTDextender does not fix ==<br />
<br />
Just more or less as a note to the reader, TFTDextender does not fix some of the following things that are sometimes thought of as needing fixing (and this is probably deliberate?):<br />
<br />
* Does not fix the apparent swap of the ground map for the VERY SMALL Survey Ship (1 occupant) with the SMALL Escort (half-dozen or more occupants). So you get the VERY SMALL sub occupying about 25 squares of usable area on the Battlescape, and the supposedly larger SMALL sub occupying one square of usable area on the Battlescape, begging the question of how all those aliens got inside there in the first place. XcomUtil will fix this, as will the original patches that XcomUtil incorporates.<br />
* Does not fix the incorrect pictures for the large USO in the interception window. <br />
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]<br />
* Does not fix the Dart Gun to make it any less utterly useless. Though you can do this yourself via the OBDATA.DAT section of TFTDextender. (Suggestion: don't fix it. The useless Dart Gun is all part of the "oh no we're all gonna die" experience of the beginning of TFTD.)<br />
* Does not improve the armour and effectiveness of the basic Aqua-Jet and Gas Cannon Coelecanths (it does upgrade the Coelecanth/Gauss). (Again, suggestion: this is a good thing - XCOM should start the game hopelessly outclassed, and scramble to catch up).<br />
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.<br />
* Does not allow you to have 360 degree vision out of your sub before exiting it. (What kind of coward would want that?). XComUtil does this.<br />
<br />
= Feature Requests and Suggestions =<br />
<br />
== Useful alien species research ==<br />
<br />
Tycho, I really like this idea you proposed in the StrategyCore forum:<br />
<br />
:I'm thinking about giving a hp bonus to all aliens until Xcom performs an autopsy on the species to learn the location of their vital organs (like in the movie "Battle of LA"). This would give more importance to performing autopsies rather than just as a stepping stone to new tech.<br />
<br />
Definite +1. It would be equally valid to add to UFO Extender. I suppose it could also be implemented using Vulnerabilities (no Vulnerabilities are in effect until the Autopsy is completed), or Resistances (across-the-board increased Resistances until Autopsy is completed). If that's easier. <br />
<br />
:''The bonus to hp was an initial thought. Later, I decided against it since it would make aliens more resistant to HE and stun, which don't rely on hitting the right locations. Increasing resistances would be the most appropriate but the damage routine code is very tight and adding anything new that won't break the existing variable stack pointers is tough.'' [[User:Morgan525|Tycho]]<br />
::''A new idea for this that I recently have been toying with, would be on the damage generation routine: Most direct fire damage is 0-200%, with anything over 100% considered a "critical hit". If autopsy hasn't been preformed, then the base damage would be 0-100% and a small chance (maybe 25%) of another 0-100% for that lucky shot. With autopsy done, the game reverts back to the usual 0-200% on any hit.''<br />
<br />
::: That works. And it makes doing Alien Autopsies a no-brainer, as it should be. It is pretty much inconceivable that XCom wouldn't prioritise the autopsy of any newly encountered alien. And any player playing the game for the first time would do autopsies too. This mod will help experienced players to stop playing as if they've "seen it all before". [[User:Spike|Spike]] 10:35, 15 September 2012 (EDT)<br />
<br />
Would it also be worth adding some kind of bonus for Live Alien research? Maybe the negation of some kind of Morale penalty and/or Psi penalty? Fear of the unknown, know your enemy, that kind of thing?<br />
<br />
:''I thought about that but the game doesn't record live aliens that have been researched. When you finish research on a live alien, it only follows the routine to unlock the appropriate UFOpaedia articles and then checks to see if the finished research can unlock other topics.'' [[User:Morgan525|Tycho]]<br />
<br />
I had a further thought on this while trying to guess what your new pre-requisites are for the various armours. For now it's really cool to be guessing but once people have figured it out, well, it will be more logical but still will have 'replay fatigue'. Would it be possible to randomise the pre-requisites for a lot of the key research topics, from out of a plausible list of items (or even randomise pre-requisite topics)? That would make every game fresh in terms of the research sequence, and make the research aspect of the game more challenging and less dry & predictable. As ever, just a suggestion. :) Cheers, [[User:Spike|Spike]] 16:01, 19 October 2012 (EDT)<br />
<br />
== All Units Can "Fly" In Water ==<br />
<br />
It's very illogical that most units are stuck on the seabed in underwater missions. Please provide the option to set all units (X-Com and alien) to have "flying" (i.e. swimming) ability when underwater. This is unlikely to cause an outbreak of 3D combat, since there is no cover except at seabed level, so anyone swimming excessively or incautiously is going to get shot. It might disadvantage the aliens if their tactical map waypoints are all set on the surface. But as some of them can "fly", there is hopefully a mechanism to deal with that in the code already. For me it will just solve the frustration of being unable to swim over small obstacles or swim up a level, and being stuck or tactically limited for no sensible reason. Mag-Ion Armour remains useful as an important step in Sub Research and (if using the Everything Works on Land mod) for land use. [[User:Spike|Spike]] 11:36, 9 September 2012 (EDT)<br />
: This requires setting [[UNITREF.DAT]] byte 0x78 bit 2 for the unit (e.g. for all units on both sides). Or the in-memory equivalent of UNITREF.DAT. [[User:Spike|Spike]] 10:19, 5 October 2012 (EDT)<br />
<br />
== Aliens Pick Up Weapons ==<br />
<br />
Related to Improved Alien AI. This makes the game tougher as stunned / panicked bipedal-type aliens are no longer permanently disarmed. This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. A fix for this would be a very helpful rebalancing of both games that eliminates one of the aliens' weak spots. The existing (but unused) routine looks pretty smart and not immediately exploitable to ambush aliens using weapons as traps. <br />
<br />
: I noticed the UFO Extender source code has a 'get' keyword under the OBDATA.DAT directive that populates this field 0x2D. Is that working? [[User:Spike|Spike]] 21:03, 16 October 2012 (EDT)<br />
<br />
== General Tank Modding ==<br />
<br />
I see you are interested in modding tanks (HWPs/SWPs) and that's partly what got you into updating UFO Extender. I made some suggestions for Tank Modding myself, including some of the mechanics required to make it work via a config file such as the UFO / TFD Extender config file. For example you could have cargo carrier / ambulance / casevac tanks, you could have demolition tanks, mine thrower tanks, and of course tanks with custom weapons including dual weapons. Could you have a look here: [[User:Spike#Tank_mods]] and see if any of that makes you feel like getting creative?<br />
<br />
Thanks,<br />
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)<br />
<br />
== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==<br />
<br />
Hook the right and left weapon menus on mind controlled aliens to add in actions for their built in melee attacks (if they have them) and built in Psi/MC attacks (if they have Psi/MC Skill). Ideally add these actions to the menu, and pop up a menu, even if the alien isn't holding any weapons.<br />
<br />
This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.<br />
<br />
== Fix Interception and Navigation Course Algorithms ==<br />
<br />
Or just find the algorithms and I volunteer to fix them!<br />
<br />
=== Use Great Circle Routes ===<br />
<br />
Travel toward the target on the shortest Great Circle, rather than always travelling along lines of latitude first (like they are some kind of main bus route!). <br />
<br />
=== Use Predictive Interception ===<br />
<br />
For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.<br />
<br />
=== Show Degree Headings ===<br />
<br />
The game only ever reports alien headings as North, South, East, West, but clearly alien craft move in other directions than just these four, and clearly XCOM detection equipment is capable of resolving these finer-grained headings, since the crafts' tracks are shown correctly in the Geoscope. <br />
As a first step towards predictive interceptions, it would be great to display the alien craft's heading in degrees, eg 135 degrees for South-East. Maybe rounded to the nearest 5 or 10 degrees.<br />
<br />
== Interception Craft vs Touched Down Alien Craft == <br />
<br />
If an alien craft is touched down and an XCOM interception craft (not touched down) is at the same X/Y position, if the alien craft begins to move, immediately open the Interception window at minimum range (8km/nm), presumably with the alien attempting to get away / break off. Currently the Interception window only happens if the XCom craft is faster, which is dumb, ''even if'' the alien craft could accelerate instantly to its maximum speed. <br />
<br />
For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach. <br />
<br />
== Fun, not Funky, Fire ==<br />
<br />
An alternative option for incendiaries/phosphorous damage processing: Do process the so called 'impact' damage of an incendiary on every shot, not just at the end of the turn. But only apply it to those in the area of affect of this specific shell burst, not to all units who are standing in smoke or fire anywhere on the map. This will please fans of incendiaries/phosphorous. It's probably a balancing, rather than unbalancing, change in the relative strengths of the ammo types. Makes incendiaries/phosphorous useful for more than just illumination or desperation. Gives some use to the research topics that advise use of incendiaries/phosphorous, and the damage modifiers aliens have been assigned.<br />
<br />
== Rearming Rates ==<br />
<br />
<br />
From [[Known_Bugs_(TFTD)#Geoscape_Bugs]]:<br />
<br />
=== Craft Gauss Cannon Rearming Rate ===<br />
<br />
This weapon rearms at 10/hr but probably should be 50/hr or at least 25/hr, otherwise it is far slower to rearm than any other cannon weapon in either game. In fact it's the second slowest weapon system to rearm, slower only than AJAX...<br />
<br />
=== AJAX Rearming Rate ===<br />
<br />
An AJAX system takes twice as long to fully reload as a D.U.P. system, as a result AJAX-armed Craft have much worse operational tempo and readiness than D.U.P. armed Craft. Like we needed yet another reason to always use D.U.Ps. This is probably a design error rather than a bug, but it would be good to fix it - anything to give a more balanced set of craft weapon choices. The rearming rate should be raised from 1/hr to 2/hr. The AJAX system will then have the same operational tempo as the D.U.P. system. <br />
<br />
Could also be applied to Stingray missiles in EU 1994, as the same analysis applies to Stingray vs Avalanche.</div>
Spike
https://www.ufopaedia.org/index.php?title=Talk:Alien_Colony_Attack_Mission&diff=40326
Talk:Alien Colony Attack Mission
2012-10-24T11:42:37Z
<p>Spike: /* Evil or Awesome? */</p>
<hr />
<div>== Evil or Awesome? ==<br />
<br />
===Evil!===<br />
<br />
Alien Colony Assault? Evil!<br />
<br />
Don't get hurt, don't get mind controlled, do take it thorough, do throw flares like hot potatoes, do take 30!!!! Don't hand-to-hand Tentaculats, do take 14 soldiers (or more). DO NOT go unless you have [[Thermic Lance]] and MC knowledge and Disruptor Pulse Launcher, and do edit this post!<br />
<br />
*If you don't have the Thermic Lance and/or DPLs, take Thermal Tazers. Rush the lift, taking out as many aliens as you can (particularly the lift garrison), and be very, very sneaky in the second part - avoid contact as much as possible, stay out of the Lobstermen's line of sight, and whack them from behind with the Thermal Tazers if you can. Also, '''Ion Armour'''. Bare minimum protection, Ion Armour.<br />
: Depending on the Difficulty level, it is do-able at reasonable Difficulty levels with only Plastic Aqua Armour, no offensive MC, no drills, no DPLs and no Thermal Shok launchers. It is possible (though hard) to do this on Superhuman. However extreme caution must always be taken with troops who are not already proven as M.C.-resistant. But the Colony seabed raids themselves offer a great opportunity to screen troops for M.C.-resistance. (Yes, it is a lot less hassle if you have M.C. Labs). See below... [[User:Spike|Spike]] 07:42, 24 October 2012 (EDT)<br />
<br />
=== Awesome! ===<br />
<br />
Alien Colony Assault? Awesome!<br />
<br />
The presence of an Alien Colony can be a great boon to a Commander with the determination and nerve to exploit the situation. No longer is X-COM at the mercy of the aliens schedule, or X-COM's detection ability, base coverage, craft interception capabilities, and strike team reaction time. The Commander can generate a Colony raid mission whenever it is required. As soon as a strike team has recovered from the previous mission you can launch a new one. Multiple strike teams can easily engage in back to back missions. Strategically, this offers X-COM an unending source of (real, hazardous) experience training, loot to use or sell for cash, in-field testing of M.C. resistance, and improved standing with the funding nations (i.e. extra score). A few successful or even semi-successful raids per month will easily compensate for the negative score the Colony generates: 5 points per day to the aliens, plus 50 to them for founding the Colony, plus the alien score for running its supply missions - call it a few hundred a month, which you can easily achieve in a single raid. Colony raids can even supply a fair proportion of the specimens and items you will need for research. But for as long as the Colony continues to exist, X-COM are assured of a tactical mission every few days, or as often as daily if there are no casualties, for every strike team. In fact, if you can perform the mission with low or no casualties, it is financially viable to hire a second transport simply to decrease mission turnover time and increase the rate of missions per month. It is definitely advisable to move your primary strike team to the base closest to the Colony, and it may be appropriate to build a new forward strike base close to the Colony, depending on how long you plan on keeping the Colony around. When you finally decide to destroy the Colony (probably due to pressure from higher up the X-COM chain of command), it may be a bittersweet moment. [[User:Spike|Spike]] 07:42, 24 October 2012 (EDT)<br />
<br />
== Low Tech Colony Raiding ==<br />
<br />
OK, so I am replaying the game on Veteran with no battlescape game-saving. I've lost 10 killed so far on about 6 missions. It's March and my only alien technology is the Sonic Pulser. <br />
<br />
I've detected Alien Colony 1 in the Barents Sea. If I want to attack this colony, I will for the first time in this campaign be going up against Tasoths, Flying Cauliflowers, and Lobstermen. My guys will be armed only with gas cannon and sonic pulsers. I have no armour. <br />
<br />
It is probably impossible to load / carry enough GC ammunition to destroy all the aliens I'll encounter. My options appear to be: <br />
<br />
1/ attack the top level, loot it, and retire. Repeat when short of money. <br />
2/ attack the top level, access the lower level, ignore everything except the Synomium Device, destroy it and retire.<br />
3/ don't attempt this mission yet. <br />
<br />
Tactically I think all I can do is try to get into one or other of the access tunnels that leads into the exit area. This would mean the one to the north, south, or east. Once in there, any oncoming melee attackers will face four shooters, two kneeling two standing. Any attacking from behind will have to cross the minefield of PD grenades they will drop behind themselves. Of course, the risk of MC attack is there all the way through, and very dangerous in a confined space. <br />
<br />
Once on the exit grid, I then go to the second level. I would need to send 2 or 3 guys to find the Synomium Device and to destroy it. The other soldiers would provide a moving defensive perimeter, secured with reaction fire and PD grenades. Once the SD is destroyed the whole force would then need to retreat the same way they came. <br />
<br />
What does the panel suggest? [[User:4th Cuirassier|4th Cuirassier]] 09:05, 29 March 2011 (EDT)<br />
<br />
: I've been in the same situation and it's a rough ride. I would suggest option 1, loot 'n assault the top level, withdraw 'n repeat until you've built up the extra capability to assault the lower base. But, if you go for it, attacking the Synomium level with just Gas Cannon, Sonic Pulsers, and wetsuits - then I salute you, Sir! [[User:Spike|Spike]] 16:23, 29 March 2011 (EDT)<br />
<br />
----<br />
<br />
I am retrying this in early March with a Colony founded at the end of Feb. So the only advances I have on starting equipment are Plastic Aqua Armour, Gauss Rifles (not much use here) and Sonic Pulsers. <br />
<br />
The key tactical differences this early in the game, versus the suggestions on the main page, are what to do when you lack offensive MC and DPLs. These are the two biggest tactical equalisers with the aliens (tactical advantages over the aliens, really). My mix and tactics look something like this:<br />
<br />
*Loadout: GC-HE, Tazers for everyone, 2 HJC and a lot of HJC-P (6 reloads?) for illumination, some GC-AP. Don't bother with Gauss Rifles, they are not the best way to kill anything you need to worry about down here. Sonic Pulsers are your main kill mechanism, bring plenty. GC-HE is also good vs Tentaculats/Hallucinoids/Aquatoids.<br />
*Initially disarm everyone and stay in the transport holding only tazers. Peek out to expose to MC attacks, as this is the first encounter with any major MC. If there are aliens outside the transport doors to be dispatched, firers must return to the transport after firing and drop any lethal weapons on the transport floor. Anyone who succumbs to an MC attack is stunned, dragged back inside if necessary, and left on the transport floor. They will be labelled psi-weak in their name, and sacked or relegated after the mission. Be sure to make an immediate note of the full name of anyone who succumbed, and what effect they succumbed to (Mind Control, Berserk, Panic). <br />
*If you have enough MC-strong survivors, continue. If not, return to base, hire some more Aquanauts, and come back.<br />
*Once you have a stable group of survivors who can resist MC at this range, cautiously move out. Don't move out too far too fast as you will be getting closer to the MC aliens and so becoming more susceptible. At this stage you do need to carry lethal weapons but be sure everyone is also carrying tazers, so if one aquanaut freaks out his buddies can stun him asap. Auto weapons are not a good idea. It might be smart not to use GC-HE yet either. <br />
*First of all try to clear the area in front of the transport doors, and just post high-reaction guards at the front and back of the transport, hiding behind it. They will need GC-HE but you will also need to be firing HJC-P as well to provide illumination. The terrain never burns for more than a couple of turns, so you will need quite a bit of ammunition. Some fires on the ground will also help you see Hallucinoids or Tentaculats above you. Work your way carefully back from the transport doors with small movements and lots of covering fire. Use illumination rounds to reveal aliens and then engage them with Sonic Pulsers or GC-HE. Your firepower is weak, so hold most of it in reserve, using only a few expendable scouts and everyone else ready to fire. Don't bunch up!<br />
*Now clear the other side(s) of the transport in the same fashion. <br />
*If you are just attempting a raid, carefully retrieve loot, just one or two strong and expendable gophers, with everyone else covering. Just do one sector at a time, don't risk becoming engaged on more than one front. <br />
*Approach any cover deliberately and carefully. Use Sonic Pulsers into any concealed areas before you move up. Use a lot of cover and stay down, concealed as much as possible. <br />
*If anyone else succumbs to MC, stun them, pull back, get the stunned body in the transport, re-evaluate whether you are strong enough to continue, or should abort to go and get more troops. <br />
*Sweep the outer areas of the map so you are sure of your escape routes if you need to fall back to the transport. <br />
*You are now ready to assault the Colony buildings, IF you still have sufficient troops and ammunition. If not, abort, and come back next time. Eventually you will have a full complement of MC-resistant troops to tackle this mission. Until you are strong enough to enter the lower levels of the Colony and destroy it, the score from a steady series of successful raids will hopefully offset the score penalty for leaving an Alien Colony active. <br />
*I'm not sure how it's going to work out, assaulting the Colony buildings on the sea bed, so I will let you know if and when I've done it. ;)<br />
*Any other suggestions?<br />
[[User:Spike|Spike]] 10:13, 25 September 2012 (EDT)<br />
<br />
----<br />
<br />
With an MC-resistant squad proven on the first raid, since I have Plastic Aqua Armour all round I'm going to go for HJC-HE as the standard weapon for assaulting into the seabed buildings, especially given that HE is a good choice for pretty much all the enemies on the Seabed level of a colony. Safe firing distance against my own front armour is 2-3 squares with HJC-HE. With GC-HE I need 5 squares of safe distance, which is slightly trickier to achieve inside the alien structures. Of course, I still stick to the policy of no HE weapons, much less HE auto weapons, for aquanauts who have not previously been shown to be resistant to MC. Newbies carry Tazers, period.<br />
<br />
In practice this worked pretty well. I was able to test the MC resistance of the newbies while sweeping outside the alien structures. The alien structures were entered by the stronger newbies carrying HJC-HE and Tazers. More experienced troops remained outside, sniping through the openings in the T-shaped structures, and the doors. Rookies then entered to retrieve loot. Overall I lost 3 rookies but captured valuable research material such as a live Aquatoid Squad Leader (and assorted new Corpse types) and about a million dollars of other loot. And by the end of it I had a confirmed strong squad of 11 MC resistant Aquanauts. The HJC-HE was very effective inside the structures, while the GC-HE was more effective outside the structures and for sniping into the structures. Sonic Pulsers in the hands of strong aquanauts with good throwing accuracy were the best way of dealing with aliens detected in the terrain outside the structures. Most Pulsers had to remain on the transport due to the danger of having them in the hands of MC'd aquanauts, so the rear commander also had the function of starting off the sonic pulser relays. <br />
<br />
HJC-HE was not so helpful with Zombies / Tentaculats, so I may experiment with some kind of Phosphor weapon in the mix. Having said that, HJC-HE was fine for ''killing'' them, it just didn't prevent Temtaculats from spawning from Zombies. Maybe it's better to have a weapon that will definitely kill the spawned Tentaculat, rather than a weapon that ''might'' prevent one from spawning?<br />
<br />
[[User:Spike|Spike]] 09:57, 30 September 2012 (EDT)<br />
----<br />
<br />
Repeatable and safe Colony Raiding of the Seabed level with low-tech weapons is definitely feasible. Aqua Armour works very well with a mix of HJC-HE for general use and GC-HE for harder targets (Tasoths). Sonic Pulsers are really only necessary for tricky situations. Lacking Aqua Armour, a lot more care would be needed, but the offensive firepower is still sufficient. Also, it's not necessary to field DPLs to be able to create new entry points into the seabed buildings, as for some reason they are much weaker than USO hulls. Sonic Pulsers or Sonic Cannon are certainly sufficient to create breaches in the outer building walls, and probably lesser weapons such as Magna-packs or even Large Torpedos (to be tested). After a number of raids I have a very psi-hardened squad and can complete a full sweep of the Seabed level with only one or two Rookie casualties, netting a million dollars in loot and several hundred points of positive score per raid. As an existent Colony only costs 150 per month in negative score, this is a winning proposition. In fact, while I would not relish it, and a considerable amount of painstaking caution would be required, I believe that effective Colony raiding on the Seabed level could be conducted using only starting weapons & equipment - meaning no Aqua Armour and no Sonic Pulsers. <br />
[[User:Spike|Spike]] 20:27, 13 October 2012 (EDT)<br />
----<br />
The diagonal wall sections of the main Seabed building that face ''southwest'' (i.e. facing bottom left in map view) can be destroyed reliably by Large Torpedo, 90 HE (and therefore also by Magna-pack Explosive, 100 HE). This then gives direct access to the interior double doors of the main grav lift area, which can also be destroyed easily by Large Torpedo / Magna-pack Explosive. Most of the other exterior wall tiles seem immune to starting weapons (but not Sonic Pulsers). <br />
<br />
Most of the towers have openings at L1 above the seabed, through which rounds can be fired (i.e. HE) or grenades etc thrown. There are similar openings on L1 of the T-shaped secondary part of the main Seabed building, allowing rounds / grenades to be directed at aliens waiting above that T-shaped area's grav lift. Grenades etc can also be thrown up into the L1 gallery above the central grav lift in the main building, without entering line of sight of that gallery, by approaching within the building from the southeast. [[User:Spike|Spike]] 22:16, 13 October 2012 (EDT)<br />
<br />
== Low Tech Colony Destruction ==<br />
<br />
There comes a time when you have to bite the bullet and stop raiding the Alien Colony, and actually destroy it. This is bittersweet, since by the time you are able to contemplate destroying the Colony you will have become adept at 'milking' it for artefacts, experience, and score. But sometimes you gotta do what you gotta do. <br />
<br />
To tangle with the lower level, the Alien Base proper, is a tough challenge if using only low tech equipment. While the HE weapons that you used on the seabed level work fine against the Tentaculats, they are almost completely ineffective against the Lobstermen. The best starting weapons against Lobstermen are Thermal Tazers, and the next best starting weapon is possibly a Large Torpedo. Both of these weapons have significant tactical challenges to their use. You are looking at 4 to 5 direct hits from a Large Torpedo to bring down an ordinary Lobsterman soldier. That's an exhausting logistical requirement if nothing else - it would require having around 50 Large Torpedoes left, ''after'' completing the Seabed level. Thermal Tazers are far superior as they don't use ammunition, and should take down a Lobsterman or Tentaculat in two hits. But of course the tactical challenges in getting into melee range with either of these two aliens are considerable. Nonetheless, the Tazer is the best weapon to use against the Lobstermen, you don't really have time to kill them with any form of HE unless you're just encountering a single alien with a large squad. <br />
<br />
Out of the low-tech non-starting weapons, Sonic Pulsers will make the fight against the Lobstermen easier, though it can still take 2-3 direct hits for a kill, with or without 'finishing' fire from direct fire HE weapons. The Thermal Shok Launcher of course is the weapon of choice - taking an Alien Base armed with Thermal Shok Launchers does not qualify as a "low tech" option, it's practically the preferred option (much less property damage and collateral damage than DPLs). Some Medi-Kits are very useful on this level because of the use of Thermal Shok Launchers by the aliens, and the need to awaken stunned Aquanauts. This can also be caused by friendly fire or aiming errors with XCOM Thermal Shok Launchers of course. If you don't have Sonic Pulsers, you should bring some Magna-Pack Explosives, though not that many. You will not be using them for combat - use Tazers and direct fire HE weapons for that - but they will be very helpful as breaching charges. <br />
<br />
Prior to transitioning to the Alien Base level from the Entry (Seabed), load up fully with all the equipment you need and don't worry too much about Encumbrance. You can dump and cache excess equipment once you have transitioned to the lower level. You need to have three weapons ready - Thermal Tazer, Sonic Pulser (or Magna-pack if you lack Pulsers), and an HE direct fire weapon. Sadly you only have two hands. It may be best to hold an HE direct fire weapon in one hand (for Tentaculats or Zombies at a distance) and have the other hand free, ready to pull a Thermal Tazer against short range opponents, or a Sonic Pulser against Lobstermen at a distance.<br />
<br />
Tactically your first move must be to regroup. More powerful assault forces can afford to be more adventurous, but the low-tech assault really needs to be cautious. First bring all your forces onto the same level. Use the map to identify those who are on a lower level. They will be near to an ascending grav lift (with bubbles rising over it) - head up to the same level as the rest of your forces. Establish a defensive area in one or both of the main grav lifts. This is your ticket home, your staging area for loot, casualties and excess equipment / supplies. Bring the outlying aquanauts into the defensive area, expanding your defensive perimeter cautiously in the direction of the outliers to help bring them in. Then once you are all grouped together, dump excess supplies, get properly kitted for mobile combat, then move out. Outliers can dump all but minimum supplies on the first term to help them stay mobile and make it back to the group. Dropped supplies can be recovered later. <br />
<br />
Make your way as directly as possible straight down to Level 0, the lowest level. You want to avoid a fight as much as possible and just get to the Synomium Device chamber. Make a note of your route and in particular which grav lifts you use, as you may be heading out in a hurry, pursued by angry Lobstermen! <br />
<br />
The Synomium Device, which looks like 2 loops rotating above a dais, is located under a sort of altar enclosed within what amounts to a ditch on the lowest level, L0. On the map you are looking for a green rectangle, open on the north side, about 15 squares by 15 squares, shown in the map in light green. Obviously this will only become visible on the map once your aquanauts have seen parts of it, but it often helps to see the pattern on the big map. The three green lines are three galleries that overlook the chamber across the 'ditch'. From the gallery on the south side of this chamber, you can see a staircase that goes up to its roof. The staircase can be destroyed by a Large Torpedo or better. This will reveal a wall which can be destroyed by a Magna-Pack Explosive or better (Large Torpedo won't work). You can then see the Device directly, so you can direct-fire from the gallery into the Synomium Device chamber and destroy the Synomium Device as well as mildly irritating the Lobsterman guards. To accomplish the wall-breaching unharmed from the gallery you will need at least Aqua Armour - or throw multiple Magna-Packs and fall back out of blast range. As noted, it is also possible to drop a grenade in from the roof on L1, via a 2 x 2 hole directly above the chamber, but the approaches to this area on L1 can be more heavily guarded. The alternative is to storm the chamber through the various doors using Thermal Tazers, but that is likely to be carnage at close quarters with the Lobstermen guards. <br />
<br />
Once the Synomium Device is destroyed, run like the wind and get out of there. Don't bother engaging anything unless it's in your way of escape or catching up on your rear. If necessary, sacrifice a few aquanauts to allow others to escape. It's crucial at least one aquanaut makes it back to the Seabed, or all the loot from both levels will be lost. Even so, you will get a terrific score, and eliminate the Colony. Which is a shame, since you were having so much success 'milking' the Colony for cash, loot and score. <br />
<br />
[[User:Spike|Spike]] 19:09, 14 October 2012 (EDT)<br />
<br />
== Loot and tactics ==<br />
<br />
It is possible to hunt down every single Alien in both stages and dismantle the base without destroying the symonium device. The loot is similar to a dismantled Artefact site. <br />
However this is by no means an easy feat(harder and more annoying then a ship lane mission where you can at least systematically comb the level.). <br />
The first stage(surface) which always has a similar layout can be considered a warm up. Consider putting one alien unter constant MC while you deal with the rest. Then collect the ammunition to use it during the second stage. Kill the last alien to proceed.<br />
<br />
The second stage is the ultimate tactical nightmare. There are 4 levels. Each has a 5x5 (or was it 6x6) basic grid - 2nd stage layout is random. Some modules cover more then one square/cell of the basic grid. The are plenty of interconnections between the levels. So if you form a search line and sweep one level enemies can move in our rear by changing the level using an elevator, stairs or a hole in the ground. Clear level 1 put aquanaut in each cell and then simultaneously move to level 2? Good ideas if there were not these cells/modules which can not be declared clean by one glance because they contain small closets or secondary walls which divide the cell in away that a aquanaut needs a lot of its TU to move from one half to the next and/or secondary walls forming long narrow corridors along the wall - I think you get the picture - perfect tentaculat territory. In my experience these secondary walls limit the usefulness of DPL. It tears down the secondary walls but not everything is rubble if a DPL torpedo hits the center of a room. So even with the large supply pillaged from the first stage one finds oneself hard pressed to shell everything(in order to clean out the obstacles and an tentaculats and soften up the lobsters). This tactic also greatly diminishes you loot. So usually I find my scouts trailing behind my lobster or tentaculat pet going from room to room killing all additional aliens I come across, or switching them for my pet and killing it when its energy runs too low. Meanwhile the MCs huddle together in the staging areas only contributing to the killing with an occasional DPL strike if the situation calls for it. Which it rarely does since it is usually more efficient in terms of TU to take over the offending Alien(s) and have the scout drill it/them later or have them shoot each other.<br />
Try to reveal the entire base. Any aliens left at that time should be close to panicking which might help to locate them. However expect the entire endeavor to take plenty of time. If anyone has a good plan/system for a systematic sweep I would be most interested in it. <br />
<br />
For the 80 starting items I would mainly pack MC disruptors, tazers/drills, medikits, maybe 2 flares. Everything else can be picked up from the alien corpses. I'm not masochistic enough to attempt a base recovery without 10 MC troopers(MCstr 80+,MCsk 80-100+, TU 75+) and everyone else featuring MCstr 70+. But there is a chance to win every battle(single soldier, termal tazer, no offensiv MC use, diving suit, no reload anyone ;) ) --[[User:Tauon|Tauon]] 18:58, 11 October 2010 (EDT)<br />
<br />
Can you dismantle the base without destroying the Synomium Device? Sure, you just kill all the aliens, although I don't recall ever recovering a Synomium Device as loot. <br />
<br />
The challenging aspect of bases is that you can discover them before you have done any MC research (in fact I have won the campaign before now without MC research ever reaching the top of the priority table). This means the top level is very tough, and the survivors then face the Lobsters and Flying Cauliflowers. If you are short of firepower at this stage, the best bet is to send a handful of guys to find and destroy the Synomium Device and then bug out. [[User:4th Cuirassier|4th Cuirassier]] 09:10, 29 March 2011 (EDT)<br />
<br />
----<br />
<br />
I thought this note from silencer_pl on StrategyCore was worth copying here for inclusion into the eventually to be revised main page:<br />
<br />
''don't forget to scout top floor for 100 Zrbite. You must find engine room. 2 of the engines has this yellow thing on the right corner - destroy the engine and pick 100 Zrbite (50 each). If you pick it up, the After Action Report will not mention that you had taken it, but it will be added to the stores''<br />
<br />
[[User:Spike|Spike]] 20:08, 22 October 2012 (EDT)</div>
Spike
https://www.ufopaedia.org/index.php?title=Tactical_Exploits&diff=40312
Tactical Exploits
2012-10-24T10:08:41Z
<p>Spike: /* Risk Free Milking of Alien Bases */ Grouping</p>
<hr />
<div>= Tactical Exploits =<br />
<br />
== Grenades: Pass the Experience Trick ==<br />
'''(Or who gets the experience when you "drop" a grenade)'''<br />
<br />
Some commanders may have noticed that a soldier that drops a primed grenade rather than throwing it will often not get credited for the damage or killed enemies. <br />
<br />
There is a very odd explanation for this. In order to credit the right person with experience, the game assigns ownership to a grenade. However, ownership is assigned ''after'' the grenade has been thrown, but not when it's dropped or picked up.<br />
<br />
So who gets the experience if its dropped? At the start of a mission, all X-COM owned grenades default to the very first soldier on the transport, or the very first [[Heavy Weapons Platforms|HWP]] if present. This means that if a grenade is used but never thrown during its lifetime, the first soldier or tank gets the experience regardless of actually used it. <br />
<br />
Can we move the ownership around and pass the experience to soldiers of our choice? Definitely! Just have the person you want to get the experience throw the grenade, then get someone else to pick it up and drop it where it can be useful. Just remember to not throw it again.<br />
<br />
The method of deployment for these grenades will be left as a practical exercise to the commander. Be creative, or be heartless - it's all up to you!<br />
<br />
The biggest advantage of this unusual pass-the-experience technique would be to provide training for frail soldiers that would prove to be more of a detriment in combat than out of it - yet another reason for commanders to not sieve troops based on poor combat statistics.<br />
<br />
== Fire ==<br />
<br />
<br />
The [[Known Bugs#Funky Fire|Funky Fire]] bug can be exploited to cause extra damage to units in fire per shot fired, which is arguably an exploit, and to cause additional damage to units who are standing in fire but who are not targeted by the current incendiary attack that is causing the damage, which is definitely an exploit. <br />
<br />
Smoke grenades can be used to put out fire. <br />
<br />
See the [[Incendiary]] topic<br />
<br />
== Fog of War Scouting ==<br />
<br />
The 3D cursor shows the terrain inside it, regardless of whether you have explored the tile or not. While the obscure shapes shown don't mean much to novice players, veterans will soon recognise tiles, and then the map segments they are native to. For example, you can easily find a UFO by looking for the destinctive wall patterns, and the power supply in the center. Or, you could use this to bombard locations such as command centers, or places you know aliens spawn at the beginning of play, with early Blaster Bombs.<br />
<br />
== Object Radar ==<br />
<br />
The map view shows the position of all objects on the map, and updates their current state regardless of whether an X-COM unit has a current line of site to the object. And the largest object on the tile is shown on the main map for any tile which has been previously spotted. Together this can allow you to sometimes detect, and definitely determine by inspection, if an alien has woken up from being stunned, without having line of sight to the target. In multiplayer games (rare) it can be used to deduced the location and progress of opposing forces, if they pick up items from the ground. <br />
<br />
== Dead Man Switches ==<br />
<br />
Grenades will only detonate when they are on the ground and when their timer has counted down. Timers will continue to count down regardless of location, but if the grenade is not on the ground, it will not explode. This means that you can set all the grenades to a time of "0" at the beginning of play, or at an earlier turn, and throw them when it's tactically feasible.<br />
<br />
This is a double-edged sword, however, because should a unit fall dead or unconcious the grenade will hit the ground and promptly take out anything in the near vicinity... which may (or may not) work to your advantage. This tactic encourages keeping your troops far apart. If you anticipate the soldier will have a very high chance of being killed, it may be wise to use the "pass the experience" trick as described earlier before handing the soldier an armed grenade. However, it can be exploited against Tentaculats: give a soldier two armed grenades. If he/she is caught by a Tentaculat, the grenades will drop. The first will kill the zombie while the second kills the newly formed creature. Could also be used with proximity/PD grenades. (This will not work against Chryssalids because the second grenade will be destroyed before detonation, whereas in TFTD, explosives cannot be destroyed by other explosions.)<br />
<br />
As it is possible in reality to carry two grenades with the pins removed, on a very short fuse setting, holding them by the spoons (with the fuse not starting until the spoons are released), this is really only an Exploit if used with grenades other than those held in the hands, or large explosive packs. (Alien grenades could feasibly have a similar mechanism - it's actually a good safety feature.) Even then, for small numbers of grenades (4?) it's probably doable, if one were suicidal enough. <br />
<br />
==Defusing Proximity Mines==<br />
<br />
If your proximity grenades' locations have become inconvenient, all proximity mines on the Battlescape can be defused by saving, quitting the game, restarting it then reloading the game. You can still drop on top of them with a flying suit, or by dropping from a hole in the roof in order to safely pick them up.<br />
<br />
Fixes are available for the underlying bug, which can also be fatal in a situation where you are relying on proximity grenades to work correctly.<br />
<br />
==Base Defence Mission Spawning Issues==<br />
<br />
If there are too many soldiers and/or aliens in too small a base, their initial spawning is unusual. Soldiers can spawn in the Access Lift and Hangars. Aliens can spawn outside the Access Lift and Hangars. Some lifeforms may not spawn at all.<br />
<br />
Why does this happen? Each base facility has certain hardcoded spawn tiles. The Living Quarters, for example, have 8 spawn tiles, 7 on the lower level in an "H" pattern, and 1 on the upper level. Soldiers usually spawn at these spawn tiles, semi-randomly outside the Access Lift and Hangars. Aliens are assigned the spawn tiles within the Lift and Hangars. <br />
<br />
But, if the number of soldiers exceeds the number of "friendly" spawn tiles, the excess soldiers will spawn at the "alien" spawn tiles inside the Access Lift and Hangars. Similarly, if the number of aliens exceeds the number of "alien" spawn tiles, the excess aliens will spawn at the "friendly" spawn tiles in the rest of the base. If there are not enough spawn tiles for the sum of soldiers and aliens, then some lifeforms will not spawn at all. Soldiers have higher spawning priority than aliens, so aliens will be the first to go (fail to spawn). All weapons and items will still be generated, though.<br />
<br />
This can be exploited by garrisoning a base with so many soldiers that all spawn tiles are used up. Zero aliens will spawn (but their toys will still be generated), resulting in a bloodless victory and millions of dollars of loot!<br />
<br />
A radar base with one Large Radar or HWD, an Access Lift, and one Living Quarters, can be filled up with 22 soldiers.<br />
<br />
But if this is considered an exploit, then what is the "ethical" thing to do? To get all aliens to spawn properly at a radar base, you would have to go out of your way and build a hangar. This would in turn affect your defence tactics, and cost you money. If you don't build the hangar, you need to recruit at least 25 armed soldiers (with the accompanying Living Quarters and General Stores), or else a Sectopod or Chrysallid will probably spawn behind friendly lines. At that point, you could argue that the computer is the one doing the cheating, and 25 soldiers seems excessive for a radar base. On the other hand, you would be fighting a reduced number of aliens, since the Access Lift only has 8 spawn tiles.<br />
<br />
Also, you can only have 40 "units" where a soldier is one unit and a HWP is 4.<br />
<br />
Maybe you should just shoot down the scouts.<br />
<br />
<table><br />
<tr><td>Base Facility</td><td>Spawn Tiles on Lower / Upper Floor</td></tr><br />
<tr><td>Access Lift</td><td>5 / 3</td></tr><br />
<tr><td>Hangar</td><td>15 / 0</td></tr><br />
<tr><td>Alien Containment</td><td>7 / 5</td></tr><br />
<tr><td>General Stores</td><td>7 / 4</td></tr><br />
<tr><td>HWD or Large Radar</td><td>5 / 1</td></tr><br />
<tr><td>Lab or Workshop</td><td>6 / 1</td></tr><br />
<tr><td>Living Quarters</td><td>7 / 1</td></tr><br />
<tr><td>Missile Defence</td><td>4 / 5</td></tr><br />
<tr><td>Defences (non-missile) or Shields</td><td>5 / 1</td></tr><br />
<tr><td>Psi Lab</td><td>7 / 3</td></tr><br />
<tr><td>Small Radar</td><td>0 / 2</td></tr><br />
</table><br />
<br />
==Elevator Shielding==<br />
Due to questionable AI, aliens will not fire at you through an elevator (either up or down), even though they can see you and you can see them. When approaching elevators, have a soldier stand on it at the end of the turn, even if this leaves them with no TU. The aliens will not be able to come up/down through the elevator, keeping you safely shielded while you bring up rear troops and prepare for a floor breach. Additionally, soldiers may be able to see aliens standing at/near the elevator above or below them and can fire on them from the safety of their "elevator shield".<br />
<br />
===Risk Free Milking of Alien Bases===<br />
This experience training and (optionally) booty-gathering exploit relies on the "Elevator Shielding" exploit. When assaulting an alien base, your soldiers will be deployed at two staging areas with a 2x2 elevator in each one. Block all eight elevator squares with a soldier and wait for the fun to begin. Just keep skipping your turn and eventually, the aliens will find your soldiers and begin to congregate under the elevator. You can now shoot at them with complete impunity and can even pick out specific soldiers who need Accuracy training. When you see that no more aliens are appearing after a few turns, get your solders onto the evacuation area and leave. The alien base is intact for you to return for additional practice later. If you happened to kill everyone the base will be destroyed, so watch the timing of the alien movement phase and take care not to kill everyone (in practice this means 'save regularly', since there is no in-game way to determine ''exactly'' how many enemy units are left alive). However, the alien leader or commander will almost always stay in the command center, so this is usually not a problem. For best results, arm your soldiers with pistols to maximize the number of shots they can take on each alien. Also, it is not recommended to attempt this tactic on a Sectoid or Ethereal base unless you are very confident of your soldiers' psi strength. As an extra bonus, you can collect alien weapons and equipment before evacuating. It is worth noting that this "shield" does not prevent aliens firing a Blaster Bomb up the lift shaft. However, unless you are running a version of the game that fixes the [[Known_Bugs#Collectors_Edition_Blaster_Bomb_Bug|Vertical Waypoint Blaster Bomb bug]], such attacks will rarely succeed - mostly they will explode on the level below, with no harm to your troops. So unless you have fixed the Vertical Waypoint bug, there is minimal risk with this exploit. But as it is a cowardly and egregious Exploit, fix the Waypoint bug, or better yet, just don't do it.<br />
<br />
==Panicking Alien Location Exploit==<br />
<br />
Whenever a soldier or alien panics or goes berserk from low [[Morale]], there is a message given to the player stating what soldier or alien has done what. As well, the screen is centered on the unit that has failed it's morale check. At times, this will allow sharp-eyed players to locate aliens who have panicked in areas you have already fought, by displaying the location of the alien who has lost their cool.<br />
<br />
==Relaying and Sharing==<br />
<br />
A set of related Exploits arise from the TU system, and the fact that it allows the sequential execution of tasks by different units that really all should be occurring simultaneously, in parallel. <br />
<br />
<br />
===Grenade Relay===<br />
<br />
Many consider this simply a tactic and don't think of it as an Exploit, but measured against realism, its use anything other than very occasionally is an exploit. Simply, a grenade can be primed by one soldier, then thrown between any number of soldiers before being finally delivered to the target. While it is desirable to be able to throw already-primed grenades, for the well attested (but dangerous) practice of throwing a primed grenade ''away'' from friendly troops, using this to cover the battlefield with leap frogging grenades is an exploit to circumvent the (high) TU costs of priming grenades and the (minimal) encumbrance costs of carrying grenades, and is a way of 'concentrating' TUs from safe rear units toward exposed front line units. A number of self-imposed rulesets require not using this tactic. Or rather, this exploit.<br />
<br />
===Weapon Use Relay===<br />
<br />
A less obvious but more obviously bizarre variant of the grenade relay is a weapon-use relay. A weapon can be fired and then thrown to another soldier who fires it again, then throws it to another soldier, and so on, without limitation. There is no reason why an entire squad could not fire the same weapon in the same round, possibly multiple times each depending on the specific weapon's TU costs. This will then greatly exceed the normal maximum rate of fire of this weapon, as well as being patently ridiculous. Scenarios where this would be advantageous would be any time that effective weapons against the enemy are in short supply in inventory. Particularly effective with weapons that do have unlimited ammo (lasers, stun rods / tazers / drills).<br />
<br />
===Equipment Use Relay===<br />
The same technique can also be used with Psi Amps / MC Disruptors to allow part or all of the squad to get at least one Psi/MC attempt from just one device. And it can be used with Medi-Kits to exceed the normal limit on healing (etc) per turn. It can also be used with Motion Scanners / Particle Disturbance Sensors to achieve excellent triangulation of signals while only having one such sensing device on the mission.<br />
<br />
===Loot Relay===<br />
<br />
A variant of this technique can be used when ferrying loot, corpses, casualties or equipment back to the transport / exit area during a planned (or unplanned) abort, for example during alien base/colony raiding operations. One unit picks up some heavy objects, and moves with them (some times it is more TU-efficient to throw some objects, depending on the unit's strength and object's weight). Before the end of the unit's turn it throws the object forward, or drops it and moves off the square, so that another unit can continue the Loot Relay during the current turn. <br />
<br />
There are two advantages. First of all, as with the other related exploits, all the squad's combined TUs can be pooled onto a single operation that really should be limited to 100% of one unit's TUs per turn. Instead you can use as much as 1000% TUs per turn, or more, moving a set of heavy objects right across the map in one turn at speeds far faster than should really be possible. It's the equivalent of FTL travel for Battlescape loot. <br />
<br />
The second advantage is to ensure that no one (or as few units as possible) involved in the ferrying process begins or ends their turn holding the heavy objects. This then avoids the significant TU penalties for being encumbered, which only kick in at the beginning of the next turn. It is often more efficient for the last link in the ferrying chain on a given turn to wait over the ferried objects, and only pick them up at the beginning of the next turn, thus having many more TUs to move them forward to the next link. <br />
<br />
The ferrying units should be set up in a "fireman's chain" type of relay. This in itself is not an Exploit, just a good tactic that works in reality. The difference is that by exploiting the TU mechanics, it's as if a chain of ten people could suddenly all run/throw ten times faster than normal.</div>
Spike
https://www.ufopaedia.org/index.php?title=Tactical_Exploits&diff=40311
Tactical Exploits
2012-10-24T10:07:00Z
<p>Spike: /* Weapon Use Relay */ renamed</p>
<hr />
<div>= Tactical Exploits =<br />
<br />
== Grenades: Pass the Experience Trick ==<br />
'''(Or who gets the experience when you "drop" a grenade)'''<br />
<br />
Some commanders may have noticed that a soldier that drops a primed grenade rather than throwing it will often not get credited for the damage or killed enemies. <br />
<br />
There is a very odd explanation for this. In order to credit the right person with experience, the game assigns ownership to a grenade. However, ownership is assigned ''after'' the grenade has been thrown, but not when it's dropped or picked up.<br />
<br />
So who gets the experience if its dropped? At the start of a mission, all X-COM owned grenades default to the very first soldier on the transport, or the very first [[Heavy Weapons Platforms|HWP]] if present. This means that if a grenade is used but never thrown during its lifetime, the first soldier or tank gets the experience regardless of actually used it. <br />
<br />
Can we move the ownership around and pass the experience to soldiers of our choice? Definitely! Just have the person you want to get the experience throw the grenade, then get someone else to pick it up and drop it where it can be useful. Just remember to not throw it again.<br />
<br />
The method of deployment for these grenades will be left as a practical exercise to the commander. Be creative, or be heartless - it's all up to you!<br />
<br />
The biggest advantage of this unusual pass-the-experience technique would be to provide training for frail soldiers that would prove to be more of a detriment in combat than out of it - yet another reason for commanders to not sieve troops based on poor combat statistics.<br />
<br />
== Fire ==<br />
<br />
<br />
The [[Known Bugs#Funky Fire|Funky Fire]] bug can be exploited to cause extra damage to units in fire per shot fired, which is arguably an exploit, and to cause additional damage to units who are standing in fire but who are not targeted by the current incendiary attack that is causing the damage, which is definitely an exploit. <br />
<br />
Smoke grenades can be used to put out fire. <br />
<br />
See the [[Incendiary]] topic<br />
<br />
== Fog of War Scouting ==<br />
<br />
The 3D cursor shows the terrain inside it, regardless of whether you have explored the tile or not. While the obscure shapes shown don't mean much to novice players, veterans will soon recognise tiles, and then the map segments they are native to. For example, you can easily find a UFO by looking for the destinctive wall patterns, and the power supply in the center. Or, you could use this to bombard locations such as command centers, or places you know aliens spawn at the beginning of play, with early Blaster Bombs.<br />
<br />
== Object Radar ==<br />
<br />
The map view shows the position of all objects on the map, and updates their current state regardless of whether an X-COM unit has a current line of site to the object. And the largest object on the tile is shown on the main map for any tile which has been previously spotted. Together this can allow you to sometimes detect, and definitely determine by inspection, if an alien has woken up from being stunned, without having line of sight to the target. In multiplayer games (rare) it can be used to deduced the location and progress of opposing forces, if they pick up items from the ground. <br />
<br />
== Dead Man Switches ==<br />
<br />
Grenades will only detonate when they are on the ground and when their timer has counted down. Timers will continue to count down regardless of location, but if the grenade is not on the ground, it will not explode. This means that you can set all the grenades to a time of "0" at the beginning of play, or at an earlier turn, and throw them when it's tactically feasible.<br />
<br />
This is a double-edged sword, however, because should a unit fall dead or unconcious the grenade will hit the ground and promptly take out anything in the near vicinity... which may (or may not) work to your advantage. This tactic encourages keeping your troops far apart. If you anticipate the soldier will have a very high chance of being killed, it may be wise to use the "pass the experience" trick as described earlier before handing the soldier an armed grenade. However, it can be exploited against Tentaculats: give a soldier two armed grenades. If he/she is caught by a Tentaculat, the grenades will drop. The first will kill the zombie while the second kills the newly formed creature. Could also be used with proximity/PD grenades. (This will not work against Chryssalids because the second grenade will be destroyed before detonation, whereas in TFTD, explosives cannot be destroyed by other explosions.)<br />
<br />
As it is possible in reality to carry two grenades with the pins removed, on a very short fuse setting, holding them by the spoons (with the fuse not starting until the spoons are released), this is really only an Exploit if used with grenades other than those held in the hands, or large explosive packs. (Alien grenades could feasibly have a similar mechanism - it's actually a good safety feature.) Even then, for small numbers of grenades (4?) it's probably doable, if one were suicidal enough. <br />
<br />
==Defusing Proximity Mines==<br />
<br />
If your proximity grenades' locations have become inconvenient, all proximity mines on the Battlescape can be defused by saving, quitting the game, restarting it then reloading the game. You can still drop on top of them with a flying suit, or by dropping from a hole in the roof in order to safely pick them up.<br />
<br />
Fixes are available for the underlying bug, which can also be fatal in a situation where you are relying on proximity grenades to work correctly.<br />
<br />
==Base Defence Mission Spawning Issues==<br />
<br />
If there are too many soldiers and/or aliens in too small a base, their initial spawning is unusual. Soldiers can spawn in the Access Lift and Hangars. Aliens can spawn outside the Access Lift and Hangars. Some lifeforms may not spawn at all.<br />
<br />
Why does this happen? Each base facility has certain hardcoded spawn tiles. The Living Quarters, for example, have 8 spawn tiles, 7 on the lower level in an "H" pattern, and 1 on the upper level. Soldiers usually spawn at these spawn tiles, semi-randomly outside the Access Lift and Hangars. Aliens are assigned the spawn tiles within the Lift and Hangars. <br />
<br />
But, if the number of soldiers exceeds the number of "friendly" spawn tiles, the excess soldiers will spawn at the "alien" spawn tiles inside the Access Lift and Hangars. Similarly, if the number of aliens exceeds the number of "alien" spawn tiles, the excess aliens will spawn at the "friendly" spawn tiles in the rest of the base. If there are not enough spawn tiles for the sum of soldiers and aliens, then some lifeforms will not spawn at all. Soldiers have higher spawning priority than aliens, so aliens will be the first to go (fail to spawn). All weapons and items will still be generated, though.<br />
<br />
This can be exploited by garrisoning a base with so many soldiers that all spawn tiles are used up. Zero aliens will spawn (but their toys will still be generated), resulting in a bloodless victory and millions of dollars of loot!<br />
<br />
A radar base with one Large Radar or HWD, an Access Lift, and one Living Quarters, can be filled up with 22 soldiers.<br />
<br />
But if this is considered an exploit, then what is the "ethical" thing to do? To get all aliens to spawn properly at a radar base, you would have to go out of your way and build a hangar. This would in turn affect your defence tactics, and cost you money. If you don't build the hangar, you need to recruit at least 25 armed soldiers (with the accompanying Living Quarters and General Stores), or else a Sectopod or Chrysallid will probably spawn behind friendly lines. At that point, you could argue that the computer is the one doing the cheating, and 25 soldiers seems excessive for a radar base. On the other hand, you would be fighting a reduced number of aliens, since the Access Lift only has 8 spawn tiles.<br />
<br />
Also, you can only have 40 "units" where a soldier is one unit and a HWP is 4.<br />
<br />
Maybe you should just shoot down the scouts.<br />
<br />
<table><br />
<tr><td>Base Facility</td><td>Spawn Tiles on Lower / Upper Floor</td></tr><br />
<tr><td>Access Lift</td><td>5 / 3</td></tr><br />
<tr><td>Hangar</td><td>15 / 0</td></tr><br />
<tr><td>Alien Containment</td><td>7 / 5</td></tr><br />
<tr><td>General Stores</td><td>7 / 4</td></tr><br />
<tr><td>HWD or Large Radar</td><td>5 / 1</td></tr><br />
<tr><td>Lab or Workshop</td><td>6 / 1</td></tr><br />
<tr><td>Living Quarters</td><td>7 / 1</td></tr><br />
<tr><td>Missile Defence</td><td>4 / 5</td></tr><br />
<tr><td>Defences (non-missile) or Shields</td><td>5 / 1</td></tr><br />
<tr><td>Psi Lab</td><td>7 / 3</td></tr><br />
<tr><td>Small Radar</td><td>0 / 2</td></tr><br />
</table><br />
<br />
==Elevator Shielding==<br />
Due to questionable AI, aliens will not fire at you through an elevator (either up or down), even though they can see you and you can see them. When approaching elevators, have a soldier stand on it at the end of the turn, even if this leaves them with no TU. The aliens will not be able to come up/down through the elevator, keeping you safely shielded while you bring up rear troops and prepare for a floor breach. Additionally, soldiers may be able to see aliens standing at/near the elevator above or below them and can fire on them from the safety of their "elevator shield".<br />
<br />
==Risk Free Milking of Alien Bases==<br />
This experience training and (optionally) booty-gathering exploit relies on the "Elevator Shielding" exploit. When assaulting an alien base, your soldiers will be deployed at two staging areas with a 2x2 elevator in each one. Block all eight elevator squares with a soldier and wait for the fun to begin. Just keep skipping your turn and eventually, the aliens will find your soldiers and begin to congregate under the elevator. You can now shoot at them with complete impunity and can even pick out specific soldiers who need Accuracy training. When you see that no more aliens are appearing after a few turns, get your solders onto the evacuation area and leave. The alien base is intact for you to return for additional practice later. If you happened to kill everyone the base will be destroyed, so watch the timing of the alien movement phase and take care not to kill everyone (in practice this means 'save regularly', since there is no in-game way to determine ''exactly'' how many enemy units are left alive). However, the alien leader or commander will almost always stay in the command center, so this is usually not a problem. For best results, arm your soldiers with pistols to maximize the number of shots they can take on each alien. Also, it is not recommended to attempt this tactic on a Sectoid or Ethereal base unless you are very confident of your soldiers' psi strength. As an extra bonus, you can collect alien weapons and equipment before evacuating. It is worth noting that this "shield" does not prevent aliens firing a Blaster Bomb up the lift shaft. However, unless you are running a version of the game that fixes the [[Known_Bugs#Collectors_Edition_Blaster_Bomb_Bug|Vertical Waypoint Blaster Bomb bug]], such attacks will rarely succeed - mostly they will explode on the level below, with no harm to your troops. So unless you have fixed the Vertical Waypoint bug, there is minimal risk with this exploit. But as it is a cowardly and egregious Exploit, fix the Waypoint bug, or better yet, just don't do it.<br />
<br />
==Panicking Alien Location Exploit==<br />
<br />
Whenever a soldier or alien panics or goes berserk from low [[Morale]], there is a message given to the player stating what soldier or alien has done what. As well, the screen is centered on the unit that has failed it's morale check. At times, this will allow sharp-eyed players to locate aliens who have panicked in areas you have already fought, by displaying the location of the alien who has lost their cool.<br />
<br />
==Relaying and Sharing==<br />
<br />
A set of related Exploits arise from the TU system, and the fact that it allows the sequential execution of tasks by different units that really all should be occurring simultaneously, in parallel. <br />
<br />
<br />
===Grenade Relay===<br />
<br />
Many consider this simply a tactic and don't think of it as an Exploit, but measured against realism, its use anything other than very occasionally is an exploit. Simply, a grenade can be primed by one soldier, then thrown between any number of soldiers before being finally delivered to the target. While it is desirable to be able to throw already-primed grenades, for the well attested (but dangerous) practice of throwing a primed grenade ''away'' from friendly troops, using this to cover the battlefield with leap frogging grenades is an exploit to circumvent the (high) TU costs of priming grenades and the (minimal) encumbrance costs of carrying grenades, and is a way of 'concentrating' TUs from safe rear units toward exposed front line units. A number of self-imposed rulesets require not using this tactic. Or rather, this exploit.<br />
<br />
===Weapon Use Relay===<br />
<br />
A less obvious but more obviously bizarre variant of the grenade relay is a weapon-use relay. A weapon can be fired and then thrown to another soldier who fires it again, then throws it to another soldier, and so on, without limitation. There is no reason why an entire squad could not fire the same weapon in the same round, possibly multiple times each depending on the specific weapon's TU costs. This will then greatly exceed the normal maximum rate of fire of this weapon, as well as being patently ridiculous. Scenarios where this would be advantageous would be any time that effective weapons against the enemy are in short supply in inventory. Particularly effective with weapons that do have unlimited ammo (lasers, stun rods / tazers / drills).<br />
<br />
===Equipment Use Relay===<br />
The same technique can also be used with Psi Amps / MC Disruptors to allow part or all of the squad to get at least one Psi/MC attempt from just one device. And it can be used with Medi-Kits to exceed the normal limit on healing (etc) per turn. It can also be used with Motion Scanners / Particle Disturbance Sensors to achieve excellent triangulation of signals while only having one such sensing device on the mission.<br />
<br />
===Loot Relay===<br />
<br />
A variant of this technique can be used when ferrying loot, corpses, casualties or equipment back to the transport / exit area during a planned (or unplanned) abort, for example during alien base/colony raiding operations. One unit picks up some heavy objects, and moves with them (some times it is more TU-efficient to throw some objects, depending on the unit's strength and object's weight). Before the end of the unit's turn it throws the object forward, or drops it and moves off the square, so that another unit can continue the Loot Relay during the current turn. <br />
<br />
There are two advantages. First of all, as with the other related exploits, all the squad's combined TUs can be pooled onto a single operation that really should be limited to 100% of one unit's TUs per turn. Instead you can use as much as 1000% TUs per turn, or more, moving a set of heavy objects right across the map in one turn at speeds far faster than should really be possible. It's the equivalent of FTL travel for Battlescape loot. <br />
<br />
The second advantage is to ensure that no one (or as few units as possible) involved in the ferrying process begins or ends their turn holding the heavy objects. This then avoids the significant TU penalties for being encumbered, which only kick in at the beginning of the next turn. It is often more efficient for the last link in the ferrying chain on a given turn to wait over the ferried objects, and only pick them up at the beginning of the next turn, thus having many more TUs to move them forward to the next link. <br />
<br />
The ferrying units should be set up in a "fireman's chain" type of relay. This in itself is not an Exploit, just a good tactic that works in reality. The difference is that by exploiting the TU mechanics, it's as if a chain of ten people could suddenly all run/throw ten times faster than normal.</div>
Spike
https://www.ufopaedia.org/index.php?title=Tactical_Exploits&diff=40310
Tactical Exploits
2012-10-24T09:57:12Z
<p>Spike: /* Base Defence Mission Spawning Issues */</p>
<hr />
<div>= Tactical Exploits =<br />
<br />
== Grenades: Pass the Experience Trick ==<br />
'''(Or who gets the experience when you "drop" a grenade)'''<br />
<br />
Some commanders may have noticed that a soldier that drops a primed grenade rather than throwing it will often not get credited for the damage or killed enemies. <br />
<br />
There is a very odd explanation for this. In order to credit the right person with experience, the game assigns ownership to a grenade. However, ownership is assigned ''after'' the grenade has been thrown, but not when it's dropped or picked up.<br />
<br />
So who gets the experience if its dropped? At the start of a mission, all X-COM owned grenades default to the very first soldier on the transport, or the very first [[Heavy Weapons Platforms|HWP]] if present. This means that if a grenade is used but never thrown during its lifetime, the first soldier or tank gets the experience regardless of actually used it. <br />
<br />
Can we move the ownership around and pass the experience to soldiers of our choice? Definitely! Just have the person you want to get the experience throw the grenade, then get someone else to pick it up and drop it where it can be useful. Just remember to not throw it again.<br />
<br />
The method of deployment for these grenades will be left as a practical exercise to the commander. Be creative, or be heartless - it's all up to you!<br />
<br />
The biggest advantage of this unusual pass-the-experience technique would be to provide training for frail soldiers that would prove to be more of a detriment in combat than out of it - yet another reason for commanders to not sieve troops based on poor combat statistics.<br />
<br />
== Fire ==<br />
<br />
<br />
The [[Known Bugs#Funky Fire|Funky Fire]] bug can be exploited to cause extra damage to units in fire per shot fired, which is arguably an exploit, and to cause additional damage to units who are standing in fire but who are not targeted by the current incendiary attack that is causing the damage, which is definitely an exploit. <br />
<br />
Smoke grenades can be used to put out fire. <br />
<br />
See the [[Incendiary]] topic<br />
<br />
== Fog of War Scouting ==<br />
<br />
The 3D cursor shows the terrain inside it, regardless of whether you have explored the tile or not. While the obscure shapes shown don't mean much to novice players, veterans will soon recognise tiles, and then the map segments they are native to. For example, you can easily find a UFO by looking for the destinctive wall patterns, and the power supply in the center. Or, you could use this to bombard locations such as command centers, or places you know aliens spawn at the beginning of play, with early Blaster Bombs.<br />
<br />
== Object Radar ==<br />
<br />
The map view shows the position of all objects on the map, and updates their current state regardless of whether an X-COM unit has a current line of site to the object. And the largest object on the tile is shown on the main map for any tile which has been previously spotted. Together this can allow you to sometimes detect, and definitely determine by inspection, if an alien has woken up from being stunned, without having line of sight to the target. In multiplayer games (rare) it can be used to deduced the location and progress of opposing forces, if they pick up items from the ground. <br />
<br />
== Dead Man Switches ==<br />
<br />
Grenades will only detonate when they are on the ground and when their timer has counted down. Timers will continue to count down regardless of location, but if the grenade is not on the ground, it will not explode. This means that you can set all the grenades to a time of "0" at the beginning of play, or at an earlier turn, and throw them when it's tactically feasible.<br />
<br />
This is a double-edged sword, however, because should a unit fall dead or unconcious the grenade will hit the ground and promptly take out anything in the near vicinity... which may (or may not) work to your advantage. This tactic encourages keeping your troops far apart. If you anticipate the soldier will have a very high chance of being killed, it may be wise to use the "pass the experience" trick as described earlier before handing the soldier an armed grenade. However, it can be exploited against Tentaculats: give a soldier two armed grenades. If he/she is caught by a Tentaculat, the grenades will drop. The first will kill the zombie while the second kills the newly formed creature. Could also be used with proximity/PD grenades. (This will not work against Chryssalids because the second grenade will be destroyed before detonation, whereas in TFTD, explosives cannot be destroyed by other explosions.)<br />
<br />
As it is possible in reality to carry two grenades with the pins removed, on a very short fuse setting, holding them by the spoons (with the fuse not starting until the spoons are released), this is really only an Exploit if used with grenades other than those held in the hands, or large explosive packs. (Alien grenades could feasibly have a similar mechanism - it's actually a good safety feature.) Even then, for small numbers of grenades (4?) it's probably doable, if one were suicidal enough. <br />
<br />
==Defusing Proximity Mines==<br />
<br />
If your proximity grenades' locations have become inconvenient, all proximity mines on the Battlescape can be defused by saving, quitting the game, restarting it then reloading the game. You can still drop on top of them with a flying suit, or by dropping from a hole in the roof in order to safely pick them up.<br />
<br />
Fixes are available for the underlying bug, which can also be fatal in a situation where you are relying on proximity grenades to work correctly.<br />
<br />
==Base Defence Mission Spawning Issues==<br />
<br />
If there are too many soldiers and/or aliens in too small a base, their initial spawning is unusual. Soldiers can spawn in the Access Lift and Hangars. Aliens can spawn outside the Access Lift and Hangars. Some lifeforms may not spawn at all.<br />
<br />
Why does this happen? Each base facility has certain hardcoded spawn tiles. The Living Quarters, for example, have 8 spawn tiles, 7 on the lower level in an "H" pattern, and 1 on the upper level. Soldiers usually spawn at these spawn tiles, semi-randomly outside the Access Lift and Hangars. Aliens are assigned the spawn tiles within the Lift and Hangars. <br />
<br />
But, if the number of soldiers exceeds the number of "friendly" spawn tiles, the excess soldiers will spawn at the "alien" spawn tiles inside the Access Lift and Hangars. Similarly, if the number of aliens exceeds the number of "alien" spawn tiles, the excess aliens will spawn at the "friendly" spawn tiles in the rest of the base. If there are not enough spawn tiles for the sum of soldiers and aliens, then some lifeforms will not spawn at all. Soldiers have higher spawning priority than aliens, so aliens will be the first to go (fail to spawn). All weapons and items will still be generated, though.<br />
<br />
This can be exploited by garrisoning a base with so many soldiers that all spawn tiles are used up. Zero aliens will spawn (but their toys will still be generated), resulting in a bloodless victory and millions of dollars of loot!<br />
<br />
A radar base with one Large Radar or HWD, an Access Lift, and one Living Quarters, can be filled up with 22 soldiers.<br />
<br />
But if this is considered an exploit, then what is the "ethical" thing to do? To get all aliens to spawn properly at a radar base, you would have to go out of your way and build a hangar. This would in turn affect your defence tactics, and cost you money. If you don't build the hangar, you need to recruit at least 25 armed soldiers (with the accompanying Living Quarters and General Stores), or else a Sectopod or Chrysallid will probably spawn behind friendly lines. At that point, you could argue that the computer is the one doing the cheating, and 25 soldiers seems excessive for a radar base. On the other hand, you would be fighting a reduced number of aliens, since the Access Lift only has 8 spawn tiles.<br />
<br />
Also, you can only have 40 "units" where a soldier is one unit and a HWP is 4.<br />
<br />
Maybe you should just shoot down the scouts.<br />
<br />
<table><br />
<tr><td>Base Facility</td><td>Spawn Tiles on Lower / Upper Floor</td></tr><br />
<tr><td>Access Lift</td><td>5 / 3</td></tr><br />
<tr><td>Hangar</td><td>15 / 0</td></tr><br />
<tr><td>Alien Containment</td><td>7 / 5</td></tr><br />
<tr><td>General Stores</td><td>7 / 4</td></tr><br />
<tr><td>HWD or Large Radar</td><td>5 / 1</td></tr><br />
<tr><td>Lab or Workshop</td><td>6 / 1</td></tr><br />
<tr><td>Living Quarters</td><td>7 / 1</td></tr><br />
<tr><td>Missile Defence</td><td>4 / 5</td></tr><br />
<tr><td>Defences (non-missile) or Shields</td><td>5 / 1</td></tr><br />
<tr><td>Psi Lab</td><td>7 / 3</td></tr><br />
<tr><td>Small Radar</td><td>0 / 2</td></tr><br />
</table><br />
<br />
==Elevator Shielding==<br />
Due to questionable AI, aliens will not fire at you through an elevator (either up or down), even though they can see you and you can see them. When approaching elevators, have a soldier stand on it at the end of the turn, even if this leaves them with no TU. The aliens will not be able to come up/down through the elevator, keeping you safely shielded while you bring up rear troops and prepare for a floor breach. Additionally, soldiers may be able to see aliens standing at/near the elevator above or below them and can fire on them from the safety of their "elevator shield".<br />
<br />
==Risk Free Milking of Alien Bases==<br />
This experience training and (optionally) booty-gathering exploit relies on the "Elevator Shielding" exploit. When assaulting an alien base, your soldiers will be deployed at two staging areas with a 2x2 elevator in each one. Block all eight elevator squares with a soldier and wait for the fun to begin. Just keep skipping your turn and eventually, the aliens will find your soldiers and begin to congregate under the elevator. You can now shoot at them with complete impunity and can even pick out specific soldiers who need Accuracy training. When you see that no more aliens are appearing after a few turns, get your solders onto the evacuation area and leave. The alien base is intact for you to return for additional practice later. If you happened to kill everyone the base will be destroyed, so watch the timing of the alien movement phase and take care not to kill everyone (in practice this means 'save regularly', since there is no in-game way to determine ''exactly'' how many enemy units are left alive). However, the alien leader or commander will almost always stay in the command center, so this is usually not a problem. For best results, arm your soldiers with pistols to maximize the number of shots they can take on each alien. Also, it is not recommended to attempt this tactic on a Sectoid or Ethereal base unless you are very confident of your soldiers' psi strength. As an extra bonus, you can collect alien weapons and equipment before evacuating. It is worth noting that this "shield" does not prevent aliens firing a Blaster Bomb up the lift shaft. However, unless you are running a version of the game that fixes the [[Known_Bugs#Collectors_Edition_Blaster_Bomb_Bug|Vertical Waypoint Blaster Bomb bug]], such attacks will rarely succeed - mostly they will explode on the level below, with no harm to your troops. So unless you have fixed the Vertical Waypoint bug, there is minimal risk with this exploit. But as it is a cowardly and egregious Exploit, fix the Waypoint bug, or better yet, just don't do it.<br />
<br />
==Panicking Alien Location Exploit==<br />
<br />
Whenever a soldier or alien panics or goes berserk from low [[Morale]], there is a message given to the player stating what soldier or alien has done what. As well, the screen is centered on the unit that has failed it's morale check. At times, this will allow sharp-eyed players to locate aliens who have panicked in areas you have already fought, by displaying the location of the alien who has lost their cool.<br />
<br />
==Relaying and Sharing==<br />
<br />
A set of related Exploits arise from the TU system, and the fact that it allows the sequential execution of tasks by different units that really all should be occurring simultaneously, in parallel. <br />
<br />
<br />
===Grenade Relay===<br />
<br />
Many consider this simply a tactic and don't think of it as an Exploit, but measured against realism, its use anything other than very occasionally is an exploit. Simply, a grenade can be primed by one soldier, then thrown between any number of soldiers before being finally delivered to the target. While it is desirable to be able to throw already-primed grenades, for the well attested (but dangerous) practice of throwing a primed grenade ''away'' from friendly troops, using this to cover the battlefield with leap frogging grenades is an exploit to circumvent the (high) TU costs of priming grenades and the (minimal) encumbrance costs of carrying grenades, and is a way of 'concentrating' TUs from safe rear units toward exposed front line units. A number of self-imposed rulesets require not using this tactic. Or rather, this exploit.<br />
<br />
===Weapon Relay===<br />
<br />
A less obvious but more obviously bizarre variant of the grenade relay is a weapon relay. A weapon can be fired and then thrown to another soldier who fires it again, then throws it to another soldier, and so on, without limitation. There is no reason why an entire squad could not fire the same weapon in the same round, possibly multiple times each depending on the specific weapon's TU costs. This will then greatly exceed the normal maximum rate of fire of this weapon, as well as being patently ridiculous. Scenarios where this would be advantageous would be any time that effective weapons against the enemy are in short supply in inventory. Particularly effective with weapons that do have unlimited ammo (lasers, stun rods / tazers / drills).<br />
<br />
===Equipment Use Relay===<br />
The same technique can also be used with Psi Amps / MC Disruptors to allow part or all of the squad to get at least one Psi/MC attempt from just one device. And it can be used with Medi-Kits to exceed the normal limit on healing (etc) per turn. It can also be used with Motion Scanners / Particle Disturbance Sensors to achieve excellent triangulation of signals while only having one such sensing device on the mission.<br />
<br />
===Loot Relay===<br />
<br />
A variant of this technique can be used when ferrying loot, corpses, casualties or equipment back to the transport / exit area during a planned (or unplanned) abort, for example during alien base/colony raiding operations. One unit picks up some heavy objects, and moves with them (some times it is more TU-efficient to throw some objects, depending on the unit's strength and object's weight). Before the end of the unit's turn it throws the object forward, or drops it and moves off the square, so that another unit can continue the Loot Relay during the current turn. <br />
<br />
There are two advantages. First of all, as with the other related exploits, all the squad's combined TUs can be pooled onto a single operation that really should be limited to 100% of one unit's TUs per turn. Instead you can use as much as 1000% TUs per turn, or more, moving a set of heavy objects right across the map in one turn at speeds far faster than should really be possible. It's the equivalent of FTL travel for Battlescape loot. <br />
<br />
The second advantage is to ensure that no one (or as few units as possible) involved in the ferrying process begins or ends their turn holding the heavy objects. This then avoids the significant TU penalties for being encumbered, which only kick in at the beginning of the next turn. It is often more efficient for the last link in the ferrying chain on a given turn to wait over the ferried objects, and only pick them up at the beginning of the next turn, thus having many more TUs to move them forward to the next link. <br />
<br />
The ferrying units should be set up in a "fireman's chain" type of relay. This in itself is not an Exploit, just a good tactic that works in reality. The difference is that by exploiting the TU mechanics, it's as if a chain of ten people could suddenly all run/throw ten times faster than normal.</div>
Spike
https://www.ufopaedia.org/index.php?title=Tactical_Exploits&diff=40309
Tactical Exploits
2012-10-24T09:47:15Z
<p>Spike: /* Grenades */</p>
<hr />
<div>= Tactical Exploits =<br />
<br />
== Grenades: Pass the Experience Trick ==<br />
'''(Or who gets the experience when you "drop" a grenade)'''<br />
<br />
Some commanders may have noticed that a soldier that drops a primed grenade rather than throwing it will often not get credited for the damage or killed enemies. <br />
<br />
There is a very odd explanation for this. In order to credit the right person with experience, the game assigns ownership to a grenade. However, ownership is assigned ''after'' the grenade has been thrown, but not when it's dropped or picked up.<br />
<br />
So who gets the experience if its dropped? At the start of a mission, all X-COM owned grenades default to the very first soldier on the transport, or the very first [[Heavy Weapons Platforms|HWP]] if present. This means that if a grenade is used but never thrown during its lifetime, the first soldier or tank gets the experience regardless of actually used it. <br />
<br />
Can we move the ownership around and pass the experience to soldiers of our choice? Definitely! Just have the person you want to get the experience throw the grenade, then get someone else to pick it up and drop it where it can be useful. Just remember to not throw it again.<br />
<br />
The method of deployment for these grenades will be left as a practical exercise to the commander. Be creative, or be heartless - it's all up to you!<br />
<br />
The biggest advantage of this unusual pass-the-experience technique would be to provide training for frail soldiers that would prove to be more of a detriment in combat than out of it - yet another reason for commanders to not sieve troops based on poor combat statistics.<br />
<br />
== Fire ==<br />
<br />
<br />
The [[Known Bugs#Funky Fire|Funky Fire]] bug can be exploited to cause extra damage to units in fire per shot fired, which is arguably an exploit, and to cause additional damage to units who are standing in fire but who are not targeted by the current incendiary attack that is causing the damage, which is definitely an exploit. <br />
<br />
Smoke grenades can be used to put out fire. <br />
<br />
See the [[Incendiary]] topic<br />
<br />
== Fog of War Scouting ==<br />
<br />
The 3D cursor shows the terrain inside it, regardless of whether you have explored the tile or not. While the obscure shapes shown don't mean much to novice players, veterans will soon recognise tiles, and then the map segments they are native to. For example, you can easily find a UFO by looking for the destinctive wall patterns, and the power supply in the center. Or, you could use this to bombard locations such as command centers, or places you know aliens spawn at the beginning of play, with early Blaster Bombs.<br />
<br />
== Object Radar ==<br />
<br />
The map view shows the position of all objects on the map, and updates their current state regardless of whether an X-COM unit has a current line of site to the object. And the largest object on the tile is shown on the main map for any tile which has been previously spotted. Together this can allow you to sometimes detect, and definitely determine by inspection, if an alien has woken up from being stunned, without having line of sight to the target. In multiplayer games (rare) it can be used to deduced the location and progress of opposing forces, if they pick up items from the ground. <br />
<br />
== Dead Man Switches ==<br />
<br />
Grenades will only detonate when they are on the ground and when their timer has counted down. Timers will continue to count down regardless of location, but if the grenade is not on the ground, it will not explode. This means that you can set all the grenades to a time of "0" at the beginning of play, or at an earlier turn, and throw them when it's tactically feasible.<br />
<br />
This is a double-edged sword, however, because should a unit fall dead or unconcious the grenade will hit the ground and promptly take out anything in the near vicinity... which may (or may not) work to your advantage. This tactic encourages keeping your troops far apart. If you anticipate the soldier will have a very high chance of being killed, it may be wise to use the "pass the experience" trick as described earlier before handing the soldier an armed grenade. However, it can be exploited against Tentaculats: give a soldier two armed grenades. If he/she is caught by a Tentaculat, the grenades will drop. The first will kill the zombie while the second kills the newly formed creature. Could also be used with proximity/PD grenades. (This will not work against Chryssalids because the second grenade will be destroyed before detonation, whereas in TFTD, explosives cannot be destroyed by other explosions.)<br />
<br />
As it is possible in reality to carry two grenades with the pins removed, on a very short fuse setting, holding them by the spoons (with the fuse not starting until the spoons are released), this is really only an Exploit if used with grenades other than those held in the hands, or large explosive packs. (Alien grenades could feasibly have a similar mechanism - it's actually a good safety feature.) Even then, for small numbers of grenades (4?) it's probably doable, if one were suicidal enough. <br />
<br />
==Defusing Proximity Mines==<br />
<br />
If your proximity grenades' locations have become inconvenient, all proximity mines on the Battlescape can be defused by saving, quitting the game, restarting it then reloading the game. You can still drop on top of them with a flying suit, or by dropping from a hole in the roof in order to safely pick them up.<br />
<br />
Fixes are available for the underlying bug, which can also be fatal in a situation where you are relying on proximity grenades to work correctly.<br />
<br />
==Base Defence Mission Spawning Issues==<br />
<br />
If there are too many soldiers and/or aliens in too small a base, their initial spawning is unusual. Soldiers can spawn in the Access Lift and Hangars. Aliens can spawn outside the Access Lift and Hangars. Some lifeforms may not spawn at all.<br />
<br />
Why does this happen? Each base facility has certain hardcoded spawn tiles. The Living Quarters, for example, have 8 spawn tiles, 7 on the lower level in an "H" pattern, and 1 on the upper level. Soldiers usually spawn at these spawn tiles, semi-randomly outside the Access Lift and Hangars. Aliens are assigned the spawn tiles within the Lift and Hangars. <br />
<br />
But, if the number of soldiers exceeds the number of "friendly" spawn tiles, the excess soldiers will spawn at the "alien" spawn tiles inside the Access Lift and Hangars. Similarly, if the number of aliens exceeds the number of "alien" spawn tiles, the excess aliens will spawn at the "friendly" spawn tiles in the rest of the base. If there are not enough spawn tiles for the sum of soldiers and aliens, then some lifeforms will not spawn at all. Soldiers have higher spawning priority than aliens, so aliens will be the first to go (fail to spawn). All weapons and items will still be generated, though.<br />
<br />
This can be exploited by garrisoning a base with so many soldiers that all spawn tiles are used up. Zero aliens will spawn (but their toys will still be generated), resulting in a bloodless victory and millions of dollars of loot!<br />
<br />
A radar base with one Large Radar or HWD, an Access Lift, and one Living Quarters, can be filled up with 22 soldiers.<br />
<br />
But if this is considered an exploit, then what is the "ethical" thing to do? To get all aliens to spawn properly at a radar base, you would have to go out of your way and build a hangar. This would in turn affect your defence tactics, and cost you money. If you don't build the hangar, you need to recruit at least 25 armed soldiers (with the accompanying Living Quarters and General Stores), or else a Sectopod or Chrysallid will probably spawn behind friendly lines. At that point, you could argue that the computer is the one doing the cheating, and 25 soldiers seems excessive for a radar base. On the other hand, you would be fighting a reduced number of aliens, since the Access Lift only has 8 spawn tiles.<br />
<br />
Also, you can only have 40 "units" where a soldier is one unit and a HWP is 4.<br />
<br />
Maybe you should just shoot down the scouts.<br />
<br />
<table><br />
<tr><td>Base Facility</td><td>Spawn Tiles on Lower / Upper Floor</td></tr><br />
<tr><td>Access Lift</td><td>5 / 3</td></tr><br />
<tr><td>Hangar</td><td>15 / 0</td></tr><br />
<tr><td>Alien Containment</td><td>7 / 5</td></tr><br />
<tr><td>General Stores</td><td>7 / 4</td></tr><br />
<tr><td>HWD or Large Radar</td><td>5 / 1</td></tr><br />
<tr><td>Lab or Workshop</td><td>6 / 1</td></tr><br />
<tr><td>Living Quarters</td><td>7 / 1</td></tr><br />
<tr><td>Missile Defence</td><td>4 / 5</td></tr><br />
<tr><td>Defences (non-missile) or Shields</td><td>5 / 1</td></tr><br />
<tr><td>Psi Lab</td><td>7 / 3</td></tr><br />
<tr><td>Small Radar</td><td>0 / 2</td></tr><br />
</table><br />
<br />
<br />
==Elevator Shielding==<br />
Due to questionable AI, aliens will not fire at you through an elevator (either up or down), even though they can see you and you can see them. When approaching elevators, have a soldier stand on it at the end of the turn, even if this leaves them with no TU. The aliens will not be able to come up/down through the elevator, keeping you safely shielded while you bring up rear troops and prepare for a floor breach. Additionally, soldiers may be able to see aliens standing at/near the elevator above or below them and can fire on them from the safety of their "elevator shield".<br />
<br />
==Risk Free Milking of Alien Bases==<br />
This experience training and (optionally) booty-gathering exploit relies on the "Elevator Shielding" exploit. When assaulting an alien base, your soldiers will be deployed at two staging areas with a 2x2 elevator in each one. Block all eight elevator squares with a soldier and wait for the fun to begin. Just keep skipping your turn and eventually, the aliens will find your soldiers and begin to congregate under the elevator. You can now shoot at them with complete impunity and can even pick out specific soldiers who need Accuracy training. When you see that no more aliens are appearing after a few turns, get your solders onto the evacuation area and leave. The alien base is intact for you to return for additional practice later. If you happened to kill everyone the base will be destroyed, so watch the timing of the alien movement phase and take care not to kill everyone (in practice this means 'save regularly', since there is no in-game way to determine ''exactly'' how many enemy units are left alive). However, the alien leader or commander will almost always stay in the command center, so this is usually not a problem. For best results, arm your soldiers with pistols to maximize the number of shots they can take on each alien. Also, it is not recommended to attempt this tactic on a Sectoid or Ethereal base unless you are very confident of your soldiers' psi strength. As an extra bonus, you can collect alien weapons and equipment before evacuating. It is worth noting that this "shield" does not prevent aliens firing a Blaster Bomb up the lift shaft. However, unless you are running a version of the game that fixes the [[Known_Bugs#Collectors_Edition_Blaster_Bomb_Bug|Vertical Waypoint Blaster Bomb bug]], such attacks will rarely succeed - mostly they will explode on the level below, with no harm to your troops. So unless you have fixed the Vertical Waypoint bug, there is minimal risk with this exploit. But as it is a cowardly and egregious Exploit, fix the Waypoint bug, or better yet, just don't do it.<br />
<br />
==Panicking Alien Location Exploit==<br />
<br />
Whenever a soldier or alien panics or goes berserk from low [[Morale]], there is a message given to the player stating what soldier or alien has done what. As well, the screen is centered on the unit that has failed it's morale check. At times, this will allow sharp-eyed players to locate aliens who have panicked in areas you have already fought, by displaying the location of the alien who has lost their cool.<br />
<br />
==Relaying and Sharing==<br />
<br />
A set of related Exploits arise from the TU system, and the fact that it allows the sequential execution of tasks by different units that really all should be occurring simultaneously, in parallel. <br />
<br />
<br />
===Grenade Relay===<br />
<br />
Many consider this simply a tactic and don't think of it as an Exploit, but measured against realism, its use anything other than very occasionally is an exploit. Simply, a grenade can be primed by one soldier, then thrown between any number of soldiers before being finally delivered to the target. While it is desirable to be able to throw already-primed grenades, for the well attested (but dangerous) practice of throwing a primed grenade ''away'' from friendly troops, using this to cover the battlefield with leap frogging grenades is an exploit to circumvent the (high) TU costs of priming grenades and the (minimal) encumbrance costs of carrying grenades, and is a way of 'concentrating' TUs from safe rear units toward exposed front line units. A number of self-imposed rulesets require not using this tactic. Or rather, this exploit.<br />
<br />
===Weapon Relay===<br />
<br />
A less obvious but more obviously bizarre variant of the grenade relay is a weapon relay. A weapon can be fired and then thrown to another soldier who fires it again, then throws it to another soldier, and so on, without limitation. There is no reason why an entire squad could not fire the same weapon in the same round, possibly multiple times each depending on the specific weapon's TU costs. This will then greatly exceed the normal maximum rate of fire of this weapon, as well as being patently ridiculous. Scenarios where this would be advantageous would be any time that effective weapons against the enemy are in short supply in inventory. Particularly effective with weapons that do have unlimited ammo (lasers, stun rods / tazers / drills).<br />
<br />
===Equipment Use Relay===<br />
The same technique can also be used with Psi Amps / MC Disruptors to allow part or all of the squad to get at least one Psi/MC attempt from just one device. And it can be used with Medi-Kits to exceed the normal limit on healing (etc) per turn. It can also be used with Motion Scanners / Particle Disturbance Sensors to achieve excellent triangulation of signals while only having one such sensing device on the mission.<br />
<br />
===Loot Relay===<br />
<br />
A variant of this technique can be used when ferrying loot, corpses, casualties or equipment back to the transport / exit area during a planned (or unplanned) abort, for example during alien base/colony raiding operations. One unit picks up some heavy objects, and moves with them (some times it is more TU-efficient to throw some objects, depending on the unit's strength and object's weight). Before the end of the unit's turn it throws the object forward, or drops it and moves off the square, so that another unit can continue the Loot Relay during the current turn. <br />
<br />
There are two advantages. First of all, as with the other related exploits, all the squad's combined TUs can be pooled onto a single operation that really should be limited to 100% of one unit's TUs per turn. Instead you can use as much as 1000% TUs per turn, or more, moving a set of heavy objects right across the map in one turn at speeds far faster than should really be possible. It's the equivalent of FTL travel for Battlescape loot. <br />
<br />
The second advantage is to ensure that no one (or as few units as possible) involved in the ferrying process begins or ends their turn holding the heavy objects. This then avoids the significant TU penalties for being encumbered, which only kick in at the beginning of the next turn. It is often more efficient for the last link in the ferrying chain on a given turn to wait over the ferried objects, and only pick them up at the beginning of the next turn, thus having many more TUs to move them forward to the next link. <br />
<br />
The ferrying units should be set up in a "fireman's chain" type of relay. This in itself is not an Exploit, just a good tactic that works in reality. The difference is that by exploiting the TU mechanics, it's as if a chain of ten people could suddenly all run/throw ten times faster than normal.</div>
Spike
https://www.ufopaedia.org/index.php?title=Tactical_Exploits&diff=40308
Tactical Exploits
2012-10-24T09:37:27Z
<p>Spike: /* Loot Relay */ Grouping</p>
<hr />
<div>= Tactical Exploits =<br />
<br />
== Grenades: Pass the Experience Trick ==<br />
'''(Or who gets the experience when you "drop" a grenade)'''<br />
<br />
Some commanders may have noticed that a soldier that drops a primed grenade rather than throwing it will often not get credited for the damage or killed enemies. <br />
<br />
There is a very odd explanation for this. In order to credit the right person with experience, the game assigns ownership to a grenade. However, ownership is assigned ''after'' the grenade has been thrown, but not when it's dropped or picked up.<br />
<br />
So who gets the experience if its dropped? At the start of a mission, all X-COM owned grenades default to the very first soldier on the transport, or the very first [[Heavy Weapons Platforms|HWP]] if present. This means that if a grenade is used but never thrown during its lifetime, the first soldier or tank gets the experience regardless of actually used it. <br />
<br />
Can we move the ownership around and pass the experience to soldiers of our choice? Definitely! Just have the person you want to get the experience throw the grenade, then get someone else to pick it up and drop it where it can be useful. Just remember to not throw it again.<br />
<br />
The method of deployment for these grenades will be left as a practical exercise to the commander. Be creative, or be heartless - it's all up to you!<br />
<br />
The biggest advantage of this unusual pass-the-experience technique would be to provide training for frail soldiers that would prove to be more of a detriment in combat than out of it - yet another reason for commanders to not sieve troops based on poor combat statistics.<br />
<br />
== Fire ==<br />
<br />
<br />
The [[Known Bugs#Funky Fire|Funky Fire]] bug can be exploited to cause extra damage to units in fire per shot fired, which is arguably an exploit, and to cause additional damage to units who are standing in fire but who are not targeted by the current incendiary attack that is causing the damage, which is definitely an exploit. <br />
<br />
Smoke grenades can be used to put out fire. <br />
<br />
See the [[Incendiary]] topic<br />
<br />
== Fog of War Scouting ==<br />
<br />
The 3D cursor shows the terrain inside it, regardless of whether you have explored the tile or not. While the obscure shapes shown don't mean much to novice players, veterans will soon recognise tiles, and then the map segments they are native to. For example, you can easily find a UFO by looking for the destinctive wall patterns, and the power supply in the center. Or, you could use this to bombard locations such as command centers, or places you know aliens spawn at the beginning of play, with early Blaster Bombs.<br />
<br />
== Object Radar ==<br />
<br />
The map view shows the position of all objects on the map, and updates their current state regardless of whether an X-COM unit has a current line of site to the object. And the largest object on the tile is shown on the main map for any tile which has been previously spotted. Together this can allow you to sometimes detect, and definitely determine by inspection, if an alien has woken up from being stunned, without having line of sight to the target. In multiplayer games (rare) it can be used to deduced the location and progress of opposing forces, if they pick up items from the ground. <br />
<br />
== Dead Man Switches ==<br />
<br />
Grenades will only detonate when they are on the ground and when their timer has counted down. Timers will continue to count down regardless of location, but if the grenade is not on the ground, it will not explode. This means that you can set all the grenades to a time of "0" at the beginning of play, or at an earlier turn, and throw them when it's tactically feasible.<br />
<br />
This is a double-edged sword, however, because should a unit fall dead or unconcious the grenade will hit the ground and promptly take out anything in the near vicinity... which may (or may not) work to your advantage. This tactic encourages keeping your troops far apart. If you anticipate the soldier will have a very high chance of being killed, it may be wise to use the "pass the experience" trick as described earlier before handing the soldier an armed grenade. However, it can be exploited against Tentaculats: give a soldier two armed grenades. If he/she is caught by a Tentaculat, the grenades will drop. The first will kill the zombie while the second kills the newly formed creature. Could also be used with proximity/PD grenades. (This will not work against Chryssalids because the second grenade will be destroyed before detonation, whereas in TFTD, explosives cannot be destroyed by other explosions.)<br />
<br />
Proximity mines can be defused by saving, quitting the game, restarting it then reloading the game. You can still drop on top of them with a flying suit, or by dropping from a hole in the roof in order to safely pick them up.<br />
<br />
==Base Defence Mission Spawning Issues==<br />
<br />
If there are too many soldiers and/or aliens in too small a base, their initial spawning is unusual. Soldiers can spawn in the Access Lift and Hangars. Aliens can spawn outside the Access Lift and Hangars. Some lifeforms may not spawn at all.<br />
<br />
Why does this happen? Each base facility has certain hardcoded spawn tiles. The Living Quarters, for example, have 8 spawn tiles, 7 on the lower level in an "H" pattern, and 1 on the upper level. Soldiers usually spawn at these spawn tiles, semi-randomly outside the Access Lift and Hangars. Aliens are assigned the spawn tiles within the Lift and Hangars. <br />
<br />
But, if the number of soldiers exceeds the number of "friendly" spawn tiles, the excess soldiers will spawn at the "alien" spawn tiles inside the Access Lift and Hangars. Similarly, if the number of aliens exceeds the number of "alien" spawn tiles, the excess aliens will spawn at the "friendly" spawn tiles in the rest of the base. If there are not enough spawn tiles for the sum of soldiers and aliens, then some lifeforms will not spawn at all. Soldiers have higher spawning priority than aliens, so aliens will be the first to go (fail to spawn). All weapons and items will still be generated, though.<br />
<br />
This can be exploited by garrisoning a base with so many soldiers that all spawn tiles are used up. Zero aliens will spawn (but their toys will still be generated), resulting in a bloodless victory and millions of dollars of loot!<br />
<br />
A radar base with one Large Radar or HWD, an Access Lift, and one Living Quarters, can be filled up with 22 soldiers.<br />
<br />
But if this is considered an exploit, then what is the "ethical" thing to do? To get all aliens to spawn properly at a radar base, you would have to go out of your way and build a hangar. This would in turn affect your defence tactics, and cost you money. If you don't build the hangar, you need to recruit at least 25 armed soldiers (with the accompanying Living Quarters and General Stores), or else a Sectopod or Chrysallid will probably spawn behind friendly lines. At that point, you could argue that the computer is the one doing the cheating, and 25 soldiers seems excessive for a radar base. On the other hand, you would be fighting a reduced number of aliens, since the Access Lift only has 8 spawn tiles.<br />
<br />
Also, you can only have 40 "units" where a soldier is one unit and a HWP is 4.<br />
<br />
Maybe you should just shoot down the scouts.<br />
<br />
<table><br />
<tr><td>Base Facility</td><td>Spawn Tiles on Lower / Upper Floor</td></tr><br />
<tr><td>Access Lift</td><td>5 / 3</td></tr><br />
<tr><td>Hangar</td><td>15 / 0</td></tr><br />
<tr><td>Alien Containment</td><td>7 / 5</td></tr><br />
<tr><td>General Stores</td><td>7 / 4</td></tr><br />
<tr><td>HWD or Large Radar</td><td>5 / 1</td></tr><br />
<tr><td>Lab or Workshop</td><td>6 / 1</td></tr><br />
<tr><td>Living Quarters</td><td>7 / 1</td></tr><br />
<tr><td>Missile Defence</td><td>4 / 5</td></tr><br />
<tr><td>Defences (non-missile) or Shields</td><td>5 / 1</td></tr><br />
<tr><td>Psi Lab</td><td>7 / 3</td></tr><br />
<tr><td>Small Radar</td><td>0 / 2</td></tr><br />
</table><br />
<br />
<br />
==Elevator Shielding==<br />
Due to questionable AI, aliens will not fire at you through an elevator (either up or down), even though they can see you and you can see them. When approaching elevators, have a soldier stand on it at the end of the turn, even if this leaves them with no TU. The aliens will not be able to come up/down through the elevator, keeping you safely shielded while you bring up rear troops and prepare for a floor breach. Additionally, soldiers may be able to see aliens standing at/near the elevator above or below them and can fire on them from the safety of their "elevator shield".<br />
<br />
==Risk Free Milking of Alien Bases==<br />
This experience training and (optionally) booty-gathering exploit relies on the "Elevator Shielding" exploit. When assaulting an alien base, your soldiers will be deployed at two staging areas with a 2x2 elevator in each one. Block all eight elevator squares with a soldier and wait for the fun to begin. Just keep skipping your turn and eventually, the aliens will find your soldiers and begin to congregate under the elevator. You can now shoot at them with complete impunity and can even pick out specific soldiers who need Accuracy training. When you see that no more aliens are appearing after a few turns, get your solders onto the evacuation area and leave. The alien base is intact for you to return for additional practice later. If you happened to kill everyone the base will be destroyed, so watch the timing of the alien movement phase and take care not to kill everyone (in practice this means 'save regularly', since there is no in-game way to determine ''exactly'' how many enemy units are left alive). However, the alien leader or commander will almost always stay in the command center, so this is usually not a problem. For best results, arm your soldiers with pistols to maximize the number of shots they can take on each alien. Also, it is not recommended to attempt this tactic on a Sectoid or Ethereal base unless you are very confident of your soldiers' psi strength. As an extra bonus, you can collect alien weapons and equipment before evacuating. It is worth noting that this "shield" does not prevent aliens firing a Blaster Bomb up the lift shaft. However, unless you are running a version of the game that fixes the [[Known_Bugs#Collectors_Edition_Blaster_Bomb_Bug|Vertical Waypoint Blaster Bomb bug]], such attacks will rarely succeed - mostly they will explode on the level below, with no harm to your troops. So unless you have fixed the Vertical Waypoint bug, there is minimal risk with this exploit. But as it is a cowardly and egregious Exploit, fix the Waypoint bug, or better yet, just don't do it.<br />
<br />
==Panicking Alien Location Exploit==<br />
<br />
Whenever a soldier or alien panics or goes berserk from low [[Morale]], there is a message given to the player stating what soldier or alien has done what. As well, the screen is centered on the unit that has failed it's morale check. At times, this will allow sharp-eyed players to locate aliens who have panicked in areas you have already fought, by displaying the location of the alien who has lost their cool.<br />
<br />
==Relaying and Sharing==<br />
<br />
A set of related Exploits arise from the TU system, and the fact that it allows the sequential execution of tasks by different units that really all should be occurring simultaneously, in parallel. <br />
<br />
<br />
===Grenade Relay===<br />
<br />
Many consider this simply a tactic and don't think of it as an Exploit, but measured against realism, its use anything other than very occasionally is an exploit. Simply, a grenade can be primed by one soldier, then thrown between any number of soldiers before being finally delivered to the target. While it is desirable to be able to throw already-primed grenades, for the well attested (but dangerous) practice of throwing a primed grenade ''away'' from friendly troops, using this to cover the battlefield with leap frogging grenades is an exploit to circumvent the (high) TU costs of priming grenades and the (minimal) encumbrance costs of carrying grenades, and is a way of 'concentrating' TUs from safe rear units toward exposed front line units. A number of self-imposed rulesets require not using this tactic. Or rather, this exploit.<br />
<br />
===Weapon Relay===<br />
<br />
A less obvious but more obviously bizarre variant of the grenade relay is a weapon relay. A weapon can be fired and then thrown to another soldier who fires it again, then throws it to another soldier, and so on, without limitation. There is no reason why an entire squad could not fire the same weapon in the same round, possibly multiple times each depending on the specific weapon's TU costs. This will then greatly exceed the normal maximum rate of fire of this weapon, as well as being patently ridiculous. Scenarios where this would be advantageous would be any time that effective weapons against the enemy are in short supply in inventory. Particularly effective with weapons that do have unlimited ammo (lasers, stun rods / tazers / drills).<br />
<br />
===Equipment Use Relay===<br />
The same technique can also be used with Psi Amps / MC Disruptors to allow part or all of the squad to get at least one Psi/MC attempt from just one device. And it can be used with Medi-Kits to exceed the normal limit on healing (etc) per turn. It can also be used with Motion Scanners / Particle Disturbance Sensors to achieve excellent triangulation of signals while only having one such sensing device on the mission.<br />
<br />
===Loot Relay===<br />
<br />
A variant of this technique can be used when ferrying loot, corpses, casualties or equipment back to the transport / exit area during a planned (or unplanned) abort, for example during alien base/colony raiding operations. One unit picks up some heavy objects, and moves with them (some times it is more TU-efficient to throw some objects, depending on the unit's strength and object's weight). Before the end of the unit's turn it throws the object forward, or drops it and moves off the square, so that another unit can continue the Loot Relay during the current turn. <br />
<br />
There are two advantages. First of all, as with the other related exploits, all the squad's combined TUs can be pooled onto a single operation that really should be limited to 100% of one unit's TUs per turn. Instead you can use as much as 1000% TUs per turn, or more, moving a set of heavy objects right across the map in one turn at speeds far faster than should really be possible. It's the equivalent of FTL travel for Battlescape loot. <br />
<br />
The second advantage is to ensure that no one (or as few units as possible) involved in the ferrying process begins or ends their turn holding the heavy objects. This then avoids the significant TU penalties for being encumbered, which only kick in at the beginning of the next turn. It is often more efficient for the last link in the ferrying chain on a given turn to wait over the ferried objects, and only pick them up at the beginning of the next turn, thus having many more TUs to move them forward to the next link. <br />
<br />
The ferrying units should be set up in a "fireman's chain" type of relay. This in itself is not an Exploit, just a good tactic that works in reality. The difference is that by exploiting the TU mechanics, it's as if a chain of ten people could suddenly all run/throw ten times faster than normal.</div>
Spike
https://www.ufopaedia.org/index.php?title=Tactical_Exploits&diff=40307
Tactical Exploits
2012-10-24T09:36:50Z
<p>Spike: /* Equipment Use Relay */ Grouping</p>
<hr />
<div>= Tactical Exploits =<br />
<br />
== Grenades: Pass the Experience Trick ==<br />
'''(Or who gets the experience when you "drop" a grenade)'''<br />
<br />
Some commanders may have noticed that a soldier that drops a primed grenade rather than throwing it will often not get credited for the damage or killed enemies. <br />
<br />
There is a very odd explanation for this. In order to credit the right person with experience, the game assigns ownership to a grenade. However, ownership is assigned ''after'' the grenade has been thrown, but not when it's dropped or picked up.<br />
<br />
So who gets the experience if its dropped? At the start of a mission, all X-COM owned grenades default to the very first soldier on the transport, or the very first [[Heavy Weapons Platforms|HWP]] if present. This means that if a grenade is used but never thrown during its lifetime, the first soldier or tank gets the experience regardless of actually used it. <br />
<br />
Can we move the ownership around and pass the experience to soldiers of our choice? Definitely! Just have the person you want to get the experience throw the grenade, then get someone else to pick it up and drop it where it can be useful. Just remember to not throw it again.<br />
<br />
The method of deployment for these grenades will be left as a practical exercise to the commander. Be creative, or be heartless - it's all up to you!<br />
<br />
The biggest advantage of this unusual pass-the-experience technique would be to provide training for frail soldiers that would prove to be more of a detriment in combat than out of it - yet another reason for commanders to not sieve troops based on poor combat statistics.<br />
<br />
== Fire ==<br />
<br />
<br />
The [[Known Bugs#Funky Fire|Funky Fire]] bug can be exploited to cause extra damage to units in fire per shot fired, which is arguably an exploit, and to cause additional damage to units who are standing in fire but who are not targeted by the current incendiary attack that is causing the damage, which is definitely an exploit. <br />
<br />
Smoke grenades can be used to put out fire. <br />
<br />
See the [[Incendiary]] topic<br />
<br />
== Fog of War Scouting ==<br />
<br />
The 3D cursor shows the terrain inside it, regardless of whether you have explored the tile or not. While the obscure shapes shown don't mean much to novice players, veterans will soon recognise tiles, and then the map segments they are native to. For example, you can easily find a UFO by looking for the destinctive wall patterns, and the power supply in the center. Or, you could use this to bombard locations such as command centers, or places you know aliens spawn at the beginning of play, with early Blaster Bombs.<br />
<br />
== Object Radar ==<br />
<br />
The map view shows the position of all objects on the map, and updates their current state regardless of whether an X-COM unit has a current line of site to the object. And the largest object on the tile is shown on the main map for any tile which has been previously spotted. Together this can allow you to sometimes detect, and definitely determine by inspection, if an alien has woken up from being stunned, without having line of sight to the target. In multiplayer games (rare) it can be used to deduced the location and progress of opposing forces, if they pick up items from the ground. <br />
<br />
== Dead Man Switches ==<br />
<br />
Grenades will only detonate when they are on the ground and when their timer has counted down. Timers will continue to count down regardless of location, but if the grenade is not on the ground, it will not explode. This means that you can set all the grenades to a time of "0" at the beginning of play, or at an earlier turn, and throw them when it's tactically feasible.<br />
<br />
This is a double-edged sword, however, because should a unit fall dead or unconcious the grenade will hit the ground and promptly take out anything in the near vicinity... which may (or may not) work to your advantage. This tactic encourages keeping your troops far apart. If you anticipate the soldier will have a very high chance of being killed, it may be wise to use the "pass the experience" trick as described earlier before handing the soldier an armed grenade. However, it can be exploited against Tentaculats: give a soldier two armed grenades. If he/she is caught by a Tentaculat, the grenades will drop. The first will kill the zombie while the second kills the newly formed creature. Could also be used with proximity/PD grenades. (This will not work against Chryssalids because the second grenade will be destroyed before detonation, whereas in TFTD, explosives cannot be destroyed by other explosions.)<br />
<br />
Proximity mines can be defused by saving, quitting the game, restarting it then reloading the game. You can still drop on top of them with a flying suit, or by dropping from a hole in the roof in order to safely pick them up.<br />
<br />
==Base Defence Mission Spawning Issues==<br />
<br />
If there are too many soldiers and/or aliens in too small a base, their initial spawning is unusual. Soldiers can spawn in the Access Lift and Hangars. Aliens can spawn outside the Access Lift and Hangars. Some lifeforms may not spawn at all.<br />
<br />
Why does this happen? Each base facility has certain hardcoded spawn tiles. The Living Quarters, for example, have 8 spawn tiles, 7 on the lower level in an "H" pattern, and 1 on the upper level. Soldiers usually spawn at these spawn tiles, semi-randomly outside the Access Lift and Hangars. Aliens are assigned the spawn tiles within the Lift and Hangars. <br />
<br />
But, if the number of soldiers exceeds the number of "friendly" spawn tiles, the excess soldiers will spawn at the "alien" spawn tiles inside the Access Lift and Hangars. Similarly, if the number of aliens exceeds the number of "alien" spawn tiles, the excess aliens will spawn at the "friendly" spawn tiles in the rest of the base. If there are not enough spawn tiles for the sum of soldiers and aliens, then some lifeforms will not spawn at all. Soldiers have higher spawning priority than aliens, so aliens will be the first to go (fail to spawn). All weapons and items will still be generated, though.<br />
<br />
This can be exploited by garrisoning a base with so many soldiers that all spawn tiles are used up. Zero aliens will spawn (but their toys will still be generated), resulting in a bloodless victory and millions of dollars of loot!<br />
<br />
A radar base with one Large Radar or HWD, an Access Lift, and one Living Quarters, can be filled up with 22 soldiers.<br />
<br />
But if this is considered an exploit, then what is the "ethical" thing to do? To get all aliens to spawn properly at a radar base, you would have to go out of your way and build a hangar. This would in turn affect your defence tactics, and cost you money. If you don't build the hangar, you need to recruit at least 25 armed soldiers (with the accompanying Living Quarters and General Stores), or else a Sectopod or Chrysallid will probably spawn behind friendly lines. At that point, you could argue that the computer is the one doing the cheating, and 25 soldiers seems excessive for a radar base. On the other hand, you would be fighting a reduced number of aliens, since the Access Lift only has 8 spawn tiles.<br />
<br />
Also, you can only have 40 "units" where a soldier is one unit and a HWP is 4.<br />
<br />
Maybe you should just shoot down the scouts.<br />
<br />
<table><br />
<tr><td>Base Facility</td><td>Spawn Tiles on Lower / Upper Floor</td></tr><br />
<tr><td>Access Lift</td><td>5 / 3</td></tr><br />
<tr><td>Hangar</td><td>15 / 0</td></tr><br />
<tr><td>Alien Containment</td><td>7 / 5</td></tr><br />
<tr><td>General Stores</td><td>7 / 4</td></tr><br />
<tr><td>HWD or Large Radar</td><td>5 / 1</td></tr><br />
<tr><td>Lab or Workshop</td><td>6 / 1</td></tr><br />
<tr><td>Living Quarters</td><td>7 / 1</td></tr><br />
<tr><td>Missile Defence</td><td>4 / 5</td></tr><br />
<tr><td>Defences (non-missile) or Shields</td><td>5 / 1</td></tr><br />
<tr><td>Psi Lab</td><td>7 / 3</td></tr><br />
<tr><td>Small Radar</td><td>0 / 2</td></tr><br />
</table><br />
<br />
<br />
==Elevator Shielding==<br />
Due to questionable AI, aliens will not fire at you through an elevator (either up or down), even though they can see you and you can see them. When approaching elevators, have a soldier stand on it at the end of the turn, even if this leaves them with no TU. The aliens will not be able to come up/down through the elevator, keeping you safely shielded while you bring up rear troops and prepare for a floor breach. Additionally, soldiers may be able to see aliens standing at/near the elevator above or below them and can fire on them from the safety of their "elevator shield".<br />
<br />
==Risk Free Milking of Alien Bases==<br />
This experience training and (optionally) booty-gathering exploit relies on the "Elevator Shielding" exploit. When assaulting an alien base, your soldiers will be deployed at two staging areas with a 2x2 elevator in each one. Block all eight elevator squares with a soldier and wait for the fun to begin. Just keep skipping your turn and eventually, the aliens will find your soldiers and begin to congregate under the elevator. You can now shoot at them with complete impunity and can even pick out specific soldiers who need Accuracy training. When you see that no more aliens are appearing after a few turns, get your solders onto the evacuation area and leave. The alien base is intact for you to return for additional practice later. If you happened to kill everyone the base will be destroyed, so watch the timing of the alien movement phase and take care not to kill everyone (in practice this means 'save regularly', since there is no in-game way to determine ''exactly'' how many enemy units are left alive). However, the alien leader or commander will almost always stay in the command center, so this is usually not a problem. For best results, arm your soldiers with pistols to maximize the number of shots they can take on each alien. Also, it is not recommended to attempt this tactic on a Sectoid or Ethereal base unless you are very confident of your soldiers' psi strength. As an extra bonus, you can collect alien weapons and equipment before evacuating. It is worth noting that this "shield" does not prevent aliens firing a Blaster Bomb up the lift shaft. However, unless you are running a version of the game that fixes the [[Known_Bugs#Collectors_Edition_Blaster_Bomb_Bug|Vertical Waypoint Blaster Bomb bug]], such attacks will rarely succeed - mostly they will explode on the level below, with no harm to your troops. So unless you have fixed the Vertical Waypoint bug, there is minimal risk with this exploit. But as it is a cowardly and egregious Exploit, fix the Waypoint bug, or better yet, just don't do it.<br />
<br />
==Panicking Alien Location Exploit==<br />
<br />
Whenever a soldier or alien panics or goes berserk from low [[Morale]], there is a message given to the player stating what soldier or alien has done what. As well, the screen is centered on the unit that has failed it's morale check. At times, this will allow sharp-eyed players to locate aliens who have panicked in areas you have already fought, by displaying the location of the alien who has lost their cool.<br />
<br />
==Relaying and Sharing==<br />
<br />
A set of related Exploits arise from the TU system, and the fact that it allows the sequential execution of tasks by different units that really all should be occurring simultaneously, in parallel. <br />
<br />
<br />
===Grenade Relay===<br />
<br />
Many consider this simply a tactic and don't think of it as an Exploit, but measured against realism, its use anything other than very occasionally is an exploit. Simply, a grenade can be primed by one soldier, then thrown between any number of soldiers before being finally delivered to the target. While it is desirable to be able to throw already-primed grenades, for the well attested (but dangerous) practice of throwing a primed grenade ''away'' from friendly troops, using this to cover the battlefield with leap frogging grenades is an exploit to circumvent the (high) TU costs of priming grenades and the (minimal) encumbrance costs of carrying grenades, and is a way of 'concentrating' TUs from safe rear units toward exposed front line units. A number of self-imposed rulesets require not using this tactic. Or rather, this exploit.<br />
<br />
===Weapon Relay===<br />
<br />
A less obvious but more obviously bizarre variant of the grenade relay is a weapon relay. A weapon can be fired and then thrown to another soldier who fires it again, then throws it to another soldier, and so on, without limitation. There is no reason why an entire squad could not fire the same weapon in the same round, possibly multiple times each depending on the specific weapon's TU costs. This will then greatly exceed the normal maximum rate of fire of this weapon, as well as being patently ridiculous. Scenarios where this would be advantageous would be any time that effective weapons against the enemy are in short supply in inventory. Particularly effective with weapons that do have unlimited ammo (lasers, stun rods / tazers / drills).<br />
<br />
===Equipment Use Relay===<br />
The same technique can also be used with Psi Amps / MC Disruptors to allow part or all of the squad to get at least one Psi/MC attempt from just one device. And it can be used with Medi-Kits to exceed the normal limit on healing (etc) per turn. It can also be used with Motion Scanners / Particle Disturbance Sensors to achieve excellent triangulation of signals while only having one such sensing device on the mission.<br />
<br />
==Loot Relay==<br />
<br />
A variant of this technique can be used when ferrying loot, corpses, casualties or equipment back to the transport / exit area during a planned (or unplanned) abort, for example during alien base/colony raiding operations. One unit picks up some heavy objects, and moves with them (some times it is more TU-efficient to throw some objects, depending on the unit's strength and object's weight). Before the end of the unit's turn it throws the object forward, or drops it and moves off the square, so that another unit can continue the Loot Relay during the current turn. <br />
<br />
There are two advantages. First of all, as with the other related exploits, all the squad's combined TUs can be pooled onto a single operation that really should be limited to 100% of one unit's TUs per turn. Instead you can use as much as 1000% TUs per turn, or more, moving a set of heavy objects right across the map in one turn at speeds far faster than should really be possible. It's the equivalent of FTL travel for Battlescape loot. <br />
<br />
The second advantage is to ensure that no one (or as few units as possible) involved in the ferrying process begins or ends their turn holding the heavy objects. This then avoids the significant TU penalties for being encumbered, which only kick in at the beginning of the next turn. It is often more efficient for the last link in the ferrying chain on a given turn to wait over the ferried objects, and only pick them up at the beginning of the next turn, thus having many more TUs to move them forward to the next link. <br />
<br />
The ferrying units should be set up in a "fireman's chain" type of relay. This in itself is not an Exploit, just a good tactic that works in reality. The difference is that by exploiting the TU mechanics, it's as if a chain of ten people could suddenly all run/throw ten times faster than normal.</div>
Spike
https://www.ufopaedia.org/index.php?title=Tactical_Exploits&diff=40306
Tactical Exploits
2012-10-24T09:36:18Z
<p>Spike: /* Weapon Relay */ Grouping</p>
<hr />
<div>= Tactical Exploits =<br />
<br />
== Grenades: Pass the Experience Trick ==<br />
'''(Or who gets the experience when you "drop" a grenade)'''<br />
<br />
Some commanders may have noticed that a soldier that drops a primed grenade rather than throwing it will often not get credited for the damage or killed enemies. <br />
<br />
There is a very odd explanation for this. In order to credit the right person with experience, the game assigns ownership to a grenade. However, ownership is assigned ''after'' the grenade has been thrown, but not when it's dropped or picked up.<br />
<br />
So who gets the experience if its dropped? At the start of a mission, all X-COM owned grenades default to the very first soldier on the transport, or the very first [[Heavy Weapons Platforms|HWP]] if present. This means that if a grenade is used but never thrown during its lifetime, the first soldier or tank gets the experience regardless of actually used it. <br />
<br />
Can we move the ownership around and pass the experience to soldiers of our choice? Definitely! Just have the person you want to get the experience throw the grenade, then get someone else to pick it up and drop it where it can be useful. Just remember to not throw it again.<br />
<br />
The method of deployment for these grenades will be left as a practical exercise to the commander. Be creative, or be heartless - it's all up to you!<br />
<br />
The biggest advantage of this unusual pass-the-experience technique would be to provide training for frail soldiers that would prove to be more of a detriment in combat than out of it - yet another reason for commanders to not sieve troops based on poor combat statistics.<br />
<br />
== Fire ==<br />
<br />
<br />
The [[Known Bugs#Funky Fire|Funky Fire]] bug can be exploited to cause extra damage to units in fire per shot fired, which is arguably an exploit, and to cause additional damage to units who are standing in fire but who are not targeted by the current incendiary attack that is causing the damage, which is definitely an exploit. <br />
<br />
Smoke grenades can be used to put out fire. <br />
<br />
See the [[Incendiary]] topic<br />
<br />
== Fog of War Scouting ==<br />
<br />
The 3D cursor shows the terrain inside it, regardless of whether you have explored the tile or not. While the obscure shapes shown don't mean much to novice players, veterans will soon recognise tiles, and then the map segments they are native to. For example, you can easily find a UFO by looking for the destinctive wall patterns, and the power supply in the center. Or, you could use this to bombard locations such as command centers, or places you know aliens spawn at the beginning of play, with early Blaster Bombs.<br />
<br />
== Object Radar ==<br />
<br />
The map view shows the position of all objects on the map, and updates their current state regardless of whether an X-COM unit has a current line of site to the object. And the largest object on the tile is shown on the main map for any tile which has been previously spotted. Together this can allow you to sometimes detect, and definitely determine by inspection, if an alien has woken up from being stunned, without having line of sight to the target. In multiplayer games (rare) it can be used to deduced the location and progress of opposing forces, if they pick up items from the ground. <br />
<br />
== Dead Man Switches ==<br />
<br />
Grenades will only detonate when they are on the ground and when their timer has counted down. Timers will continue to count down regardless of location, but if the grenade is not on the ground, it will not explode. This means that you can set all the grenades to a time of "0" at the beginning of play, or at an earlier turn, and throw them when it's tactically feasible.<br />
<br />
This is a double-edged sword, however, because should a unit fall dead or unconcious the grenade will hit the ground and promptly take out anything in the near vicinity... which may (or may not) work to your advantage. This tactic encourages keeping your troops far apart. If you anticipate the soldier will have a very high chance of being killed, it may be wise to use the "pass the experience" trick as described earlier before handing the soldier an armed grenade. However, it can be exploited against Tentaculats: give a soldier two armed grenades. If he/she is caught by a Tentaculat, the grenades will drop. The first will kill the zombie while the second kills the newly formed creature. Could also be used with proximity/PD grenades. (This will not work against Chryssalids because the second grenade will be destroyed before detonation, whereas in TFTD, explosives cannot be destroyed by other explosions.)<br />
<br />
Proximity mines can be defused by saving, quitting the game, restarting it then reloading the game. You can still drop on top of them with a flying suit, or by dropping from a hole in the roof in order to safely pick them up.<br />
<br />
==Base Defence Mission Spawning Issues==<br />
<br />
If there are too many soldiers and/or aliens in too small a base, their initial spawning is unusual. Soldiers can spawn in the Access Lift and Hangars. Aliens can spawn outside the Access Lift and Hangars. Some lifeforms may not spawn at all.<br />
<br />
Why does this happen? Each base facility has certain hardcoded spawn tiles. The Living Quarters, for example, have 8 spawn tiles, 7 on the lower level in an "H" pattern, and 1 on the upper level. Soldiers usually spawn at these spawn tiles, semi-randomly outside the Access Lift and Hangars. Aliens are assigned the spawn tiles within the Lift and Hangars. <br />
<br />
But, if the number of soldiers exceeds the number of "friendly" spawn tiles, the excess soldiers will spawn at the "alien" spawn tiles inside the Access Lift and Hangars. Similarly, if the number of aliens exceeds the number of "alien" spawn tiles, the excess aliens will spawn at the "friendly" spawn tiles in the rest of the base. If there are not enough spawn tiles for the sum of soldiers and aliens, then some lifeforms will not spawn at all. Soldiers have higher spawning priority than aliens, so aliens will be the first to go (fail to spawn). All weapons and items will still be generated, though.<br />
<br />
This can be exploited by garrisoning a base with so many soldiers that all spawn tiles are used up. Zero aliens will spawn (but their toys will still be generated), resulting in a bloodless victory and millions of dollars of loot!<br />
<br />
A radar base with one Large Radar or HWD, an Access Lift, and one Living Quarters, can be filled up with 22 soldiers.<br />
<br />
But if this is considered an exploit, then what is the "ethical" thing to do? To get all aliens to spawn properly at a radar base, you would have to go out of your way and build a hangar. This would in turn affect your defence tactics, and cost you money. If you don't build the hangar, you need to recruit at least 25 armed soldiers (with the accompanying Living Quarters and General Stores), or else a Sectopod or Chrysallid will probably spawn behind friendly lines. At that point, you could argue that the computer is the one doing the cheating, and 25 soldiers seems excessive for a radar base. On the other hand, you would be fighting a reduced number of aliens, since the Access Lift only has 8 spawn tiles.<br />
<br />
Also, you can only have 40 "units" where a soldier is one unit and a HWP is 4.<br />
<br />
Maybe you should just shoot down the scouts.<br />
<br />
<table><br />
<tr><td>Base Facility</td><td>Spawn Tiles on Lower / Upper Floor</td></tr><br />
<tr><td>Access Lift</td><td>5 / 3</td></tr><br />
<tr><td>Hangar</td><td>15 / 0</td></tr><br />
<tr><td>Alien Containment</td><td>7 / 5</td></tr><br />
<tr><td>General Stores</td><td>7 / 4</td></tr><br />
<tr><td>HWD or Large Radar</td><td>5 / 1</td></tr><br />
<tr><td>Lab or Workshop</td><td>6 / 1</td></tr><br />
<tr><td>Living Quarters</td><td>7 / 1</td></tr><br />
<tr><td>Missile Defence</td><td>4 / 5</td></tr><br />
<tr><td>Defences (non-missile) or Shields</td><td>5 / 1</td></tr><br />
<tr><td>Psi Lab</td><td>7 / 3</td></tr><br />
<tr><td>Small Radar</td><td>0 / 2</td></tr><br />
</table><br />
<br />
<br />
==Elevator Shielding==<br />
Due to questionable AI, aliens will not fire at you through an elevator (either up or down), even though they can see you and you can see them. When approaching elevators, have a soldier stand on it at the end of the turn, even if this leaves them with no TU. The aliens will not be able to come up/down through the elevator, keeping you safely shielded while you bring up rear troops and prepare for a floor breach. Additionally, soldiers may be able to see aliens standing at/near the elevator above or below them and can fire on them from the safety of their "elevator shield".<br />
<br />
==Risk Free Milking of Alien Bases==<br />
This experience training and (optionally) booty-gathering exploit relies on the "Elevator Shielding" exploit. When assaulting an alien base, your soldiers will be deployed at two staging areas with a 2x2 elevator in each one. Block all eight elevator squares with a soldier and wait for the fun to begin. Just keep skipping your turn and eventually, the aliens will find your soldiers and begin to congregate under the elevator. You can now shoot at them with complete impunity and can even pick out specific soldiers who need Accuracy training. When you see that no more aliens are appearing after a few turns, get your solders onto the evacuation area and leave. The alien base is intact for you to return for additional practice later. If you happened to kill everyone the base will be destroyed, so watch the timing of the alien movement phase and take care not to kill everyone (in practice this means 'save regularly', since there is no in-game way to determine ''exactly'' how many enemy units are left alive). However, the alien leader or commander will almost always stay in the command center, so this is usually not a problem. For best results, arm your soldiers with pistols to maximize the number of shots they can take on each alien. Also, it is not recommended to attempt this tactic on a Sectoid or Ethereal base unless you are very confident of your soldiers' psi strength. As an extra bonus, you can collect alien weapons and equipment before evacuating. It is worth noting that this "shield" does not prevent aliens firing a Blaster Bomb up the lift shaft. However, unless you are running a version of the game that fixes the [[Known_Bugs#Collectors_Edition_Blaster_Bomb_Bug|Vertical Waypoint Blaster Bomb bug]], such attacks will rarely succeed - mostly they will explode on the level below, with no harm to your troops. So unless you have fixed the Vertical Waypoint bug, there is minimal risk with this exploit. But as it is a cowardly and egregious Exploit, fix the Waypoint bug, or better yet, just don't do it.<br />
<br />
==Panicking Alien Location Exploit==<br />
<br />
Whenever a soldier or alien panics or goes berserk from low [[Morale]], there is a message given to the player stating what soldier or alien has done what. As well, the screen is centered on the unit that has failed it's morale check. At times, this will allow sharp-eyed players to locate aliens who have panicked in areas you have already fought, by displaying the location of the alien who has lost their cool.<br />
<br />
==Relaying and Sharing==<br />
<br />
A set of related Exploits arise from the TU system, and the fact that it allows the sequential execution of tasks by different units that really all should be occurring simultaneously, in parallel. <br />
<br />
<br />
===Grenade Relay===<br />
<br />
Many consider this simply a tactic and don't think of it as an Exploit, but measured against realism, its use anything other than very occasionally is an exploit. Simply, a grenade can be primed by one soldier, then thrown between any number of soldiers before being finally delivered to the target. While it is desirable to be able to throw already-primed grenades, for the well attested (but dangerous) practice of throwing a primed grenade ''away'' from friendly troops, using this to cover the battlefield with leap frogging grenades is an exploit to circumvent the (high) TU costs of priming grenades and the (minimal) encumbrance costs of carrying grenades, and is a way of 'concentrating' TUs from safe rear units toward exposed front line units. A number of self-imposed rulesets require not using this tactic. Or rather, this exploit.<br />
<br />
===Weapon Relay===<br />
<br />
A less obvious but more obviously bizarre variant of the grenade relay is a weapon relay. A weapon can be fired and then thrown to another soldier who fires it again, then throws it to another soldier, and so on, without limitation. There is no reason why an entire squad could not fire the same weapon in the same round, possibly multiple times each depending on the specific weapon's TU costs. This will then greatly exceed the normal maximum rate of fire of this weapon, as well as being patently ridiculous. Scenarios where this would be advantageous would be any time that effective weapons against the enemy are in short supply in inventory. Particularly effective with weapons that do have unlimited ammo (lasers, stun rods / tazers / drills).<br />
<br />
==Equipment Use Relay==<br />
The same technique can also be used with Psi Amps / MC Disruptors to allow part or all of the squad to get at least one Psi/MC attempt from just one device. And it can be used with Medi-Kits to exceed the normal limit on healing (etc) per turn. It can also be used with Motion Scanners / Particle Disturbance Sensors to achieve excellent triangulation of signals while only having one such sensing device on the mission.<br />
<br />
==Loot Relay==<br />
<br />
A variant of this technique can be used when ferrying loot, corpses, casualties or equipment back to the transport / exit area during a planned (or unplanned) abort, for example during alien base/colony raiding operations. One unit picks up some heavy objects, and moves with them (some times it is more TU-efficient to throw some objects, depending on the unit's strength and object's weight). Before the end of the unit's turn it throws the object forward, or drops it and moves off the square, so that another unit can continue the Loot Relay during the current turn. <br />
<br />
There are two advantages. First of all, as with the other related exploits, all the squad's combined TUs can be pooled onto a single operation that really should be limited to 100% of one unit's TUs per turn. Instead you can use as much as 1000% TUs per turn, or more, moving a set of heavy objects right across the map in one turn at speeds far faster than should really be possible. It's the equivalent of FTL travel for Battlescape loot. <br />
<br />
The second advantage is to ensure that no one (or as few units as possible) involved in the ferrying process begins or ends their turn holding the heavy objects. This then avoids the significant TU penalties for being encumbered, which only kick in at the beginning of the next turn. It is often more efficient for the last link in the ferrying chain on a given turn to wait over the ferried objects, and only pick them up at the beginning of the next turn, thus having many more TUs to move them forward to the next link. <br />
<br />
The ferrying units should be set up in a "fireman's chain" type of relay. This in itself is not an Exploit, just a good tactic that works in reality. The difference is that by exploiting the TU mechanics, it's as if a chain of ten people could suddenly all run/throw ten times faster than normal.</div>
Spike
https://www.ufopaedia.org/index.php?title=Tactical_Exploits&diff=40305
Tactical Exploits
2012-10-24T09:35:36Z
<p>Spike: /* Relaying and Sharing */ Grouping TU exploits</p>
<hr />
<div>= Tactical Exploits =<br />
<br />
== Grenades: Pass the Experience Trick ==<br />
'''(Or who gets the experience when you "drop" a grenade)'''<br />
<br />
Some commanders may have noticed that a soldier that drops a primed grenade rather than throwing it will often not get credited for the damage or killed enemies. <br />
<br />
There is a very odd explanation for this. In order to credit the right person with experience, the game assigns ownership to a grenade. However, ownership is assigned ''after'' the grenade has been thrown, but not when it's dropped or picked up.<br />
<br />
So who gets the experience if its dropped? At the start of a mission, all X-COM owned grenades default to the very first soldier on the transport, or the very first [[Heavy Weapons Platforms|HWP]] if present. This means that if a grenade is used but never thrown during its lifetime, the first soldier or tank gets the experience regardless of actually used it. <br />
<br />
Can we move the ownership around and pass the experience to soldiers of our choice? Definitely! Just have the person you want to get the experience throw the grenade, then get someone else to pick it up and drop it where it can be useful. Just remember to not throw it again.<br />
<br />
The method of deployment for these grenades will be left as a practical exercise to the commander. Be creative, or be heartless - it's all up to you!<br />
<br />
The biggest advantage of this unusual pass-the-experience technique would be to provide training for frail soldiers that would prove to be more of a detriment in combat than out of it - yet another reason for commanders to not sieve troops based on poor combat statistics.<br />
<br />
== Fire ==<br />
<br />
<br />
The [[Known Bugs#Funky Fire|Funky Fire]] bug can be exploited to cause extra damage to units in fire per shot fired, which is arguably an exploit, and to cause additional damage to units who are standing in fire but who are not targeted by the current incendiary attack that is causing the damage, which is definitely an exploit. <br />
<br />
Smoke grenades can be used to put out fire. <br />
<br />
See the [[Incendiary]] topic<br />
<br />
== Fog of War Scouting ==<br />
<br />
The 3D cursor shows the terrain inside it, regardless of whether you have explored the tile or not. While the obscure shapes shown don't mean much to novice players, veterans will soon recognise tiles, and then the map segments they are native to. For example, you can easily find a UFO by looking for the destinctive wall patterns, and the power supply in the center. Or, you could use this to bombard locations such as command centers, or places you know aliens spawn at the beginning of play, with early Blaster Bombs.<br />
<br />
== Object Radar ==<br />
<br />
The map view shows the position of all objects on the map, and updates their current state regardless of whether an X-COM unit has a current line of site to the object. And the largest object on the tile is shown on the main map for any tile which has been previously spotted. Together this can allow you to sometimes detect, and definitely determine by inspection, if an alien has woken up from being stunned, without having line of sight to the target. In multiplayer games (rare) it can be used to deduced the location and progress of opposing forces, if they pick up items from the ground. <br />
<br />
== Dead Man Switches ==<br />
<br />
Grenades will only detonate when they are on the ground and when their timer has counted down. Timers will continue to count down regardless of location, but if the grenade is not on the ground, it will not explode. This means that you can set all the grenades to a time of "0" at the beginning of play, or at an earlier turn, and throw them when it's tactically feasible.<br />
<br />
This is a double-edged sword, however, because should a unit fall dead or unconcious the grenade will hit the ground and promptly take out anything in the near vicinity... which may (or may not) work to your advantage. This tactic encourages keeping your troops far apart. If you anticipate the soldier will have a very high chance of being killed, it may be wise to use the "pass the experience" trick as described earlier before handing the soldier an armed grenade. However, it can be exploited against Tentaculats: give a soldier two armed grenades. If he/she is caught by a Tentaculat, the grenades will drop. The first will kill the zombie while the second kills the newly formed creature. Could also be used with proximity/PD grenades. (This will not work against Chryssalids because the second grenade will be destroyed before detonation, whereas in TFTD, explosives cannot be destroyed by other explosions.)<br />
<br />
Proximity mines can be defused by saving, quitting the game, restarting it then reloading the game. You can still drop on top of them with a flying suit, or by dropping from a hole in the roof in order to safely pick them up.<br />
<br />
==Base Defence Mission Spawning Issues==<br />
<br />
If there are too many soldiers and/or aliens in too small a base, their initial spawning is unusual. Soldiers can spawn in the Access Lift and Hangars. Aliens can spawn outside the Access Lift and Hangars. Some lifeforms may not spawn at all.<br />
<br />
Why does this happen? Each base facility has certain hardcoded spawn tiles. The Living Quarters, for example, have 8 spawn tiles, 7 on the lower level in an "H" pattern, and 1 on the upper level. Soldiers usually spawn at these spawn tiles, semi-randomly outside the Access Lift and Hangars. Aliens are assigned the spawn tiles within the Lift and Hangars. <br />
<br />
But, if the number of soldiers exceeds the number of "friendly" spawn tiles, the excess soldiers will spawn at the "alien" spawn tiles inside the Access Lift and Hangars. Similarly, if the number of aliens exceeds the number of "alien" spawn tiles, the excess aliens will spawn at the "friendly" spawn tiles in the rest of the base. If there are not enough spawn tiles for the sum of soldiers and aliens, then some lifeforms will not spawn at all. Soldiers have higher spawning priority than aliens, so aliens will be the first to go (fail to spawn). All weapons and items will still be generated, though.<br />
<br />
This can be exploited by garrisoning a base with so many soldiers that all spawn tiles are used up. Zero aliens will spawn (but their toys will still be generated), resulting in a bloodless victory and millions of dollars of loot!<br />
<br />
A radar base with one Large Radar or HWD, an Access Lift, and one Living Quarters, can be filled up with 22 soldiers.<br />
<br />
But if this is considered an exploit, then what is the "ethical" thing to do? To get all aliens to spawn properly at a radar base, you would have to go out of your way and build a hangar. This would in turn affect your defence tactics, and cost you money. If you don't build the hangar, you need to recruit at least 25 armed soldiers (with the accompanying Living Quarters and General Stores), or else a Sectopod or Chrysallid will probably spawn behind friendly lines. At that point, you could argue that the computer is the one doing the cheating, and 25 soldiers seems excessive for a radar base. On the other hand, you would be fighting a reduced number of aliens, since the Access Lift only has 8 spawn tiles.<br />
<br />
Also, you can only have 40 "units" where a soldier is one unit and a HWP is 4.<br />
<br />
Maybe you should just shoot down the scouts.<br />
<br />
<table><br />
<tr><td>Base Facility</td><td>Spawn Tiles on Lower / Upper Floor</td></tr><br />
<tr><td>Access Lift</td><td>5 / 3</td></tr><br />
<tr><td>Hangar</td><td>15 / 0</td></tr><br />
<tr><td>Alien Containment</td><td>7 / 5</td></tr><br />
<tr><td>General Stores</td><td>7 / 4</td></tr><br />
<tr><td>HWD or Large Radar</td><td>5 / 1</td></tr><br />
<tr><td>Lab or Workshop</td><td>6 / 1</td></tr><br />
<tr><td>Living Quarters</td><td>7 / 1</td></tr><br />
<tr><td>Missile Defence</td><td>4 / 5</td></tr><br />
<tr><td>Defences (non-missile) or Shields</td><td>5 / 1</td></tr><br />
<tr><td>Psi Lab</td><td>7 / 3</td></tr><br />
<tr><td>Small Radar</td><td>0 / 2</td></tr><br />
</table><br />
<br />
<br />
==Elevator Shielding==<br />
Due to questionable AI, aliens will not fire at you through an elevator (either up or down), even though they can see you and you can see them. When approaching elevators, have a soldier stand on it at the end of the turn, even if this leaves them with no TU. The aliens will not be able to come up/down through the elevator, keeping you safely shielded while you bring up rear troops and prepare for a floor breach. Additionally, soldiers may be able to see aliens standing at/near the elevator above or below them and can fire on them from the safety of their "elevator shield".<br />
<br />
==Risk Free Milking of Alien Bases==<br />
This experience training and (optionally) booty-gathering exploit relies on the "Elevator Shielding" exploit. When assaulting an alien base, your soldiers will be deployed at two staging areas with a 2x2 elevator in each one. Block all eight elevator squares with a soldier and wait for the fun to begin. Just keep skipping your turn and eventually, the aliens will find your soldiers and begin to congregate under the elevator. You can now shoot at them with complete impunity and can even pick out specific soldiers who need Accuracy training. When you see that no more aliens are appearing after a few turns, get your solders onto the evacuation area and leave. The alien base is intact for you to return for additional practice later. If you happened to kill everyone the base will be destroyed, so watch the timing of the alien movement phase and take care not to kill everyone (in practice this means 'save regularly', since there is no in-game way to determine ''exactly'' how many enemy units are left alive). However, the alien leader or commander will almost always stay in the command center, so this is usually not a problem. For best results, arm your soldiers with pistols to maximize the number of shots they can take on each alien. Also, it is not recommended to attempt this tactic on a Sectoid or Ethereal base unless you are very confident of your soldiers' psi strength. As an extra bonus, you can collect alien weapons and equipment before evacuating. It is worth noting that this "shield" does not prevent aliens firing a Blaster Bomb up the lift shaft. However, unless you are running a version of the game that fixes the [[Known_Bugs#Collectors_Edition_Blaster_Bomb_Bug|Vertical Waypoint Blaster Bomb bug]], such attacks will rarely succeed - mostly they will explode on the level below, with no harm to your troops. So unless you have fixed the Vertical Waypoint bug, there is minimal risk with this exploit. But as it is a cowardly and egregious Exploit, fix the Waypoint bug, or better yet, just don't do it.<br />
<br />
==Panicking Alien Location Exploit==<br />
<br />
Whenever a soldier or alien panics or goes berserk from low [[Morale]], there is a message given to the player stating what soldier or alien has done what. As well, the screen is centered on the unit that has failed it's morale check. At times, this will allow sharp-eyed players to locate aliens who have panicked in areas you have already fought, by displaying the location of the alien who has lost their cool.<br />
<br />
==Relaying and Sharing==<br />
<br />
A set of related Exploits arise from the TU system, and the fact that it allows the sequential execution of tasks by different units that really all should be occurring simultaneously, in parallel. <br />
<br />
<br />
===Grenade Relay===<br />
<br />
Many consider this simply a tactic and don't think of it as an Exploit, but measured against realism, its use anything other than very occasionally is an exploit. Simply, a grenade can be primed by one soldier, then thrown between any number of soldiers before being finally delivered to the target. While it is desirable to be able to throw already-primed grenades, for the well attested (but dangerous) practice of throwing a primed grenade ''away'' from friendly troops, using this to cover the battlefield with leap frogging grenades is an exploit to circumvent the (high) TU costs of priming grenades and the (minimal) encumbrance costs of carrying grenades, and is a way of 'concentrating' TUs from safe rear units toward exposed front line units. A number of self-imposed rulesets require not using this tactic. Or rather, this exploit.<br />
<br />
==Weapon Relay==<br />
<br />
A less obvious but more obviously bizarre variant of the grenade relay is a weapon relay. A weapon can be fired and then thrown to another soldier who fires it again, then throws it to another soldier, and so on, without limitation. There is no reason why an entire squad could not fire the same weapon in the same round, possibly multiple times each depending on the specific weapon's TU costs. This will then greatly exceed the normal maximum rate of fire of this weapon, as well as being patently ridiculous. Scenarios where this would be advantageous would be any time that effective weapons against the enemy are in short supply in inventory. Particularly effective with weapons that do have unlimited ammo (lasers, stun rods / tazers / drills).<br />
<br />
==Equipment Use Relay==<br />
The same technique can also be used with Psi Amps / MC Disruptors to allow part or all of the squad to get at least one Psi/MC attempt from just one device. And it can be used with Medi-Kits to exceed the normal limit on healing (etc) per turn. It can also be used with Motion Scanners / Particle Disturbance Sensors to achieve excellent triangulation of signals while only having one such sensing device on the mission.<br />
<br />
==Loot Relay==<br />
<br />
A variant of this technique can be used when ferrying loot, corpses, casualties or equipment back to the transport / exit area during a planned (or unplanned) abort, for example during alien base/colony raiding operations. One unit picks up some heavy objects, and moves with them (some times it is more TU-efficient to throw some objects, depending on the unit's strength and object's weight). Before the end of the unit's turn it throws the object forward, or drops it and moves off the square, so that another unit can continue the Loot Relay during the current turn. <br />
<br />
There are two advantages. First of all, as with the other related exploits, all the squad's combined TUs can be pooled onto a single operation that really should be limited to 100% of one unit's TUs per turn. Instead you can use as much as 1000% TUs per turn, or more, moving a set of heavy objects right across the map in one turn at speeds far faster than should really be possible. It's the equivalent of FTL travel for Battlescape loot. <br />
<br />
The second advantage is to ensure that no one (or as few units as possible) involved in the ferrying process begins or ends their turn holding the heavy objects. This then avoids the significant TU penalties for being encumbered, which only kick in at the beginning of the next turn. It is often more efficient for the last link in the ferrying chain on a given turn to wait over the ferried objects, and only pick them up at the beginning of the next turn, thus having many more TUs to move them forward to the next link. <br />
<br />
The ferrying units should be set up in a "fireman's chain" type of relay. This in itself is not an Exploit, just a good tactic that works in reality. The difference is that by exploiting the TU mechanics, it's as if a chain of ten people could suddenly all run/throw ten times faster than normal.</div>
Spike
https://www.ufopaedia.org/index.php?title=Tactical_Exploits&diff=40304
Tactical Exploits
2012-10-24T09:30:45Z
<p>Spike: /* Free Milk at Alien Bases */ Base Milking per se is not an Exploit, so renamed this Exploit</p>
<hr />
<div>= Tactical Exploits =<br />
<br />
== Grenades: Pass the Experience Trick ==<br />
'''(Or who gets the experience when you "drop" a grenade)'''<br />
<br />
Some commanders may have noticed that a soldier that drops a primed grenade rather than throwing it will often not get credited for the damage or killed enemies. <br />
<br />
There is a very odd explanation for this. In order to credit the right person with experience, the game assigns ownership to a grenade. However, ownership is assigned ''after'' the grenade has been thrown, but not when it's dropped or picked up.<br />
<br />
So who gets the experience if its dropped? At the start of a mission, all X-COM owned grenades default to the very first soldier on the transport, or the very first [[Heavy Weapons Platforms|HWP]] if present. This means that if a grenade is used but never thrown during its lifetime, the first soldier or tank gets the experience regardless of actually used it. <br />
<br />
Can we move the ownership around and pass the experience to soldiers of our choice? Definitely! Just have the person you want to get the experience throw the grenade, then get someone else to pick it up and drop it where it can be useful. Just remember to not throw it again.<br />
<br />
The method of deployment for these grenades will be left as a practical exercise to the commander. Be creative, or be heartless - it's all up to you!<br />
<br />
The biggest advantage of this unusual pass-the-experience technique would be to provide training for frail soldiers that would prove to be more of a detriment in combat than out of it - yet another reason for commanders to not sieve troops based on poor combat statistics.<br />
<br />
== Fire ==<br />
<br />
<br />
The [[Known Bugs#Funky Fire|Funky Fire]] bug can be exploited to cause extra damage to units in fire per shot fired, which is arguably an exploit, and to cause additional damage to units who are standing in fire but who are not targeted by the current incendiary attack that is causing the damage, which is definitely an exploit. <br />
<br />
Smoke grenades can be used to put out fire. <br />
<br />
See the [[Incendiary]] topic<br />
<br />
== Fog of War Scouting ==<br />
<br />
The 3D cursor shows the terrain inside it, regardless of whether you have explored the tile or not. While the obscure shapes shown don't mean much to novice players, veterans will soon recognise tiles, and then the map segments they are native to. For example, you can easily find a UFO by looking for the destinctive wall patterns, and the power supply in the center. Or, you could use this to bombard locations such as command centers, or places you know aliens spawn at the beginning of play, with early Blaster Bombs.<br />
<br />
== Object Radar ==<br />
<br />
The map view shows the position of all objects on the map, and updates their current state regardless of whether an X-COM unit has a current line of site to the object. And the largest object on the tile is shown on the main map for any tile which has been previously spotted. Together this can allow you to sometimes detect, and definitely determine by inspection, if an alien has woken up from being stunned, without having line of sight to the target. In multiplayer games (rare) it can be used to deduced the location and progress of opposing forces, if they pick up items from the ground. <br />
<br />
== Dead Man Switches ==<br />
<br />
Grenades will only detonate when they are on the ground and when their timer has counted down. Timers will continue to count down regardless of location, but if the grenade is not on the ground, it will not explode. This means that you can set all the grenades to a time of "0" at the beginning of play, or at an earlier turn, and throw them when it's tactically feasible.<br />
<br />
This is a double-edged sword, however, because should a unit fall dead or unconcious the grenade will hit the ground and promptly take out anything in the near vicinity... which may (or may not) work to your advantage. This tactic encourages keeping your troops far apart. If you anticipate the soldier will have a very high chance of being killed, it may be wise to use the "pass the experience" trick as described earlier before handing the soldier an armed grenade. However, it can be exploited against Tentaculats: give a soldier two armed grenades. If he/she is caught by a Tentaculat, the grenades will drop. The first will kill the zombie while the second kills the newly formed creature. Could also be used with proximity/PD grenades. (This will not work against Chryssalids because the second grenade will be destroyed before detonation, whereas in TFTD, explosives cannot be destroyed by other explosions.)<br />
<br />
Proximity mines can be defused by saving, quitting the game, restarting it then reloading the game. You can still drop on top of them with a flying suit, or by dropping from a hole in the roof in order to safely pick them up.<br />
<br />
==Base Defence Mission Spawning Issues==<br />
<br />
If there are too many soldiers and/or aliens in too small a base, their initial spawning is unusual. Soldiers can spawn in the Access Lift and Hangars. Aliens can spawn outside the Access Lift and Hangars. Some lifeforms may not spawn at all.<br />
<br />
Why does this happen? Each base facility has certain hardcoded spawn tiles. The Living Quarters, for example, have 8 spawn tiles, 7 on the lower level in an "H" pattern, and 1 on the upper level. Soldiers usually spawn at these spawn tiles, semi-randomly outside the Access Lift and Hangars. Aliens are assigned the spawn tiles within the Lift and Hangars. <br />
<br />
But, if the number of soldiers exceeds the number of "friendly" spawn tiles, the excess soldiers will spawn at the "alien" spawn tiles inside the Access Lift and Hangars. Similarly, if the number of aliens exceeds the number of "alien" spawn tiles, the excess aliens will spawn at the "friendly" spawn tiles in the rest of the base. If there are not enough spawn tiles for the sum of soldiers and aliens, then some lifeforms will not spawn at all. Soldiers have higher spawning priority than aliens, so aliens will be the first to go (fail to spawn). All weapons and items will still be generated, though.<br />
<br />
This can be exploited by garrisoning a base with so many soldiers that all spawn tiles are used up. Zero aliens will spawn (but their toys will still be generated), resulting in a bloodless victory and millions of dollars of loot!<br />
<br />
A radar base with one Large Radar or HWD, an Access Lift, and one Living Quarters, can be filled up with 22 soldiers.<br />
<br />
But if this is considered an exploit, then what is the "ethical" thing to do? To get all aliens to spawn properly at a radar base, you would have to go out of your way and build a hangar. This would in turn affect your defence tactics, and cost you money. If you don't build the hangar, you need to recruit at least 25 armed soldiers (with the accompanying Living Quarters and General Stores), or else a Sectopod or Chrysallid will probably spawn behind friendly lines. At that point, you could argue that the computer is the one doing the cheating, and 25 soldiers seems excessive for a radar base. On the other hand, you would be fighting a reduced number of aliens, since the Access Lift only has 8 spawn tiles.<br />
<br />
Also, you can only have 40 "units" where a soldier is one unit and a HWP is 4.<br />
<br />
Maybe you should just shoot down the scouts.<br />
<br />
<table><br />
<tr><td>Base Facility</td><td>Spawn Tiles on Lower / Upper Floor</td></tr><br />
<tr><td>Access Lift</td><td>5 / 3</td></tr><br />
<tr><td>Hangar</td><td>15 / 0</td></tr><br />
<tr><td>Alien Containment</td><td>7 / 5</td></tr><br />
<tr><td>General Stores</td><td>7 / 4</td></tr><br />
<tr><td>HWD or Large Radar</td><td>5 / 1</td></tr><br />
<tr><td>Lab or Workshop</td><td>6 / 1</td></tr><br />
<tr><td>Living Quarters</td><td>7 / 1</td></tr><br />
<tr><td>Missile Defence</td><td>4 / 5</td></tr><br />
<tr><td>Defences (non-missile) or Shields</td><td>5 / 1</td></tr><br />
<tr><td>Psi Lab</td><td>7 / 3</td></tr><br />
<tr><td>Small Radar</td><td>0 / 2</td></tr><br />
</table><br />
<br />
<br />
==Elevator Shielding==<br />
Due to questionable AI, aliens will not fire at you through an elevator (either up or down), even though they can see you and you can see them. When approaching elevators, have a soldier stand on it at the end of the turn, even if this leaves them with no TU. The aliens will not be able to come up/down through the elevator, keeping you safely shielded while you bring up rear troops and prepare for a floor breach. Additionally, soldiers may be able to see aliens standing at/near the elevator above or below them and can fire on them from the safety of their "elevator shield".<br />
<br />
==Risk Free Milking of Alien Bases==<br />
This experience training and (optionally) booty-gathering exploit relies on the "Elevator Shielding" exploit. When assaulting an alien base, your soldiers will be deployed at two staging areas with a 2x2 elevator in each one. Block all eight elevator squares with a soldier and wait for the fun to begin. Just keep skipping your turn and eventually, the aliens will find your soldiers and begin to congregate under the elevator. You can now shoot at them with complete impunity and can even pick out specific soldiers who need Accuracy training. When you see that no more aliens are appearing after a few turns, get your solders onto the evacuation area and leave. The alien base is intact for you to return for additional practice later. If you happened to kill everyone the base will be destroyed, so watch the timing of the alien movement phase and take care not to kill everyone (in practice this means 'save regularly', since there is no in-game way to determine ''exactly'' how many enemy units are left alive). However, the alien leader or commander will almost always stay in the command center, so this is usually not a problem. For best results, arm your soldiers with pistols to maximize the number of shots they can take on each alien. Also, it is not recommended to attempt this tactic on a Sectoid or Ethereal base unless you are very confident of your soldiers' psi strength. As an extra bonus, you can collect alien weapons and equipment before evacuating. It is worth noting that this "shield" does not prevent aliens firing a Blaster Bomb up the lift shaft. However, unless you are running a version of the game that fixes the [[Known_Bugs#Collectors_Edition_Blaster_Bomb_Bug|Vertical Waypoint Blaster Bomb bug]], such attacks will rarely succeed - mostly they will explode on the level below, with no harm to your troops. So unless you have fixed the Vertical Waypoint bug, there is minimal risk with this exploit. But as it is a cowardly and egregious Exploit, fix the Waypoint bug, or better yet, just don't do it.<br />
<br />
==Panicking Alien Location Exploit==<br />
<br />
Whenever a soldier or alien panics or goes berserk from low [[Morale]], there is a message given to the player stating what soldier or alien has done what. As well, the screen is centered on the unit that has failed it's morale check. At times, this will allow sharp-eyed players to locate aliens who have panicked in areas you have already fought, by displaying the location of the alien who has lost their cool.<br />
<br />
==Grenade Relay==<br />
<br />
Some consider this simply a tactic, but measured against realism, its use anything other than very occasionally is an exploit. Simply, a grenade can be primed by one soldier, then thrown between any number of soldiers before being finally delivered to the target. While it is desirable to be able to throw already-primed grenades, for the well attested (but dangerous) practice of throwing a primed grenade ''away'' from friendly troops, using this to cover the battlefield with leap frogging grenades is an exploit to circumvent the (high) TU costs of priming grenades and the (minimal) encumbrance costs of carrying grenades, and is a way of 'concentrating' TUs from safe rear units toward exposed front line units. A number of self-imposed rulesets require not using this tactic. Or exploit. <br />
<br />
==Weapon Relay==<br />
<br />
A less obvious but more obviously bizarre variant of the grenade relay is a weapon relay. A weapon can be fired and then thrown to another soldier who fires it again, then throws it to another soldier, and so on, without limitation. There is no reason why an entire squad could not fire the same weapon in the same round, possibly multiple times each depending on the specific weapon's TU costs. This will then greatly exceed the normal maximum rate of fire of this weapon, as well as being patently ridiculous. Scenarios where this would be advantageous would be any time that effective weapons against the enemy are in short supply in inventory. Particularly effective with weapons that do have unlimited ammo (lasers, stun rods / tazers / drills).<br />
<br />
==Equipment Use Relay==<br />
The same technique can also be used with Psi Amps / MC Disruptors to allow part or all of the squad to get at least one Psi/MC attempt from just one device. And it can be used with Medi-Kits to exceed the normal limit on healing (etc) per turn. It can also be used with Motion Scanners / Particle Disturbance Sensors to achieve excellent triangulation of signals while only having one such sensing device on the mission.<br />
<br />
==Loot Relay==<br />
<br />
A variant of this technique can be used when ferrying loot, corpses, casualties or equipment back to the transport / exit area during a planned (or unplanned) abort, for example during alien base/colony raiding operations. One unit picks up some heavy objects, and moves with them (some times it is more TU-efficient to throw some objects, depending on the unit's strength and object's weight). Before the end of the unit's turn it throws the object forward, or drops it and moves off the square, so that another unit can continue the Loot Relay during the current turn. <br />
<br />
There are two advantages. First of all, as with the other related exploits, all the squad's combined TUs can be pooled onto a single operation that really should be limited to 100% of one unit's TUs per turn. Instead you can use as much as 1000% TUs per turn, or more, moving a set of heavy objects right across the map in one turn at speeds far faster than should really be possible. It's the equivalent of FTL travel for Battlescape loot. <br />
<br />
The second advantage is to ensure that no one (or as few units as possible) involved in the ferrying process begins or ends their turn holding the heavy objects. This then avoids the significant TU penalties for being encumbered, which only kick in at the beginning of the next turn. It is often more efficient for the last link in the ferrying chain on a given turn to wait over the ferried objects, and only pick them up at the beginning of the next turn, thus having many more TUs to move them forward to the next link. <br />
<br />
The ferrying units should be set up in a "fireman's chain" type of relay. This in itself is not an Exploit, just a good tactic that works in reality. The difference is that by exploiting the TU mechanics, it's as if a chain of ten people could suddenly all run/throw ten times faster than normal.</div>
Spike
https://www.ufopaedia.org/index.php?title=Tactical_Exploits&diff=40302
Tactical Exploits
2012-10-24T09:24:57Z
<p>Spike: /* Loot Relay */</p>
<hr />
<div>= Tactical Exploits =<br />
<br />
== Grenades: Pass the Experience Trick ==<br />
'''(Or who gets the experience when you "drop" a grenade)'''<br />
<br />
Some commanders may have noticed that a soldier that drops a primed grenade rather than throwing it will often not get credited for the damage or killed enemies. <br />
<br />
There is a very odd explanation for this. In order to credit the right person with experience, the game assigns ownership to a grenade. However, ownership is assigned ''after'' the grenade has been thrown, but not when it's dropped or picked up.<br />
<br />
So who gets the experience if its dropped? At the start of a mission, all X-COM owned grenades default to the very first soldier on the transport, or the very first [[Heavy Weapons Platforms|HWP]] if present. This means that if a grenade is used but never thrown during its lifetime, the first soldier or tank gets the experience regardless of actually used it. <br />
<br />
Can we move the ownership around and pass the experience to soldiers of our choice? Definitely! Just have the person you want to get the experience throw the grenade, then get someone else to pick it up and drop it where it can be useful. Just remember to not throw it again.<br />
<br />
The method of deployment for these grenades will be left as a practical exercise to the commander. Be creative, or be heartless - it's all up to you!<br />
<br />
The biggest advantage of this unusual pass-the-experience technique would be to provide training for frail soldiers that would prove to be more of a detriment in combat than out of it - yet another reason for commanders to not sieve troops based on poor combat statistics.<br />
<br />
== Fire ==<br />
<br />
<br />
The [[Known Bugs#Funky Fire|Funky Fire]] bug can be exploited to cause extra damage to units in fire per shot fired, which is arguably an exploit, and to cause additional damage to units who are standing in fire but who are not targeted by the current incendiary attack that is causing the damage, which is definitely an exploit. <br />
<br />
Smoke grenades can be used to put out fire. <br />
<br />
See the [[Incendiary]] topic<br />
<br />
== Fog of War Scouting ==<br />
<br />
The 3D cursor shows the terrain inside it, regardless of whether you have explored the tile or not. While the obscure shapes shown don't mean much to novice players, veterans will soon recognise tiles, and then the map segments they are native to. For example, you can easily find a UFO by looking for the destinctive wall patterns, and the power supply in the center. Or, you could use this to bombard locations such as command centers, or places you know aliens spawn at the beginning of play, with early Blaster Bombs.<br />
<br />
== Object Radar ==<br />
<br />
The map view shows the position of all objects on the map, and updates their current state regardless of whether an X-COM unit has a current line of site to the object. And the largest object on the tile is shown on the main map for any tile which has been previously spotted. Together this can allow you to sometimes detect, and definitely determine by inspection, if an alien has woken up from being stunned, without having line of sight to the target. In multiplayer games (rare) it can be used to deduced the location and progress of opposing forces, if they pick up items from the ground. <br />
<br />
== Dead Man Switches ==<br />
<br />
Grenades will only detonate when they are on the ground and when their timer has counted down. Timers will continue to count down regardless of location, but if the grenade is not on the ground, it will not explode. This means that you can set all the grenades to a time of "0" at the beginning of play, or at an earlier turn, and throw them when it's tactically feasible.<br />
<br />
This is a double-edged sword, however, because should a unit fall dead or unconcious the grenade will hit the ground and promptly take out anything in the near vicinity... which may (or may not) work to your advantage. This tactic encourages keeping your troops far apart. If you anticipate the soldier will have a very high chance of being killed, it may be wise to use the "pass the experience" trick as described earlier before handing the soldier an armed grenade. However, it can be exploited against Tentaculats: give a soldier two armed grenades. If he/she is caught by a Tentaculat, the grenades will drop. The first will kill the zombie while the second kills the newly formed creature. Could also be used with proximity/PD grenades. (This will not work against Chryssalids because the second grenade will be destroyed before detonation, whereas in TFTD, explosives cannot be destroyed by other explosions.)<br />
<br />
Proximity mines can be defused by saving, quitting the game, restarting it then reloading the game. You can still drop on top of them with a flying suit, or by dropping from a hole in the roof in order to safely pick them up.<br />
<br />
==Base Defence Mission Spawning Issues==<br />
<br />
If there are too many soldiers and/or aliens in too small a base, their initial spawning is unusual. Soldiers can spawn in the Access Lift and Hangars. Aliens can spawn outside the Access Lift and Hangars. Some lifeforms may not spawn at all.<br />
<br />
Why does this happen? Each base facility has certain hardcoded spawn tiles. The Living Quarters, for example, have 8 spawn tiles, 7 on the lower level in an "H" pattern, and 1 on the upper level. Soldiers usually spawn at these spawn tiles, semi-randomly outside the Access Lift and Hangars. Aliens are assigned the spawn tiles within the Lift and Hangars. <br />
<br />
But, if the number of soldiers exceeds the number of "friendly" spawn tiles, the excess soldiers will spawn at the "alien" spawn tiles inside the Access Lift and Hangars. Similarly, if the number of aliens exceeds the number of "alien" spawn tiles, the excess aliens will spawn at the "friendly" spawn tiles in the rest of the base. If there are not enough spawn tiles for the sum of soldiers and aliens, then some lifeforms will not spawn at all. Soldiers have higher spawning priority than aliens, so aliens will be the first to go (fail to spawn). All weapons and items will still be generated, though.<br />
<br />
This can be exploited by garrisoning a base with so many soldiers that all spawn tiles are used up. Zero aliens will spawn (but their toys will still be generated), resulting in a bloodless victory and millions of dollars of loot!<br />
<br />
A radar base with one Large Radar or HWD, an Access Lift, and one Living Quarters, can be filled up with 22 soldiers.<br />
<br />
But if this is considered an exploit, then what is the "ethical" thing to do? To get all aliens to spawn properly at a radar base, you would have to go out of your way and build a hangar. This would in turn affect your defence tactics, and cost you money. If you don't build the hangar, you need to recruit at least 25 armed soldiers (with the accompanying Living Quarters and General Stores), or else a Sectopod or Chrysallid will probably spawn behind friendly lines. At that point, you could argue that the computer is the one doing the cheating, and 25 soldiers seems excessive for a radar base. On the other hand, you would be fighting a reduced number of aliens, since the Access Lift only has 8 spawn tiles.<br />
<br />
Also, you can only have 40 "units" where a soldier is one unit and a HWP is 4.<br />
<br />
Maybe you should just shoot down the scouts.<br />
<br />
<table><br />
<tr><td>Base Facility</td><td>Spawn Tiles on Lower / Upper Floor</td></tr><br />
<tr><td>Access Lift</td><td>5 / 3</td></tr><br />
<tr><td>Hangar</td><td>15 / 0</td></tr><br />
<tr><td>Alien Containment</td><td>7 / 5</td></tr><br />
<tr><td>General Stores</td><td>7 / 4</td></tr><br />
<tr><td>HWD or Large Radar</td><td>5 / 1</td></tr><br />
<tr><td>Lab or Workshop</td><td>6 / 1</td></tr><br />
<tr><td>Living Quarters</td><td>7 / 1</td></tr><br />
<tr><td>Missile Defence</td><td>4 / 5</td></tr><br />
<tr><td>Defences (non-missile) or Shields</td><td>5 / 1</td></tr><br />
<tr><td>Psi Lab</td><td>7 / 3</td></tr><br />
<tr><td>Small Radar</td><td>0 / 2</td></tr><br />
</table><br />
<br />
<br />
==Elevator Shielding==<br />
Due to questionable AI, aliens will not fire at you through an elevator (either up or down), even though they can see you and you can see them. When approaching elevators, have a soldier stand on it at the end of the turn, even if this leaves them with no TU. The aliens will not be able to come up/down through the elevator, keeping you safely shielded while you bring up rear troops and prepare for a floor breach. Additionally, soldiers may be able to see aliens standing at/near the elevator above or below them and can fire on them from the safety of their "elevator shield".<br />
<br />
==Milking Alien Bases==<br />
This experience training and (optionally) booty-gathering exploit relies on the "Elevator Shielding" exploit. When assaulting an alien base, your soldiers will be deployed at two staging areas with a 2x2 elevator in each one. Block all eight elevator squares with a soldier and wait for the fun to begin. Just keep skipping your turn and eventually, the aliens will find your soldiers and begin to congregate under the elevator. You can now shoot at them with complete impunity and can even pick out specific soldiers who need Accuracy training. When you see that no more aliens are appearing after a few turns, get your solders onto the evactuation area and leave. The alien base is intact for you to return for additional practice later. If you happened to kill everyone the base will be destroyed, so watch the timing of the alien movement phase and take care not to kill everyone (in practice this means 'save regularly', since there is no in-game way to determine ''exactly'' how many enemy units are left alive). However, the alien leader or commander will almost always stay in the command center, so this is usually not a problem. For best results, arm your soldiers with pistols to maximize the number of shots they can take on each alien. Also, it is not recommended to attempt this tactic on a Sectoid or Ethereal base unless you are very confident of your soldiers' psi strength. As an extra bonus, you can collect alien weapons and equipment before evacuating. It is worth noting that this "shield" does not prevent aliens firing a Blaster Bomb up the lift shaft. However, unless you are running a version of the game that fixes the [[Known_Bugs#Collectors_Edition_Blaster_Bomb_Bug|Vertical Waypoint Blaster Bomb bug]], such attacks will rarely succeed - mostly they will explode on the level below, with no harm to your troops. So unless you have fixed the Vertical Waypoint bug, there is minimal risk with this exploit.<br />
<br />
==Panicking Alien Location Exploit==<br />
<br />
Whenever a soldier or alien panics or goes berserk from low [[Morale]], there is a message given to the player stating what soldier or alien has done what. As well, the screen is centered on the unit that has failed it's morale check. At times, this will allow sharp-eyed players to locate aliens who have panicked in areas you have already fought, by displaying the location of the alien who has lost their cool.<br />
<br />
==Grenade Relay==<br />
<br />
Some consider this simply a tactic, but measured against realism, its use anything other than very occasionally is an exploit. Simply, a grenade can be primed by one soldier, then thrown between any number of soldiers before being finally delivered to the target. While it is desirable to be able to throw already-primed grenades, for the well attested (but dangerous) practice of throwing a primed grenade ''away'' from friendly troops, using this to cover the battlefield with leap frogging grenades is an exploit to circumvent the (high) TU costs of priming grenades and the (minimal) encumbrance costs of carrying grenades, and is a way of 'concentrating' TUs from safe rear units toward exposed front line units. A number of self-imposed rulesets require not using this tactic. Or exploit. <br />
<br />
==Weapon Relay==<br />
<br />
A less obvious but more obviously bizarre variant of the grenade relay is a weapon relay. A weapon can be fired and then thrown to another soldier who fires it again, then throws it to another soldier, and so on, without limitation. There is no reason why an entire squad could not fire the same weapon in the same round, possibly multiple times each depending on the specific weapon's TU costs. This will then greatly exceed the normal maximum rate of fire of this weapon, as well as being patently ridiculous. Scenarios where this would be advantageous would be any time that effective weapons against the enemy are in short supply in inventory. Particularly effective with weapons that do have unlimited ammo (lasers, stun rods / tazers / drills).<br />
<br />
==Equipment Use Relay==<br />
The same technique can also be used with Psi Amps / MC Disruptors to allow part or all of the squad to get at least one Psi/MC attempt from just one device. And it can be used with Medi-Kits to exceed the normal limit on healing (etc) per turn. It can also be used with Motion Scanners / Particle Disturbance Sensors to achieve excellent triangulation of signals while only having one such sensing device on the mission.<br />
<br />
==Loot Relay==<br />
<br />
A variant of this technique can be used when ferrying loot, corpses, casualties or equipment back to the transport / exit area during a planned (or unplanned) abort, for example during alien base/colony raiding operations. One unit picks up some heavy objects, and moves with them (some times it is more TU-efficient to throw some objects, depending on the unit's strength and object's weight). Before the end of the unit's turn it throws the object forward, or drops it and moves off the square, so that another unit can continue the Loot Relay during the current turn. <br />
<br />
There are two advantages. First of all, as with the other related exploits, all the squad's combined TUs can be pooled onto a single operation that really should be limited to 100% of one unit's TUs per turn. Instead you can use as much as 1000% TUs per turn, or more, moving a set of heavy objects right across the map in one turn at speeds far faster than should really be possible. It's the equivalent of FTL travel for Battlescape loot. <br />
<br />
The second advantage is to ensure that no one (or as few units as possible) involved in the ferrying process begins or ends their turn holding the heavy objects. This then avoids the significant TU penalties for being encumbered, which only kick in at the beginning of the next turn. It is often more efficient for the last link in the ferrying chain on a given turn to wait over the ferried objects, and only pick them up at the beginning of the next turn, thus having many more TUs to move them forward to the next link. <br />
<br />
The ferrying units should be set up in a "fireman's chain" type of relay. This in itself is not an Exploit, just a good tactic that works in reality. The difference is that by exploiting the TU mechanics, it's as if a chain of ten people could suddenly all run/throw ten times faster than normal.</div>
Spike
https://www.ufopaedia.org/index.php?title=Talk:TFTDextender&diff=40272
Talk:TFTDextender
2012-10-24T01:38:58Z
<p>Spike: /* Items on transport floor lost */ Could be original bug</p>
<hr />
<div>=Questions or Comments=<br />
'''A place to provide feedback or ask questions:'''<br />
<br />
The zip archive does not seem to include an .ini file. Where do I get the .ini file from? <br />
:: Oh hang on. It looks like the latest version of the zip file does not include the .ini file. When I go back to the previous version of the zip file, I can see the .ini file. [[User:Spike|Spike]] 17:45, 6 September 2012 (EDT)<br />
<br />
:::''The latest release is a patch, which means there are no new additions to the INI. I don't include it in patches usually so that those who already have the prior release don't have to reconfigure their current INI. It may not seem like a big deal now but earlier, I was releasing fixes almost on a weekly basis and so I still continue with that idea.''[[User:Morgan525|Tycho]]<br />
<br />
== Bug Reports ==<br />
<br />
=== Crash 0xFFE00B30 ===<br />
<br />
:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."<br />
<br />
''Interesting. I had someone report a similar thing when they were starting their first instance of the battlescape on a new install of the game. I looked into it and the game generated some bad data. When he let the UFO take off and land again, the battle started with no problems..''<br />
<br />
:It's [[Known_Bugs_(TFTD)#Geoscape_Bugs|a bug I've reported before]] (before TFTD Extender even existed), so it's not specific to TFTDExtender / UFOExtender. What is happening is the Alien Sub is landing on land, and the Triton is also attempting to land on land. Probably the game crashes when it fails to generate the appropriate terrain type? So the GEOSCAPE map/terrain data must be corrupted. I've seen three examples of this. In a couple of cases the landing site is clearly inland, by hundreds of kilometres. In some cases it's right on the sea/land boundary and hard to tell. I have two save games that reproduce the bug now. From memory, the previous cases all happened around North Africa, like these present cases. [[User:Spike|Spike]] 08:31, 9 September 2012 (EDT)<br />
<br />
=== Cannot build Leviathan ===<br />
<br />
Hi Tycho. I've just researched Leviathan in my TFDExtender game but cannot manufacture it! I have enough resources (Plastics, IBA, ManNav), 3 workshops, more than 100 technicans and one empty sub pen. But when starting the Leviathan manufacture task I cannot assign any technicans to it. I press the "up" button, and there are no reaction to this. I can build Manta, but not Leviathan. Don't you know what is it? [[User:PavelB|PavelB]] 06:55, 2 October 2012 (EDT)<br />
<br />
: Double check that you have sufficient cash to start the project, iirc $600K or so. That matches this symptom. Also that you have enough workshop space available (Leviathan needs a lot of space). Failing that, cancel all existing manufacturing projects, then retry. Failing that you could try reducing Technicians below 100 but that's taking us into Bug territory. [[User:Spike|Spike]] 07:17, 2 October 2012 (EDT)<br />
<br />
:: Resources are 100% enough. I've launched "Terror from the Deep.exe", loaded this saved game and started manufacturing Lev without any problems. I've saved this variant with Lev being manufactured and then loaded it from "TFTDextender.exe". As a result the process was okey, but I could only decrease the number of technicans working on it, not increase (even after decreasing!). That is: with 64 technicans had been assigned, I've pressed the "down" button, and the number changed to 63. But then I was unable to revert it to 64 by pressing "up" button: it didn't work! [[User:PavelB|PavelB]] 07:57, 2 October 2012 (EDT)<br />
:''I'll check into it. Although, I can't understand how changes to the research tree would affect production. Unless it has something to do with the autoproduce feature?''<br />
:'''This problem may be fixed with the same patch that fixed the production materials being deducted from the wrong base. Can anyone confirm?'''- - [[User:Morgan525|Tycho]] 23:12, 17 October 2012 (EDT)<br />
:: If I try to replicate PavelB's situation, I am able to build a Leviathan with no problems using the latest build. However I am also able to build a Leviathan using the 1.05p1.1 build. So I'm not able to replicate his original problem unfortunately. [[User:Spike|Spike]] 19:18, 19 October 2012 (EDT)<br />
<br />
===<s> Materials deducted from wrong base </s>===<br />
<br />
My second base has -20 Aqua Plastics. Might be XComUtil's fault rather than TFTD Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
I don't use any mods/editor except TFDExtender, bus still have -98 Zrbite, -4 Lobster Man Corpses, -5 I-B Accs, -3 MagNavs and -358 Aqua Plastics on my second base! (and nothing extraordinary at other bases).<br />
:: Interesting. In the game where I found - 20 Aqua Plastics at my second base, I was manufacturing Plastic Aqua Armour at the first base. So it could be that a change to the manufacturing routine in TFTDextender is deducting manufacturing resources from the wrong base. It might also explain PavelB's Leviathan problem. [[User:Spike|Spike]] 09:32, 3 October 2012 (EDT)<br />
<br />
As an update on this, it does render the affected base if not unusable, hard to use, because the negative value is interpreted as a very large unsigned integer (60000+) and this has the effect of eliminating all Stores capacity at the base. The consequence is you can't buy anything at the base, nor transfer to it. [[User:Spike|Spike]] 22:41, 14 October 2012 (EDT)<br />
<br />
Steps to reproduce: <br />
# Start a new game under TFTDExtender<br />
# Create a second base. <br />
# Start construction of General Stores at second base (probably this is irrelevant)<br />
# Enable Aqua Plastics technology and Plastic Aqua Armour technology (eg XComUtil TEC:ALL) <br />
# Produce 4 Aqua Plastics at first base, without using autoproduce/autosell<br />
# Check Base Information - Stores at both bases. <br />
## = as expected, 4 at base 1 and zero at base 2<br />
# Then produce 1 Plastic Aqua Armour at first base, without using autoproduce/autosell<br />
# As soon as production starts, check Buy/Sell and Base Info - Stores at both bases<br />
## = At first base, 4 Aqua Plastics are still present and have not been deducted. <br />
## = At second base, -4 Aqua Plastics shown in Buy/Sell, equivalent unsigned two byte number shown in Stores<br />
<br />
Weirdly, this seems to happen even if Auto sell = 0 in the TFTDExtender.ini file. But it seems like a fairly ordinary off-by-one index type of error I guess? I confirmed it does not recur in the base game, the CE executable from Steam. It does not occur when running the game under XComUtil. Only when running under TFTD Extender. Since it does not seem sensitive to Auto sell = 0/1, I would guess it is due one of the bug fixes? Maybe some of the manufacturing exploit fixes? [[User:Spike|Spike]] 22:00, 16 October 2012 (EDT)<br />
<br />
: I think I may have localised this bug to the "Manufacture Rate Limit Fix". If I disable that particular bug fix, I get normal behaviour, i.e. manufacturing materials are deducted from the base where the manufacturing happens, not the next base. Also I'm going to go out on a limb and guess this is the same cause as Cannot Build Leviathan, above. [[User:Spike|Spike]] 22:14, 16 October 2012 (EDT)<br />
<br />
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''<br />
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)<br />
<br />
== Minor Bugs ==<br />
<br />
===<s> OBDATA / Dye Grenade mod not working? </s>===<br />
<br />
I can't seem to get this to work. Regardless of what I do, the Dye Grenade radius is the same as in the unpatched game. It starts on one square, slowly spreads out to about a 4 by 4 diamond, then contracts and fades out. Am I doing something wrong? Is it using the right OBDATA.DAT file? [[User:Spike|Spike]] 09:41, 7 September 2012 (EDT)<br />
: I'm not sure this feature is working for me at all. I tried changing the stats of a Dart Gun like this, also with no apparent effect. <br />
<br />
[OBDATA.DAT]<br />
Apply=01<br />
;Dye grenade will have similar initial effect as smoke grenade in EU.<br />
Dye Grenade Damage=60<br />
;Mega Dart Gun<br />
Dart Pistol Auto TUs=50<br />
Dart Pistol Auto accuracy=20<br />
Dart Pistol Snap accuracy=50<br />
Dart Pistol Aimed accuracy=100<br />
;Mega Dart Pistol ammo<br />
Dart Pod Damage=250<br />
Dart Pod Size=100<br />
;Turn HJC-AP into mega-phosphorous shell<br />
AP-Shell Damage Type=1<br />
AP-Shell Damage=250<br />
;Turn HJC-P into mega-phosphorous shell<br />
Phosphorous-Shell Damage=250<br />
;mega-pack<br />
Magna-Pack Damage=250<br />
;mini-pack<br />
;Magna-Pack Damage=20<br />
<br />
[[User:Spike|Spike]] 16:39, 8 September 2012 (EDT)<br />
I've checked that OBDATA modding works ok in UFOExtender. I can't get it to work in TFDExtender though. I have tried modding one-word items like Magna-pack. I have tried using the [[Talk:OBDATA.DAT (TFTD)|exact literal names from OBDATA.DAT (TFTD)]]. I have tried using the literal names from UFO. All no good. The record structure looks to be the same in TFTD as in UFO. I am a bit stumped. [[User:Spike|Spike]] 22:32, 8 September 2012 (EDT)<br />
<br />
:''OK. I'll look into it. My work has restarted so I am a little busy right now. Once I get readjusted to the work schedule, I'll be able to investigate more.''[[User:Morgan525|Tycho]] 04:23, 9 September 2012 (EDT) <br />
I completely understand. Thank you so much for this amazing contribution. [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
: update - ''I think I located the problem, the LoadFile command had been referencing the wrong LoadFile subroutine.''<br />
Excellent. I will be happy test as soon as you have time to upload an update. [[User:Spike|Spike]] 09:45, 20 September 2012 (EDT)<br />
: ''check this with the latest patch. [[User:Morgan525|Tycho]]''<br />
<br />
With 1.05p1.1, the Dye Grenade fix is working regardless of whether I do Apply=1 in the OBDATA.DAT section. I can't get anything else to work still. [[User:Spike|Spike]] 10:05, 2 October 2012 (EDT)<br />
<br />
Hang on, looks like it only works with a New Game? I got some things working but it's still not working 100% for me, but I will continue to investigate, I could be using the wrong names or settings etc. See updates to config file above. [[User:Spike|Spike]] 11:17, 2 October 2012 (EDT)<br />
:''It could be that I'll need to add multiple hooks into the executable to ensure that the mod is loaded at all times. - [[User:Morgan525|Tycho]] 22:35, 2 October 2012 (EDT)''<br />
<br />
OK it does seem to work on loaded saved games as well as in new games. The OBDATA.DAT changes are reflected in the in-game UFOPedia. But, the names of the objects to modify must be the exact literal strings that I posted in [[Talk:OBDATA.DAT_(TFTD)#Exact literal item name strings]]. The strings on the main page of the OBDATA.DAT article have been "corrected" and don't always exactly match what's in OBDATA.DAT. And I'm still not convinced all attributes are being copied over correctly into TACTICAL, even when they appear correctly in the in-game UFOPedia. I can change the damage of ammo types and see updates in the in game UFOPedia, but no change in damage or area of effect on the battlefield. [[User:Spike|Spike]] 10:34, 3 October 2012 (EDT)<br />
:''maybe the best test would be to zero damage on items and shoot an unarmed aquanaut?''<br />
<br />
I went back and checked UFO Extender. In UFO Extender I am able to make a full set of changes to a Pistol using basically the same config settings as above. In TFTD Extender, I am only able to affect what is reported in the in game UFOPedia, and the actual clip size. I even went so far as to double check the structure of OBDATA.DAT in both games, by inspection, but it does appear to be the same, at least for Damage which is the thing I'm unable to change in TFTD. Could this possibly be that LoadFile issue again? [[User:Spike|Spike]] 18:24, 3 October 2012 (EDT)<br />
<br />
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)<br />
<br />
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
=== Weightless Ammo Bug ===<br />
<br />
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)<br />
<br />
''From what I understand right now, I am pretty sure I can arrange it so that weapons are not automatically loaded and soldiers would be given an extra clip. Feedback?''<br />
: By an extra clip, you mean the clip/ammo that would have been loaded into the weapon is instead carried by the soldier? And for carried clips, the encumbrance effects are correct. For me anyway, in order of most benefit, the options would be<br />
:# Fix the root cause of the bug (ensure all relevant object locations and "contains/contained in" pointers are set during automatic clip loading) so that automatically loaded clips correctly affect encumbrance <br />
:# As a workaround, don't load ammo for multi-ammotype weapons (Heavy Cannon/Gas Cannon, Auto-Cannon/Hydrojet Cannon, Rocket Launcher / Torpedo Launcher). These are the weapons for which the bug has the greatest impact, since it imposes a 'cost' of switching away from the automatically-loaded ammo (usually AP or Small Rocket/Torp). With single-ammotype weapons, there's never any need to change the clips before combat. <br />
:# As a workaround, don't load ammo for any weapons. This avoids the 'switching cost' issue but does impose a fairly significant logistics overhead on each combat, to go through and manually load all clips. Plus the risk that you forget to load a weapon and only find out at a critical moment. :) This is for the "purist" who wants to make the game harder.<br />
:If it's tricky to fix the root cause, any of the other two options would be helpful. Suggested text:<br />
:* [Multi Ammo Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. Weapons using multiple ammo types (Heavy Cannon, Auto-Cannon, Rocket Launcher / Gas Cannon, Hydrojet Cannon, Torpedo Launcher) will not be pre-loaded before combat. You will need to load these weapons manually during the pre-combat Equip phase. This will significantly affect the heavy weapons ammunition load your squad can carry into combat without suffering encumbrance penalties, thus making the early game harder.<br />
:* [All Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. This option overrides the previous option. No weapons will be pre-loaded before combat. You will need to load all ammo manually during the pre-combat Equip phase. This will significantly affect the ammunition load your squad can carry into combat without suffering encumbrance penalties, making the early game harder.<br />
:[[User:Spike|Spike]] 05:10, 21 September 2012 (EDT)<br />
::''I found the source of the problem: None of the subroutines for inventory consider the clips in weapons so their entries in OBPOS.DAT are never updated. So when clips are autoloaded at the beginning of each battle, they have no owner. I've got the code to sync the ownership of clips with the weapon they are loaded into at the beginning of each battle and to update the clips when changed in inventory management.-''[[User:Morgan525|Tycho]] 19:00, 19 October 2012 (EDT)<br />
::: That is just awesome! :D [[User:Spike|Spike]] 22:36, 19 October 2012 (EDT)<br />
<br />
=== <s>Grenade Resistance in INI file </s> ===<br />
<br />
I think this is a holdover from UFOExtender, because 'Grenade' is not a TFTD object, and in TFTD I think all forms of grenades already have high damage resistance, and so are already "stackable". [[User:Spike|Spike]] 09:14, 7 September 2012 (EDT)<br />
:''Your correct. I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]<br />
<br />
=== MIA Bugs ===<br />
<br />
==== <s>Stunned MC'd Aquanauts MIA on Abort </s> ====<br />
<br />
This is a subset of MC'd Aquanauts go MIA [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]. In this case Aquanauts are MC'd by the aliens, then stunned (by friendlies), then the mission is Aborted with the stunned X-Com Aquanauts aboard the transport. The Aquanauts then disappear from the roster forever. I'm not sure if it's due to Abort rather than Victory, or due to them being stunned first. <br />
:''This is one of those exceptional cases where my End of Battle (Abort?) routine doesn't cover. If the aquanaut is MCed or unconscious the EOB routine will correct these states and end the battle but it doesn't check for both on the same unit, so an aquanaut who was MCed and then made unconscious, may fall through the hole that was originally in the game. [[User:Morgan525|Tycho]]'' <br />
<br />
::''I now have the code in place to uncontrol any creature that has been rendered unconscious. - -''[[User:Morgan525|Tycho]] 02:47, 11 October 2012 (EDT)<br />
<br />
This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
==== Stunned Carried Aquanauts MIA on Abort ====<br />
<br />
While you are looking the EOB script, I noticed one more anomaly. I'm not sure if this is an original bug or an Extender bug. If you are carrying a stunned Aquanaut in the transport at the time of Abort, the stunned Aquanaut is lost (MIA). You have to drop the stunned Aquanaut on the floor. Probably this is because the position of the Aquanaut has not been updated and is still pointing to where they were stunned, not to the location of the carrying Aquanaut. [[User:Spike|Spike]] 04:49, 27 September 2012 (EDT)<br />
<br />
:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. At least it is manageable: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)<br />
<br />
==== Supernumary MIA on Abort ====<br />
<br />
I Abort a mission with 8 Aquanauts and get the confirmation message "8 Aquanauts inside craft, 2 outside". No one has been stunned or MCd. I did have two aquanauts, only, outside, but they have moved back inside the transport. Very odd. Saved Equipment was enabled. [[User:Spike|Spike]] 11:06, 5 October 2012 (EDT)<br />
<br />
:''How many Aquanauts did you have in total: 10?- -''[[User:Morgan525|Tycho]] 02:54, 11 October 2012 (EDT)<br />
:: I started the mission with only 8 Aquanauts and they all survived. Only two had even been outside the transport (quite an unusual situation). However I can't reproduce this bug, so please ignore it unless/until I can reproduce it. :) [[User:Spike|Spike]] 06:48, 17 October 2012 (EDT)<br />
<br />
==== Crewed Flying Sub Lost on Abort ====<br />
<br />
Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)<br />
<br />
:Presumably the 3 aquanauts in the craft were not stunned or mind controlled on the Abort turn? [[User:Spike|Spike]] 16:37, 21 October 2012 (EDT)<br />
:Right, they are not stunned (or dead) and they are under your control. And they are definitely in the sub. OK this is similar to a minor bug I have seen before - see [[#Supernumary MIA on Abort|preceding item]]. On your pre-abort confirmation screen it says "3 units in craft, 9 units outside". I've had a similar issue before. It's double counting your aquanauts as being both inside and outside the craft on the confirm screen, since you only have 9 units (8 and 1 tank) in total. On actual abort you incorrectly get 9 MIAs (including the tank presumably) and I guess that's why you lose the sub. Interestingly, the 3 affected aquanauts look like they never moved from their original positions, is that true? I believe when I've had similar problems before, it related to aquanauts who had never left the sub / never left their initial positions. We will have to see if Tycho can get to the bottom of this one. [[User:Spike|Spike]] 16:51, 21 October 2012 (EDT)<br />
::Yes, that's true - those 3 haven't moved from their original positions. --[[User:Player701|Player701]] 17:19, 21 October 2012 (EDT)<br />
<br />
=== <s>Extra Artefacts Reported</s> ===<br />
<br />
I quite often recover 1 or 2 alien artefacts according to the Results screen, even though I am Aborting the mission and have definitely not brought anything back to the transport. I don't think I'm actually bringing back any artefacts - I think the Results screen is reporting incorrectly for some reason. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''I've seen this too. You are correct that no artifacts are actually found and it's a minor problem with the EOB calculations. Since it only gives players a minor boost (a few points at most) to their score, it's low on my to-do list at the moment.''<br />
:: Hmm I just came back from a mission (first mission of a new game) and I had two alien sonic clips available as new Research topics (Pistol and Blasta), even though I aborted the mission with no loot. I did use XComHack to edit other equipment on the Triton so it may be related to that. I'll let you know if it recurs. [[User:Spike|Spike]] 08:47, 2 October 2012 (EDT)<br />
:::''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)<br />
:::''This will be fixed in the next release.-''[[User:Morgan525|Tycho]] 03:00, 13 October 2012 (EDT)<br />
<br />
:::: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
===<s>Manufacturing Projects Minimum Production</s> ===<br />
<br />
In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''<br />
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)<br />
<br />
Tested - If I reduce the production quantity of a current production run to less than what as already been produced, the display completion time changes (incorrectly) to 'Indefinite', but production ends after completion of the next unit. So if I start by producing 10 units, wait until I have produced 2, then reduce the quantity to 2 (or probably 1), production stops after 3 units. Thies basically replicates the pre-existing behaviour when using the down arrow on the Quantity, so there has been no loss of functionality with your Mod. Also, Autosell and Autoproduce work normally when applied as changes to an existing production run. The only thing is I can't distinguish them on the Manufacturing display - both say 'unlimited' quantity and 'indefinite' period - is that intended? I suppose it makes sense, but it would be good to be able to tell which kind of production it is, *** Autoproduce or $$$ Autosell. [[User:Spike|Spike]] 08:57, 2 October 2012 (EDT)<br />
<br />
:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''<br />
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)<br />
:::''OK. Changed the output to display "$unlimited$".[[User:Morgan525|Tycho]]<br />
<br />
=== Weight Display in Inventory not Localised ===<br />
<br />
At least when I run the game in German, it comes up as "Weight" and not something like "Gewicht". Reactions comes up ok as "Zeitwerte". [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
<br />
:''There is no entry in the text DAT files for "weight". Seb had to add the text string for it into his subroutine. Thanks for pointing it out.'' [[User:Morgan525|Tycho]]<br />
<br />
===<s> Executable directive </s>===<br />
<br />
It looks to me that the Executable directive is being ignored and the loader always loads Terror from the Deep.exe. Is that correct? [[User:Spike|Spike]] 15:35, 24 September 2012 (EDT)<br />
<br />
:''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should.-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)<br />
<br />
=== Items on transport floor lost ===<br />
<br />
I went in to a mission with ten Sonic Cannons and came back with 3, despite retrieving them from the battlefield and dumping them on the transport floor. I only had 3 aquanauts on the transport armed with Sonic Cannon at the time of abort. The rest were stunned or unarmed. I also dumped half a dozen corpses and some alien items on the transport floor and I don't think those made it back to my base either. The transport was operating from base 2 rather than base 1, in case that's a factor. This may be an original bug of course. I just read through the multiplayer TFTD LP on StrategyCore, and they reported missing equipment on a lot of missions. I can go back and check if the missing equipment was on abort missions rather than victory missions. Sorry not to provide more specifics at this time but it was a hard mission and not exactly a controlled experiment. ;) [[User:Spike|Spike]] 21:35, 23 October 2012 (EDT)<br />
<br />
== Displacer/Sonic damage fix ==<br />
<br />
If I understand this fix correctly, the Displacer/Sonic weapon damage has been increased to 150 from the previous in-code value of 110, and vs the previous UFOPedia entry of 130? SWS Sonic weapon damage has been increased to 150 because this matches the craft-mounted Sonic Oscillator?<br />
<br />
I don't think this is the right idea. Increasing damage to 150 gives Displacer/Sonic a higher damage level than Displacer/PWT. That removes some of the distinctiveness of Displacer/PWT, and more importantly it is inconsistent with the general principle in the game that PWT weapons (of a given class) do more damage than Sonic (which in turn do more than Gauss). That is true for infantry weapons, SWS weapons (unless you create this exception), and Craft weapons. <br />
<br />
Also, there is no reason why SWS weapon damage should be equated to Craft weapon damage. I'm pretty sure that Battlescape damage values and Craft combat (Geoscape Interception) damage values are completely different, they are not meant to be compared to each other in any way. There is only one SWS weapon that has the same damage as its equivalent Craft weapon, and that is the Coelacanth/Gauss = Gauss Cannon. I think this is a coincidence, as the other equivalent weapons are all different between the SWS version and the Craft version (this applies to Gas Cannon, PWT, Sonic, and also Aqua Jet vs torpedos). <br />
<br />
Clearly there ''is'' an inconsistency between the code and the UFOPedia, and that should be fixed. It's hard to say if the "right" value is 110 or 130. Is the code wrong or is the UFOPedia wrong? It could be either way. But I would correct this inconsistency either to 110 or to 130, not increase it to 150. <br />
<br />
[[User:Spike|Spike]] 08:02, 7 September 2012 (EDT)<br />
<br />
: Or make it an option: Displacer Sonic Fix={0|110|130|150} [[User:Spike|Spike]] 09:50, 9 September 2012 (EDT)<br />
'' I changed the damage to be 125, similar to the ratio for the hovertank turrent to plasma cannon.-''[[User:Morgan525|Tycho]] 03:52, 13 October 2012 (EDT)<br />
<br />
== Things that TFTDextender does not fix ==<br />
<br />
Just more or less as a note to the reader, TFTDextender does not fix some of the following things that are sometimes thought of as needing fixing (and this is probably deliberate?):<br />
<br />
* Does not fix the apparent swap of the ground map for the VERY SMALL Survey Ship (1 occupant) with the SMALL Escort (half-dozen or more occupants). So you get the VERY SMALL sub occupying about 25 squares of usable area on the Battlescape, and the supposedly larger SMALL sub occupying one square of usable area on the Battlescape, begging the question of how all those aliens got inside there in the first place. XcomUtil will fix this, as will the original patches that XcomUtil incorporates.<br />
* Does not fix the incorrect pictures for the large USO in the interception window. <br />
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]<br />
* Does not fix the Dart Gun to make it any less utterly useless. Though you can do this yourself via the OBDATA.DAT section of TFTDextender. (Suggestion: don't fix it. The useless Dart Gun is all part of the "oh no we're all gonna die" experience of the beginning of TFTD.)<br />
* Does not improve the armour and effectiveness of the basic Aqua-Jet and Gas Cannon Coelecanths (it does upgrade the Coelecanth/Gauss). (Again, suggestion: this is a good thing - XCOM should start the game hopelessly outclassed, and scramble to catch up).<br />
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.<br />
* Does not allow you to have 360 degree vision out of your sub before exiting it. (What kind of coward would want that?). XComUtil does this.<br />
<br />
== Save Equipment not working? ==<br />
<br />
With "Save Equipment" option enabled, the soldiers' loadout at first was always like this: grenade in leg slot, clip in backpack - and it didn't change on the next mission, despite the fact that I re-equipped the soldiers correctly (grenades and clips on the belt). When I manufactured Gauss Rifles and issued them to my soldiers, it got even worse - none of the soldiers got clips, and two of the rifles were unloaded. Next I upgraded to Sonic-Blasta Rifles and now nothing, except some grenades (still in leg slots), is issued to the soldiers at all. "Save Equipment" was known to work in UFOExtender, did something get broken? --[[User:Player701|Player701]] 09:18, 21 October 2012 (EDT)<br />
<br />
:''Yes. Something is broken but not by the Extender. Many subroutines, their order of execution, or variable were modified in the TFTD game code. Problems like these are deducing what changed in the game code and what changes are needed to get the UFOextender code to work. See the discussion on problems with the OBDATA mod about the final source of the problem and its solution.-[[User:Morgan525|Tycho]] 20:03, 21 October 2012 (EDT)''<br />
<br />
= Feature Requests and Suggestions =<br />
<br />
== Useful alien species research ==<br />
<br />
Tycho, I really like this idea you proposed in the StrategyCore forum:<br />
<br />
:I'm thinking about giving a hp bonus to all aliens until Xcom performs an autopsy on the species to learn the location of their vital organs (like in the movie "Battle of LA"). This would give more importance to performing autopsies rather than just as a stepping stone to new tech.<br />
<br />
Definite +1. It would be equally valid to add to UFO Extender. I suppose it could also be implemented using Vulnerabilities (no Vulnerabilities are in effect until the Autopsy is completed), or Resistances (across-the-board increased Resistances until Autopsy is completed). If that's easier. <br />
<br />
:''The bonus to hp was an initial thought. Later, I decided against it since it would make aliens more resistant to HE and stun, which don't rely on hitting the right locations. Increasing resistances would be the most appropriate but the damage routine code is very tight and adding anything new that won't break the existing variable stack pointers is tough.'' [[User:Morgan525|Tycho]]<br />
::''A new idea for this that I recently have been toying with, would be on the damage generation routine: Most direct fire damage is 0-200%, with anything over 100% considered a "critical hit". If autopsy hasn't been preformed, then the base damage would be 0-100% and a small chance (maybe 25%) of another 0-100% for that lucky shot. With autopsy done, the game reverts back to the usual 0-200% on any hit.''<br />
<br />
::: That works. And it makes doing Alien Autopsies a no-brainer, as it should be. It is pretty much inconceivable that XCom wouldn't prioritise the autopsy of any newly encountered alien. And any player playing the game for the first time would do autopsies too. This mod will help experienced players to stop playing as if they've "seen it all before". [[User:Spike|Spike]] 10:35, 15 September 2012 (EDT)<br />
<br />
Would it also be worth adding some kind of bonus for Live Alien research? Maybe the negation of some kind of Morale penalty and/or Psi penalty? Fear of the unknown, know your enemy, that kind of thing?<br />
<br />
:''I thought about that but the game doesn't record live aliens that have been researched. When you finish research on a live alien, it only follows the routine to unlock the appropriate UFOpaedia articles and then checks to see if the finished research can unlock other topics.'' [[User:Morgan525|Tycho]]<br />
<br />
I had a further thought on this while trying to guess what your new pre-requisites are for the various armours. For now it's really cool to be guessing but once people have figured it out, well, it will be more logical but still will have 'replay fatigue'. Would it be possible to randomise the pre-requisites for a lot of the key research topics, from out of a plausible list of items (or even randomise pre-requisite topics)? That would make every game fresh in terms of the research sequence, and make the research aspect of the game more challenging and less dry & predictable. As ever, just a suggestion. :) Cheers, [[User:Spike|Spike]] 16:01, 19 October 2012 (EDT)<br />
<br />
== All Units Can "Fly" In Water ==<br />
<br />
It's very illogical that most units are stuck on the seabed in underwater missions. Please provide the option to set all units (X-Com and alien) to have "flying" (i.e. swimming) ability when underwater. This is unlikely to cause an outbreak of 3D combat, since there is no cover except at seabed level, so anyone swimming excessively or incautiously is going to get shot. It might disadvantage the aliens if their tactical map waypoints are all set on the surface. But as some of them can "fly", there is hopefully a mechanism to deal with that in the code already. For me it will just solve the frustration of being unable to swim over small obstacles or swim up a level, and being stuck or tactically limited for no sensible reason. Mag-Ion Armour remains useful as an important step in Sub Research and (if using the Everything Works on Land mod) for land use. [[User:Spike|Spike]] 11:36, 9 September 2012 (EDT)<br />
: This requires setting [[UNITREF.DAT]] byte 0x78 bit 2 for the unit (e.g. for all units on both sides). Or the in-memory equivalent of UNITREF.DAT. [[User:Spike|Spike]] 10:19, 5 October 2012 (EDT)<br />
<br />
== Aliens Pick Up Weapons ==<br />
<br />
Related to Improved Alien AI. This makes the game tougher as stunned / panicked bipedal-type aliens are no longer permanently disarmed. This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. A fix for this would be a very helpful rebalancing of both games that eliminates one of the aliens' weak spots. The existing (but unused) routine looks pretty smart and not immediately exploitable to ambush aliens using weapons as traps. <br />
<br />
: I noticed the UFO Extender source code has a 'get' keyword under the OBDATA.DAT directive that populates this field 0x2D. Is that working? [[User:Spike|Spike]] 21:03, 16 October 2012 (EDT)<br />
<br />
== General Tank Modding ==<br />
<br />
I see you are interested in modding tanks (HWPs/SWPs) and that's partly what got you into updating UFO Extender. I made some suggestions for Tank Modding myself, including some of the mechanics required to make it work via a config file such as the UFO / TFD Extender config file. For example you could have cargo carrier / ambulance / casevac tanks, you could have demolition tanks, mine thrower tanks, and of course tanks with custom weapons including dual weapons. Could you have a look here: [[User:Spike#Tank_mods]] and see if any of that makes you feel like getting creative?<br />
<br />
Thanks,<br />
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)<br />
<br />
== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==<br />
<br />
Hook the right and left weapon menus on mind controlled aliens to add in actions for their built in melee attacks (if they have them) and built in Psi/MC attacks (if they have Psi/MC Skill). Ideally add these actions to the menu, and pop up a menu, even if the alien isn't holding any weapons.<br />
<br />
This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.<br />
<br />
== Fix Interception and Navigation Course Algorithms ==<br />
<br />
Or just find the algorithms and I volunteer to fix them!<br />
<br />
=== Use Great Circle Routes ===<br />
<br />
Travel toward the target on the shortest Great Circle, rather than always travelling along lines of latitude first (like they are some kind of main bus route!). <br />
<br />
=== Use Predictive Interception ===<br />
<br />
For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.<br />
<br />
=== Show Degree Headings ===<br />
<br />
The game only ever reports alien headings as North, South, East, West, but clearly alien craft move in other directions than just these four, and clearly XCOM detection equipment is capable of resolving these finer-grained headings, since the crafts' tracks are shown correctly in the Geoscope. <br />
As a first step towards predictive interceptions, it would be great to display the alien craft's heading in degrees, eg 135 degrees for South-East. Maybe rounded to the nearest 5 or 10 degrees.<br />
<br />
== Interception Craft vs Touched Down Alien Craft == <br />
<br />
If an alien craft is touched down and an XCOM interception craft (not touched down) is at the same X/Y position, if the alien craft begins to move, immediately open the Interception window at minimum range (8km/nm), presumably with the alien attempting to get away / break off. Currently the Interception window only happens if the XCom craft is faster, which is dumb, ''even if'' the alien craft could accelerate instantly to its maximum speed. <br />
<br />
For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach. <br />
<br />
== Fun, not Funky, Fire ==<br />
<br />
An alternative option for incendiaries/phosphorous damage processing: Do process the so called 'impact' damage of an incendiary on every shot, not just at the end of the turn. But only apply it to those in the area of affect of this specific shell burst, not to all units who are standing in smoke or fire anywhere on the map. This will please fans of incendiaries/phosphorous. It's probably a balancing, rather than unbalancing, change in the relative strengths of the ammo types. Makes incendiaries/phosphorous useful for more than just illumination or desperation. Gives some use to the research topics that advise use of incendiaries/phosphorous, and the damage modifiers aliens have been assigned.<br />
<br />
== Rearming Rates ==<br />
<br />
<br />
From [[Known_Bugs_(TFTD)#Geoscape_Bugs]]:<br />
<br />
=== Craft Gauss Cannon Rearming Rate ===<br />
<br />
This weapon rearms at 10/hr but probably should be 50/hr or at least 25/hr, otherwise it is far slower to rearm than any other cannon weapon in either game. In fact it's the second slowest weapon system to rearm, slower only than AJAX...<br />
<br />
=== AJAX Rearming Rate ===<br />
<br />
An AJAX system takes twice as long to fully reload as a D.U.P. system, as a result AJAX-armed Craft have much worse operational tempo and readiness than D.U.P. armed Craft. Like we needed yet another reason to always use D.U.Ps. This is probably a design error rather than a bug, but it would be good to fix it - anything to give a more balanced set of craft weapon choices. The rearming rate should be raised from 1/hr to 2/hr. The AJAX system will then have the same operational tempo as the D.U.P. system. <br />
<br />
Could also be applied to Stingray missiles in EU 1994, as the same analysis applies to Stingray vs Avalanche.</div>
Spike
https://www.ufopaedia.org/index.php?title=Talk:TFTDextender&diff=40268
Talk:TFTDextender
2012-10-24T01:35:53Z
<p>Spike: /* Items lost on transport floor */</p>
<hr />
<div>=Questions or Comments=<br />
'''A place to provide feedback or ask questions:'''<br />
<br />
The zip archive does not seem to include an .ini file. Where do I get the .ini file from? <br />
:: Oh hang on. It looks like the latest version of the zip file does not include the .ini file. When I go back to the previous version of the zip file, I can see the .ini file. [[User:Spike|Spike]] 17:45, 6 September 2012 (EDT)<br />
<br />
:::''The latest release is a patch, which means there are no new additions to the INI. I don't include it in patches usually so that those who already have the prior release don't have to reconfigure their current INI. It may not seem like a big deal now but earlier, I was releasing fixes almost on a weekly basis and so I still continue with that idea.''[[User:Morgan525|Tycho]]<br />
<br />
== Bug Reports ==<br />
<br />
=== Crash 0xFFE00B30 ===<br />
<br />
:"XCOM crashed at 0x7C82A5CD with error 0xC0000005 trying to access 0xFFE00B30."<br />
<br />
''Interesting. I had someone report a similar thing when they were starting their first instance of the battlescape on a new install of the game. I looked into it and the game generated some bad data. When he let the UFO take off and land again, the battle started with no problems..''<br />
<br />
:It's [[Known_Bugs_(TFTD)#Geoscape_Bugs|a bug I've reported before]] (before TFTD Extender even existed), so it's not specific to TFTDExtender / UFOExtender. What is happening is the Alien Sub is landing on land, and the Triton is also attempting to land on land. Probably the game crashes when it fails to generate the appropriate terrain type? So the GEOSCAPE map/terrain data must be corrupted. I've seen three examples of this. In a couple of cases the landing site is clearly inland, by hundreds of kilometres. In some cases it's right on the sea/land boundary and hard to tell. I have two save games that reproduce the bug now. From memory, the previous cases all happened around North Africa, like these present cases. [[User:Spike|Spike]] 08:31, 9 September 2012 (EDT)<br />
<br />
=== Cannot build Leviathan ===<br />
<br />
Hi Tycho. I've just researched Leviathan in my TFDExtender game but cannot manufacture it! I have enough resources (Plastics, IBA, ManNav), 3 workshops, more than 100 technicans and one empty sub pen. But when starting the Leviathan manufacture task I cannot assign any technicans to it. I press the "up" button, and there are no reaction to this. I can build Manta, but not Leviathan. Don't you know what is it? [[User:PavelB|PavelB]] 06:55, 2 October 2012 (EDT)<br />
<br />
: Double check that you have sufficient cash to start the project, iirc $600K or so. That matches this symptom. Also that you have enough workshop space available (Leviathan needs a lot of space). Failing that, cancel all existing manufacturing projects, then retry. Failing that you could try reducing Technicians below 100 but that's taking us into Bug territory. [[User:Spike|Spike]] 07:17, 2 October 2012 (EDT)<br />
<br />
:: Resources are 100% enough. I've launched "Terror from the Deep.exe", loaded this saved game and started manufacturing Lev without any problems. I've saved this variant with Lev being manufactured and then loaded it from "TFTDextender.exe". As a result the process was okey, but I could only decrease the number of technicans working on it, not increase (even after decreasing!). That is: with 64 technicans had been assigned, I've pressed the "down" button, and the number changed to 63. But then I was unable to revert it to 64 by pressing "up" button: it didn't work! [[User:PavelB|PavelB]] 07:57, 2 October 2012 (EDT)<br />
:''I'll check into it. Although, I can't understand how changes to the research tree would affect production. Unless it has something to do with the autoproduce feature?''<br />
:'''This problem may be fixed with the same patch that fixed the production materials being deducted from the wrong base. Can anyone confirm?'''- - [[User:Morgan525|Tycho]] 23:12, 17 October 2012 (EDT)<br />
:: If I try to replicate PavelB's situation, I am able to build a Leviathan with no problems using the latest build. However I am also able to build a Leviathan using the 1.05p1.1 build. So I'm not able to replicate his original problem unfortunately. [[User:Spike|Spike]] 19:18, 19 October 2012 (EDT)<br />
<br />
===<s> Materials deducted from wrong base </s>===<br />
<br />
My second base has -20 Aqua Plastics. Might be XComUtil's fault rather than TFTD Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
I don't use any mods/editor except TFDExtender, bus still have -98 Zrbite, -4 Lobster Man Corpses, -5 I-B Accs, -3 MagNavs and -358 Aqua Plastics on my second base! (and nothing extraordinary at other bases).<br />
:: Interesting. In the game where I found - 20 Aqua Plastics at my second base, I was manufacturing Plastic Aqua Armour at the first base. So it could be that a change to the manufacturing routine in TFTDextender is deducting manufacturing resources from the wrong base. It might also explain PavelB's Leviathan problem. [[User:Spike|Spike]] 09:32, 3 October 2012 (EDT)<br />
<br />
As an update on this, it does render the affected base if not unusable, hard to use, because the negative value is interpreted as a very large unsigned integer (60000+) and this has the effect of eliminating all Stores capacity at the base. The consequence is you can't buy anything at the base, nor transfer to it. [[User:Spike|Spike]] 22:41, 14 October 2012 (EDT)<br />
<br />
Steps to reproduce: <br />
# Start a new game under TFTDExtender<br />
# Create a second base. <br />
# Start construction of General Stores at second base (probably this is irrelevant)<br />
# Enable Aqua Plastics technology and Plastic Aqua Armour technology (eg XComUtil TEC:ALL) <br />
# Produce 4 Aqua Plastics at first base, without using autoproduce/autosell<br />
# Check Base Information - Stores at both bases. <br />
## = as expected, 4 at base 1 and zero at base 2<br />
# Then produce 1 Plastic Aqua Armour at first base, without using autoproduce/autosell<br />
# As soon as production starts, check Buy/Sell and Base Info - Stores at both bases<br />
## = At first base, 4 Aqua Plastics are still present and have not been deducted. <br />
## = At second base, -4 Aqua Plastics shown in Buy/Sell, equivalent unsigned two byte number shown in Stores<br />
<br />
Weirdly, this seems to happen even if Auto sell = 0 in the TFTDExtender.ini file. But it seems like a fairly ordinary off-by-one index type of error I guess? I confirmed it does not recur in the base game, the CE executable from Steam. It does not occur when running the game under XComUtil. Only when running under TFTD Extender. Since it does not seem sensitive to Auto sell = 0/1, I would guess it is due one of the bug fixes? Maybe some of the manufacturing exploit fixes? [[User:Spike|Spike]] 22:00, 16 October 2012 (EDT)<br />
<br />
: I think I may have localised this bug to the "Manufacture Rate Limit Fix". If I disable that particular bug fix, I get normal behaviour, i.e. manufacturing materials are deducted from the base where the manufacturing happens, not the next base. Also I'm going to go out on a limb and guess this is the same cause as Cannot Build Leviathan, above. [[User:Spike|Spike]] 22:14, 16 October 2012 (EDT)<br />
<br />
:'''I reproduced the issue thanks to the instructions that Spike provided and I found the problem. A few minor tweaks and now things are working as they should. - [[User:Morgan525|Tycho]] 08:33, 17 October 2012 (EDT)'''<br />
:: I can confirm this is fixed and all is working correctly - great job, thanks Tycho. [[User:Spike|Spike]] 15:22, 19 October 2012 (EDT)<br />
<br />
== Minor Bugs ==<br />
<br />
===<s> OBDATA / Dye Grenade mod not working? </s>===<br />
<br />
I can't seem to get this to work. Regardless of what I do, the Dye Grenade radius is the same as in the unpatched game. It starts on one square, slowly spreads out to about a 4 by 4 diamond, then contracts and fades out. Am I doing something wrong? Is it using the right OBDATA.DAT file? [[User:Spike|Spike]] 09:41, 7 September 2012 (EDT)<br />
: I'm not sure this feature is working for me at all. I tried changing the stats of a Dart Gun like this, also with no apparent effect. <br />
<br />
[OBDATA.DAT]<br />
Apply=01<br />
;Dye grenade will have similar initial effect as smoke grenade in EU.<br />
Dye Grenade Damage=60<br />
;Mega Dart Gun<br />
Dart Pistol Auto TUs=50<br />
Dart Pistol Auto accuracy=20<br />
Dart Pistol Snap accuracy=50<br />
Dart Pistol Aimed accuracy=100<br />
;Mega Dart Pistol ammo<br />
Dart Pod Damage=250<br />
Dart Pod Size=100<br />
;Turn HJC-AP into mega-phosphorous shell<br />
AP-Shell Damage Type=1<br />
AP-Shell Damage=250<br />
;Turn HJC-P into mega-phosphorous shell<br />
Phosphorous-Shell Damage=250<br />
;mega-pack<br />
Magna-Pack Damage=250<br />
;mini-pack<br />
;Magna-Pack Damage=20<br />
<br />
[[User:Spike|Spike]] 16:39, 8 September 2012 (EDT)<br />
I've checked that OBDATA modding works ok in UFOExtender. I can't get it to work in TFDExtender though. I have tried modding one-word items like Magna-pack. I have tried using the [[Talk:OBDATA.DAT (TFTD)|exact literal names from OBDATA.DAT (TFTD)]]. I have tried using the literal names from UFO. All no good. The record structure looks to be the same in TFTD as in UFO. I am a bit stumped. [[User:Spike|Spike]] 22:32, 8 September 2012 (EDT)<br />
<br />
:''OK. I'll look into it. My work has restarted so I am a little busy right now. Once I get readjusted to the work schedule, I'll be able to investigate more.''[[User:Morgan525|Tycho]] 04:23, 9 September 2012 (EDT) <br />
I completely understand. Thank you so much for this amazing contribution. [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
: update - ''I think I located the problem, the LoadFile command had been referencing the wrong LoadFile subroutine.''<br />
Excellent. I will be happy test as soon as you have time to upload an update. [[User:Spike|Spike]] 09:45, 20 September 2012 (EDT)<br />
: ''check this with the latest patch. [[User:Morgan525|Tycho]]''<br />
<br />
With 1.05p1.1, the Dye Grenade fix is working regardless of whether I do Apply=1 in the OBDATA.DAT section. I can't get anything else to work still. [[User:Spike|Spike]] 10:05, 2 October 2012 (EDT)<br />
<br />
Hang on, looks like it only works with a New Game? I got some things working but it's still not working 100% for me, but I will continue to investigate, I could be using the wrong names or settings etc. See updates to config file above. [[User:Spike|Spike]] 11:17, 2 October 2012 (EDT)<br />
:''It could be that I'll need to add multiple hooks into the executable to ensure that the mod is loaded at all times. - [[User:Morgan525|Tycho]] 22:35, 2 October 2012 (EDT)''<br />
<br />
OK it does seem to work on loaded saved games as well as in new games. The OBDATA.DAT changes are reflected in the in-game UFOPedia. But, the names of the objects to modify must be the exact literal strings that I posted in [[Talk:OBDATA.DAT_(TFTD)#Exact literal item name strings]]. The strings on the main page of the OBDATA.DAT article have been "corrected" and don't always exactly match what's in OBDATA.DAT. And I'm still not convinced all attributes are being copied over correctly into TACTICAL, even when they appear correctly in the in-game UFOPedia. I can change the damage of ammo types and see updates in the in game UFOPedia, but no change in damage or area of effect on the battlefield. [[User:Spike|Spike]] 10:34, 3 October 2012 (EDT)<br />
:''maybe the best test would be to zero damage on items and shoot an unarmed aquanaut?''<br />
<br />
I went back and checked UFO Extender. In UFO Extender I am able to make a full set of changes to a Pistol using basically the same config settings as above. In TFTD Extender, I am only able to affect what is reported in the in game UFOPedia, and the actual clip size. I even went so far as to double check the structure of OBDATA.DAT in both games, by inspection, but it does appear to be the same, at least for Damage which is the thing I'm unable to change in TFTD. Could this possibly be that LoadFile issue again? [[User:Spike|Spike]] 18:24, 3 October 2012 (EDT)<br />
<br />
:''OK. I was right. Enemy Unknown only loads the OBDATA once when the game loads. TFTD loads it twice - once whenever it generates a battle. I needed a second hook for the mod in this case. I tested it and it now works as it should. -''[[User:Morgan525|Tycho]] 20:24, 5 October 2012 (EDT)<br />
<br />
:: Confirmed fixed. Thanks again. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
=== Weightless Ammo Bug ===<br />
<br />
Do you think you could fix this bug? [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Seb76 had a look at it, and diagnosed the cause, but he did not get around to fixing it. It's only mildly annoying and, some probably consider it to be useful as a very minor exploit. For me, it just really bugs me! (No pun intended). [[User:Spike|Spike]] 22:55, 6 September 2012 (EDT)<br />
<br />
''From what I understand right now, I am pretty sure I can arrange it so that weapons are not automatically loaded and soldiers would be given an extra clip. Feedback?''<br />
: By an extra clip, you mean the clip/ammo that would have been loaded into the weapon is instead carried by the soldier? And for carried clips, the encumbrance effects are correct. For me anyway, in order of most benefit, the options would be<br />
:# Fix the root cause of the bug (ensure all relevant object locations and "contains/contained in" pointers are set during automatic clip loading) so that automatically loaded clips correctly affect encumbrance <br />
:# As a workaround, don't load ammo for multi-ammotype weapons (Heavy Cannon/Gas Cannon, Auto-Cannon/Hydrojet Cannon, Rocket Launcher / Torpedo Launcher). These are the weapons for which the bug has the greatest impact, since it imposes a 'cost' of switching away from the automatically-loaded ammo (usually AP or Small Rocket/Torp). With single-ammotype weapons, there's never any need to change the clips before combat. <br />
:# As a workaround, don't load ammo for any weapons. This avoids the 'switching cost' issue but does impose a fairly significant logistics overhead on each combat, to go through and manually load all clips. Plus the risk that you forget to load a weapon and only find out at a critical moment. :) This is for the "purist" who wants to make the game harder.<br />
:If it's tricky to fix the root cause, any of the other two options would be helpful. Suggested text:<br />
:* [Multi Ammo Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. Weapons using multiple ammo types (Heavy Cannon, Auto-Cannon, Rocket Launcher / Gas Cannon, Hydrojet Cannon, Torpedo Launcher) will not be pre-loaded before combat. You will need to load these weapons manually during the pre-combat Equip phase. This will significantly affect the heavy weapons ammunition load your squad can carry into combat without suffering encumbrance penalties, thus making the early game harder.<br />
:* [All Weapons Start Unloaded] - Workaround for the Weightless Ammo Bug. This option overrides the previous option. No weapons will be pre-loaded before combat. You will need to load all ammo manually during the pre-combat Equip phase. This will significantly affect the ammunition load your squad can carry into combat without suffering encumbrance penalties, making the early game harder.<br />
:[[User:Spike|Spike]] 05:10, 21 September 2012 (EDT)<br />
::''I found the source of the problem: None of the subroutines for inventory consider the clips in weapons so their entries in OBPOS.DAT are never updated. So when clips are autoloaded at the beginning of each battle, they have no owner. I've got the code to sync the ownership of clips with the weapon they are loaded into at the beginning of each battle and to update the clips when changed in inventory management.-''[[User:Morgan525|Tycho]] 19:00, 19 October 2012 (EDT)<br />
::: That is just awesome! :D [[User:Spike|Spike]] 22:36, 19 October 2012 (EDT)<br />
<br />
=== <s>Grenade Resistance in INI file </s> ===<br />
<br />
I think this is a holdover from UFOExtender, because 'Grenade' is not a TFTD object, and in TFTD I think all forms of grenades already have high damage resistance, and so are already "stackable". [[User:Spike|Spike]] 09:14, 7 September 2012 (EDT)<br />
:''Your correct. I removed the reference in the INI since it's unnecessary.-''[[User:Morgan525|Tycho]]<br />
<br />
=== MIA Bugs ===<br />
<br />
==== <s>Stunned MC'd Aquanauts MIA on Abort </s> ====<br />
<br />
This is a subset of MC'd Aquanauts go MIA [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]. In this case Aquanauts are MC'd by the aliens, then stunned (by friendlies), then the mission is Aborted with the stunned X-Com Aquanauts aboard the transport. The Aquanauts then disappear from the roster forever. I'm not sure if it's due to Abort rather than Victory, or due to them being stunned first. <br />
:''This is one of those exceptional cases where my End of Battle (Abort?) routine doesn't cover. If the aquanaut is MCed or unconscious the EOB routine will correct these states and end the battle but it doesn't check for both on the same unit, so an aquanaut who was MCed and then made unconscious, may fall through the hole that was originally in the game. [[User:Morgan525|Tycho]]'' <br />
<br />
::''I now have the code in place to uncontrol any creature that has been rendered unconscious. - -''[[User:Morgan525|Tycho]] 02:47, 11 October 2012 (EDT)<br />
<br />
This would also apply to UFO Extender. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
<br />
==== Stunned Carried Aquanauts MIA on Abort ====<br />
<br />
While you are looking the EOB script, I noticed one more anomaly. I'm not sure if this is an original bug or an Extender bug. If you are carrying a stunned Aquanaut in the transport at the time of Abort, the stunned Aquanaut is lost (MIA). You have to drop the stunned Aquanaut on the floor. Probably this is because the position of the Aquanaut has not been updated and is still pointing to where they were stunned, not to the location of the carrying Aquanaut. [[User:Spike|Spike]] 04:49, 27 September 2012 (EDT)<br />
<br />
:''This would be an original bug that was hidden beneath the general bug of stunned units MIA on abort. At least it is manageable: Just be sure to drop all creatures carried before calling for an abort.- -''[[User:Morgan525|Tycho]] 02:51, 11 October 2012 (EDT)<br />
<br />
==== Supernumary MIA on Abort ====<br />
<br />
I Abort a mission with 8 Aquanauts and get the confirmation message "8 Aquanauts inside craft, 2 outside". No one has been stunned or MCd. I did have two aquanauts, only, outside, but they have moved back inside the transport. Very odd. Saved Equipment was enabled. [[User:Spike|Spike]] 11:06, 5 October 2012 (EDT)<br />
<br />
:''How many Aquanauts did you have in total: 10?- -''[[User:Morgan525|Tycho]] 02:54, 11 October 2012 (EDT)<br />
:: I started the mission with only 8 Aquanauts and they all survived. Only two had even been outside the transport (quite an unusual situation). However I can't reproduce this bug, so please ignore it unless/until I can reproduce it. :) [[User:Spike|Spike]] 06:48, 17 October 2012 (EDT)<br />
<br />
==== Crewed Flying Sub Lost on Abort ====<br />
<br />
Aborting [https://dl.dropbox.com/u/23157535/FlyingSubLost.zip this mission] will lead to loss of the craft, despite 3 soldiers still being in the Triton. --[[User:Player701|Player701]] 10:39, 21 October 2012 (EDT)<br />
<br />
:Presumably the 3 aquanauts in the craft were not stunned or mind controlled on the Abort turn? [[User:Spike|Spike]] 16:37, 21 October 2012 (EDT)<br />
:Right, they are not stunned (or dead) and they are under your control. And they are definitely in the sub. OK this is similar to a minor bug I have seen before - see [[#Supernumary MIA on Abort|preceding item]]. On your pre-abort confirmation screen it says "3 units in craft, 9 units outside". I've had a similar issue before. It's double counting your aquanauts as being both inside and outside the craft on the confirm screen, since you only have 9 units (8 and 1 tank) in total. On actual abort you incorrectly get 9 MIAs (including the tank presumably) and I guess that's why you lose the sub. Interestingly, the 3 affected aquanauts look like they never moved from their original positions, is that true? I believe when I've had similar problems before, it related to aquanauts who had never left the sub / never left their initial positions. We will have to see if Tycho can get to the bottom of this one. [[User:Spike|Spike]] 16:51, 21 October 2012 (EDT)<br />
::Yes, that's true - those 3 haven't moved from their original positions. --[[User:Player701|Player701]] 17:19, 21 October 2012 (EDT)<br />
<br />
=== <s>Extra Artefacts Reported</s> ===<br />
<br />
I quite often recover 1 or 2 alien artefacts according to the Results screen, even though I am Aborting the mission and have definitely not brought anything back to the transport. I don't think I'm actually bringing back any artefacts - I think the Results screen is reporting incorrectly for some reason. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''I've seen this too. You are correct that no artifacts are actually found and it's a minor problem with the EOB calculations. Since it only gives players a minor boost (a few points at most) to their score, it's low on my to-do list at the moment.''<br />
:: Hmm I just came back from a mission (first mission of a new game) and I had two alien sonic clips available as new Research topics (Pistol and Blasta), even though I aborted the mission with no loot. I did use XComHack to edit other equipment on the Triton so it may be related to that. I'll let you know if it recurs. [[User:Spike|Spike]] 08:47, 2 October 2012 (EDT)<br />
:::''After some tests, I know the exact nature of the problem: clips loaded into weapons for any killed aliens (including those killed before mission starts as a result of a downed USO) are being allocated to the player when they abort a mission. This is not a bug from Extender this is in the original CE.-''[[User:Morgan525|Tycho]] 20:27, 5 October 2012 (EDT)<br />
:::''This will be fixed in the next release.-''[[User:Morgan525|Tycho]] 03:00, 13 October 2012 (EDT)<br />
<br />
:::: Confirmed fixed. Killed aliens' clips are not allocated to XCOM on Abort. [[User:Spike|Spike]] 15:36, 19 October 2012 (EDT)<br />
<br />
===<s>Manufacturing Projects Minimum Production</s> ===<br />
<br />
In the unmodified game, if you have a manufacturing project underway, you can't reduce the quantity below the level that have been built or are in production now (the number that have been built, plus 1). With the autosell and autobuild features turned on, you need to be able to cursor down below zero, so the quantity cursor no longer stops when you reduce to this minimum. This may have some unintended effects, like changing a manufacturing project to produce less units than it has already reduced. On the other hand there may be no impact at all other than losing the built-in stop on the quantity cursor that reminds you how many units of that type you have already built or started to build. [[User:Spike|Spike]] 22:06, 21 September 2012 (EDT)<br />
:''It would be interesting to experiment to see what the effects of doing this are, if any: What happens if you reduce the number desired for an item below what has already been produced? What happens if you create an order for a set number of items and later change it to auto-produce? [[User:Morgan525|Tycho]]''<br />
:: OK I will take a look at this and report back. Unless some bugs/glitches are being introduced, the only loss of existing functionality is that you can currently use the down arrow keys in the unmodified version to in effect say "stop production after completion of the next unit", which avoids the wasted cost and effort of hitting the Stop Production button. [[User:Spike|Spike]] 04:45, 25 September 2012 (EDT)<br />
<br />
Tested - If I reduce the production quantity of a current production run to less than what as already been produced, the display completion time changes (incorrectly) to 'Indefinite', but production ends after completion of the next unit. So if I start by producing 10 units, wait until I have produced 2, then reduce the quantity to 2 (or probably 1), production stops after 3 units. Thies basically replicates the pre-existing behaviour when using the down arrow on the Quantity, so there has been no loss of functionality with your Mod. Also, Autosell and Autoproduce work normally when applied as changes to an existing production run. The only thing is I can't distinguish them on the Manufacturing display - both say 'unlimited' quantity and 'indefinite' period - is that intended? I suppose it makes sense, but it would be good to be able to tell which kind of production it is, *** Autoproduce or $$$ Autosell. [[User:Spike|Spike]] 08:57, 2 October 2012 (EDT)<br />
<br />
:''Autosell should report 'unlimited $' like the pic on the information page. I could change this to '$unlimited$' - [[User:Morgan525|Tycho]]''<br />
:: I think that extra '$' would be helpful. Also, maybe when production is reduced to equal-to or below the already-completed quantity, could you change the quantity display to 'halting' instead of 'indefinite'? [[User:Spike|Spike]] 09:46, 5 October 2012 (EDT)<br />
:::''OK. Changed the output to display "$unlimited$".[[User:Morgan525|Tycho]]<br />
<br />
=== Weight Display in Inventory not Localised ===<br />
<br />
At least when I run the game in German, it comes up as "Weight" and not something like "Gewicht". Reactions comes up ok as "Zeitwerte". [[User:Spike|Spike]] 09:47, 9 September 2012 (EDT)<br />
<br />
:''There is no entry in the text DAT files for "weight". Seb had to add the text string for it into his subroutine. Thanks for pointing it out.'' [[User:Morgan525|Tycho]]<br />
<br />
===<s> Executable directive </s>===<br />
<br />
It looks to me that the Executable directive is being ignored and the loader always loads Terror from the Deep.exe. Is that correct? [[User:Spike|Spike]] 15:35, 24 September 2012 (EDT)<br />
<br />
:''I found the problem: In the program file for the loader, the INI file name that is was expecting was TFTDloader.INI. A simple name change, recompile, and it works as it should.-''[[User:Morgan525|Tycho]] 10:24, 4 October 2012 (EDT)<br />
<br />
=== Items on transport floor lost ===<br />
<br />
I went in to a mission with ten Sonic Cannons and came back with 3, despite retrieving them from the battlefield and dumping them on the transport floor. I only had 3 aquanauts on the transport armed with Sonic Cannon at the time of abort. The rest were stunned or unarmed. I also dumped half a dozen corpses and some alien items on the transport floor and I don't think those made it back to my base either. The transport was operating from base 2 rather than base 1, in case that's a factor. Sorry not to provide more specifics at this time but it was a hard mission and not exactly a controlled experiment. ;) [[User:Spike|Spike]] 21:35, 23 October 2012 (EDT)<br />
<br />
== Displacer/Sonic damage fix ==<br />
<br />
If I understand this fix correctly, the Displacer/Sonic weapon damage has been increased to 150 from the previous in-code value of 110, and vs the previous UFOPedia entry of 130? SWS Sonic weapon damage has been increased to 150 because this matches the craft-mounted Sonic Oscillator?<br />
<br />
I don't think this is the right idea. Increasing damage to 150 gives Displacer/Sonic a higher damage level than Displacer/PWT. That removes some of the distinctiveness of Displacer/PWT, and more importantly it is inconsistent with the general principle in the game that PWT weapons (of a given class) do more damage than Sonic (which in turn do more than Gauss). That is true for infantry weapons, SWS weapons (unless you create this exception), and Craft weapons. <br />
<br />
Also, there is no reason why SWS weapon damage should be equated to Craft weapon damage. I'm pretty sure that Battlescape damage values and Craft combat (Geoscape Interception) damage values are completely different, they are not meant to be compared to each other in any way. There is only one SWS weapon that has the same damage as its equivalent Craft weapon, and that is the Coelacanth/Gauss = Gauss Cannon. I think this is a coincidence, as the other equivalent weapons are all different between the SWS version and the Craft version (this applies to Gas Cannon, PWT, Sonic, and also Aqua Jet vs torpedos). <br />
<br />
Clearly there ''is'' an inconsistency between the code and the UFOPedia, and that should be fixed. It's hard to say if the "right" value is 110 or 130. Is the code wrong or is the UFOPedia wrong? It could be either way. But I would correct this inconsistency either to 110 or to 130, not increase it to 150. <br />
<br />
[[User:Spike|Spike]] 08:02, 7 September 2012 (EDT)<br />
<br />
: Or make it an option: Displacer Sonic Fix={0|110|130|150} [[User:Spike|Spike]] 09:50, 9 September 2012 (EDT)<br />
'' I changed the damage to be 125, similar to the ratio for the hovertank turrent to plasma cannon.-''[[User:Morgan525|Tycho]] 03:52, 13 October 2012 (EDT)<br />
<br />
== Things that TFTDextender does not fix ==<br />
<br />
Just more or less as a note to the reader, TFTDextender does not fix some of the following things that are sometimes thought of as needing fixing (and this is probably deliberate?):<br />
<br />
* Does not fix the apparent swap of the ground map for the VERY SMALL Survey Ship (1 occupant) with the SMALL Escort (half-dozen or more occupants). So you get the VERY SMALL sub occupying about 25 squares of usable area on the Battlescape, and the supposedly larger SMALL sub occupying one square of usable area on the Battlescape, begging the question of how all those aliens got inside there in the first place. XcomUtil will fix this, as will the original patches that XcomUtil incorporates.<br />
* Does not fix the incorrect pictures for the large USO in the interception window. <br />
:''Both of the above issues have been corrected by Zombie, who swapped the USO map files and changed INTERCEPTION.DAT. You can get these updates from the StrategyCore file section.''[http://www.strategycore.co.uk/files/x-com-terror-from-the-deep/patches/]<br />
* Does not fix the Dart Gun to make it any less utterly useless. Though you can do this yourself via the OBDATA.DAT section of TFTDextender. (Suggestion: don't fix it. The useless Dart Gun is all part of the "oh no we're all gonna die" experience of the beginning of TFTD.)<br />
* Does not improve the armour and effectiveness of the basic Aqua-Jet and Gas Cannon Coelecanths (it does upgrade the Coelecanth/Gauss). (Again, suggestion: this is a good thing - XCOM should start the game hopelessly outclassed, and scramble to catch up).<br />
* Does not allow you to mount weapons on Tritons, or use Barracudas as transport subs. XComUtil can help you cheat in this way.<br />
* Does not allow you to have 360 degree vision out of your sub before exiting it. (What kind of coward would want that?). XComUtil does this.<br />
<br />
== Save Equipment not working? ==<br />
<br />
With "Save Equipment" option enabled, the soldiers' loadout at first was always like this: grenade in leg slot, clip in backpack - and it didn't change on the next mission, despite the fact that I re-equipped the soldiers correctly (grenades and clips on the belt). When I manufactured Gauss Rifles and issued them to my soldiers, it got even worse - none of the soldiers got clips, and two of the rifles were unloaded. Next I upgraded to Sonic-Blasta Rifles and now nothing, except some grenades (still in leg slots), is issued to the soldiers at all. "Save Equipment" was known to work in UFOExtender, did something get broken? --[[User:Player701|Player701]] 09:18, 21 October 2012 (EDT)<br />
<br />
:''Yes. Something is broken but not by the Extender. Many subroutines, their order of execution, or variable were modified in the TFTD game code. Problems like these are deducing what changed in the game code and what changes are needed to get the UFOextender code to work. See the discussion on problems with the OBDATA mod about the final source of the problem and its solution.-[[User:Morgan525|Tycho]] 20:03, 21 October 2012 (EDT)''<br />
<br />
= Feature Requests and Suggestions =<br />
<br />
== Useful alien species research ==<br />
<br />
Tycho, I really like this idea you proposed in the StrategyCore forum:<br />
<br />
:I'm thinking about giving a hp bonus to all aliens until Xcom performs an autopsy on the species to learn the location of their vital organs (like in the movie "Battle of LA"). This would give more importance to performing autopsies rather than just as a stepping stone to new tech.<br />
<br />
Definite +1. It would be equally valid to add to UFO Extender. I suppose it could also be implemented using Vulnerabilities (no Vulnerabilities are in effect until the Autopsy is completed), or Resistances (across-the-board increased Resistances until Autopsy is completed). If that's easier. <br />
<br />
:''The bonus to hp was an initial thought. Later, I decided against it since it would make aliens more resistant to HE and stun, which don't rely on hitting the right locations. Increasing resistances would be the most appropriate but the damage routine code is very tight and adding anything new that won't break the existing variable stack pointers is tough.'' [[User:Morgan525|Tycho]]<br />
::''A new idea for this that I recently have been toying with, would be on the damage generation routine: Most direct fire damage is 0-200%, with anything over 100% considered a "critical hit". If autopsy hasn't been preformed, then the base damage would be 0-100% and a small chance (maybe 25%) of another 0-100% for that lucky shot. With autopsy done, the game reverts back to the usual 0-200% on any hit.''<br />
<br />
::: That works. And it makes doing Alien Autopsies a no-brainer, as it should be. It is pretty much inconceivable that XCom wouldn't prioritise the autopsy of any newly encountered alien. And any player playing the game for the first time would do autopsies too. This mod will help experienced players to stop playing as if they've "seen it all before". [[User:Spike|Spike]] 10:35, 15 September 2012 (EDT)<br />
<br />
Would it also be worth adding some kind of bonus for Live Alien research? Maybe the negation of some kind of Morale penalty and/or Psi penalty? Fear of the unknown, know your enemy, that kind of thing?<br />
<br />
:''I thought about that but the game doesn't record live aliens that have been researched. When you finish research on a live alien, it only follows the routine to unlock the appropriate UFOpaedia articles and then checks to see if the finished research can unlock other topics.'' [[User:Morgan525|Tycho]]<br />
<br />
I had a further thought on this while trying to guess what your new pre-requisites are for the various armours. For now it's really cool to be guessing but once people have figured it out, well, it will be more logical but still will have 'replay fatigue'. Would it be possible to randomise the pre-requisites for a lot of the key research topics, from out of a plausible list of items (or even randomise pre-requisite topics)? That would make every game fresh in terms of the research sequence, and make the research aspect of the game more challenging and less dry & predictable. As ever, just a suggestion. :) Cheers, [[User:Spike|Spike]] 16:01, 19 October 2012 (EDT)<br />
<br />
== All Units Can "Fly" In Water ==<br />
<br />
It's very illogical that most units are stuck on the seabed in underwater missions. Please provide the option to set all units (X-Com and alien) to have "flying" (i.e. swimming) ability when underwater. This is unlikely to cause an outbreak of 3D combat, since there is no cover except at seabed level, so anyone swimming excessively or incautiously is going to get shot. It might disadvantage the aliens if their tactical map waypoints are all set on the surface. But as some of them can "fly", there is hopefully a mechanism to deal with that in the code already. For me it will just solve the frustration of being unable to swim over small obstacles or swim up a level, and being stuck or tactically limited for no sensible reason. Mag-Ion Armour remains useful as an important step in Sub Research and (if using the Everything Works on Land mod) for land use. [[User:Spike|Spike]] 11:36, 9 September 2012 (EDT)<br />
: This requires setting [[UNITREF.DAT]] byte 0x78 bit 2 for the unit (e.g. for all units on both sides). Or the in-memory equivalent of UNITREF.DAT. [[User:Spike|Spike]] 10:19, 5 October 2012 (EDT)<br />
<br />
== Aliens Pick Up Weapons ==<br />
<br />
Related to Improved Alien AI. This makes the game tougher as stunned / panicked bipedal-type aliens are no longer permanently disarmed. This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. A fix for this would be a very helpful rebalancing of both games that eliminates one of the aliens' weak spots. The existing (but unused) routine looks pretty smart and not immediately exploitable to ambush aliens using weapons as traps. <br />
<br />
: I noticed the UFO Extender source code has a 'get' keyword under the OBDATA.DAT directive that populates this field 0x2D. Is that working? [[User:Spike|Spike]] 21:03, 16 October 2012 (EDT)<br />
<br />
== General Tank Modding ==<br />
<br />
I see you are interested in modding tanks (HWPs/SWPs) and that's partly what got you into updating UFO Extender. I made some suggestions for Tank Modding myself, including some of the mechanics required to make it work via a config file such as the UFO / TFD Extender config file. For example you could have cargo carrier / ambulance / casevac tanks, you could have demolition tanks, mine thrower tanks, and of course tanks with custom weapons including dual weapons. Could you have a look here: [[User:Spike#Tank_mods]] and see if any of that makes you feel like getting creative?<br />
<br />
Thanks,<br />
[[User:Spike|Spike]] 10:46, 3 September 2012 (EDT)<br />
<br />
== Use Melee Attacks and Psi/MC on Mind Controlled Aliens ==<br />
<br />
Hook the right and left weapon menus on mind controlled aliens to add in actions for their built in melee attacks (if they have them) and built in Psi/MC attacks (if they have Psi/MC Skill). Ideally add these actions to the menu, and pop up a menu, even if the alien isn't holding any weapons.<br />
<br />
This would make playing Multiplayer XCOM (via XComUtil) way, way nicer.<br />
<br />
== Fix Interception and Navigation Course Algorithms ==<br />
<br />
Or just find the algorithms and I volunteer to fix them!<br />
<br />
=== Use Great Circle Routes ===<br />
<br />
Travel toward the target on the shortest Great Circle, rather than always travelling along lines of latitude first (like they are some kind of main bus route!). <br />
<br />
=== Use Predictive Interception ===<br />
<br />
For a moving target, don't head towards where it is ''now'', head towards where it's ''going to be when you get there''.<br />
<br />
=== Show Degree Headings ===<br />
<br />
The game only ever reports alien headings as North, South, East, West, but clearly alien craft move in other directions than just these four, and clearly XCOM detection equipment is capable of resolving these finer-grained headings, since the crafts' tracks are shown correctly in the Geoscope. <br />
As a first step towards predictive interceptions, it would be great to display the alien craft's heading in degrees, eg 135 degrees for South-East. Maybe rounded to the nearest 5 or 10 degrees.<br />
<br />
== Interception Craft vs Touched Down Alien Craft == <br />
<br />
If an alien craft is touched down and an XCOM interception craft (not touched down) is at the same X/Y position, if the alien craft begins to move, immediately open the Interception window at minimum range (8km/nm), presumably with the alien attempting to get away / break off. Currently the Interception window only happens if the XCom craft is faster, which is dumb, ''even if'' the alien craft could accelerate instantly to its maximum speed. <br />
<br />
For TFTD, only open the window if the alien craft is touched down at a depth that the XCOM craft can reach. <br />
<br />
== Fun, not Funky, Fire ==<br />
<br />
An alternative option for incendiaries/phosphorous damage processing: Do process the so called 'impact' damage of an incendiary on every shot, not just at the end of the turn. But only apply it to those in the area of affect of this specific shell burst, not to all units who are standing in smoke or fire anywhere on the map. This will please fans of incendiaries/phosphorous. It's probably a balancing, rather than unbalancing, change in the relative strengths of the ammo types. Makes incendiaries/phosphorous useful for more than just illumination or desperation. Gives some use to the research topics that advise use of incendiaries/phosphorous, and the damage modifiers aliens have been assigned.<br />
<br />
== Rearming Rates ==<br />
<br />
<br />
From [[Known_Bugs_(TFTD)#Geoscape_Bugs]]:<br />
<br />
=== Craft Gauss Cannon Rearming Rate ===<br />
<br />
This weapon rearms at 10/hr but probably should be 50/hr or at least 25/hr, otherwise it is far slower to rearm than any other cannon weapon in either game. In fact it's the second slowest weapon system to rearm, slower only than AJAX...<br />
<br />
=== AJAX Rearming Rate ===<br />
<br />
An AJAX system takes twice as long to fully reload as a D.U.P. system, as a result AJAX-armed Craft have much worse operational tempo and readiness than D.U.P. armed Craft. Like we needed yet another reason to always use D.U.Ps. This is probably a design error rather than a bug, but it would be good to fix it - anything to give a more balanced set of craft weapon choices. The rearming rate should be raised from 1/hr to 2/hr. The AJAX system will then have the same operational tempo as the D.U.P. system. <br />
<br />
Could also be applied to Stingray missiles in EU 1994, as the same analysis applies to Stingray vs Avalanche.</div>
Spike
https://www.ufopaedia.org/index.php?title=Tactical_Exploits&diff=40244
Tactical Exploits
2012-10-23T18:18:38Z
<p>Spike: /* Weapon Relay */</p>
<hr />
<div>= Tactical Exploits =<br />
<br />
== Grenades: Pass the Experience Trick ==<br />
'''(Or who gets the experience when you "drop" a grenade)'''<br />
<br />
Some commanders may have noticed that a soldier that drops a primed grenade rather than throwing it will often not get credited for the damage or killed enemies. <br />
<br />
There is a very odd explanation for this. In order to credit the right person with experience, the game assigns ownership to a grenade. However, ownership is assigned ''after'' the grenade has been thrown, but not when it's dropped or picked up.<br />
<br />
So who gets the experience if its dropped? At the start of a mission, all X-COM owned grenades default to the very first soldier on the transport, or the very first [[Heavy Weapons Platforms|HWP]] if present. This means that if a grenade is used but never thrown during its lifetime, the first soldier or tank gets the experience regardless of actually used it. <br />
<br />
Can we move the ownership around and pass the experience to soldiers of our choice? Definitely! Just have the person you want to get the experience throw the grenade, then get someone else to pick it up and drop it where it can be useful. Just remember to not throw it again.<br />
<br />
The method of deployment for these grenades will be left as a practical exercise to the commander. Be creative, or be heartless - it's all up to you!<br />
<br />
The biggest advantage of this unusual pass-the-experience technique would be to provide training for frail soldiers that would prove to be more of a detriment in combat than out of it - yet another reason for commanders to not sieve troops based on poor combat statistics.<br />
<br />
== Fire ==<br />
<br />
<br />
The [[Known Bugs#Funky Fire|Funky Fire]] bug can be exploited to cause extra damage to units in fire per shot fired, which is arguably an exploit, and to cause additional damage to units who are standing in fire but who are not targeted by the current incendiary attack that is causing the damage, which is definitely an exploit. <br />
<br />
Smoke grenades can be used to put out fire. <br />
<br />
See the [[Incendiary]] topic<br />
<br />
== Fog of War Scouting ==<br />
<br />
The 3D cursor shows the terrain inside it, regardless of whether you have explored the tile or not. While the obscure shapes shown don't mean much to novice players, veterans will soon recognise tiles, and then the map segments they are native to. For example, you can easily find a UFO by looking for the destinctive wall patterns, and the power supply in the center. Or, you could use this to bombard locations such as command centers, or places you know aliens spawn at the beginning of play, with early Blaster Bombs.<br />
<br />
== Object Radar ==<br />
<br />
The map view shows the position of all objects on the map, and updates their current state regardless of whether an X-COM unit has a current line of site to the object. And the largest object on the tile is shown on the main map for any tile which has been previously spotted. Together this can allow you to sometimes detect, and definitely determine by inspection, if an alien has woken up from being stunned, without having line of sight to the target. In multiplayer games (rare) it can be used to deduced the location and progress of opposing forces, if they pick up items from the ground. <br />
<br />
== Dead Man Switches ==<br />
<br />
Grenades will only detonate when they are on the ground and when their timer has counted down. Timers will continue to count down regardless of location, but if the grenade is not on the ground, it will not explode. This means that you can set all the grenades to a time of "0" at the beginning of play, or at an earlier turn, and throw them when it's tactically feasible.<br />
<br />
This is a double-edged sword, however, because should a unit fall dead or unconcious the grenade will hit the ground and promptly take out anything in the near vicinity... which may (or may not) work to your advantage. This tactic encourages keeping your troops far apart. If you anticipate the soldier will have a very high chance of being killed, it may be wise to use the "pass the experience" trick as described earlier before handing the soldier an armed grenade. However, it can be exploited against Tentaculats: give a soldier two armed grenades. If he/she is caught by a Tentaculat, the grenades will drop. The first will kill the zombie while the second kills the newly formed creature. Could also be used with proximity/PD grenades. (This will not work against Chryssalids because the second grenade will be destroyed before detonation, whereas in TFTD, explosives cannot be destroyed by other explosions.)<br />
<br />
Proximity mines can be defused by saving, quitting the game, restarting it then reloading the game. You can still drop on top of them with a flying suit, or by dropping from a hole in the roof in order to safely pick them up.<br />
<br />
==Base Defence Mission Spawning Issues==<br />
<br />
If there are too many soldiers and/or aliens in too small a base, their initial spawning is unusual. Soldiers can spawn in the Access Lift and Hangars. Aliens can spawn outside the Access Lift and Hangars. Some lifeforms may not spawn at all.<br />
<br />
Why does this happen? Each base facility has certain hardcoded spawn tiles. The Living Quarters, for example, have 8 spawn tiles, 7 on the lower level in an "H" pattern, and 1 on the upper level. Soldiers usually spawn at these spawn tiles, semi-randomly outside the Access Lift and Hangars. Aliens are assigned the spawn tiles within the Lift and Hangars. <br />
<br />
But, if the number of soldiers exceeds the number of "friendly" spawn tiles, the excess soldiers will spawn at the "alien" spawn tiles inside the Access Lift and Hangars. Similarly, if the number of aliens exceeds the number of "alien" spawn tiles, the excess aliens will spawn at the "friendly" spawn tiles in the rest of the base. If there are not enough spawn tiles for the sum of soldiers and aliens, then some lifeforms will not spawn at all. Soldiers have higher spawning priority than aliens, so aliens will be the first to go (fail to spawn). All weapons and items will still be generated, though.<br />
<br />
This can be exploited by garrisoning a base with so many soldiers that all spawn tiles are used up. Zero aliens will spawn (but their toys will still be generated), resulting in a bloodless victory and millions of dollars of loot!<br />
<br />
A radar base with one Large Radar or HWD, an Access Lift, and one Living Quarters, can be filled up with 22 soldiers.<br />
<br />
But if this is considered an exploit, then what is the "ethical" thing to do? To get all aliens to spawn properly at a radar base, you would have to go out of your way and build a hangar. This would in turn affect your defence tactics, and cost you money. If you don't build the hangar, you need to recruit at least 25 armed soldiers (with the accompanying Living Quarters and General Stores), or else a Sectopod or Chrysallid will probably spawn behind friendly lines. At that point, you could argue that the computer is the one doing the cheating, and 25 soldiers seems excessive for a radar base. On the other hand, you would be fighting a reduced number of aliens, since the Access Lift only has 8 spawn tiles.<br />
<br />
Also, you can only have 40 "units" where a soldier is one unit and a HWP is 4.<br />
<br />
Maybe you should just shoot down the scouts.<br />
<br />
<table><br />
<tr><td>Base Facility</td><td>Spawn Tiles on Lower / Upper Floor</td></tr><br />
<tr><td>Access Lift</td><td>5 / 3</td></tr><br />
<tr><td>Hangar</td><td>15 / 0</td></tr><br />
<tr><td>Alien Containment</td><td>7 / 5</td></tr><br />
<tr><td>General Stores</td><td>7 / 4</td></tr><br />
<tr><td>HWD or Large Radar</td><td>5 / 1</td></tr><br />
<tr><td>Lab or Workshop</td><td>6 / 1</td></tr><br />
<tr><td>Living Quarters</td><td>7 / 1</td></tr><br />
<tr><td>Missile Defence</td><td>4 / 5</td></tr><br />
<tr><td>Defences (non-missile) or Shields</td><td>5 / 1</td></tr><br />
<tr><td>Psi Lab</td><td>7 / 3</td></tr><br />
<tr><td>Small Radar</td><td>0 / 2</td></tr><br />
</table><br />
<br />
<br />
==Elevator Shielding==<br />
Due to questionable AI, aliens will not fire at you through an elevator (either up or down), even though they can see you and you can see them. When approaching elevators, have a soldier stand on it at the end of the turn, even if this leaves them with no TU. The aliens will not be able to come up/down through the elevator, keeping you safely shielded while you bring up rear troops and prepare for a floor breach. Additionally, soldiers may be able to see aliens standing at/near the elevator above or below them and can fire on them from the safety of their "elevator shield".<br />
<br />
==Milking Alien Bases==<br />
This experience training and (optionally) booty-gathering exploit relies on the "Elevator Shielding" exploit. When assaulting an alien base, your soldiers will be deployed at two staging areas with a 2x2 elevator in each one. Block all eight elevator squares with a soldier and wait for the fun to begin. Just keep skipping your turn and eventually, the aliens will find your soldiers and begin to congregate under the elevator. You can now shoot at them with complete impunity and can even pick out specific soldiers who need Accuracy training. When you see that no more aliens are appearing after a few turns, get your solders onto the evactuation area and leave. The alien base is intact for you to return for additional practice later. If you happened to kill everyone the base will be destroyed, so watch the timing of the alien movement phase and take care not to kill everyone (in practice this means 'save regularly', since there is no in-game way to determine ''exactly'' how many enemy units are left alive). However, the alien leader or commander will almost always stay in the command center, so this is usually not a problem. For best results, arm your soldiers with pistols to maximize the number of shots they can take on each alien. Also, it is not recommended to attempt this tactic on a Sectoid or Ethereal base unless you are very confident of your soldiers' psi strength. As an extra bonus, you can collect alien weapons and equipment before evacuating. It is worth noting that this "shield" does not prevent aliens firing a Blaster Bomb up the lift shaft. However, unless you are running a version of the game that fixes the [[Known_Bugs#Collectors_Edition_Blaster_Bomb_Bug|Vertical Waypoint Blaster Bomb bug]], such attacks will rarely succeed - mostly they will explode on the level below, with no harm to your troops. So unless you have fixed the Vertical Waypoint bug, there is minimal risk with this exploit.<br />
<br />
==Panicking Alien Location Exploit==<br />
<br />
Whenever a soldier or alien panics or goes berserk from low [[Morale]], there is a message given to the player stating what soldier or alien has done what. As well, the screen is centered on the unit that has failed it's morale check. At times, this will allow sharp-eyed players to locate aliens who have panicked in areas you have already fought, by displaying the location of the alien who has lost their cool.<br />
<br />
==Grenade Relay==<br />
<br />
Some consider this simply a tactic, but measured against realism, its use anything other than very occasionally is an exploit. Simply, a grenade can be primed by one soldier, then thrown between any number of soldiers before being finally delivered to the target. While it is desirable to be able to throw already-primed grenades, for the well attested (but dangerous) practice of throwing a primed grenade ''away'' from friendly troops, using this to cover the battlefield with leap frogging grenades is an exploit to circumvent the (high) TU costs of priming grenades and the (minimal) encumbrance costs of carrying grenades, and is a way of 'concentrating' TUs from safe rear units toward exposed front line units. A number of self-imposed rulesets require not using this tactic. Or exploit. <br />
<br />
==Weapon Relay==<br />
<br />
A less obvious but more obviously bizarre variant of the grenade relay is a weapon relay. A weapon can be fired and then thrown to another soldier who fires it again, then throws it to another soldier, and so on, without limitation. There is no reason why an entire squad could not fire the same weapon in the same round, possibly multiple times each depending on the specific weapon's TU costs. This will then greatly exceed the normal maximum rate of fire of this weapon, as well as being patently ridiculous. Scenarios where this would be advantageous would be any time that effective weapons against the enemy are in short supply in inventory. Particularly effective with weapons that do have unlimited ammo (lasers, stun rods / tazers / drills).<br />
<br />
==Equipment Relay==<br />
The same technique can also be used with Psi Amps / MC Disruptors to allow part or all of the squad to get at least one Psi/MC attempt from just one device. And it can be used with Medi-Kits to exceed the normal limit on healing (etc) per turn. It can also be used with Motion Scanners / Particle Disturbance Sensors to achieve excellent triangulation of signals while only having one such sensing device on the mission.</div>
Spike
https://www.ufopaedia.org/index.php?title=Tactical_Exploits&diff=40237
Tactical Exploits
2012-10-23T16:39:54Z
<p>Spike: Cleaned up Fire. Object radar. Grenade relay. Weapon relay. Psi Amp / MC Relay. Equipment Relay.</p>
<hr />
<div>= Tactical Exploits =<br />
<br />
== Grenades: Pass the Experience Trick ==<br />
'''(Or who gets the experience when you "drop" a grenade)'''<br />
<br />
Some commanders may have noticed that a soldier that drops a primed grenade rather than throwing it will often not get credited for the damage or killed enemies. <br />
<br />
There is a very odd explanation for this. In order to credit the right person with experience, the game assigns ownership to a grenade. However, ownership is assigned ''after'' the grenade has been thrown, but not when it's dropped or picked up.<br />
<br />
So who gets the experience if its dropped? At the start of a mission, all X-COM owned grenades default to the very first soldier on the transport, or the very first [[Heavy Weapons Platforms|HWP]] if present. This means that if a grenade is used but never thrown during its lifetime, the first soldier or tank gets the experience regardless of actually used it. <br />
<br />
Can we move the ownership around and pass the experience to soldiers of our choice? Definitely! Just have the person you want to get the experience throw the grenade, then get someone else to pick it up and drop it where it can be useful. Just remember to not throw it again.<br />
<br />
The method of deployment for these grenades will be left as a practical exercise to the commander. Be creative, or be heartless - it's all up to you!<br />
<br />
The biggest advantage of this unusual pass-the-experience technique would be to provide training for frail soldiers that would prove to be more of a detriment in combat than out of it - yet another reason for commanders to not sieve troops based on poor combat statistics.<br />
<br />
== Fire ==<br />
<br />
<br />
The [[Known Bugs#Funky Fire|Funky Fire]] bug can be exploited to cause extra damage to units in fire per shot fired, which is arguably an exploit, and to cause additional damage to units who are standing in fire but who are not targeted by the current incendiary attack that is causing the damage, which is definitely an exploit. <br />
<br />
Smoke grenades can be used to put out fire. <br />
<br />
See the [[Incendiary]] topic<br />
<br />
== Fog of War Scouting ==<br />
<br />
The 3D cursor shows the terrain inside it, regardless of whether you have explored the tile or not. While the obscure shapes shown don't mean much to novice players, veterans will soon recognise tiles, and then the map segments they are native to. For example, you can easily find a UFO by looking for the destinctive wall patterns, and the power supply in the center. Or, you could use this to bombard locations such as command centers, or places you know aliens spawn at the beginning of play, with early Blaster Bombs.<br />
<br />
== Object Radar ==<br />
<br />
The map view shows the position of all objects on the map, and updates their current state regardless of whether an X-COM unit has a current line of site to the object. And the largest object on the tile is shown on the main map for any tile which has been previously spotted. Together this can allow you to sometimes detect, and definitely determine by inspection, if an alien has woken up from being stunned, without having line of sight to the target. In multiplayer games (rare) it can be used to deduced the location and progress of opposing forces, if they pick up items from the ground. <br />
<br />
== Dead Man Switches ==<br />
<br />
Grenades will only detonate when they are on the ground and when their timer has counted down. Timers will continue to count down regardless of location, but if the grenade is not on the ground, it will not explode. This means that you can set all the grenades to a time of "0" at the beginning of play, or at an earlier turn, and throw them when it's tactically feasible.<br />
<br />
This is a double-edged sword, however, because should a unit fall dead or unconcious the grenade will hit the ground and promptly take out anything in the near vicinity... which may (or may not) work to your advantage. This tactic encourages keeping your troops far apart. If you anticipate the soldier will have a very high chance of being killed, it may be wise to use the "pass the experience" trick as described earlier before handing the soldier an armed grenade. However, it can be exploited against Tentaculats: give a soldier two armed grenades. If he/she is caught by a Tentaculat, the grenades will drop. The first will kill the zombie while the second kills the newly formed creature. Could also be used with proximity/PD grenades. (This will not work against Chryssalids because the second grenade will be destroyed before detonation, whereas in TFTD, explosives cannot be destroyed by other explosions.)<br />
<br />
Proximity mines can be defused by saving, quitting the game, restarting it then reloading the game. You can still drop on top of them with a flying suit, or by dropping from a hole in the roof in order to safely pick them up.<br />
<br />
==Base Defence Mission Spawning Issues==<br />
<br />
If there are too many soldiers and/or aliens in too small a base, their initial spawning is unusual. Soldiers can spawn in the Access Lift and Hangars. Aliens can spawn outside the Access Lift and Hangars. Some lifeforms may not spawn at all.<br />
<br />
Why does this happen? Each base facility has certain hardcoded spawn tiles. The Living Quarters, for example, have 8 spawn tiles, 7 on the lower level in an "H" pattern, and 1 on the upper level. Soldiers usually spawn at these spawn tiles, semi-randomly outside the Access Lift and Hangars. Aliens are assigned the spawn tiles within the Lift and Hangars. <br />
<br />
But, if the number of soldiers exceeds the number of "friendly" spawn tiles, the excess soldiers will spawn at the "alien" spawn tiles inside the Access Lift and Hangars. Similarly, if the number of aliens exceeds the number of "alien" spawn tiles, the excess aliens will spawn at the "friendly" spawn tiles in the rest of the base. If there are not enough spawn tiles for the sum of soldiers and aliens, then some lifeforms will not spawn at all. Soldiers have higher spawning priority than aliens, so aliens will be the first to go (fail to spawn). All weapons and items will still be generated, though.<br />
<br />
This can be exploited by garrisoning a base with so many soldiers that all spawn tiles are used up. Zero aliens will spawn (but their toys will still be generated), resulting in a bloodless victory and millions of dollars of loot!<br />
<br />
A radar base with one Large Radar or HWD, an Access Lift, and one Living Quarters, can be filled up with 22 soldiers.<br />
<br />
But if this is considered an exploit, then what is the "ethical" thing to do? To get all aliens to spawn properly at a radar base, you would have to go out of your way and build a hangar. This would in turn affect your defence tactics, and cost you money. If you don't build the hangar, you need to recruit at least 25 armed soldiers (with the accompanying Living Quarters and General Stores), or else a Sectopod or Chrysallid will probably spawn behind friendly lines. At that point, you could argue that the computer is the one doing the cheating, and 25 soldiers seems excessive for a radar base. On the other hand, you would be fighting a reduced number of aliens, since the Access Lift only has 8 spawn tiles.<br />
<br />
Also, you can only have 40 "units" where a soldier is one unit and a HWP is 4.<br />
<br />
Maybe you should just shoot down the scouts.<br />
<br />
<table><br />
<tr><td>Base Facility</td><td>Spawn Tiles on Lower / Upper Floor</td></tr><br />
<tr><td>Access Lift</td><td>5 / 3</td></tr><br />
<tr><td>Hangar</td><td>15 / 0</td></tr><br />
<tr><td>Alien Containment</td><td>7 / 5</td></tr><br />
<tr><td>General Stores</td><td>7 / 4</td></tr><br />
<tr><td>HWD or Large Radar</td><td>5 / 1</td></tr><br />
<tr><td>Lab or Workshop</td><td>6 / 1</td></tr><br />
<tr><td>Living Quarters</td><td>7 / 1</td></tr><br />
<tr><td>Missile Defence</td><td>4 / 5</td></tr><br />
<tr><td>Defences (non-missile) or Shields</td><td>5 / 1</td></tr><br />
<tr><td>Psi Lab</td><td>7 / 3</td></tr><br />
<tr><td>Small Radar</td><td>0 / 2</td></tr><br />
</table><br />
<br />
<br />
==Elevator Shielding==<br />
Due to questionable AI, aliens will not fire at you through an elevator (either up or down), even though they can see you and you can see them. When approaching elevators, have a soldier stand on it at the end of the turn, even if this leaves them with no TU. The aliens will not be able to come up/down through the elevator, keeping you safely shielded while you bring up rear troops and prepare for a floor breach. Additionally, soldiers may be able to see aliens standing at/near the elevator above or below them and can fire on them from the safety of their "elevator shield".<br />
<br />
==Milking Alien Bases==<br />
This experience training and (optionally) booty-gathering exploit relies on the "Elevator Shielding" exploit. When assaulting an alien base, your soldiers will be deployed at two staging areas with a 2x2 elevator in each one. Block all eight elevator squares with a soldier and wait for the fun to begin. Just keep skipping your turn and eventually, the aliens will find your soldiers and begin to congregate under the elevator. You can now shoot at them with complete impunity and can even pick out specific soldiers who need Accuracy training. When you see that no more aliens are appearing after a few turns, get your solders onto the evactuation area and leave. The alien base is intact for you to return for additional practice later. If you happened to kill everyone the base will be destroyed, so watch the timing of the alien movement phase and take care not to kill everyone (in practice this means 'save regularly', since there is no in-game way to determine ''exactly'' how many enemy units are left alive). However, the alien leader or commander will almost always stay in the command center, so this is usually not a problem. For best results, arm your soldiers with pistols to maximize the number of shots they can take on each alien. Also, it is not recommended to attempt this tactic on a Sectoid or Ethereal base unless you are very confident of your soldiers' psi strength. As an extra bonus, you can collect alien weapons and equipment before evacuating. It is worth noting that this "shield" does not prevent aliens firing a Blaster Bomb up the lift shaft. However, unless you are running a version of the game that fixes the [[Known_Bugs#Collectors_Edition_Blaster_Bomb_Bug|Vertical Waypoint Blaster Bomb bug]], such attacks will rarely succeed - mostly they will explode on the level below, with no harm to your troops. So unless you have fixed the Vertical Waypoint bug, there is minimal risk with this exploit.<br />
<br />
==Panicking Alien Location Exploit==<br />
<br />
Whenever a soldier or alien panics or goes berserk from low [[Morale]], there is a message given to the player stating what soldier or alien has done what. As well, the screen is centered on the unit that has failed it's morale check. At times, this will allow sharp-eyed players to locate aliens who have panicked in areas you have already fought, by displaying the location of the alien who has lost their cool.<br />
<br />
==Grenade Relay==<br />
<br />
Some consider this simply a tactic, but measured against realism, its use anything other than very occasionally is an exploit. Simply, a grenade can be primed by one soldier, then thrown between any number of soldiers before being finally delivered to the target. While it is desirable to be able to throw already-primed grenades, for the well attested (but dangerous) practice of throwing a primed grenade ''away'' from friendly troops, using this to cover the battlefield with leap frogging grenades is an exploit to circumvent the (high) TU costs of priming grenades and the (minimal) encumbrance costs of carrying grenades, and is a way of 'concentrating' TUs from safe rear units toward exposed front line units. A number of self-imposed rulesets require not using this tactic. Or exploit. <br />
<br />
==Weapon Relay==<br />
<br />
A less obvious but more obviously bizarre variant of the grenade relay is a weapon relay. A weapon can be fired and then thrown to another soldier who fires it again, then throws it to another soldier, and so on, without limitation. There is no reason why an entire squad could not fire the same weapon in the same round, possibly multiple times depending on the specific weapon's TU costs. This will then greatly exceed the normal maximum rate of fire of this weapon, as well as being patently ridiculous. Scenarios where this would be advantageous would be any time that effective weapons against the enemy are in short supply in inventory. Particularly effective with weapons that do have unlimited ammo (lasers, stun rods / tazers / drills). <br />
<br />
==Equipment Relay==<br />
The same technique can also be used with Psi Amps / MC Disruptors to allow part or all of the squad to get at least one Psi/MC attempt from just one device. And it can be used with Medi-Kits to exceed the normal limit on healing (etc) per turn. It can also be used with Motion Scanners / Particle Disturbance Sensors to achieve excellent triangulation of signals while only having one such sensing device on the mission.</div>
Spike
https://www.ufopaedia.org/index.php?title=Talk:Psionics&diff=40235
Talk:Psionics
2012-10-23T16:13:34Z
<p>Spike: /* How a tiny bunch of human civilians beat the aliens at Psionics */</p>
<hr />
<div>Just had a thought on the formula!<br />
<br />
What if the "Psionic Combat Strength" formula was a''' ' + ' '''rather than a''' ' * ' '''?<br />
<br />
It would mean the example Soldier would have a PCS of 111, rather than 1520, and the defending Muton would have:<br />
<br />
Panic Chance = 76%<br />
MC Chance = 56%<br />
<br />
These numbers seem more reasonable, don't you think?<br />
<br />
--[[User:Danial|Danial]] 15:32, 19 Nov 2005 (PST)<br />
----<br />
Right, it sounds '''much''' more reasonable now. My actual results were 1192 successes out of 2420 tries = 49.26% success rate. The MCer was right next to MC victim, and we know distance introduces ''some'' kind of decrease to base chance. That's the good news. The bad news is that I also tested psi str 95, skill 44 (and some higher skill levels) and never failed to MC ''once'' with these better MCers. Using your revision, a psi str 95, skill 44 guy should have had a success rate of 84% vs. a beginner Muton soldier (psi str 25, skill 0), not 100%. My higher-skill guys were also right next to their MC victims. So, to me the first example makes sense relative to your idea (fits base chance, plus a little distance adds a little more), but the second example counters it.<br />
<br />
Still, it sounds WAY better than 1500% :)<br />
<br />
I sure wish psi testing wasn't so labor intensive. I got those 2400 counts doing all that experience testing... not interested in doing it again, just for psi equations. At least not at the moment. :P ---[[User:MikeTheRed|MikeTheRed]] 21:12, 23 Nov 2005 (PST)<br />
----<br />
Question: why is the Sectopod's psionic resistance listed as N/A? I've mind-controlled sectopods (or at least one square of a sectopod) on many occasions. I usually have it shoot itself, since it can target one of its other, non-MC'ed squares. From my anecdotal experience, their psi resistance seems somewhat high. --[[User:Papa Legba|Papa Legba]] 14:19, 2 February 2006 (PST)<br />
----<br />
Answer: If you look on the alien summaries in the wiki they all have a PSI resistance listed, except the Sectopod. Since it's not listed anyplace I put N/A. Feel free to put it where it belongs in the list if you have enough experience to feel comfortable ranking it. --[[User:Darksun|Darksun]]<br />
----<br />
Darksun, I took the liberty of signing your name for you, and making a separator line. Why not say a word about yourself under [[User:Darksun]] and also, use four dashes (----) to demarcate entries. For more on the basics of wiki'ing, see NKF's "Community Portal" at the bottom of the homepage. Past all that - welcome, fellow XCOMMIE! We were all wiki noobs once. But not everybody loves XCOM. You must. Welcome aboard!<br />
<br />
Proceeding right along to flagellating, laugh - Where are you folks talking about Sectopod psi resistance being "N/A"? I see their Psi Strength as 100, and their Psi Skill as 0 at Beginner; Psi Strenth 116 and Skill still 0 at Superhuman. In this respect, they match Cyberdisks. What do you folks mean by Psi "resistance"? Do you know the math behind the psi equations? I haven't been able to figure it out. But the stats I just listed are ones hacked out of the game... Zombie is going to present a full precis' some time soon.<br />
<br />
Great speaking at ya ... keep on contributing, Darksun!! --[[User:MikeTheRed|MikeTheRed]]<br />
<br />
== Alien psionic resistance ==<br />
<br />
I haven't tried mind-controlling Cyberdiscs much, but if, as I've read elsewhere, both Sectopods and Cyberdiscs have have a Psi Strength of 100, they should probably both be classed "extremely high".<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 10:30, 4 May 2006 (PDT)<br />
<br />
== Psionic testing ==<br />
<br />
I started doing some testing to figure out the psionics formula. <br />
<br />
Initial finding: ''distance'' takes the hypotenuse into account. I'm not sure if the actual Pythagorean formula is used, but I can say this much: an Ethereal was able to panic a moderately-psi-weak soldier at 30 squares along the horizontal but not at 30 squares along the diagonal.<br />
<br />
Second finding: the difference in "difficulty" between MC and panic is definitely 20 points (although that may not be percent). A soldier with 97 Psi strength, 0 Psi skill standing adjacent to an Ethereal Leader (60 str/45 skill) could not be panicked at all, but 96 Psi str could (often). The same soldier with 77 Psi str couldn't be mind-controlled, but could at 76 Psi str. ''With further testing, I see that 60/45 vs. 97 should succeed occasionally; I might retest this for greater precision, although the +20 still seems to hold.''<br />
<br />
Third finding: A soldier with 99 Psi str/0 skill could ''just barely'' be panicked by an adjacent Ethereal with 63/45. I couldn't count how often the Ethereal succeeded, but it was something like 1%-2% of the time. The same soldier was panicked just as infrequently by an Ethereal with 45/63 (str & skill reversed), and much more often by an Ethereal with 54/54. This pretty strongly suggests the attack portion of the formula involves psi str & skill multiplied together.<br />
<br />
Data points collected so far:<br />
*Ethereal, 63/45, just barely panicked soldier, 99/0<br />
*Ethereal 40/40 just barely panicked soldier 75/0<br />
*Ethereal 27/27 (multiplied together = 729) just barely panicked soldier 57/0<br />
*Ethereal 10/73 (multiplied = 730) just barely panicked soldier 57/0<br />
**''this confirms that attacking is based on str*skill<br />
*Ethereal 18/18 just barely panicked soldier 49/0<br />
*Ethereal 1/1 just barely panicked soldier 43/0<br />
*Ethereal 1/1 just barely panicked soldier 1/210<br />
**''this confirms Psi skill / 5 is used in calculating defense; 1 + (210/5) = 43''<br />
<br />
I also tested Ethereal 0/1 (no psi str, 1 pt. skill); it still attacked, but did not attack at 0 pts. skill no matter how high psi str was (no surprise there, otherwise all units would do psi attacks).<br />
<br />
I ran the points through a curve-fitting program and got a nice and simple answer:<br />
<br />
attack strength = psi str * psi skill '''/ 50'''<br />
defense strength = psi str + (psi skill / 5)<br />
<br />
Panic Attack chance = 44% + attack strength - defense strength<br />
Mind Control Attack chance = 24% + attack strength - defense strength<br />
<br />
The formula has held up under limited further testing; I'm satisfied it's correct. I invite others to test it more than I have.<br />
<br />
The impact of distance has yet to be tested, but it should be easy to figure out now.<br />
<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 22:03, 26 May 2006 (PDT)<br />
<br />
----<br />
<br />
There is a reasonable approximation to the Pythagorean formula (in the plane) that could have been used, that doesn't require loops or floating-point math:<br />
<br />
max( | &Delta;x | , | &Delta;y | ) + &frac12;min( | &Delta;x | , | &Delta;y | )<br />
<br />
where &Delta;_ := _<sub>2</sub> - _<sub>1</sub>.<br />
<br />
It overestimates slightly. I haven't thought through how this would generalize to 3D. [Yanked from Moria, Angband, and variants...think it's too basic to copyright, though.]<br />
<br />
One way to test whether the distance estimator is no greater than true Pythagorean formula by working out the greatest distance (pure x or pure y) that MC/Panic is not 0%, then testing on a diagonal with a "computed same". An integer-math overestimator (like the above) would by 0%.<br />
<br />
Muliple of 5 allows replacing the diagonal with a suitably scaled 3-4-5 triangle...should work as well for testing.<br />
<br />
--[[User:Zaimoni|Zaimoni]] 2:38PM, 26 May 2006 (CDT)<br />
<br />
----<br />
<br />
Wow... good approach to teasing this out, Ethereal!<br />
<br />
Am I doing this right? I plugged in numbers for Muton, 25/0, Me 95/44, and got 83% MC Base Chance... But in much repeated testing (when learning about experience counters) it seemed quite solid that I was MC'ing him about half the time. Say 45-55% of the time. This was when right next to each other. Is 83% right for your equations?<br />
<br />
Zaimoni, re: your equation, see [[Explosions#Distance_from_Ground_Zero]]. XCOM seems to use a fairly simple approach that doesn't involve Pythagoras per se. Since it's based on a very old engine, much of its stuff is integer based. Cool deal on the deltas and other wiki symbols - I wish I knew about them sooner! Actually I know where wiki symbol tables are... just didn't bother to look up so many symbols. :P<br />
<br />
Nobody has tackled 3D distance yet, but I may soon, in studying illumination.<br />
<br />
Once the equations are well known (maybe they are already), I imagine some cool 3D topographical graphs of the various factors (skill and strength, you vs. enemy) could be made. Do either of you have surface graph s/w at hand? All I've got at the moment is Excel. :(<br />
<br />
Great work! Also thanks for cleaning up the page in general, Eth.<br />
<br />
---[[User:MikeTheRed|MikeTheRed]] 22:24, 2 June 2006 (PDT)<br />
<br />
----<br />
<br />
I suspect you've misremembered the details of your tests. The 49.26% success rate out of 2400 trials that you quote above would have been for your 95/16 soldier doing panics, not MCs: 44 + [95*16/50 = 30.4] - 25 = 49.4%, almost exactly the same as your 49.26%. A 95/44 doing panics would always succeed: 102.6%. A 95/44 doing MCs would succeed 82.6% of the time.<br />
<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 11:06, 3 June 2006 (PDT)<br />
<br />
----<br />
<br />
Ah, there's that data. Thanks for reminding me. I can't remember what I put in which discussions and was going to dig it out of my db. <br />
<br />
No, it was MCs. Indeed I relied on the lack of seeing an enemy, if I got moving too fast and couldn't remember if I successfully MC'd. Attention starts to wander with such highly repetitive testing. This was before I realized the following...<br />
<br />
Anyone doing repetitive psi testing can readily and accurately get the number of positive results from the [[UNITREF.DAT]] Psi byte [84] if you work it right. Note the turn you start psi attempts. Then do exactly 2 or 3 psi Attempts each turn, as your TUs allow. Then note the turn you stop and get the delta. Turns x Attempts/Turn = Attempts. A failed psi attempt adds 1 to [84] and a successful attempt adds 3, so the number of successes is: ([84]-Attempts)/2. Be careful during testing marathons because the byte wraps around at 255 (=85 straight successes, or 28.3 turns at 3 successful attempts per turn). Then it starts counting again so actually even this can be dealt with by adding 255 if you're on top of it. If anybody wants an applet that shows Unitref experience values on the fly, let me know. It's great for building experience. Right now it's embedded within my mdb though... I'd have to tease it out.<br />
<br />
I'm using XCOM DOS which I once ran XcomUtil on, if that matters. <br />
<br />
Hmm.<br />
<br />
---[[User:MikeTheRed|MikeTheRed]] 12:21, 3 June 2006 (PDT)<br />
<br />
----<br />
<br />
Distance...ok, no reason for the game to use multiple 2-d distance formul&aelig;.<br />
<br />
I have software set up to render 3D graphs. Is there anything on the site that jumps out as "would like to see first"? I'd rather wait until the psi formul&aelig; are calibrated first before graphing those.<br />
<br />
Ethereal: What I see posted is test data for ethereal MC human. Do you have test data for human MC ethereal as well? [That would test whether the game calculations are symmetrical.]<br />
<br />
---[[User:Zaimoni|Zaimoni]] 2:37, 3 June 2006 (EDT)<br />
<br />
----<br />
<br />
It ''is'' possible X-COM units get a different formula from aliens -- I only tested an alien doing psi, as it was more automated -- the thing would psi without my having to control it.<br />
<br />
I'm not not volunteering to test x-com units for the time being -- it's a bit more laborious -- but if I ''had'' to test it, I'd do a small number of trials of 35/16, 50/51, and 100/51 soldiers trying to MC (not panic) an adjacent Muton, which should succeed 10.2%, 50% and 101% of the time.<br />
<br />
Feel free to test it before I do. ;-P<br />
<br />
Oh, and nice work on the flares, Mike.<br />
<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 12:50, 3 June 2006 (PDT)<br />
<br />
----<br />
<br />
Sounds cool, Zaimoni... As for "like to see",<br />
<br />
Once my troops have psi ability, I try to get 90+ psi strength guys. Then the question becomes "at psi str 90, at what psi skill point are most/all aliens certain to be MC'ed?" In my experience, it's somewhere around skill 40-60... Anything that might show this, or show how you fare relative to aliens at, say, STR 90, is something I've always wanted. However it might be done. In one sense you could simply plug the "worst" psi alien (Ethereal CDR?) into Eth's equations to get the final answer. But it'd be good to see the lay of the land.<br />
<br />
If you make the simplifying assumption that many of your targets are psi skill 0, there's one less variable. Additional graphs can be done later just for the psi-capable aliens... first things first though...<br />
<br />
Taking the above into consideration, then, XCOM Psi Skill (Str=90) vs. Alien Psi Strength (Skill=0) vs. Success rate is one 3D graph that could be made. If you can do a 4th dimension as color, you could replace the Success rate axis with XCOM Psi Str, then have color indicate success rate, from primary red for "no way" through yellow for "sometimes" to primary green for "always". Or something like that. It'd also be nice but not critical to have annotations for where various aliens lie along their dimension. I can supply this info if you want. Which reminds me: Eth, Zombie and others found some errors in Aztec's table (which came from the OSG). Just a few percent of them, but they're definitely there (I can't remember where). I've hacked alien stats straight out of GEOSCAPE... see the alien stats page. I believe Zombie has found these to be correct, but he has not yet given the final word.<br />
<br />
Zai, as far as I'm concerned, you can model using EC's equation already, if you have the time... I'm sure his equations are very close, if not spot on, and even if not, it may show key places to test and otherwise support further testing. E.g., both aliens and XCOM can readily have their relevant values hacked to test for boundary conditions of 0% and 100% success. Plus once it's set up it shouldn't be hard to tweak the equation and voila, the graphs update. But if you don't have the time - eh, it's all volunteer work anyway.<br />
<br />
Eth, I suppose it's possible aliens vs. humans is different. They are known to have some differences in functionality, such as night vision. I don't know if I'll be able to test, but it definitely intrigues me. BTW I said somewhere else that I was looking into automating the XCOM interface in order to do psi testing. I have concluded that I can't do it. At least not the way I was hoping to. Oh well. Still, my belated realization that one can use Unitref[84] to count psi successes is a real boon to repetitive testing. So we'll see. Thanks for suggestions on what to test if I do. By the way, did I do that 83% correct? I just want to make sure I'm doing the math right.<br />
<br />
Thanks re: the flares!<br />
<br />
---[[User:MikeTheRed|MikeTheRed]] 21:08, 3 June 2006 (PDT)<br />
<br />
----<br />
<br />
The influence of distance still needs to be tested, although it doesn't seem to be an enormous factor. Rather than a complicated graph, I think a few charts with distance = 1, 10 and 20 would probably tell the story more clearly. The distance formula might even prove to be something really simple, like +1 distance = -1% chance.<br />
<br />
The hardest aliens to MC are Sectopods and Cyberdiscs: look at the [[Psionics#Summary_of_Alien_Psionic_Resistance]] section I added. At distance 1 on Superhuman you'll need 93 to 192 Attack Strength to achieve 1% to 100% chance. Assuming Psi Str 90, that's Skill 52 to 107.<br />
<br />
Now vs. the strongest attacker: Superhuman Ethereal Commander, attack str 88. You'll need a Resistance of 132 to be totally immune to panics from one adjacent to you -- that's str 100, skill 160, or str 90, skill 210. Against MC, it's str 100/skill 60 or str 90/skill 110. In practice you won't be right next to them, so you can probably go a bit lower. They'll focus on the weakest soldiers anyhow, which in practice means a couple of decoys in with some supertroopers is a good strategy.<br />
<br />
82.6%, yes.<br />
<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 21:51, 3 June 2006 (PDT)<br />
<br />
OpenOffice.org is CPU-bound when converting the graph from 2D to 3D. [XCOM Psi Str/Sk 90/0-107, alien Psi Str/Sk 25-116/0; I'm on a 1GHz Pentium III/512MB] Not sure how ColdFusion single-IP demo would do yet (would have to reinstall), but the UI options look better in OpenOffice.org.<br />
<br />
I'll attempt the transition later today (when I know I'll be away from the system and positively not working). I just need to be able to take a screenshot.<br />
<br />
You probably already noticed this: even if a bug permitted a 0 Psi Skill operative to use a Psi Amp, the success chance of MC is still negative.<br />
<br />
Also (thinking about the testing anomaly MikeTheRed had): The floating-point change in success rate from an increase of 1 in Psi Skill is 1.9 at 95 Psi Str. Integer truncation would make this 1...leaving the floating-point formula overestimating by 39.6%. At the precision of reporting, this works.<br />
<br />
[Edit: but does *not* work against the initial regression. So, no good.]<br />
<br />
---[[User:Zaimoni|Zaimoni]] 9:51, 4 June 2006 (CDT)<br />
<br />
Got a chance to run the bar graph this morning...no go, OpenOffice.org doesn't like a horde of data points on both axes. <br />
<br />
But...this particular graph is essentially a plane. It should be hand-drawable, even if the more complicated ones aren't.<br />
<br />
---[[User:Zaimoni|Zaimoni]] 8:35, 5 June 2006 (CDT)<br />
<br />
----<br />
<br />
Hi Zaimoni... I'm not sure I understand the differences you talk about. You mean you can get your s/w to make a graph where you've specified the points by hand? Anyway, if you take a shot at most anything, we'd be able to give feedback... a picture's worth a thousand words. Thanks for working on it! ---[[User:MikeTheRed|MikeTheRed]] 06:36, 5 June 2006 (PDT)<br />
<br />
Somewhat. Layer 1 of the spreadsheet is the raw data to be graphed (took about five minutes to set up). If I was going to commit to this representation, I'd go back and make the XCOM Psi Str and Alien Psi Skill configurable. So it's trying to graph data points (the MC success chances) on 0-107 by 25-116. I was planning to rotate the view after getting the initial graph up on Layer 2. [Time loading is not favorable for working further on this today.]<br />
<br />
OpenOffice.org's autoscaling isn't compensating properly. I haven't checked how to suppress the "color key" that was auto-generated for Alien Psi Str &mdash; it's not leaving enough space for the vertical bars to even be 1 pixel in size. The result is decidedly flat, with "correct" vertical range.<br />
<br />
As a bar graph, I could get away with subsampling (but don't have a clean way to do it). Yes, it should be possible to correctly graph this (as a plane in three-dimensional space) with only four data points: the corners.<br />
<br />
---[[User:Zaimoni|Zaimoni]] 12:39, 7 June 2006 (CDT)<br />
<br />
<br />
== Psychic Farm ==<br />
There's a sort of tactic I use which may fit into this article. It's blatant simple: building a base with a couple Living Quarters and as many <br />
Psionic Laboratories as possible, hire the entire population of a small town and get them into psionic training. There may be a pre-selection for soldiers with appalling stats. I don't know what happens to veterans, but in my games by the time I get Psionic Labs money is not a constraint anymore, so I find this industrial breeding quite viable. What do the savvy say about this?--[[User:Trotsky|Trotsky]] 02:40, 11 July 2006 (PDT)<br />
----<br />
Hiya Trotsky,<br />
<br />
That's what I do. You might want to see my info on [[Raw_recruit_statistical_likelihood|recruit statistics]] and [[Hiring/firing]] (esp. the last bullet under General Info). If you get the full 1,000 recruits per month, about 50 will have psi strength of 95+. Taking other stats into consideration, one or two dozen will be top-notch recruits. <br />
<br />
I only have 2 or 3 actual combat squads. One of my less-busy bases serves as initial receiving for batches of ~100 (no psi labs needed), and other un-busy bases get the recruits who made the initial cut farmed out to them, for psi evaluation (lots of psi labs needed).<br />
<br />
FWIW I have an applet that reads a savegame; I run it when a new batch of recruits shows up, and it prints out who to keep based on a prioritization. It's ordered by base and soldier names at that base so I go directly to Sell/Sack and dump the ones that didn't cut it, without needing to look at their stats in the game. Then those guys move on to your "psychic farm" bases for psi evaluation. Before I wrote the applet, I would stick a little plus sign next to the names of the guys to keep as I reviewed them in the Soldier Stats screen, so I'd know who to Sack.<br />
<br />
Because you can only have 250 soldiers max, and some are devoted to combat or other duties, depending on how you draw the line on initial recruit stats (and how hard you want to work at it), plus the fact that psi results only come up at the end of the month and you need to have the next batch on hand for next month's evaluation... this all means that there's actually only ~100 noobs undergoing psi evaluation on any given month. Also, the number of new recruits you order in batches goes down from the beginning of the month to its end, since you only have a window of ~100 to work with initially. At least, that's how it works for me.<br />
<br />
If I run a game a long time, over time what happens is that the bar for psi strength in my 2-3 active combat crews rises over time. Each month, the few high-psi recruits push a few vets below the bar. The best of these vets are farmed out to lesser bases, in case of attack. Of course, any of us could've won long before this point; we're playing just for the joy of play.<br />
<br />
Despite all the above, if a soldier has good psi strength, almost anybody can become a superman, given enough [[Experience#Soldier_Advancement|combat]]. The difference between the worst recruit and the best is only about a dozen combats (assuming they can get 3 actions for firing and reaction each combat).<br />
<br />
---[[User:MikeTheRed|MikeTheRed]] 16:14, 11 July 2006 (PDT)<br />
:I see people creating scripts and stuff to analyse the game files to know who to sack, psi training hundreds of soldiers to finally only keep 2 or 3 guys... All of this is time consuming at best. Why don't you just hex-edit the games file to improve the soldiers? Or hack the game to always show the psi strength, or generate only ubersoldiers? Yeah this would be cheating. But screening 1000 soldiers a month... [[User:Seb76|Seb76]] 03:20, 25 May 2008 (PDT)<br />
<br />
== Suggestions for Psi Defence ==<br />
<br />
The first aim on missions is to pick off as many aliens as possible without them sighting you. With luck you can break their morale before you get a single psi-attack. Once a soldier is seen the aliens will often, but not always, pick off your weakest soldiers mercilesly (I've had a soldier with 83 strenth panicked as the sole attack during a mission, strangely). The second aim is to get your vulnerable soldiers disarmed so they can soak up all the psi-attacks harmlessly. You can do this by getting soldiers to drop everything when they return to your control, making sure weapons are stored on the ground instead of in hand, or stunning and reviving soldiers. Killing a soldier under alien control will only result result in another soldier being targetted. As you can't keep all your soldiers harmless all the time you should use all available cover to make sure that your troops cannot see each other. This reduces the damage if a soldier gets controlled. Don't use explosive weapons. Don't hold primed grenades between turns. Don't use proximity grenades close to your troops and clear any when soldiers panic in their direction. <br />
<br />
Once a mission is completed you can rename the soldiers to record their Psi capability. I'd stick an X on their name, say, for poor defence. Soldiers which look like they have good Psi strength can be marked for training. Soldiers with poor defence will be no use in Cydonia so they can be sacked, used as scouts, or used as decoys on later Psi missions.<br />
<br />
On Psi-attack, I think it's worth mentioning that if you stun an alien while it is under mind control then it will not be captured at the end of the mission. I have lost a commander this way.<br />
<br />
- Egor<br />
<br />
<br />
Xconman...<br />
<br />
Is this how you add your 2cents? I've been playing xcom since PS1. I loved it but hated the load time on it. The PC version was faster but somehow not as good. Anyway, I've found the most successful preventive tactic vs psionics is to not bunch your troops together. If an alien sees you and you don't kill it that turn, it's a sure bet someone will be controlled. (someone may be controlled anyway but it cuts the result by at least half) I've played the game so much the tactical aspect is predicable (so easy) for me except when you have powerful psionics against you so I started to send out 2-3 man squads (spaced apart) toward the target and the rest of my squad spread to the 4 corners of the map. As troops die you send in one or two more troops. I've found that I hardly recieve psionic attacks when I approach the enemy this way.<br />
<br />
<br />
Xconman...<br />
<br />
This is a cheat. On Psionic farming. Create a univeristy base devoted to psionics, say 100 students. Forward the game by not attacking and ignoring everything. See the results of the troops and copy down their names. Restart a day later and expell all "failures" and hire the amount of students equal to vacant spaces. Repeat as often as you have (time) no life for. lol<br />
I've found the cpu registers the psionic power/skill when the charcter is created and not when the month is up. I've had 37 characters with 100 ps str this way in 3 game months. (it took 5 hours off my life though...)<br />
<br />
: You might want to use colons : to indent your paragraphs. Putting a space in front of it is the shortcut for preformatted text - and that has a tendency to look unpleasant depending on your screen settings. Also you can sign your posts by entering four tildes <nowiki>~~~~</nowiki> rather than head it with your username. <br />
<br />
: When a new recruit is hired, psi skill is set to 0, while psi strength is a random roll from 0 to 100. So yes, the strength level is predetermined the moment the soldier is hired. The game only reveals the psi strenth stat when the psi skill stat is greater than 0, which is where the first month in the labs comes in. <br />
<br />
: With a bit of code diving, we've confirmed the 20 turn grace period and the 2-remaining alien condition before psionics are launched. But have we done so with the visual aspect of it? -[[User:NKF|NKF]] 02:01, 25 May 2008 (PDT)<br />
<br />
::NKF: No, seems I somewhat jumped the gun on that one. For what it's worth, I've noticed that the AI gets smarter after about turn 20(what with the noted leaving of the UFO and stalking of your units) as well as a smart AI when only a handful of aliens survived the crash. (This may well be why I've had the lone alien from the small scout ambush my troops on more than one occassion; he knows where they are at all times.) Just my theories. [[User:Arrow Quivershaft|Arrow Quivershaft]] 03:24, 25 May 2008 (PDT)<br />
::The code dig was not related to psi attacks in particular. The game sets the visibility flag to 1 for all XCOM units in the 2 cases you mentionned, no more no less. [[User:Seb76|Seb76]] 03:42, 25 May 2008 (PDT)<br />
::Edit: I did a quick check: the game does not seem to test the visibility flag when searching for a target! If you patch offset 0x469B in the CE edition from 0x02 to 0x03, it _might_ test for it. Feel free to test... [[User:Seb76|Seb76]] 03:57, 25 May 2008 (PDT)<br />
<br />
----<br />
<br />
First of all, I'm a new player, and I've found this website indescribably helpful. Thanks a lot! I have a question about psionics. I'm playing the Steam version, and psionics is not turning out to be the game-breakingly-powerful weapon I've heard it described as. I can never seem to MC more than 1 alien 1 time during a mission. Even a Psi Strength 99 soldier can't grab Sectoid Solders with any reliability. I chalked it up to lack of skill, but find that 1 of the first half-dozen attempts for a single battle works great, and then it never works again. And I have NEVER seen any of my soldiers gain increased Psi Skill, though apparently it's supposed to go up like crazy. I've observed the same phenomenon in TFTD. Am I doing something wrong? I assumed MC was incredibly unreliable, but I don't even bother to use what's supposedly the most powerful ability in the game. And man, I could use it in TFTD right now, that game is rough... <br />
<br />
Thanks a lot, I really appreciate the time you guys put into this.<br />
<br />
--[[User:wfames|wfames]] 2:38, 19 Jan 2009 (EST)<br />
<br />
:Hiya wfames, welcome to the UFOpaedia! Any and all questions or contributions welcomed.<br />
:It sounds like something is definitely wrong. Please see [[Experience#Primary_Stats]]. Even if every Psi attempt fails (MC or Panic), if you try at least 11 times with any one soldier, that soldier's Psi Skill ''must'' go up by 2-6 (average 4) per combat. And a successful attempt counts as 3 tries, so you only need 4 successes to have Psi Skill go up by 2-6. But you're not seeing this? This could be a major problem, if Steam is providing a broken game (and maybe GamersGate too - wouldn't be surprised if they're both selling the same package).<br />
:A problem with the half-dozen of us diehards here (although we pray for many more) is that we have a ton of editors, utilities, and X-COM variations tied into our existing X-COM stuff. So we're hoping, of course, that the new bundles are "same old stuff, no problem". If they're not, it's a can of worms ... we'd have to buy something we already own (perhaps multiple copies of), put it somewhere new, test it out for days or weeks. So this is a black news post you made (or at least, it sounds like one). But hey, we're here to help. :)<br />
:If you don't mind, pop over to [[GEOSCAPE.EXE#X-COM_Complete_Packages]] and make a new "review". Also use the Talk page link there. For the moment, it will probably be better to have any problems or questions in one place (to see if others have the same questions or problems)... later we can diffuse them out to the wiki in general, once we get a feel for whether there are real problems we can nail down and/or easy fixes, etc.<br />
:Thanks again for dropping by. Please come back any time! -[[User:MikeTheRed|MikeTheRed]] 03:58, 19 January 2009 (CST)<br />
<br />
:: What psi skill levels have the soldiers got? Even if their strength levels are high but if the skill levels are low then you won't be getting very frequent successes. You'll want to put several missions worth of psi attempts under your belt before you can really start to hammer the aliens with the good stuff. If you've got a handy alien base nearby, you can send a team of psi troopers there, panic the first alien you see to bits, dust off, check your stats and then repeat the process over and over until you are good enough to use mind control. I recommend the panic attack as it has the highest success probability of the two attacks, and you can have everyone panic the same alien in a single turn - which can't be done with mind control if it succeeds. -[[User:NKF|NKF]] 22:55, 19 January 2009 (CST)<br />
:Good point, NKF. I assumed he'd played a lot, but should have asked. wfames, are you getting Psi to work yet? Your soldiers' Psi skill will increase ~4 points for every combat, if they make at least 11 unsuccessful or 4 successful Psi actions per combat (the [[Mind Probe]] doesn't count). See some [[Psionic_Equations#X-COM_Vs._Aliens|cool numbers I generated]] for a solid handle on when you should be MCing aliens relative to Psi Skill. -[[User:MikeTheRed|MikeTheRed]] 18:31, 23 January 2009 (CST)<br />
<br />
<br />
=== Possibly buggy tactics ===<br />
<br />
2 tactics that may or may not lead to glitches are:<br />
<br />
1) Stunning the mind controlled soldier.<br />
<br />
2) RE- Mind controlling the mind controlled soldier.<br />
<br />
Both of these tactics have unconfirmed rumors of resulting in permanent mind control by the aliens.<br />
<br />
== How a tiny bunch of human civilians beat the aliens at Psionics ==<br />
<br />
Much as I enjoy getting my *ss kicked in X-COM and thus "losing my favourite game", I sympathise with the aliens because they know exactly how I feel. After all the aliens invented Psionics, millions of years ago, built their society around it, presumably optimised their genome as well since they are masters of DNA, and we come along with no prior knowledge and no genetic mastery and hand them their 'nads, using their own pride and joy, Psionics, in a few short months. While a similar point could be made about plasma weapons and UFOs, this astounding fact still begs a little explanation. <br />
<br />
A similarly perplexing question is why X-COM, first and last line of defence of planet Earth, has extremely low field manpower, both initially and long term, and is staffed exclusively with rookies who appear to have no prior combat experience. Surely the world's most powerful governments would be only too willing to put at least some of their elite special forces at the disposal of X-COM - in their own self interest of course? But if you look at the skill gain curves of X-COM operatives, it's clear that these are true rookies. There is nothing odd going in during the Alien Wars that would explain massively accelerated skill growth for already-expert special operations forces (except in the Psi area of course). We have to conclude that X-COM rookies are exactly that, rookies, maybe with basic training but no more. And their initial ranks reflect that. <br />
<br />
Here is a non-canonical background suggestion that ties these two anomalies together neatly. Posit this: initial responses to the alien threat, national forces such as the Kiryu-kai, drew heavily on national military special forces. Initial contact with aliens was a total disaster, massively counterproductive, due to alien use of Psionics. Even without overt use of Psionics against them, military operatives in the field against aliens were overcome by Psionic 'noise', panicking and berserking. Their resistance to direct attack was effectively nil in almost all cases. Hence the advanced military skills of these first extraterrestrial defence units were turned against them, causing grievous destruction in the teams, and perhaps worse. (Perhaps in one or more instances, entire teams of heavily armed mind-controlled elite commandos were flying low, under radar, heading directly for the Kremlin or Diet or White House, and were only stopped by the drastic intervention of air force units).<br />
<br />
The secret knowledge of aliens possessed by some of the CFN governments significantly pre-dates what XCOM troops on the ground would later learn. Knowledge of the aliens and their psionic potential was a closely held secret within need-to-know groups like MJ-12 in the United States for decades prior to the First War. Analysis of the initial tactical failures suggested that defensive psionic screening was a priority by far outweighing any combat ability or military discipline. As a pre-requisite, the entire field force of X-COM would need to be assembled from individuals who had at least basic Psionic resistance. In these days the idea of Psi Lab screening was at best a hypothesis. However, decades of investigations by MJ-12, in the years after Roswell, had identified a genetic component to Psi resistance. A relatively simple DNA test could identify a tiny proportion of the human population who had the potential, at least, to resist alien Psionics - to varying degrees which could not be further tested except under field conditions. But at a minimum, the DNA test selected the very rare individuals who who not succumb to 'ambient' Psionic fields and would at least require a directed attack by an alien. Perhaps genetic testing of the few special forces soldiers who had put up any resistance helped to confirm the validity of the DNA screening. It turns out the distribution of the rare resistant individuals cut across race and gender, but did to a surprising extent reflect the major players in the CFN and even the apparent major target regions of the alien incursion itself. These very rare individuals, who overwhelmingly were untrained civilians, were inducted into X-COM and rushed through basic military training as quickly as they could be identified. <br />
<br />
Putting this in the context of the later mythos evolved in X-COM Apocalypse: What if all X-COM operatives in the First and Second Alien Wars are secretly a type of human-sectoid hybrid? Unknown to themselves and all but a few others in the highest reaches of the XCOM hierarchy, or possibly entirely unknown to human governments, who believe these individuals are just rare human mutants. In fact, a plausible explanation would be that a rebel Sectoid faction, identifying potential with the human DNA at least for the perpetuation of the barren Sectoid species, and perhaps for a new biological weapon to throw off the yoke of the Ethereals once and for all, began introducing Psi-capability genes into human DNA from the earliest contacts - Roswell or earlier. <br />
<br />
Whether the decision to recruit exclusively from hybrids was known to X-COM or the CFN at the time of the First or Second Wars, by the time of Apocalypse, the presence of hybrids in the population was well known and such an openly racist recruitment policy could not be pursued. And of course in the time of Apocalypse we see that 'pure' humans are weak or at very best mediocre Psi operators, and that it is X-COM's hybrids who excel - provided of course they are equipped with artificial psi amplifiers to compensate for what is presumably a deficit of raw psi energy, but no deficit of will or talent once the energy problem is artificially solved. All of which simply suggests that Psi Amps may have been a technological 'plant' by rebel Sectoids or hybrids working within X-COM, secretly assisting. <br />
<br />
All pure speculation of course. In fact, anyone considering such things is clearly delusional, a danger to society, and should be confined for the safety of themselves and others. Come this way sir, please don't make a fuss, it will be much easier if you just... look... into... my... MIND...<br />
<br />
[[User:Spike|Spike]] 12:05, 23 October 2012 (EDT)</div>
Spike
https://www.ufopaedia.org/index.php?title=Talk:Psionics&diff=40234
Talk:Psionics
2012-10-23T16:08:46Z
<p>Spike: /* How a tiny bunch of human civilians beat the aliens at Psionics */</p>
<hr />
<div>Just had a thought on the formula!<br />
<br />
What if the "Psionic Combat Strength" formula was a''' ' + ' '''rather than a''' ' * ' '''?<br />
<br />
It would mean the example Soldier would have a PCS of 111, rather than 1520, and the defending Muton would have:<br />
<br />
Panic Chance = 76%<br />
MC Chance = 56%<br />
<br />
These numbers seem more reasonable, don't you think?<br />
<br />
--[[User:Danial|Danial]] 15:32, 19 Nov 2005 (PST)<br />
----<br />
Right, it sounds '''much''' more reasonable now. My actual results were 1192 successes out of 2420 tries = 49.26% success rate. The MCer was right next to MC victim, and we know distance introduces ''some'' kind of decrease to base chance. That's the good news. The bad news is that I also tested psi str 95, skill 44 (and some higher skill levels) and never failed to MC ''once'' with these better MCers. Using your revision, a psi str 95, skill 44 guy should have had a success rate of 84% vs. a beginner Muton soldier (psi str 25, skill 0), not 100%. My higher-skill guys were also right next to their MC victims. So, to me the first example makes sense relative to your idea (fits base chance, plus a little distance adds a little more), but the second example counters it.<br />
<br />
Still, it sounds WAY better than 1500% :)<br />
<br />
I sure wish psi testing wasn't so labor intensive. I got those 2400 counts doing all that experience testing... not interested in doing it again, just for psi equations. At least not at the moment. :P ---[[User:MikeTheRed|MikeTheRed]] 21:12, 23 Nov 2005 (PST)<br />
----<br />
Question: why is the Sectopod's psionic resistance listed as N/A? I've mind-controlled sectopods (or at least one square of a sectopod) on many occasions. I usually have it shoot itself, since it can target one of its other, non-MC'ed squares. From my anecdotal experience, their psi resistance seems somewhat high. --[[User:Papa Legba|Papa Legba]] 14:19, 2 February 2006 (PST)<br />
----<br />
Answer: If you look on the alien summaries in the wiki they all have a PSI resistance listed, except the Sectopod. Since it's not listed anyplace I put N/A. Feel free to put it where it belongs in the list if you have enough experience to feel comfortable ranking it. --[[User:Darksun|Darksun]]<br />
----<br />
Darksun, I took the liberty of signing your name for you, and making a separator line. Why not say a word about yourself under [[User:Darksun]] and also, use four dashes (----) to demarcate entries. For more on the basics of wiki'ing, see NKF's "Community Portal" at the bottom of the homepage. Past all that - welcome, fellow XCOMMIE! We were all wiki noobs once. But not everybody loves XCOM. You must. Welcome aboard!<br />
<br />
Proceeding right along to flagellating, laugh - Where are you folks talking about Sectopod psi resistance being "N/A"? I see their Psi Strength as 100, and their Psi Skill as 0 at Beginner; Psi Strenth 116 and Skill still 0 at Superhuman. In this respect, they match Cyberdisks. What do you folks mean by Psi "resistance"? Do you know the math behind the psi equations? I haven't been able to figure it out. But the stats I just listed are ones hacked out of the game... Zombie is going to present a full precis' some time soon.<br />
<br />
Great speaking at ya ... keep on contributing, Darksun!! --[[User:MikeTheRed|MikeTheRed]]<br />
<br />
== Alien psionic resistance ==<br />
<br />
I haven't tried mind-controlling Cyberdiscs much, but if, as I've read elsewhere, both Sectopods and Cyberdiscs have have a Psi Strength of 100, they should probably both be classed "extremely high".<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 10:30, 4 May 2006 (PDT)<br />
<br />
== Psionic testing ==<br />
<br />
I started doing some testing to figure out the psionics formula. <br />
<br />
Initial finding: ''distance'' takes the hypotenuse into account. I'm not sure if the actual Pythagorean formula is used, but I can say this much: an Ethereal was able to panic a moderately-psi-weak soldier at 30 squares along the horizontal but not at 30 squares along the diagonal.<br />
<br />
Second finding: the difference in "difficulty" between MC and panic is definitely 20 points (although that may not be percent). A soldier with 97 Psi strength, 0 Psi skill standing adjacent to an Ethereal Leader (60 str/45 skill) could not be panicked at all, but 96 Psi str could (often). The same soldier with 77 Psi str couldn't be mind-controlled, but could at 76 Psi str. ''With further testing, I see that 60/45 vs. 97 should succeed occasionally; I might retest this for greater precision, although the +20 still seems to hold.''<br />
<br />
Third finding: A soldier with 99 Psi str/0 skill could ''just barely'' be panicked by an adjacent Ethereal with 63/45. I couldn't count how often the Ethereal succeeded, but it was something like 1%-2% of the time. The same soldier was panicked just as infrequently by an Ethereal with 45/63 (str & skill reversed), and much more often by an Ethereal with 54/54. This pretty strongly suggests the attack portion of the formula involves psi str & skill multiplied together.<br />
<br />
Data points collected so far:<br />
*Ethereal, 63/45, just barely panicked soldier, 99/0<br />
*Ethereal 40/40 just barely panicked soldier 75/0<br />
*Ethereal 27/27 (multiplied together = 729) just barely panicked soldier 57/0<br />
*Ethereal 10/73 (multiplied = 730) just barely panicked soldier 57/0<br />
**''this confirms that attacking is based on str*skill<br />
*Ethereal 18/18 just barely panicked soldier 49/0<br />
*Ethereal 1/1 just barely panicked soldier 43/0<br />
*Ethereal 1/1 just barely panicked soldier 1/210<br />
**''this confirms Psi skill / 5 is used in calculating defense; 1 + (210/5) = 43''<br />
<br />
I also tested Ethereal 0/1 (no psi str, 1 pt. skill); it still attacked, but did not attack at 0 pts. skill no matter how high psi str was (no surprise there, otherwise all units would do psi attacks).<br />
<br />
I ran the points through a curve-fitting program and got a nice and simple answer:<br />
<br />
attack strength = psi str * psi skill '''/ 50'''<br />
defense strength = psi str + (psi skill / 5)<br />
<br />
Panic Attack chance = 44% + attack strength - defense strength<br />
Mind Control Attack chance = 24% + attack strength - defense strength<br />
<br />
The formula has held up under limited further testing; I'm satisfied it's correct. I invite others to test it more than I have.<br />
<br />
The impact of distance has yet to be tested, but it should be easy to figure out now.<br />
<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 22:03, 26 May 2006 (PDT)<br />
<br />
----<br />
<br />
There is a reasonable approximation to the Pythagorean formula (in the plane) that could have been used, that doesn't require loops or floating-point math:<br />
<br />
max( | &Delta;x | , | &Delta;y | ) + &frac12;min( | &Delta;x | , | &Delta;y | )<br />
<br />
where &Delta;_ := _<sub>2</sub> - _<sub>1</sub>.<br />
<br />
It overestimates slightly. I haven't thought through how this would generalize to 3D. [Yanked from Moria, Angband, and variants...think it's too basic to copyright, though.]<br />
<br />
One way to test whether the distance estimator is no greater than true Pythagorean formula by working out the greatest distance (pure x or pure y) that MC/Panic is not 0%, then testing on a diagonal with a "computed same". An integer-math overestimator (like the above) would by 0%.<br />
<br />
Muliple of 5 allows replacing the diagonal with a suitably scaled 3-4-5 triangle...should work as well for testing.<br />
<br />
--[[User:Zaimoni|Zaimoni]] 2:38PM, 26 May 2006 (CDT)<br />
<br />
----<br />
<br />
Wow... good approach to teasing this out, Ethereal!<br />
<br />
Am I doing this right? I plugged in numbers for Muton, 25/0, Me 95/44, and got 83% MC Base Chance... But in much repeated testing (when learning about experience counters) it seemed quite solid that I was MC'ing him about half the time. Say 45-55% of the time. This was when right next to each other. Is 83% right for your equations?<br />
<br />
Zaimoni, re: your equation, see [[Explosions#Distance_from_Ground_Zero]]. XCOM seems to use a fairly simple approach that doesn't involve Pythagoras per se. Since it's based on a very old engine, much of its stuff is integer based. Cool deal on the deltas and other wiki symbols - I wish I knew about them sooner! Actually I know where wiki symbol tables are... just didn't bother to look up so many symbols. :P<br />
<br />
Nobody has tackled 3D distance yet, but I may soon, in studying illumination.<br />
<br />
Once the equations are well known (maybe they are already), I imagine some cool 3D topographical graphs of the various factors (skill and strength, you vs. enemy) could be made. Do either of you have surface graph s/w at hand? All I've got at the moment is Excel. :(<br />
<br />
Great work! Also thanks for cleaning up the page in general, Eth.<br />
<br />
---[[User:MikeTheRed|MikeTheRed]] 22:24, 2 June 2006 (PDT)<br />
<br />
----<br />
<br />
I suspect you've misremembered the details of your tests. The 49.26% success rate out of 2400 trials that you quote above would have been for your 95/16 soldier doing panics, not MCs: 44 + [95*16/50 = 30.4] - 25 = 49.4%, almost exactly the same as your 49.26%. A 95/44 doing panics would always succeed: 102.6%. A 95/44 doing MCs would succeed 82.6% of the time.<br />
<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 11:06, 3 June 2006 (PDT)<br />
<br />
----<br />
<br />
Ah, there's that data. Thanks for reminding me. I can't remember what I put in which discussions and was going to dig it out of my db. <br />
<br />
No, it was MCs. Indeed I relied on the lack of seeing an enemy, if I got moving too fast and couldn't remember if I successfully MC'd. Attention starts to wander with such highly repetitive testing. This was before I realized the following...<br />
<br />
Anyone doing repetitive psi testing can readily and accurately get the number of positive results from the [[UNITREF.DAT]] Psi byte [84] if you work it right. Note the turn you start psi attempts. Then do exactly 2 or 3 psi Attempts each turn, as your TUs allow. Then note the turn you stop and get the delta. Turns x Attempts/Turn = Attempts. A failed psi attempt adds 1 to [84] and a successful attempt adds 3, so the number of successes is: ([84]-Attempts)/2. Be careful during testing marathons because the byte wraps around at 255 (=85 straight successes, or 28.3 turns at 3 successful attempts per turn). Then it starts counting again so actually even this can be dealt with by adding 255 if you're on top of it. If anybody wants an applet that shows Unitref experience values on the fly, let me know. It's great for building experience. Right now it's embedded within my mdb though... I'd have to tease it out.<br />
<br />
I'm using XCOM DOS which I once ran XcomUtil on, if that matters. <br />
<br />
Hmm.<br />
<br />
---[[User:MikeTheRed|MikeTheRed]] 12:21, 3 June 2006 (PDT)<br />
<br />
----<br />
<br />
Distance...ok, no reason for the game to use multiple 2-d distance formul&aelig;.<br />
<br />
I have software set up to render 3D graphs. Is there anything on the site that jumps out as "would like to see first"? I'd rather wait until the psi formul&aelig; are calibrated first before graphing those.<br />
<br />
Ethereal: What I see posted is test data for ethereal MC human. Do you have test data for human MC ethereal as well? [That would test whether the game calculations are symmetrical.]<br />
<br />
---[[User:Zaimoni|Zaimoni]] 2:37, 3 June 2006 (EDT)<br />
<br />
----<br />
<br />
It ''is'' possible X-COM units get a different formula from aliens -- I only tested an alien doing psi, as it was more automated -- the thing would psi without my having to control it.<br />
<br />
I'm not not volunteering to test x-com units for the time being -- it's a bit more laborious -- but if I ''had'' to test it, I'd do a small number of trials of 35/16, 50/51, and 100/51 soldiers trying to MC (not panic) an adjacent Muton, which should succeed 10.2%, 50% and 101% of the time.<br />
<br />
Feel free to test it before I do. ;-P<br />
<br />
Oh, and nice work on the flares, Mike.<br />
<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 12:50, 3 June 2006 (PDT)<br />
<br />
----<br />
<br />
Sounds cool, Zaimoni... As for "like to see",<br />
<br />
Once my troops have psi ability, I try to get 90+ psi strength guys. Then the question becomes "at psi str 90, at what psi skill point are most/all aliens certain to be MC'ed?" In my experience, it's somewhere around skill 40-60... Anything that might show this, or show how you fare relative to aliens at, say, STR 90, is something I've always wanted. However it might be done. In one sense you could simply plug the "worst" psi alien (Ethereal CDR?) into Eth's equations to get the final answer. But it'd be good to see the lay of the land.<br />
<br />
If you make the simplifying assumption that many of your targets are psi skill 0, there's one less variable. Additional graphs can be done later just for the psi-capable aliens... first things first though...<br />
<br />
Taking the above into consideration, then, XCOM Psi Skill (Str=90) vs. Alien Psi Strength (Skill=0) vs. Success rate is one 3D graph that could be made. If you can do a 4th dimension as color, you could replace the Success rate axis with XCOM Psi Str, then have color indicate success rate, from primary red for "no way" through yellow for "sometimes" to primary green for "always". Or something like that. It'd also be nice but not critical to have annotations for where various aliens lie along their dimension. I can supply this info if you want. Which reminds me: Eth, Zombie and others found some errors in Aztec's table (which came from the OSG). Just a few percent of them, but they're definitely there (I can't remember where). I've hacked alien stats straight out of GEOSCAPE... see the alien stats page. I believe Zombie has found these to be correct, but he has not yet given the final word.<br />
<br />
Zai, as far as I'm concerned, you can model using EC's equation already, if you have the time... I'm sure his equations are very close, if not spot on, and even if not, it may show key places to test and otherwise support further testing. E.g., both aliens and XCOM can readily have their relevant values hacked to test for boundary conditions of 0% and 100% success. Plus once it's set up it shouldn't be hard to tweak the equation and voila, the graphs update. But if you don't have the time - eh, it's all volunteer work anyway.<br />
<br />
Eth, I suppose it's possible aliens vs. humans is different. They are known to have some differences in functionality, such as night vision. I don't know if I'll be able to test, but it definitely intrigues me. BTW I said somewhere else that I was looking into automating the XCOM interface in order to do psi testing. I have concluded that I can't do it. At least not the way I was hoping to. Oh well. Still, my belated realization that one can use Unitref[84] to count psi successes is a real boon to repetitive testing. So we'll see. Thanks for suggestions on what to test if I do. By the way, did I do that 83% correct? I just want to make sure I'm doing the math right.<br />
<br />
Thanks re: the flares!<br />
<br />
---[[User:MikeTheRed|MikeTheRed]] 21:08, 3 June 2006 (PDT)<br />
<br />
----<br />
<br />
The influence of distance still needs to be tested, although it doesn't seem to be an enormous factor. Rather than a complicated graph, I think a few charts with distance = 1, 10 and 20 would probably tell the story more clearly. The distance formula might even prove to be something really simple, like +1 distance = -1% chance.<br />
<br />
The hardest aliens to MC are Sectopods and Cyberdiscs: look at the [[Psionics#Summary_of_Alien_Psionic_Resistance]] section I added. At distance 1 on Superhuman you'll need 93 to 192 Attack Strength to achieve 1% to 100% chance. Assuming Psi Str 90, that's Skill 52 to 107.<br />
<br />
Now vs. the strongest attacker: Superhuman Ethereal Commander, attack str 88. You'll need a Resistance of 132 to be totally immune to panics from one adjacent to you -- that's str 100, skill 160, or str 90, skill 210. Against MC, it's str 100/skill 60 or str 90/skill 110. In practice you won't be right next to them, so you can probably go a bit lower. They'll focus on the weakest soldiers anyhow, which in practice means a couple of decoys in with some supertroopers is a good strategy.<br />
<br />
82.6%, yes.<br />
<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 21:51, 3 June 2006 (PDT)<br />
<br />
OpenOffice.org is CPU-bound when converting the graph from 2D to 3D. [XCOM Psi Str/Sk 90/0-107, alien Psi Str/Sk 25-116/0; I'm on a 1GHz Pentium III/512MB] Not sure how ColdFusion single-IP demo would do yet (would have to reinstall), but the UI options look better in OpenOffice.org.<br />
<br />
I'll attempt the transition later today (when I know I'll be away from the system and positively not working). I just need to be able to take a screenshot.<br />
<br />
You probably already noticed this: even if a bug permitted a 0 Psi Skill operative to use a Psi Amp, the success chance of MC is still negative.<br />
<br />
Also (thinking about the testing anomaly MikeTheRed had): The floating-point change in success rate from an increase of 1 in Psi Skill is 1.9 at 95 Psi Str. Integer truncation would make this 1...leaving the floating-point formula overestimating by 39.6%. At the precision of reporting, this works.<br />
<br />
[Edit: but does *not* work against the initial regression. So, no good.]<br />
<br />
---[[User:Zaimoni|Zaimoni]] 9:51, 4 June 2006 (CDT)<br />
<br />
Got a chance to run the bar graph this morning...no go, OpenOffice.org doesn't like a horde of data points on both axes. <br />
<br />
But...this particular graph is essentially a plane. It should be hand-drawable, even if the more complicated ones aren't.<br />
<br />
---[[User:Zaimoni|Zaimoni]] 8:35, 5 June 2006 (CDT)<br />
<br />
----<br />
<br />
Hi Zaimoni... I'm not sure I understand the differences you talk about. You mean you can get your s/w to make a graph where you've specified the points by hand? Anyway, if you take a shot at most anything, we'd be able to give feedback... a picture's worth a thousand words. Thanks for working on it! ---[[User:MikeTheRed|MikeTheRed]] 06:36, 5 June 2006 (PDT)<br />
<br />
Somewhat. Layer 1 of the spreadsheet is the raw data to be graphed (took about five minutes to set up). If I was going to commit to this representation, I'd go back and make the XCOM Psi Str and Alien Psi Skill configurable. So it's trying to graph data points (the MC success chances) on 0-107 by 25-116. I was planning to rotate the view after getting the initial graph up on Layer 2. [Time loading is not favorable for working further on this today.]<br />
<br />
OpenOffice.org's autoscaling isn't compensating properly. I haven't checked how to suppress the "color key" that was auto-generated for Alien Psi Str &mdash; it's not leaving enough space for the vertical bars to even be 1 pixel in size. The result is decidedly flat, with "correct" vertical range.<br />
<br />
As a bar graph, I could get away with subsampling (but don't have a clean way to do it). Yes, it should be possible to correctly graph this (as a plane in three-dimensional space) with only four data points: the corners.<br />
<br />
---[[User:Zaimoni|Zaimoni]] 12:39, 7 June 2006 (CDT)<br />
<br />
<br />
== Psychic Farm ==<br />
There's a sort of tactic I use which may fit into this article. It's blatant simple: building a base with a couple Living Quarters and as many <br />
Psionic Laboratories as possible, hire the entire population of a small town and get them into psionic training. There may be a pre-selection for soldiers with appalling stats. I don't know what happens to veterans, but in my games by the time I get Psionic Labs money is not a constraint anymore, so I find this industrial breeding quite viable. What do the savvy say about this?--[[User:Trotsky|Trotsky]] 02:40, 11 July 2006 (PDT)<br />
----<br />
Hiya Trotsky,<br />
<br />
That's what I do. You might want to see my info on [[Raw_recruit_statistical_likelihood|recruit statistics]] and [[Hiring/firing]] (esp. the last bullet under General Info). If you get the full 1,000 recruits per month, about 50 will have psi strength of 95+. Taking other stats into consideration, one or two dozen will be top-notch recruits. <br />
<br />
I only have 2 or 3 actual combat squads. One of my less-busy bases serves as initial receiving for batches of ~100 (no psi labs needed), and other un-busy bases get the recruits who made the initial cut farmed out to them, for psi evaluation (lots of psi labs needed).<br />
<br />
FWIW I have an applet that reads a savegame; I run it when a new batch of recruits shows up, and it prints out who to keep based on a prioritization. It's ordered by base and soldier names at that base so I go directly to Sell/Sack and dump the ones that didn't cut it, without needing to look at their stats in the game. Then those guys move on to your "psychic farm" bases for psi evaluation. Before I wrote the applet, I would stick a little plus sign next to the names of the guys to keep as I reviewed them in the Soldier Stats screen, so I'd know who to Sack.<br />
<br />
Because you can only have 250 soldiers max, and some are devoted to combat or other duties, depending on how you draw the line on initial recruit stats (and how hard you want to work at it), plus the fact that psi results only come up at the end of the month and you need to have the next batch on hand for next month's evaluation... this all means that there's actually only ~100 noobs undergoing psi evaluation on any given month. Also, the number of new recruits you order in batches goes down from the beginning of the month to its end, since you only have a window of ~100 to work with initially. At least, that's how it works for me.<br />
<br />
If I run a game a long time, over time what happens is that the bar for psi strength in my 2-3 active combat crews rises over time. Each month, the few high-psi recruits push a few vets below the bar. The best of these vets are farmed out to lesser bases, in case of attack. Of course, any of us could've won long before this point; we're playing just for the joy of play.<br />
<br />
Despite all the above, if a soldier has good psi strength, almost anybody can become a superman, given enough [[Experience#Soldier_Advancement|combat]]. The difference between the worst recruit and the best is only about a dozen combats (assuming they can get 3 actions for firing and reaction each combat).<br />
<br />
---[[User:MikeTheRed|MikeTheRed]] 16:14, 11 July 2006 (PDT)<br />
:I see people creating scripts and stuff to analyse the game files to know who to sack, psi training hundreds of soldiers to finally only keep 2 or 3 guys... All of this is time consuming at best. Why don't you just hex-edit the games file to improve the soldiers? Or hack the game to always show the psi strength, or generate only ubersoldiers? Yeah this would be cheating. But screening 1000 soldiers a month... [[User:Seb76|Seb76]] 03:20, 25 May 2008 (PDT)<br />
<br />
== Suggestions for Psi Defence ==<br />
<br />
The first aim on missions is to pick off as many aliens as possible without them sighting you. With luck you can break their morale before you get a single psi-attack. Once a soldier is seen the aliens will often, but not always, pick off your weakest soldiers mercilesly (I've had a soldier with 83 strenth panicked as the sole attack during a mission, strangely). The second aim is to get your vulnerable soldiers disarmed so they can soak up all the psi-attacks harmlessly. You can do this by getting soldiers to drop everything when they return to your control, making sure weapons are stored on the ground instead of in hand, or stunning and reviving soldiers. Killing a soldier under alien control will only result result in another soldier being targetted. As you can't keep all your soldiers harmless all the time you should use all available cover to make sure that your troops cannot see each other. This reduces the damage if a soldier gets controlled. Don't use explosive weapons. Don't hold primed grenades between turns. Don't use proximity grenades close to your troops and clear any when soldiers panic in their direction. <br />
<br />
Once a mission is completed you can rename the soldiers to record their Psi capability. I'd stick an X on their name, say, for poor defence. Soldiers which look like they have good Psi strength can be marked for training. Soldiers with poor defence will be no use in Cydonia so they can be sacked, used as scouts, or used as decoys on later Psi missions.<br />
<br />
On Psi-attack, I think it's worth mentioning that if you stun an alien while it is under mind control then it will not be captured at the end of the mission. I have lost a commander this way.<br />
<br />
- Egor<br />
<br />
<br />
Xconman...<br />
<br />
Is this how you add your 2cents? I've been playing xcom since PS1. I loved it but hated the load time on it. The PC version was faster but somehow not as good. Anyway, I've found the most successful preventive tactic vs psionics is to not bunch your troops together. If an alien sees you and you don't kill it that turn, it's a sure bet someone will be controlled. (someone may be controlled anyway but it cuts the result by at least half) I've played the game so much the tactical aspect is predicable (so easy) for me except when you have powerful psionics against you so I started to send out 2-3 man squads (spaced apart) toward the target and the rest of my squad spread to the 4 corners of the map. As troops die you send in one or two more troops. I've found that I hardly recieve psionic attacks when I approach the enemy this way.<br />
<br />
<br />
Xconman...<br />
<br />
This is a cheat. On Psionic farming. Create a univeristy base devoted to psionics, say 100 students. Forward the game by not attacking and ignoring everything. See the results of the troops and copy down their names. Restart a day later and expell all "failures" and hire the amount of students equal to vacant spaces. Repeat as often as you have (time) no life for. lol<br />
I've found the cpu registers the psionic power/skill when the charcter is created and not when the month is up. I've had 37 characters with 100 ps str this way in 3 game months. (it took 5 hours off my life though...)<br />
<br />
: You might want to use colons : to indent your paragraphs. Putting a space in front of it is the shortcut for preformatted text - and that has a tendency to look unpleasant depending on your screen settings. Also you can sign your posts by entering four tildes <nowiki>~~~~</nowiki> rather than head it with your username. <br />
<br />
: When a new recruit is hired, psi skill is set to 0, while psi strength is a random roll from 0 to 100. So yes, the strength level is predetermined the moment the soldier is hired. The game only reveals the psi strenth stat when the psi skill stat is greater than 0, which is where the first month in the labs comes in. <br />
<br />
: With a bit of code diving, we've confirmed the 20 turn grace period and the 2-remaining alien condition before psionics are launched. But have we done so with the visual aspect of it? -[[User:NKF|NKF]] 02:01, 25 May 2008 (PDT)<br />
<br />
::NKF: No, seems I somewhat jumped the gun on that one. For what it's worth, I've noticed that the AI gets smarter after about turn 20(what with the noted leaving of the UFO and stalking of your units) as well as a smart AI when only a handful of aliens survived the crash. (This may well be why I've had the lone alien from the small scout ambush my troops on more than one occassion; he knows where they are at all times.) Just my theories. [[User:Arrow Quivershaft|Arrow Quivershaft]] 03:24, 25 May 2008 (PDT)<br />
::The code dig was not related to psi attacks in particular. The game sets the visibility flag to 1 for all XCOM units in the 2 cases you mentionned, no more no less. [[User:Seb76|Seb76]] 03:42, 25 May 2008 (PDT)<br />
::Edit: I did a quick check: the game does not seem to test the visibility flag when searching for a target! If you patch offset 0x469B in the CE edition from 0x02 to 0x03, it _might_ test for it. Feel free to test... [[User:Seb76|Seb76]] 03:57, 25 May 2008 (PDT)<br />
<br />
----<br />
<br />
First of all, I'm a new player, and I've found this website indescribably helpful. Thanks a lot! I have a question about psionics. I'm playing the Steam version, and psionics is not turning out to be the game-breakingly-powerful weapon I've heard it described as. I can never seem to MC more than 1 alien 1 time during a mission. Even a Psi Strength 99 soldier can't grab Sectoid Solders with any reliability. I chalked it up to lack of skill, but find that 1 of the first half-dozen attempts for a single battle works great, and then it never works again. And I have NEVER seen any of my soldiers gain increased Psi Skill, though apparently it's supposed to go up like crazy. I've observed the same phenomenon in TFTD. Am I doing something wrong? I assumed MC was incredibly unreliable, but I don't even bother to use what's supposedly the most powerful ability in the game. And man, I could use it in TFTD right now, that game is rough... <br />
<br />
Thanks a lot, I really appreciate the time you guys put into this.<br />
<br />
--[[User:wfames|wfames]] 2:38, 19 Jan 2009 (EST)<br />
<br />
:Hiya wfames, welcome to the UFOpaedia! Any and all questions or contributions welcomed.<br />
:It sounds like something is definitely wrong. Please see [[Experience#Primary_Stats]]. Even if every Psi attempt fails (MC or Panic), if you try at least 11 times with any one soldier, that soldier's Psi Skill ''must'' go up by 2-6 (average 4) per combat. And a successful attempt counts as 3 tries, so you only need 4 successes to have Psi Skill go up by 2-6. But you're not seeing this? This could be a major problem, if Steam is providing a broken game (and maybe GamersGate too - wouldn't be surprised if they're both selling the same package).<br />
:A problem with the half-dozen of us diehards here (although we pray for many more) is that we have a ton of editors, utilities, and X-COM variations tied into our existing X-COM stuff. So we're hoping, of course, that the new bundles are "same old stuff, no problem". If they're not, it's a can of worms ... we'd have to buy something we already own (perhaps multiple copies of), put it somewhere new, test it out for days or weeks. So this is a black news post you made (or at least, it sounds like one). But hey, we're here to help. :)<br />
:If you don't mind, pop over to [[GEOSCAPE.EXE#X-COM_Complete_Packages]] and make a new "review". Also use the Talk page link there. For the moment, it will probably be better to have any problems or questions in one place (to see if others have the same questions or problems)... later we can diffuse them out to the wiki in general, once we get a feel for whether there are real problems we can nail down and/or easy fixes, etc.<br />
:Thanks again for dropping by. Please come back any time! -[[User:MikeTheRed|MikeTheRed]] 03:58, 19 January 2009 (CST)<br />
<br />
:: What psi skill levels have the soldiers got? Even if their strength levels are high but if the skill levels are low then you won't be getting very frequent successes. You'll want to put several missions worth of psi attempts under your belt before you can really start to hammer the aliens with the good stuff. If you've got a handy alien base nearby, you can send a team of psi troopers there, panic the first alien you see to bits, dust off, check your stats and then repeat the process over and over until you are good enough to use mind control. I recommend the panic attack as it has the highest success probability of the two attacks, and you can have everyone panic the same alien in a single turn - which can't be done with mind control if it succeeds. -[[User:NKF|NKF]] 22:55, 19 January 2009 (CST)<br />
:Good point, NKF. I assumed he'd played a lot, but should have asked. wfames, are you getting Psi to work yet? Your soldiers' Psi skill will increase ~4 points for every combat, if they make at least 11 unsuccessful or 4 successful Psi actions per combat (the [[Mind Probe]] doesn't count). See some [[Psionic_Equations#X-COM_Vs._Aliens|cool numbers I generated]] for a solid handle on when you should be MCing aliens relative to Psi Skill. -[[User:MikeTheRed|MikeTheRed]] 18:31, 23 January 2009 (CST)<br />
<br />
<br />
=== Possibly buggy tactics ===<br />
<br />
2 tactics that may or may not lead to glitches are:<br />
<br />
1) Stunning the mind controlled soldier.<br />
<br />
2) RE- Mind controlling the mind controlled soldier.<br />
<br />
Both of these tactics have unconfirmed rumors of resulting in permanent mind control by the aliens.<br />
<br />
== How a tiny bunch of human civilians beat the aliens at Psionics ==<br />
<br />
Much as I enjoy getting my *ss kicked in X-COM and thus "losing my favourite game", I sympathise with the aliens because they know exactly how I feel. After all the aliens invented Psionics, millions of years ago, built their society around it, presumably optimised their genome as well since they are masters of DNA, and we come along with no prior knowledge and no genetic mastery and hand them their 'nads, using their own pride and joy, Psionics, in a few short months. While a similar point could be made about plasma weapons and UFOs, this astounding fact still begs a little explanation. <br />
<br />
A similarly perplexing question is why X-COM, first and last line of defence of planet Earth, has extremely low field manpower, both initially and long term, and is staffed exclusively with rookies who appear to have no prior combat experience. Surely the world's most powerful governments would be only too willing to put at least some of their elite special forces at the disposal of X-COM - in their own self interest of course? But if you look at the skill gain curves of X-COM operatives, it's clear that these are true rookies. There is nothing odd going in during the Alien Wars that would explain massively accelerated skill growth for already-expert special operations forces (except in the Psi area of course). We have to conclude that X-COM rookies are exactly that, rookies, maybe with basic training but no more. And their initial ranks reflect that. <br />
<br />
Here is a non-canonical background suggestion that ties these two anomalies together neatly. Posit this: initial responses to the alien threat, national forces such as the Kiryu-kai, drew heavily on national military special forces. Initial contact with aliens was a total disaster, massively counterproductive, due to alien use of Psionics. Even without overt use of Psionics against them, military operatives in the field against aliens were overcome by Psionic 'noise', panicking and berserking. Their resistance to direct attack was effectively nil in almost all cases. Hence the advanced military skills of these first extraterrestrial defence units were turned against them, causing grievous destruction in the teams, and perhaps worse. (Perhaps in one or more instances, entire teams of heavily armed mind-controlled elite commandos were flying low, under radar, heading directly for the Kremlin or Diet or White House, and were only stopped by the drastic intervention of air force units).<br />
<br />
The secret knowledge of aliens possessed by some of the CFN governments significantly pre-dates what XCOM troops on the ground would later learn. Knowledge of the aliens and their psionic potential was a closely held secret within need-to-know groups like MJ-12 in the United States for decades prior to the First War. Analysis of the initial tactical failures suggested that defensive psionic screening was a priority by far outweighing any combat ability or military discipline. As a pre-requisite, the entire field force of X-COM would need to be assembled from individuals who had at least basic Psionic resistance. In these days the idea of Psi Lab screening was at best a hypothesis. However, decades of investigations by MJ-12, in the years after Roswell, had identified a genetic component to Psi resistance. A relatively simple DNA test could identify a tiny proportion of the human population who had the potential, at least, to resist alien Psionics - to varying degrees which could not be further tested except under field conditions. But at a minimum, the DNA test selected the very rare individuals who who not succumb to 'ambient' Psionic fields and would at least require a directed attack by an alien. Perhaps genetic testing of the few special forces soldiers who had put up any resistance helped to confirm the validity of the DNA screening. It turns out the distribution of the rare resistant individuals cut across race and gender, but did to a surprising extent reflect the major players in the CFN and even the apparent major target regions of the alien incursion itself. These very rare individuals, who overwhelmingly were untrained civilians, were inducted into X-COM and rushed through basic military training as quickly as they could be identified. <br />
<br />
Putting this in the context of the later mythos evolved in X-COM Apocalypse: What if all X-COM operatives in the First and Second Alien Wars are secretly a type of human-sectoid hybrid? Unknown to themselves and all but a few others in the highest reaches of the XCOM hierarchy, or possibly entirely unknown to human governments, who believe this individuals are rare human mutants. In fact, a plausible explanation would be that a rebel Sectoid faction, identifying potential with the human DNA at least for the perpetuation of the barren Sectoid species, and perhaps a new biological weapon to throw off the yoke of the Ethereals once and for all, began introducing Psi-capability genes into human DNA from the earliest contacts - Roswell or earlier. <br />
<br />
Whether the decision to recruit exclusively from hybrids was known to X-COM or the CFN at the time of the First or Second Wars, by the time of Apocalypse, the presence of hybrids in the population was well known and such an openly racist recruitment policy could not be pursued. And of course in the time of Apocalypse we see that 'pure' humans are weak or at very best mediocre Psi operators, and that it is X-COM's hybrids who excel - provided of course they are equipped with artificial psi amplifiers to compensate for what is presumably a deficit of raw psi energy, but no deficit of will or talent once the energy problem is artificially solved. All of which simply suggests that Psi Amps may have been a technological 'plant' by rebel Sectoids or hybrids working within X-COM. <br />
<br />
All pure speculation of course. In fact, anyone considering such things is clearly delusional, a danger to society, and should be confined for the safety of themselves and others. Come this way sir, please don't make a fuss, it will be much easier if you just... look... into... my... MIND...<br />
<br />
[[User:Spike|Spike]] 12:05, 23 October 2012 (EDT)</div>
Spike
https://www.ufopaedia.org/index.php?title=Talk:Psionics&diff=40233
Talk:Psionics
2012-10-23T16:05:13Z
<p>Spike: /* How a tiny bunch of human civilians beat the aliens at Psionics */ sign</p>
<hr />
<div>Just had a thought on the formula!<br />
<br />
What if the "Psionic Combat Strength" formula was a''' ' + ' '''rather than a''' ' * ' '''?<br />
<br />
It would mean the example Soldier would have a PCS of 111, rather than 1520, and the defending Muton would have:<br />
<br />
Panic Chance = 76%<br />
MC Chance = 56%<br />
<br />
These numbers seem more reasonable, don't you think?<br />
<br />
--[[User:Danial|Danial]] 15:32, 19 Nov 2005 (PST)<br />
----<br />
Right, it sounds '''much''' more reasonable now. My actual results were 1192 successes out of 2420 tries = 49.26% success rate. The MCer was right next to MC victim, and we know distance introduces ''some'' kind of decrease to base chance. That's the good news. The bad news is that I also tested psi str 95, skill 44 (and some higher skill levels) and never failed to MC ''once'' with these better MCers. Using your revision, a psi str 95, skill 44 guy should have had a success rate of 84% vs. a beginner Muton soldier (psi str 25, skill 0), not 100%. My higher-skill guys were also right next to their MC victims. So, to me the first example makes sense relative to your idea (fits base chance, plus a little distance adds a little more), but the second example counters it.<br />
<br />
Still, it sounds WAY better than 1500% :)<br />
<br />
I sure wish psi testing wasn't so labor intensive. I got those 2400 counts doing all that experience testing... not interested in doing it again, just for psi equations. At least not at the moment. :P ---[[User:MikeTheRed|MikeTheRed]] 21:12, 23 Nov 2005 (PST)<br />
----<br />
Question: why is the Sectopod's psionic resistance listed as N/A? I've mind-controlled sectopods (or at least one square of a sectopod) on many occasions. I usually have it shoot itself, since it can target one of its other, non-MC'ed squares. From my anecdotal experience, their psi resistance seems somewhat high. --[[User:Papa Legba|Papa Legba]] 14:19, 2 February 2006 (PST)<br />
----<br />
Answer: If you look on the alien summaries in the wiki they all have a PSI resistance listed, except the Sectopod. Since it's not listed anyplace I put N/A. Feel free to put it where it belongs in the list if you have enough experience to feel comfortable ranking it. --[[User:Darksun|Darksun]]<br />
----<br />
Darksun, I took the liberty of signing your name for you, and making a separator line. Why not say a word about yourself under [[User:Darksun]] and also, use four dashes (----) to demarcate entries. For more on the basics of wiki'ing, see NKF's "Community Portal" at the bottom of the homepage. Past all that - welcome, fellow XCOMMIE! We were all wiki noobs once. But not everybody loves XCOM. You must. Welcome aboard!<br />
<br />
Proceeding right along to flagellating, laugh - Where are you folks talking about Sectopod psi resistance being "N/A"? I see their Psi Strength as 100, and their Psi Skill as 0 at Beginner; Psi Strenth 116 and Skill still 0 at Superhuman. In this respect, they match Cyberdisks. What do you folks mean by Psi "resistance"? Do you know the math behind the psi equations? I haven't been able to figure it out. But the stats I just listed are ones hacked out of the game... Zombie is going to present a full precis' some time soon.<br />
<br />
Great speaking at ya ... keep on contributing, Darksun!! --[[User:MikeTheRed|MikeTheRed]]<br />
<br />
== Alien psionic resistance ==<br />
<br />
I haven't tried mind-controlling Cyberdiscs much, but if, as I've read elsewhere, both Sectopods and Cyberdiscs have have a Psi Strength of 100, they should probably both be classed "extremely high".<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 10:30, 4 May 2006 (PDT)<br />
<br />
== Psionic testing ==<br />
<br />
I started doing some testing to figure out the psionics formula. <br />
<br />
Initial finding: ''distance'' takes the hypotenuse into account. I'm not sure if the actual Pythagorean formula is used, but I can say this much: an Ethereal was able to panic a moderately-psi-weak soldier at 30 squares along the horizontal but not at 30 squares along the diagonal.<br />
<br />
Second finding: the difference in "difficulty" between MC and panic is definitely 20 points (although that may not be percent). A soldier with 97 Psi strength, 0 Psi skill standing adjacent to an Ethereal Leader (60 str/45 skill) could not be panicked at all, but 96 Psi str could (often). The same soldier with 77 Psi str couldn't be mind-controlled, but could at 76 Psi str. ''With further testing, I see that 60/45 vs. 97 should succeed occasionally; I might retest this for greater precision, although the +20 still seems to hold.''<br />
<br />
Third finding: A soldier with 99 Psi str/0 skill could ''just barely'' be panicked by an adjacent Ethereal with 63/45. I couldn't count how often the Ethereal succeeded, but it was something like 1%-2% of the time. The same soldier was panicked just as infrequently by an Ethereal with 45/63 (str & skill reversed), and much more often by an Ethereal with 54/54. This pretty strongly suggests the attack portion of the formula involves psi str & skill multiplied together.<br />
<br />
Data points collected so far:<br />
*Ethereal, 63/45, just barely panicked soldier, 99/0<br />
*Ethereal 40/40 just barely panicked soldier 75/0<br />
*Ethereal 27/27 (multiplied together = 729) just barely panicked soldier 57/0<br />
*Ethereal 10/73 (multiplied = 730) just barely panicked soldier 57/0<br />
**''this confirms that attacking is based on str*skill<br />
*Ethereal 18/18 just barely panicked soldier 49/0<br />
*Ethereal 1/1 just barely panicked soldier 43/0<br />
*Ethereal 1/1 just barely panicked soldier 1/210<br />
**''this confirms Psi skill / 5 is used in calculating defense; 1 + (210/5) = 43''<br />
<br />
I also tested Ethereal 0/1 (no psi str, 1 pt. skill); it still attacked, but did not attack at 0 pts. skill no matter how high psi str was (no surprise there, otherwise all units would do psi attacks).<br />
<br />
I ran the points through a curve-fitting program and got a nice and simple answer:<br />
<br />
attack strength = psi str * psi skill '''/ 50'''<br />
defense strength = psi str + (psi skill / 5)<br />
<br />
Panic Attack chance = 44% + attack strength - defense strength<br />
Mind Control Attack chance = 24% + attack strength - defense strength<br />
<br />
The formula has held up under limited further testing; I'm satisfied it's correct. I invite others to test it more than I have.<br />
<br />
The impact of distance has yet to be tested, but it should be easy to figure out now.<br />
<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 22:03, 26 May 2006 (PDT)<br />
<br />
----<br />
<br />
There is a reasonable approximation to the Pythagorean formula (in the plane) that could have been used, that doesn't require loops or floating-point math:<br />
<br />
max( | &Delta;x | , | &Delta;y | ) + &frac12;min( | &Delta;x | , | &Delta;y | )<br />
<br />
where &Delta;_ := _<sub>2</sub> - _<sub>1</sub>.<br />
<br />
It overestimates slightly. I haven't thought through how this would generalize to 3D. [Yanked from Moria, Angband, and variants...think it's too basic to copyright, though.]<br />
<br />
One way to test whether the distance estimator is no greater than true Pythagorean formula by working out the greatest distance (pure x or pure y) that MC/Panic is not 0%, then testing on a diagonal with a "computed same". An integer-math overestimator (like the above) would by 0%.<br />
<br />
Muliple of 5 allows replacing the diagonal with a suitably scaled 3-4-5 triangle...should work as well for testing.<br />
<br />
--[[User:Zaimoni|Zaimoni]] 2:38PM, 26 May 2006 (CDT)<br />
<br />
----<br />
<br />
Wow... good approach to teasing this out, Ethereal!<br />
<br />
Am I doing this right? I plugged in numbers for Muton, 25/0, Me 95/44, and got 83% MC Base Chance... But in much repeated testing (when learning about experience counters) it seemed quite solid that I was MC'ing him about half the time. Say 45-55% of the time. This was when right next to each other. Is 83% right for your equations?<br />
<br />
Zaimoni, re: your equation, see [[Explosions#Distance_from_Ground_Zero]]. XCOM seems to use a fairly simple approach that doesn't involve Pythagoras per se. Since it's based on a very old engine, much of its stuff is integer based. Cool deal on the deltas and other wiki symbols - I wish I knew about them sooner! Actually I know where wiki symbol tables are... just didn't bother to look up so many symbols. :P<br />
<br />
Nobody has tackled 3D distance yet, but I may soon, in studying illumination.<br />
<br />
Once the equations are well known (maybe they are already), I imagine some cool 3D topographical graphs of the various factors (skill and strength, you vs. enemy) could be made. Do either of you have surface graph s/w at hand? All I've got at the moment is Excel. :(<br />
<br />
Great work! Also thanks for cleaning up the page in general, Eth.<br />
<br />
---[[User:MikeTheRed|MikeTheRed]] 22:24, 2 June 2006 (PDT)<br />
<br />
----<br />
<br />
I suspect you've misremembered the details of your tests. The 49.26% success rate out of 2400 trials that you quote above would have been for your 95/16 soldier doing panics, not MCs: 44 + [95*16/50 = 30.4] - 25 = 49.4%, almost exactly the same as your 49.26%. A 95/44 doing panics would always succeed: 102.6%. A 95/44 doing MCs would succeed 82.6% of the time.<br />
<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 11:06, 3 June 2006 (PDT)<br />
<br />
----<br />
<br />
Ah, there's that data. Thanks for reminding me. I can't remember what I put in which discussions and was going to dig it out of my db. <br />
<br />
No, it was MCs. Indeed I relied on the lack of seeing an enemy, if I got moving too fast and couldn't remember if I successfully MC'd. Attention starts to wander with such highly repetitive testing. This was before I realized the following...<br />
<br />
Anyone doing repetitive psi testing can readily and accurately get the number of positive results from the [[UNITREF.DAT]] Psi byte [84] if you work it right. Note the turn you start psi attempts. Then do exactly 2 or 3 psi Attempts each turn, as your TUs allow. Then note the turn you stop and get the delta. Turns x Attempts/Turn = Attempts. A failed psi attempt adds 1 to [84] and a successful attempt adds 3, so the number of successes is: ([84]-Attempts)/2. Be careful during testing marathons because the byte wraps around at 255 (=85 straight successes, or 28.3 turns at 3 successful attempts per turn). Then it starts counting again so actually even this can be dealt with by adding 255 if you're on top of it. If anybody wants an applet that shows Unitref experience values on the fly, let me know. It's great for building experience. Right now it's embedded within my mdb though... I'd have to tease it out.<br />
<br />
I'm using XCOM DOS which I once ran XcomUtil on, if that matters. <br />
<br />
Hmm.<br />
<br />
---[[User:MikeTheRed|MikeTheRed]] 12:21, 3 June 2006 (PDT)<br />
<br />
----<br />
<br />
Distance...ok, no reason for the game to use multiple 2-d distance formul&aelig;.<br />
<br />
I have software set up to render 3D graphs. Is there anything on the site that jumps out as "would like to see first"? I'd rather wait until the psi formul&aelig; are calibrated first before graphing those.<br />
<br />
Ethereal: What I see posted is test data for ethereal MC human. Do you have test data for human MC ethereal as well? [That would test whether the game calculations are symmetrical.]<br />
<br />
---[[User:Zaimoni|Zaimoni]] 2:37, 3 June 2006 (EDT)<br />
<br />
----<br />
<br />
It ''is'' possible X-COM units get a different formula from aliens -- I only tested an alien doing psi, as it was more automated -- the thing would psi without my having to control it.<br />
<br />
I'm not not volunteering to test x-com units for the time being -- it's a bit more laborious -- but if I ''had'' to test it, I'd do a small number of trials of 35/16, 50/51, and 100/51 soldiers trying to MC (not panic) an adjacent Muton, which should succeed 10.2%, 50% and 101% of the time.<br />
<br />
Feel free to test it before I do. ;-P<br />
<br />
Oh, and nice work on the flares, Mike.<br />
<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 12:50, 3 June 2006 (PDT)<br />
<br />
----<br />
<br />
Sounds cool, Zaimoni... As for "like to see",<br />
<br />
Once my troops have psi ability, I try to get 90+ psi strength guys. Then the question becomes "at psi str 90, at what psi skill point are most/all aliens certain to be MC'ed?" In my experience, it's somewhere around skill 40-60... Anything that might show this, or show how you fare relative to aliens at, say, STR 90, is something I've always wanted. However it might be done. In one sense you could simply plug the "worst" psi alien (Ethereal CDR?) into Eth's equations to get the final answer. But it'd be good to see the lay of the land.<br />
<br />
If you make the simplifying assumption that many of your targets are psi skill 0, there's one less variable. Additional graphs can be done later just for the psi-capable aliens... first things first though...<br />
<br />
Taking the above into consideration, then, XCOM Psi Skill (Str=90) vs. Alien Psi Strength (Skill=0) vs. Success rate is one 3D graph that could be made. If you can do a 4th dimension as color, you could replace the Success rate axis with XCOM Psi Str, then have color indicate success rate, from primary red for "no way" through yellow for "sometimes" to primary green for "always". Or something like that. It'd also be nice but not critical to have annotations for where various aliens lie along their dimension. I can supply this info if you want. Which reminds me: Eth, Zombie and others found some errors in Aztec's table (which came from the OSG). Just a few percent of them, but they're definitely there (I can't remember where). I've hacked alien stats straight out of GEOSCAPE... see the alien stats page. I believe Zombie has found these to be correct, but he has not yet given the final word.<br />
<br />
Zai, as far as I'm concerned, you can model using EC's equation already, if you have the time... I'm sure his equations are very close, if not spot on, and even if not, it may show key places to test and otherwise support further testing. E.g., both aliens and XCOM can readily have their relevant values hacked to test for boundary conditions of 0% and 100% success. Plus once it's set up it shouldn't be hard to tweak the equation and voila, the graphs update. But if you don't have the time - eh, it's all volunteer work anyway.<br />
<br />
Eth, I suppose it's possible aliens vs. humans is different. They are known to have some differences in functionality, such as night vision. I don't know if I'll be able to test, but it definitely intrigues me. BTW I said somewhere else that I was looking into automating the XCOM interface in order to do psi testing. I have concluded that I can't do it. At least not the way I was hoping to. Oh well. Still, my belated realization that one can use Unitref[84] to count psi successes is a real boon to repetitive testing. So we'll see. Thanks for suggestions on what to test if I do. By the way, did I do that 83% correct? I just want to make sure I'm doing the math right.<br />
<br />
Thanks re: the flares!<br />
<br />
---[[User:MikeTheRed|MikeTheRed]] 21:08, 3 June 2006 (PDT)<br />
<br />
----<br />
<br />
The influence of distance still needs to be tested, although it doesn't seem to be an enormous factor. Rather than a complicated graph, I think a few charts with distance = 1, 10 and 20 would probably tell the story more clearly. The distance formula might even prove to be something really simple, like +1 distance = -1% chance.<br />
<br />
The hardest aliens to MC are Sectopods and Cyberdiscs: look at the [[Psionics#Summary_of_Alien_Psionic_Resistance]] section I added. At distance 1 on Superhuman you'll need 93 to 192 Attack Strength to achieve 1% to 100% chance. Assuming Psi Str 90, that's Skill 52 to 107.<br />
<br />
Now vs. the strongest attacker: Superhuman Ethereal Commander, attack str 88. You'll need a Resistance of 132 to be totally immune to panics from one adjacent to you -- that's str 100, skill 160, or str 90, skill 210. Against MC, it's str 100/skill 60 or str 90/skill 110. In practice you won't be right next to them, so you can probably go a bit lower. They'll focus on the weakest soldiers anyhow, which in practice means a couple of decoys in with some supertroopers is a good strategy.<br />
<br />
82.6%, yes.<br />
<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 21:51, 3 June 2006 (PDT)<br />
<br />
OpenOffice.org is CPU-bound when converting the graph from 2D to 3D. [XCOM Psi Str/Sk 90/0-107, alien Psi Str/Sk 25-116/0; I'm on a 1GHz Pentium III/512MB] Not sure how ColdFusion single-IP demo would do yet (would have to reinstall), but the UI options look better in OpenOffice.org.<br />
<br />
I'll attempt the transition later today (when I know I'll be away from the system and positively not working). I just need to be able to take a screenshot.<br />
<br />
You probably already noticed this: even if a bug permitted a 0 Psi Skill operative to use a Psi Amp, the success chance of MC is still negative.<br />
<br />
Also (thinking about the testing anomaly MikeTheRed had): The floating-point change in success rate from an increase of 1 in Psi Skill is 1.9 at 95 Psi Str. Integer truncation would make this 1...leaving the floating-point formula overestimating by 39.6%. At the precision of reporting, this works.<br />
<br />
[Edit: but does *not* work against the initial regression. So, no good.]<br />
<br />
---[[User:Zaimoni|Zaimoni]] 9:51, 4 June 2006 (CDT)<br />
<br />
Got a chance to run the bar graph this morning...no go, OpenOffice.org doesn't like a horde of data points on both axes. <br />
<br />
But...this particular graph is essentially a plane. It should be hand-drawable, even if the more complicated ones aren't.<br />
<br />
---[[User:Zaimoni|Zaimoni]] 8:35, 5 June 2006 (CDT)<br />
<br />
----<br />
<br />
Hi Zaimoni... I'm not sure I understand the differences you talk about. You mean you can get your s/w to make a graph where you've specified the points by hand? Anyway, if you take a shot at most anything, we'd be able to give feedback... a picture's worth a thousand words. Thanks for working on it! ---[[User:MikeTheRed|MikeTheRed]] 06:36, 5 June 2006 (PDT)<br />
<br />
Somewhat. Layer 1 of the spreadsheet is the raw data to be graphed (took about five minutes to set up). If I was going to commit to this representation, I'd go back and make the XCOM Psi Str and Alien Psi Skill configurable. So it's trying to graph data points (the MC success chances) on 0-107 by 25-116. I was planning to rotate the view after getting the initial graph up on Layer 2. [Time loading is not favorable for working further on this today.]<br />
<br />
OpenOffice.org's autoscaling isn't compensating properly. I haven't checked how to suppress the "color key" that was auto-generated for Alien Psi Str &mdash; it's not leaving enough space for the vertical bars to even be 1 pixel in size. The result is decidedly flat, with "correct" vertical range.<br />
<br />
As a bar graph, I could get away with subsampling (but don't have a clean way to do it). Yes, it should be possible to correctly graph this (as a plane in three-dimensional space) with only four data points: the corners.<br />
<br />
---[[User:Zaimoni|Zaimoni]] 12:39, 7 June 2006 (CDT)<br />
<br />
<br />
== Psychic Farm ==<br />
There's a sort of tactic I use which may fit into this article. It's blatant simple: building a base with a couple Living Quarters and as many <br />
Psionic Laboratories as possible, hire the entire population of a small town and get them into psionic training. There may be a pre-selection for soldiers with appalling stats. I don't know what happens to veterans, but in my games by the time I get Psionic Labs money is not a constraint anymore, so I find this industrial breeding quite viable. What do the savvy say about this?--[[User:Trotsky|Trotsky]] 02:40, 11 July 2006 (PDT)<br />
----<br />
Hiya Trotsky,<br />
<br />
That's what I do. You might want to see my info on [[Raw_recruit_statistical_likelihood|recruit statistics]] and [[Hiring/firing]] (esp. the last bullet under General Info). If you get the full 1,000 recruits per month, about 50 will have psi strength of 95+. Taking other stats into consideration, one or two dozen will be top-notch recruits. <br />
<br />
I only have 2 or 3 actual combat squads. One of my less-busy bases serves as initial receiving for batches of ~100 (no psi labs needed), and other un-busy bases get the recruits who made the initial cut farmed out to them, for psi evaluation (lots of psi labs needed).<br />
<br />
FWIW I have an applet that reads a savegame; I run it when a new batch of recruits shows up, and it prints out who to keep based on a prioritization. It's ordered by base and soldier names at that base so I go directly to Sell/Sack and dump the ones that didn't cut it, without needing to look at their stats in the game. Then those guys move on to your "psychic farm" bases for psi evaluation. Before I wrote the applet, I would stick a little plus sign next to the names of the guys to keep as I reviewed them in the Soldier Stats screen, so I'd know who to Sack.<br />
<br />
Because you can only have 250 soldiers max, and some are devoted to combat or other duties, depending on how you draw the line on initial recruit stats (and how hard you want to work at it), plus the fact that psi results only come up at the end of the month and you need to have the next batch on hand for next month's evaluation... this all means that there's actually only ~100 noobs undergoing psi evaluation on any given month. Also, the number of new recruits you order in batches goes down from the beginning of the month to its end, since you only have a window of ~100 to work with initially. At least, that's how it works for me.<br />
<br />
If I run a game a long time, over time what happens is that the bar for psi strength in my 2-3 active combat crews rises over time. Each month, the few high-psi recruits push a few vets below the bar. The best of these vets are farmed out to lesser bases, in case of attack. Of course, any of us could've won long before this point; we're playing just for the joy of play.<br />
<br />
Despite all the above, if a soldier has good psi strength, almost anybody can become a superman, given enough [[Experience#Soldier_Advancement|combat]]. The difference between the worst recruit and the best is only about a dozen combats (assuming they can get 3 actions for firing and reaction each combat).<br />
<br />
---[[User:MikeTheRed|MikeTheRed]] 16:14, 11 July 2006 (PDT)<br />
:I see people creating scripts and stuff to analyse the game files to know who to sack, psi training hundreds of soldiers to finally only keep 2 or 3 guys... All of this is time consuming at best. Why don't you just hex-edit the games file to improve the soldiers? Or hack the game to always show the psi strength, or generate only ubersoldiers? Yeah this would be cheating. But screening 1000 soldiers a month... [[User:Seb76|Seb76]] 03:20, 25 May 2008 (PDT)<br />
<br />
== Suggestions for Psi Defence ==<br />
<br />
The first aim on missions is to pick off as many aliens as possible without them sighting you. With luck you can break their morale before you get a single psi-attack. Once a soldier is seen the aliens will often, but not always, pick off your weakest soldiers mercilesly (I've had a soldier with 83 strenth panicked as the sole attack during a mission, strangely). The second aim is to get your vulnerable soldiers disarmed so they can soak up all the psi-attacks harmlessly. You can do this by getting soldiers to drop everything when they return to your control, making sure weapons are stored on the ground instead of in hand, or stunning and reviving soldiers. Killing a soldier under alien control will only result result in another soldier being targetted. As you can't keep all your soldiers harmless all the time you should use all available cover to make sure that your troops cannot see each other. This reduces the damage if a soldier gets controlled. Don't use explosive weapons. Don't hold primed grenades between turns. Don't use proximity grenades close to your troops and clear any when soldiers panic in their direction. <br />
<br />
Once a mission is completed you can rename the soldiers to record their Psi capability. I'd stick an X on their name, say, for poor defence. Soldiers which look like they have good Psi strength can be marked for training. Soldiers with poor defence will be no use in Cydonia so they can be sacked, used as scouts, or used as decoys on later Psi missions.<br />
<br />
On Psi-attack, I think it's worth mentioning that if you stun an alien while it is under mind control then it will not be captured at the end of the mission. I have lost a commander this way.<br />
<br />
- Egor<br />
<br />
<br />
Xconman...<br />
<br />
Is this how you add your 2cents? I've been playing xcom since PS1. I loved it but hated the load time on it. The PC version was faster but somehow not as good. Anyway, I've found the most successful preventive tactic vs psionics is to not bunch your troops together. If an alien sees you and you don't kill it that turn, it's a sure bet someone will be controlled. (someone may be controlled anyway but it cuts the result by at least half) I've played the game so much the tactical aspect is predicable (so easy) for me except when you have powerful psionics against you so I started to send out 2-3 man squads (spaced apart) toward the target and the rest of my squad spread to the 4 corners of the map. As troops die you send in one or two more troops. I've found that I hardly recieve psionic attacks when I approach the enemy this way.<br />
<br />
<br />
Xconman...<br />
<br />
This is a cheat. On Psionic farming. Create a univeristy base devoted to psionics, say 100 students. Forward the game by not attacking and ignoring everything. See the results of the troops and copy down their names. Restart a day later and expell all "failures" and hire the amount of students equal to vacant spaces. Repeat as often as you have (time) no life for. lol<br />
I've found the cpu registers the psionic power/skill when the charcter is created and not when the month is up. I've had 37 characters with 100 ps str this way in 3 game months. (it took 5 hours off my life though...)<br />
<br />
: You might want to use colons : to indent your paragraphs. Putting a space in front of it is the shortcut for preformatted text - and that has a tendency to look unpleasant depending on your screen settings. Also you can sign your posts by entering four tildes <nowiki>~~~~</nowiki> rather than head it with your username. <br />
<br />
: When a new recruit is hired, psi skill is set to 0, while psi strength is a random roll from 0 to 100. So yes, the strength level is predetermined the moment the soldier is hired. The game only reveals the psi strenth stat when the psi skill stat is greater than 0, which is where the first month in the labs comes in. <br />
<br />
: With a bit of code diving, we've confirmed the 20 turn grace period and the 2-remaining alien condition before psionics are launched. But have we done so with the visual aspect of it? -[[User:NKF|NKF]] 02:01, 25 May 2008 (PDT)<br />
<br />
::NKF: No, seems I somewhat jumped the gun on that one. For what it's worth, I've noticed that the AI gets smarter after about turn 20(what with the noted leaving of the UFO and stalking of your units) as well as a smart AI when only a handful of aliens survived the crash. (This may well be why I've had the lone alien from the small scout ambush my troops on more than one occassion; he knows where they are at all times.) Just my theories. [[User:Arrow Quivershaft|Arrow Quivershaft]] 03:24, 25 May 2008 (PDT)<br />
::The code dig was not related to psi attacks in particular. The game sets the visibility flag to 1 for all XCOM units in the 2 cases you mentionned, no more no less. [[User:Seb76|Seb76]] 03:42, 25 May 2008 (PDT)<br />
::Edit: I did a quick check: the game does not seem to test the visibility flag when searching for a target! If you patch offset 0x469B in the CE edition from 0x02 to 0x03, it _might_ test for it. Feel free to test... [[User:Seb76|Seb76]] 03:57, 25 May 2008 (PDT)<br />
<br />
----<br />
<br />
First of all, I'm a new player, and I've found this website indescribably helpful. Thanks a lot! I have a question about psionics. I'm playing the Steam version, and psionics is not turning out to be the game-breakingly-powerful weapon I've heard it described as. I can never seem to MC more than 1 alien 1 time during a mission. Even a Psi Strength 99 soldier can't grab Sectoid Solders with any reliability. I chalked it up to lack of skill, but find that 1 of the first half-dozen attempts for a single battle works great, and then it never works again. And I have NEVER seen any of my soldiers gain increased Psi Skill, though apparently it's supposed to go up like crazy. I've observed the same phenomenon in TFTD. Am I doing something wrong? I assumed MC was incredibly unreliable, but I don't even bother to use what's supposedly the most powerful ability in the game. And man, I could use it in TFTD right now, that game is rough... <br />
<br />
Thanks a lot, I really appreciate the time you guys put into this.<br />
<br />
--[[User:wfames|wfames]] 2:38, 19 Jan 2009 (EST)<br />
<br />
:Hiya wfames, welcome to the UFOpaedia! Any and all questions or contributions welcomed.<br />
:It sounds like something is definitely wrong. Please see [[Experience#Primary_Stats]]. Even if every Psi attempt fails (MC or Panic), if you try at least 11 times with any one soldier, that soldier's Psi Skill ''must'' go up by 2-6 (average 4) per combat. And a successful attempt counts as 3 tries, so you only need 4 successes to have Psi Skill go up by 2-6. But you're not seeing this? This could be a major problem, if Steam is providing a broken game (and maybe GamersGate too - wouldn't be surprised if they're both selling the same package).<br />
:A problem with the half-dozen of us diehards here (although we pray for many more) is that we have a ton of editors, utilities, and X-COM variations tied into our existing X-COM stuff. So we're hoping, of course, that the new bundles are "same old stuff, no problem". If they're not, it's a can of worms ... we'd have to buy something we already own (perhaps multiple copies of), put it somewhere new, test it out for days or weeks. So this is a black news post you made (or at least, it sounds like one). But hey, we're here to help. :)<br />
:If you don't mind, pop over to [[GEOSCAPE.EXE#X-COM_Complete_Packages]] and make a new "review". Also use the Talk page link there. For the moment, it will probably be better to have any problems or questions in one place (to see if others have the same questions or problems)... later we can diffuse them out to the wiki in general, once we get a feel for whether there are real problems we can nail down and/or easy fixes, etc.<br />
:Thanks again for dropping by. Please come back any time! -[[User:MikeTheRed|MikeTheRed]] 03:58, 19 January 2009 (CST)<br />
<br />
:: What psi skill levels have the soldiers got? Even if their strength levels are high but if the skill levels are low then you won't be getting very frequent successes. You'll want to put several missions worth of psi attempts under your belt before you can really start to hammer the aliens with the good stuff. If you've got a handy alien base nearby, you can send a team of psi troopers there, panic the first alien you see to bits, dust off, check your stats and then repeat the process over and over until you are good enough to use mind control. I recommend the panic attack as it has the highest success probability of the two attacks, and you can have everyone panic the same alien in a single turn - which can't be done with mind control if it succeeds. -[[User:NKF|NKF]] 22:55, 19 January 2009 (CST)<br />
:Good point, NKF. I assumed he'd played a lot, but should have asked. wfames, are you getting Psi to work yet? Your soldiers' Psi skill will increase ~4 points for every combat, if they make at least 11 unsuccessful or 4 successful Psi actions per combat (the [[Mind Probe]] doesn't count). See some [[Psionic_Equations#X-COM_Vs._Aliens|cool numbers I generated]] for a solid handle on when you should be MCing aliens relative to Psi Skill. -[[User:MikeTheRed|MikeTheRed]] 18:31, 23 January 2009 (CST)<br />
<br />
<br />
=== Possibly buggy tactics ===<br />
<br />
2 tactics that may or may not lead to glitches are:<br />
<br />
1) Stunning the mind controlled soldier.<br />
<br />
2) RE- Mind controlling the mind controlled soldier.<br />
<br />
Both of these tactics have unconfirmed rumors of resulting in permanent mind control by the aliens.<br />
<br />
== How a tiny bunch of human civilians beat the aliens at Psionics ==<br />
<br />
Much as I enjoy getting my *ss kicked in X-COM and thus "losing my favourite game", I sympathise with the aliens because they know exactly how I feel. After all the aliens invented Psionics, millions of years ago, built their society around it, presumably optimised their genome as well since they are masters of DNA, and we come along with no prior knowledge and no genetic mastery and hand them their 'nads, using their own pride and joy, Psionics, in a few short months. While a similar point could be made about plasma weapons and UFOs, this astounding fact still begs a little explanation. <br />
<br />
A similarly perplexing question is why X-COM, first and last line of defence of planet Earth, has extremely low field manpower, both initially and long term, and is staffed exclusively with rookies who appear to have no prior combat experience. Surely the world's most powerful governments would be only too willing to put at least some of their elite special forces at the disposal of X-COM - in their own self interest of course? But if you look at the skill gain curves of X-COM operatives, it's clear that these are true rookies. There is nothing odd going in during the Alien Wars that would explain massively accelerated skill growth for already-expert special operations forces (except in the Psi area of course). We have to conclude that X-COM rookies are exactly that, rookies, maybe with basic training but no more. And their initial ranks reflect that. <br />
<br />
Here is a non-canonical background suggestion that ties these two anomalies together neatly. Posit this: initial responses to the alien threat, national forces such as the Kiryu-kai, drew heavily on national military special forces. Initial contact with aliens was a total disaster, massively counterproductive, due to alien use of Psionics. Even without overt use of Psionics against them, military operatives in the field against aliens were overcome by Psionic 'noise', panicking and berserking. Their resistance to direct attack was effectively nil in almost all cases. Hence the advanced military skills of these first extraterrestrial defence units were turned against them, causing grievous destruction in the teams, and perhaps worse. (Perhaps in one or more instances, entire teams of heavily armed mind-controlled elite commandos were flying low, under radar, heading directly for the Kremlin or Diet or White House, and were only stopped by the drastic intervention of air force units).<br />
<br />
The secret knowledge of aliens possessed by some of the CFN governments significantly pre-dates what XCOM troops on the ground would later learn. Knowledge of the aliens and their psionic potential was a closely held secret within need-to-know groups like MJ-12 in the United States for decades prior to the First War. Analysis of the initial tactical failures suggested that defensive psionic screening was a priority by far outweighing any combat ability or military discipline. As a pre-requisite, the entire field force of X-COM would need to be assembled from individuals who had at least basic Psionic resistance. In these days the idea of Psi Lab screening was at best a hypothesis. However, decades of investigations by MJ-12, in the years after Roswell, had identified a genetic component to Psi resistance. A relatively simple DNA test could identify a tiny proportion of the human population who had the potential, at least, to resist alien Psionics - to varying degrees which could not be further tested except under field conditions. But at a minimum, the DNA test selected the very rare individuals who who not succumb to 'ambient' Psionic fields and would at least require a directed attack by an alien. It turns out the distribution of such individuals cut across race and gender, but did to a surprising extent reflect the major players in the CFN and even the apparent major target regions of the alien incursion itself. <br />
<br />
Putting this in the context of the later mythos evolved in X-COM Apocalypse: What if all XCOM operatives in the First and Second Alien Wars are secretly a type of human-sectoid hybrid? Unknown to themselves and all but a few others in the highest reaches of the XCOM hierarchy, or possibly entirely unknown to human governments, who believe this individuals are rare human mutants. In fact, a plausible explanation would be that a rebel Sectoid faction, identifying potential with the human DNA at least for the perpetuation of the barren Sectoid species, and perhaps a new biological weapon to throw off the yoke of the Ethereals once and for all, began introducing Psi-capability genes into human DNA from the earliest contacts - Roswell or earlier. <br />
<br />
Whether the decision to recruit exclusively from hybrids was known to X-COM or the CFN at the time of the First or Second Wars, by the time of Apocalypse, the presence of hybrids in the population was well known and such an openly racist recruitment policy could not be pursued. And of course in the time of Apocalypse we see that 'pure' humans are weak or at very best mediocre Psi operators, and that it is X-COM's hybrids who excel - provided of course they are equipped with artificial psi amplifiers to compensate for what is presumably a deficit of raw psi energy, but no deficit of will or talent once the energy problem is artificially solved. All of which simply suggests that Psi Amps may have been a technological 'plant' by rebel Sectoids or hybrids working within X-COM. <br />
<br />
All pure speculation of course. In fact, anyone considering such things is clearly delusional, a danger to society, and should be confined for the safety of themselves and others. Come this way sir, please don't make a fuss, it will be much easier if you just... look... into... my... MIND...<br />
<br />
[[User:Spike|Spike]] 12:05, 23 October 2012 (EDT)</div>
Spike
https://www.ufopaedia.org/index.php?title=Talk:Psionics&diff=40232
Talk:Psionics
2012-10-23T16:04:29Z
<p>Spike: /* How a tiny bunch of human civilians beat the aliens at Psionics */ new section</p>
<hr />
<div>Just had a thought on the formula!<br />
<br />
What if the "Psionic Combat Strength" formula was a''' ' + ' '''rather than a''' ' * ' '''?<br />
<br />
It would mean the example Soldier would have a PCS of 111, rather than 1520, and the defending Muton would have:<br />
<br />
Panic Chance = 76%<br />
MC Chance = 56%<br />
<br />
These numbers seem more reasonable, don't you think?<br />
<br />
--[[User:Danial|Danial]] 15:32, 19 Nov 2005 (PST)<br />
----<br />
Right, it sounds '''much''' more reasonable now. My actual results were 1192 successes out of 2420 tries = 49.26% success rate. The MCer was right next to MC victim, and we know distance introduces ''some'' kind of decrease to base chance. That's the good news. The bad news is that I also tested psi str 95, skill 44 (and some higher skill levels) and never failed to MC ''once'' with these better MCers. Using your revision, a psi str 95, skill 44 guy should have had a success rate of 84% vs. a beginner Muton soldier (psi str 25, skill 0), not 100%. My higher-skill guys were also right next to their MC victims. So, to me the first example makes sense relative to your idea (fits base chance, plus a little distance adds a little more), but the second example counters it.<br />
<br />
Still, it sounds WAY better than 1500% :)<br />
<br />
I sure wish psi testing wasn't so labor intensive. I got those 2400 counts doing all that experience testing... not interested in doing it again, just for psi equations. At least not at the moment. :P ---[[User:MikeTheRed|MikeTheRed]] 21:12, 23 Nov 2005 (PST)<br />
----<br />
Question: why is the Sectopod's psionic resistance listed as N/A? I've mind-controlled sectopods (or at least one square of a sectopod) on many occasions. I usually have it shoot itself, since it can target one of its other, non-MC'ed squares. From my anecdotal experience, their psi resistance seems somewhat high. --[[User:Papa Legba|Papa Legba]] 14:19, 2 February 2006 (PST)<br />
----<br />
Answer: If you look on the alien summaries in the wiki they all have a PSI resistance listed, except the Sectopod. Since it's not listed anyplace I put N/A. Feel free to put it where it belongs in the list if you have enough experience to feel comfortable ranking it. --[[User:Darksun|Darksun]]<br />
----<br />
Darksun, I took the liberty of signing your name for you, and making a separator line. Why not say a word about yourself under [[User:Darksun]] and also, use four dashes (----) to demarcate entries. For more on the basics of wiki'ing, see NKF's "Community Portal" at the bottom of the homepage. Past all that - welcome, fellow XCOMMIE! We were all wiki noobs once. But not everybody loves XCOM. You must. Welcome aboard!<br />
<br />
Proceeding right along to flagellating, laugh - Where are you folks talking about Sectopod psi resistance being "N/A"? I see their Psi Strength as 100, and their Psi Skill as 0 at Beginner; Psi Strenth 116 and Skill still 0 at Superhuman. In this respect, they match Cyberdisks. What do you folks mean by Psi "resistance"? Do you know the math behind the psi equations? I haven't been able to figure it out. But the stats I just listed are ones hacked out of the game... Zombie is going to present a full precis' some time soon.<br />
<br />
Great speaking at ya ... keep on contributing, Darksun!! --[[User:MikeTheRed|MikeTheRed]]<br />
<br />
== Alien psionic resistance ==<br />
<br />
I haven't tried mind-controlling Cyberdiscs much, but if, as I've read elsewhere, both Sectopods and Cyberdiscs have have a Psi Strength of 100, they should probably both be classed "extremely high".<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 10:30, 4 May 2006 (PDT)<br />
<br />
== Psionic testing ==<br />
<br />
I started doing some testing to figure out the psionics formula. <br />
<br />
Initial finding: ''distance'' takes the hypotenuse into account. I'm not sure if the actual Pythagorean formula is used, but I can say this much: an Ethereal was able to panic a moderately-psi-weak soldier at 30 squares along the horizontal but not at 30 squares along the diagonal.<br />
<br />
Second finding: the difference in "difficulty" between MC and panic is definitely 20 points (although that may not be percent). A soldier with 97 Psi strength, 0 Psi skill standing adjacent to an Ethereal Leader (60 str/45 skill) could not be panicked at all, but 96 Psi str could (often). The same soldier with 77 Psi str couldn't be mind-controlled, but could at 76 Psi str. ''With further testing, I see that 60/45 vs. 97 should succeed occasionally; I might retest this for greater precision, although the +20 still seems to hold.''<br />
<br />
Third finding: A soldier with 99 Psi str/0 skill could ''just barely'' be panicked by an adjacent Ethereal with 63/45. I couldn't count how often the Ethereal succeeded, but it was something like 1%-2% of the time. The same soldier was panicked just as infrequently by an Ethereal with 45/63 (str & skill reversed), and much more often by an Ethereal with 54/54. This pretty strongly suggests the attack portion of the formula involves psi str & skill multiplied together.<br />
<br />
Data points collected so far:<br />
*Ethereal, 63/45, just barely panicked soldier, 99/0<br />
*Ethereal 40/40 just barely panicked soldier 75/0<br />
*Ethereal 27/27 (multiplied together = 729) just barely panicked soldier 57/0<br />
*Ethereal 10/73 (multiplied = 730) just barely panicked soldier 57/0<br />
**''this confirms that attacking is based on str*skill<br />
*Ethereal 18/18 just barely panicked soldier 49/0<br />
*Ethereal 1/1 just barely panicked soldier 43/0<br />
*Ethereal 1/1 just barely panicked soldier 1/210<br />
**''this confirms Psi skill / 5 is used in calculating defense; 1 + (210/5) = 43''<br />
<br />
I also tested Ethereal 0/1 (no psi str, 1 pt. skill); it still attacked, but did not attack at 0 pts. skill no matter how high psi str was (no surprise there, otherwise all units would do psi attacks).<br />
<br />
I ran the points through a curve-fitting program and got a nice and simple answer:<br />
<br />
attack strength = psi str * psi skill '''/ 50'''<br />
defense strength = psi str + (psi skill / 5)<br />
<br />
Panic Attack chance = 44% + attack strength - defense strength<br />
Mind Control Attack chance = 24% + attack strength - defense strength<br />
<br />
The formula has held up under limited further testing; I'm satisfied it's correct. I invite others to test it more than I have.<br />
<br />
The impact of distance has yet to be tested, but it should be easy to figure out now.<br />
<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 22:03, 26 May 2006 (PDT)<br />
<br />
----<br />
<br />
There is a reasonable approximation to the Pythagorean formula (in the plane) that could have been used, that doesn't require loops or floating-point math:<br />
<br />
max( | &Delta;x | , | &Delta;y | ) + &frac12;min( | &Delta;x | , | &Delta;y | )<br />
<br />
where &Delta;_ := _<sub>2</sub> - _<sub>1</sub>.<br />
<br />
It overestimates slightly. I haven't thought through how this would generalize to 3D. [Yanked from Moria, Angband, and variants...think it's too basic to copyright, though.]<br />
<br />
One way to test whether the distance estimator is no greater than true Pythagorean formula by working out the greatest distance (pure x or pure y) that MC/Panic is not 0%, then testing on a diagonal with a "computed same". An integer-math overestimator (like the above) would by 0%.<br />
<br />
Muliple of 5 allows replacing the diagonal with a suitably scaled 3-4-5 triangle...should work as well for testing.<br />
<br />
--[[User:Zaimoni|Zaimoni]] 2:38PM, 26 May 2006 (CDT)<br />
<br />
----<br />
<br />
Wow... good approach to teasing this out, Ethereal!<br />
<br />
Am I doing this right? I plugged in numbers for Muton, 25/0, Me 95/44, and got 83% MC Base Chance... But in much repeated testing (when learning about experience counters) it seemed quite solid that I was MC'ing him about half the time. Say 45-55% of the time. This was when right next to each other. Is 83% right for your equations?<br />
<br />
Zaimoni, re: your equation, see [[Explosions#Distance_from_Ground_Zero]]. XCOM seems to use a fairly simple approach that doesn't involve Pythagoras per se. Since it's based on a very old engine, much of its stuff is integer based. Cool deal on the deltas and other wiki symbols - I wish I knew about them sooner! Actually I know where wiki symbol tables are... just didn't bother to look up so many symbols. :P<br />
<br />
Nobody has tackled 3D distance yet, but I may soon, in studying illumination.<br />
<br />
Once the equations are well known (maybe they are already), I imagine some cool 3D topographical graphs of the various factors (skill and strength, you vs. enemy) could be made. Do either of you have surface graph s/w at hand? All I've got at the moment is Excel. :(<br />
<br />
Great work! Also thanks for cleaning up the page in general, Eth.<br />
<br />
---[[User:MikeTheRed|MikeTheRed]] 22:24, 2 June 2006 (PDT)<br />
<br />
----<br />
<br />
I suspect you've misremembered the details of your tests. The 49.26% success rate out of 2400 trials that you quote above would have been for your 95/16 soldier doing panics, not MCs: 44 + [95*16/50 = 30.4] - 25 = 49.4%, almost exactly the same as your 49.26%. A 95/44 doing panics would always succeed: 102.6%. A 95/44 doing MCs would succeed 82.6% of the time.<br />
<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 11:06, 3 June 2006 (PDT)<br />
<br />
----<br />
<br />
Ah, there's that data. Thanks for reminding me. I can't remember what I put in which discussions and was going to dig it out of my db. <br />
<br />
No, it was MCs. Indeed I relied on the lack of seeing an enemy, if I got moving too fast and couldn't remember if I successfully MC'd. Attention starts to wander with such highly repetitive testing. This was before I realized the following...<br />
<br />
Anyone doing repetitive psi testing can readily and accurately get the number of positive results from the [[UNITREF.DAT]] Psi byte [84] if you work it right. Note the turn you start psi attempts. Then do exactly 2 or 3 psi Attempts each turn, as your TUs allow. Then note the turn you stop and get the delta. Turns x Attempts/Turn = Attempts. A failed psi attempt adds 1 to [84] and a successful attempt adds 3, so the number of successes is: ([84]-Attempts)/2. Be careful during testing marathons because the byte wraps around at 255 (=85 straight successes, or 28.3 turns at 3 successful attempts per turn). Then it starts counting again so actually even this can be dealt with by adding 255 if you're on top of it. If anybody wants an applet that shows Unitref experience values on the fly, let me know. It's great for building experience. Right now it's embedded within my mdb though... I'd have to tease it out.<br />
<br />
I'm using XCOM DOS which I once ran XcomUtil on, if that matters. <br />
<br />
Hmm.<br />
<br />
---[[User:MikeTheRed|MikeTheRed]] 12:21, 3 June 2006 (PDT)<br />
<br />
----<br />
<br />
Distance...ok, no reason for the game to use multiple 2-d distance formul&aelig;.<br />
<br />
I have software set up to render 3D graphs. Is there anything on the site that jumps out as "would like to see first"? I'd rather wait until the psi formul&aelig; are calibrated first before graphing those.<br />
<br />
Ethereal: What I see posted is test data for ethereal MC human. Do you have test data for human MC ethereal as well? [That would test whether the game calculations are symmetrical.]<br />
<br />
---[[User:Zaimoni|Zaimoni]] 2:37, 3 June 2006 (EDT)<br />
<br />
----<br />
<br />
It ''is'' possible X-COM units get a different formula from aliens -- I only tested an alien doing psi, as it was more automated -- the thing would psi without my having to control it.<br />
<br />
I'm not not volunteering to test x-com units for the time being -- it's a bit more laborious -- but if I ''had'' to test it, I'd do a small number of trials of 35/16, 50/51, and 100/51 soldiers trying to MC (not panic) an adjacent Muton, which should succeed 10.2%, 50% and 101% of the time.<br />
<br />
Feel free to test it before I do. ;-P<br />
<br />
Oh, and nice work on the flares, Mike.<br />
<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 12:50, 3 June 2006 (PDT)<br />
<br />
----<br />
<br />
Sounds cool, Zaimoni... As for "like to see",<br />
<br />
Once my troops have psi ability, I try to get 90+ psi strength guys. Then the question becomes "at psi str 90, at what psi skill point are most/all aliens certain to be MC'ed?" In my experience, it's somewhere around skill 40-60... Anything that might show this, or show how you fare relative to aliens at, say, STR 90, is something I've always wanted. However it might be done. In one sense you could simply plug the "worst" psi alien (Ethereal CDR?) into Eth's equations to get the final answer. But it'd be good to see the lay of the land.<br />
<br />
If you make the simplifying assumption that many of your targets are psi skill 0, there's one less variable. Additional graphs can be done later just for the psi-capable aliens... first things first though...<br />
<br />
Taking the above into consideration, then, XCOM Psi Skill (Str=90) vs. Alien Psi Strength (Skill=0) vs. Success rate is one 3D graph that could be made. If you can do a 4th dimension as color, you could replace the Success rate axis with XCOM Psi Str, then have color indicate success rate, from primary red for "no way" through yellow for "sometimes" to primary green for "always". Or something like that. It'd also be nice but not critical to have annotations for where various aliens lie along their dimension. I can supply this info if you want. Which reminds me: Eth, Zombie and others found some errors in Aztec's table (which came from the OSG). Just a few percent of them, but they're definitely there (I can't remember where). I've hacked alien stats straight out of GEOSCAPE... see the alien stats page. I believe Zombie has found these to be correct, but he has not yet given the final word.<br />
<br />
Zai, as far as I'm concerned, you can model using EC's equation already, if you have the time... I'm sure his equations are very close, if not spot on, and even if not, it may show key places to test and otherwise support further testing. E.g., both aliens and XCOM can readily have their relevant values hacked to test for boundary conditions of 0% and 100% success. Plus once it's set up it shouldn't be hard to tweak the equation and voila, the graphs update. But if you don't have the time - eh, it's all volunteer work anyway.<br />
<br />
Eth, I suppose it's possible aliens vs. humans is different. They are known to have some differences in functionality, such as night vision. I don't know if I'll be able to test, but it definitely intrigues me. BTW I said somewhere else that I was looking into automating the XCOM interface in order to do psi testing. I have concluded that I can't do it. At least not the way I was hoping to. Oh well. Still, my belated realization that one can use Unitref[84] to count psi successes is a real boon to repetitive testing. So we'll see. Thanks for suggestions on what to test if I do. By the way, did I do that 83% correct? I just want to make sure I'm doing the math right.<br />
<br />
Thanks re: the flares!<br />
<br />
---[[User:MikeTheRed|MikeTheRed]] 21:08, 3 June 2006 (PDT)<br />
<br />
----<br />
<br />
The influence of distance still needs to be tested, although it doesn't seem to be an enormous factor. Rather than a complicated graph, I think a few charts with distance = 1, 10 and 20 would probably tell the story more clearly. The distance formula might even prove to be something really simple, like +1 distance = -1% chance.<br />
<br />
The hardest aliens to MC are Sectopods and Cyberdiscs: look at the [[Psionics#Summary_of_Alien_Psionic_Resistance]] section I added. At distance 1 on Superhuman you'll need 93 to 192 Attack Strength to achieve 1% to 100% chance. Assuming Psi Str 90, that's Skill 52 to 107.<br />
<br />
Now vs. the strongest attacker: Superhuman Ethereal Commander, attack str 88. You'll need a Resistance of 132 to be totally immune to panics from one adjacent to you -- that's str 100, skill 160, or str 90, skill 210. Against MC, it's str 100/skill 60 or str 90/skill 110. In practice you won't be right next to them, so you can probably go a bit lower. They'll focus on the weakest soldiers anyhow, which in practice means a couple of decoys in with some supertroopers is a good strategy.<br />
<br />
82.6%, yes.<br />
<br />
--[[User:Ethereal Cereal|Ethereal Cereal]] 21:51, 3 June 2006 (PDT)<br />
<br />
OpenOffice.org is CPU-bound when converting the graph from 2D to 3D. [XCOM Psi Str/Sk 90/0-107, alien Psi Str/Sk 25-116/0; I'm on a 1GHz Pentium III/512MB] Not sure how ColdFusion single-IP demo would do yet (would have to reinstall), but the UI options look better in OpenOffice.org.<br />
<br />
I'll attempt the transition later today (when I know I'll be away from the system and positively not working). I just need to be able to take a screenshot.<br />
<br />
You probably already noticed this: even if a bug permitted a 0 Psi Skill operative to use a Psi Amp, the success chance of MC is still negative.<br />
<br />
Also (thinking about the testing anomaly MikeTheRed had): The floating-point change in success rate from an increase of 1 in Psi Skill is 1.9 at 95 Psi Str. Integer truncation would make this 1...leaving the floating-point formula overestimating by 39.6%. At the precision of reporting, this works.<br />
<br />
[Edit: but does *not* work against the initial regression. So, no good.]<br />
<br />
---[[User:Zaimoni|Zaimoni]] 9:51, 4 June 2006 (CDT)<br />
<br />
Got a chance to run the bar graph this morning...no go, OpenOffice.org doesn't like a horde of data points on both axes. <br />
<br />
But...this particular graph is essentially a plane. It should be hand-drawable, even if the more complicated ones aren't.<br />
<br />
---[[User:Zaimoni|Zaimoni]] 8:35, 5 June 2006 (CDT)<br />
<br />
----<br />
<br />
Hi Zaimoni... I'm not sure I understand the differences you talk about. You mean you can get your s/w to make a graph where you've specified the points by hand? Anyway, if you take a shot at most anything, we'd be able to give feedback... a picture's worth a thousand words. Thanks for working on it! ---[[User:MikeTheRed|MikeTheRed]] 06:36, 5 June 2006 (PDT)<br />
<br />
Somewhat. Layer 1 of the spreadsheet is the raw data to be graphed (took about five minutes to set up). If I was going to commit to this representation, I'd go back and make the XCOM Psi Str and Alien Psi Skill configurable. So it's trying to graph data points (the MC success chances) on 0-107 by 25-116. I was planning to rotate the view after getting the initial graph up on Layer 2. [Time loading is not favorable for working further on this today.]<br />
<br />
OpenOffice.org's autoscaling isn't compensating properly. I haven't checked how to suppress the "color key" that was auto-generated for Alien Psi Str &mdash; it's not leaving enough space for the vertical bars to even be 1 pixel in size. The result is decidedly flat, with "correct" vertical range.<br />
<br />
As a bar graph, I could get away with subsampling (but don't have a clean way to do it). Yes, it should be possible to correctly graph this (as a plane in three-dimensional space) with only four data points: the corners.<br />
<br />
---[[User:Zaimoni|Zaimoni]] 12:39, 7 June 2006 (CDT)<br />
<br />
<br />
== Psychic Farm ==<br />
There's a sort of tactic I use which may fit into this article. It's blatant simple: building a base with a couple Living Quarters and as many <br />
Psionic Laboratories as possible, hire the entire population of a small town and get them into psionic training. There may be a pre-selection for soldiers with appalling stats. I don't know what happens to veterans, but in my games by the time I get Psionic Labs money is not a constraint anymore, so I find this industrial breeding quite viable. What do the savvy say about this?--[[User:Trotsky|Trotsky]] 02:40, 11 July 2006 (PDT)<br />
----<br />
Hiya Trotsky,<br />
<br />
That's what I do. You might want to see my info on [[Raw_recruit_statistical_likelihood|recruit statistics]] and [[Hiring/firing]] (esp. the last bullet under General Info). If you get the full 1,000 recruits per month, about 50 will have psi strength of 95+. Taking other stats into consideration, one or two dozen will be top-notch recruits. <br />
<br />
I only have 2 or 3 actual combat squads. One of my less-busy bases serves as initial receiving for batches of ~100 (no psi labs needed), and other un-busy bases get the recruits who made the initial cut farmed out to them, for psi evaluation (lots of psi labs needed).<br />
<br />
FWIW I have an applet that reads a savegame; I run it when a new batch of recruits shows up, and it prints out who to keep based on a prioritization. It's ordered by base and soldier names at that base so I go directly to Sell/Sack and dump the ones that didn't cut it, without needing to look at their stats in the game. Then those guys move on to your "psychic farm" bases for psi evaluation. Before I wrote the applet, I would stick a little plus sign next to the names of the guys to keep as I reviewed them in the Soldier Stats screen, so I'd know who to Sack.<br />
<br />
Because you can only have 250 soldiers max, and some are devoted to combat or other duties, depending on how you draw the line on initial recruit stats (and how hard you want to work at it), plus the fact that psi results only come up at the end of the month and you need to have the next batch on hand for next month's evaluation... this all means that there's actually only ~100 noobs undergoing psi evaluation on any given month. Also, the number of new recruits you order in batches goes down from the beginning of the month to its end, since you only have a window of ~100 to work with initially. At least, that's how it works for me.<br />
<br />
If I run a game a long time, over time what happens is that the bar for psi strength in my 2-3 active combat crews rises over time. Each month, the few high-psi recruits push a few vets below the bar. The best of these vets are farmed out to lesser bases, in case of attack. Of course, any of us could've won long before this point; we're playing just for the joy of play.<br />
<br />
Despite all the above, if a soldier has good psi strength, almost anybody can become a superman, given enough [[Experience#Soldier_Advancement|combat]]. The difference between the worst recruit and the best is only about a dozen combats (assuming they can get 3 actions for firing and reaction each combat).<br />
<br />
---[[User:MikeTheRed|MikeTheRed]] 16:14, 11 July 2006 (PDT)<br />
:I see people creating scripts and stuff to analyse the game files to know who to sack, psi training hundreds of soldiers to finally only keep 2 or 3 guys... All of this is time consuming at best. Why don't you just hex-edit the games file to improve the soldiers? Or hack the game to always show the psi strength, or generate only ubersoldiers? Yeah this would be cheating. But screening 1000 soldiers a month... [[User:Seb76|Seb76]] 03:20, 25 May 2008 (PDT)<br />
<br />
== Suggestions for Psi Defence ==<br />
<br />
The first aim on missions is to pick off as many aliens as possible without them sighting you. With luck you can break their morale before you get a single psi-attack. Once a soldier is seen the aliens will often, but not always, pick off your weakest soldiers mercilesly (I've had a soldier with 83 strenth panicked as the sole attack during a mission, strangely). The second aim is to get your vulnerable soldiers disarmed so they can soak up all the psi-attacks harmlessly. You can do this by getting soldiers to drop everything when they return to your control, making sure weapons are stored on the ground instead of in hand, or stunning and reviving soldiers. Killing a soldier under alien control will only result result in another soldier being targetted. As you can't keep all your soldiers harmless all the time you should use all available cover to make sure that your troops cannot see each other. This reduces the damage if a soldier gets controlled. Don't use explosive weapons. Don't hold primed grenades between turns. Don't use proximity grenades close to your troops and clear any when soldiers panic in their direction. <br />
<br />
Once a mission is completed you can rename the soldiers to record their Psi capability. I'd stick an X on their name, say, for poor defence. Soldiers which look like they have good Psi strength can be marked for training. Soldiers with poor defence will be no use in Cydonia so they can be sacked, used as scouts, or used as decoys on later Psi missions.<br />
<br />
On Psi-attack, I think it's worth mentioning that if you stun an alien while it is under mind control then it will not be captured at the end of the mission. I have lost a commander this way.<br />
<br />
- Egor<br />
<br />
<br />
Xconman...<br />
<br />
Is this how you add your 2cents? I've been playing xcom since PS1. I loved it but hated the load time on it. The PC version was faster but somehow not as good. Anyway, I've found the most successful preventive tactic vs psionics is to not bunch your troops together. If an alien sees you and you don't kill it that turn, it's a sure bet someone will be controlled. (someone may be controlled anyway but it cuts the result by at least half) I've played the game so much the tactical aspect is predicable (so easy) for me except when you have powerful psionics against you so I started to send out 2-3 man squads (spaced apart) toward the target and the rest of my squad spread to the 4 corners of the map. As troops die you send in one or two more troops. I've found that I hardly recieve psionic attacks when I approach the enemy this way.<br />
<br />
<br />
Xconman...<br />
<br />
This is a cheat. On Psionic farming. Create a univeristy base devoted to psionics, say 100 students. Forward the game by not attacking and ignoring everything. See the results of the troops and copy down their names. Restart a day later and expell all "failures" and hire the amount of students equal to vacant spaces. Repeat as often as you have (time) no life for. lol<br />
I've found the cpu registers the psionic power/skill when the charcter is created and not when the month is up. I've had 37 characters with 100 ps str this way in 3 game months. (it took 5 hours off my life though...)<br />
<br />
: You might want to use colons : to indent your paragraphs. Putting a space in front of it is the shortcut for preformatted text - and that has a tendency to look unpleasant depending on your screen settings. Also you can sign your posts by entering four tildes <nowiki>~~~~</nowiki> rather than head it with your username. <br />
<br />
: When a new recruit is hired, psi skill is set to 0, while psi strength is a random roll from 0 to 100. So yes, the strength level is predetermined the moment the soldier is hired. The game only reveals the psi strenth stat when the psi skill stat is greater than 0, which is where the first month in the labs comes in. <br />
<br />
: With a bit of code diving, we've confirmed the 20 turn grace period and the 2-remaining alien condition before psionics are launched. But have we done so with the visual aspect of it? -[[User:NKF|NKF]] 02:01, 25 May 2008 (PDT)<br />
<br />
::NKF: No, seems I somewhat jumped the gun on that one. For what it's worth, I've noticed that the AI gets smarter after about turn 20(what with the noted leaving of the UFO and stalking of your units) as well as a smart AI when only a handful of aliens survived the crash. (This may well be why I've had the lone alien from the small scout ambush my troops on more than one occassion; he knows where they are at all times.) Just my theories. [[User:Arrow Quivershaft|Arrow Quivershaft]] 03:24, 25 May 2008 (PDT)<br />
::The code dig was not related to psi attacks in particular. The game sets the visibility flag to 1 for all XCOM units in the 2 cases you mentionned, no more no less. [[User:Seb76|Seb76]] 03:42, 25 May 2008 (PDT)<br />
::Edit: I did a quick check: the game does not seem to test the visibility flag when searching for a target! If you patch offset 0x469B in the CE edition from 0x02 to 0x03, it _might_ test for it. Feel free to test... [[User:Seb76|Seb76]] 03:57, 25 May 2008 (PDT)<br />
<br />
----<br />
<br />
First of all, I'm a new player, and I've found this website indescribably helpful. Thanks a lot! I have a question about psionics. I'm playing the Steam version, and psionics is not turning out to be the game-breakingly-powerful weapon I've heard it described as. I can never seem to MC more than 1 alien 1 time during a mission. Even a Psi Strength 99 soldier can't grab Sectoid Solders with any reliability. I chalked it up to lack of skill, but find that 1 of the first half-dozen attempts for a single battle works great, and then it never works again. And I have NEVER seen any of my soldiers gain increased Psi Skill, though apparently it's supposed to go up like crazy. I've observed the same phenomenon in TFTD. Am I doing something wrong? I assumed MC was incredibly unreliable, but I don't even bother to use what's supposedly the most powerful ability in the game. And man, I could use it in TFTD right now, that game is rough... <br />
<br />
Thanks a lot, I really appreciate the time you guys put into this.<br />
<br />
--[[User:wfames|wfames]] 2:38, 19 Jan 2009 (EST)<br />
<br />
:Hiya wfames, welcome to the UFOpaedia! Any and all questions or contributions welcomed.<br />
:It sounds like something is definitely wrong. Please see [[Experience#Primary_Stats]]. Even if every Psi attempt fails (MC or Panic), if you try at least 11 times with any one soldier, that soldier's Psi Skill ''must'' go up by 2-6 (average 4) per combat. And a successful attempt counts as 3 tries, so you only need 4 successes to have Psi Skill go up by 2-6. But you're not seeing this? This could be a major problem, if Steam is providing a broken game (and maybe GamersGate too - wouldn't be surprised if they're both selling the same package).<br />
:A problem with the half-dozen of us diehards here (although we pray for many more) is that we have a ton of editors, utilities, and X-COM variations tied into our existing X-COM stuff. So we're hoping, of course, that the new bundles are "same old stuff, no problem". If they're not, it's a can of worms ... we'd have to buy something we already own (perhaps multiple copies of), put it somewhere new, test it out for days or weeks. So this is a black news post you made (or at least, it sounds like one). But hey, we're here to help. :)<br />
:If you don't mind, pop over to [[GEOSCAPE.EXE#X-COM_Complete_Packages]] and make a new "review". Also use the Talk page link there. For the moment, it will probably be better to have any problems or questions in one place (to see if others have the same questions or problems)... later we can diffuse them out to the wiki in general, once we get a feel for whether there are real problems we can nail down and/or easy fixes, etc.<br />
:Thanks again for dropping by. Please come back any time! -[[User:MikeTheRed|MikeTheRed]] 03:58, 19 January 2009 (CST)<br />
<br />
:: What psi skill levels have the soldiers got? Even if their strength levels are high but if the skill levels are low then you won't be getting very frequent successes. You'll want to put several missions worth of psi attempts under your belt before you can really start to hammer the aliens with the good stuff. If you've got a handy alien base nearby, you can send a team of psi troopers there, panic the first alien you see to bits, dust off, check your stats and then repeat the process over and over until you are good enough to use mind control. I recommend the panic attack as it has the highest success probability of the two attacks, and you can have everyone panic the same alien in a single turn - which can't be done with mind control if it succeeds. -[[User:NKF|NKF]] 22:55, 19 January 2009 (CST)<br />
:Good point, NKF. I assumed he'd played a lot, but should have asked. wfames, are you getting Psi to work yet? Your soldiers' Psi skill will increase ~4 points for every combat, if they make at least 11 unsuccessful or 4 successful Psi actions per combat (the [[Mind Probe]] doesn't count). See some [[Psionic_Equations#X-COM_Vs._Aliens|cool numbers I generated]] for a solid handle on when you should be MCing aliens relative to Psi Skill. -[[User:MikeTheRed|MikeTheRed]] 18:31, 23 January 2009 (CST)<br />
<br />
<br />
=== Possibly buggy tactics ===<br />
<br />
2 tactics that may or may not lead to glitches are:<br />
<br />
1) Stunning the mind controlled soldier.<br />
<br />
2) RE- Mind controlling the mind controlled soldier.<br />
<br />
Both of these tactics have unconfirmed rumors of resulting in permanent mind control by the aliens.<br />
<br />
== How a tiny bunch of human civilians beat the aliens at Psionics ==<br />
<br />
Much as I enjoy getting my *ss kicked in X-COM and thus "losing my favourite game", I sympathise with the aliens because they know exactly how I feel. After all the aliens invented Psionics, millions of years ago, built their society around it, presumably optimised their genome as well since they are masters of DNA, and we come along with no prior knowledge and no genetic mastery and hand them their 'nads, using their own pride and joy, Psionics, in a few short months. While a similar point could be made about plasma weapons and UFOs, this astounding fact still begs a little explanation. <br />
<br />
A similarly perplexing question is why X-COM, first and last line of defence of planet Earth, has extremely low field manpower, both initially and long term, and is staffed exclusively with rookies who appear to have no prior combat experience. Surely the world's most powerful governments would be only too willing to put at least some of their elite special forces at the disposal of X-COM - in their own self interest of course? But if you look at the skill gain curves of X-COM operatives, it's clear that these are true rookies. There is nothing odd going in during the Alien Wars that would explain massively accelerated skill growth for already-expert special operations forces (except in the Psi area of course). We have to conclude that X-COM rookies are exactly that, rookies, maybe with basic training but no more. And their initial ranks reflect that. <br />
<br />
Here is a non-canonical background suggestion that ties these two anomalies together neatly. Posit this: initial responses to the alien threat, national forces such as the Kiryu-kai, drew heavily on national military special forces. Initial contact with aliens was a total disaster, massively counterproductive, due to alien use of Psionics. Even without overt use of Psionics against them, military operatives in the field against aliens were overcome by Psionic 'noise', panicking and berserking. Their resistance to direct attack was effectively nil in almost all cases. Hence the advanced military skills of these first extraterrestrial defence units were turned against them, causing grievous destruction in the teams, and perhaps worse. (Perhaps in one or more instances, entire teams of heavily armed mind-controlled elite commandos were flying low, under radar, heading directly for the Kremlin or Diet or White House, and were only stopped by the drastic intervention of air force units).<br />
<br />
The secret knowledge of aliens possessed by some of the CFN governments significantly pre-dates what XCOM troops on the ground would later learn. Knowledge of the aliens and their psionic potential was a closely held secret within need-to-know groups like MJ-12 in the United States for decades prior to the First War. Analysis of the initial tactical failures suggested that defensive psionic screening was a priority by far outweighing any combat ability or military discipline. As a pre-requisite, the entire field force of X-COM would need to be assembled from individuals who had at least basic Psionic resistance. In these days the idea of Psi Lab screening was at best a hypothesis. However, decades of investigations by MJ-12, in the years after Roswell, had identified a genetic component to Psi resistance. A relatively simple DNA test could identify a tiny proportion of the human population who had the potential, at least, to resist alien Psionics - to varying degrees which could not be further tested except under field conditions. But at a minimum, the DNA test selected the very rare individuals who who not succumb to 'ambient' Psionic fields and would at least require a directed attack by an alien. It turns out the distribution of such individuals cut across race and gender, but did to a surprising extent reflect the major players in the CFN and even the apparent major target regions of the alien incursion itself. <br />
<br />
Putting this in the context of the later mythos evolved in X-COM Apocalypse: What if all XCOM operatives in the First and Second Alien Wars are secretly a type of human-sectoid hybrid? Unknown to themselves and all but a few others in the highest reaches of the XCOM hierarchy, or possibly entirely unknown to human governments, who believe this individuals are rare human mutants. In fact, a plausible explanation would be that a rebel Sectoid faction, identifying potential with the human DNA at least for the perpetuation of the barren Sectoid species, and perhaps a new biological weapon to throw off the yoke of the Ethereals once and for all, began introducing Psi-capability genes into human DNA from the earliest contacts - Roswell or earlier. <br />
<br />
Whether the decision to recruit exclusively from hybrids was known to X-COM or the CFN at the time of the First or Second Wars, by the time of Apocalypse, the presence of hybrids in the population was well known and such an openly racist recruitment policy could not be pursued. And of course in the time of Apocalypse we see that 'pure' humans are weak or at very best mediocre Psi operators, and that it is X-COM's hybrids who excel - provided of course they are equipped with artificial psi amplifiers to compensate for what is presumably a deficit of raw psi energy, but no deficit of will or talent once the energy problem is artificially solved. All of which simply suggests that Psi Amps may have been a technological 'plant' by rebel Sectoids or hybrids working within X-COM. <br />
<br />
All pure speculation of course. In fact, anyone considering such things is clearly delusional, a danger to society, and should be confined for the safety of themselves and others. Come this way sir, please don't make a fuss, it will be much easier if you just... look... into... my... MIND...</div>
Spike